ನಾವು ಒಂದು LLM ಗೆ ಟೆರಾಬೈಟ್‌ಗಳಷ್ಟು CI ಲಾಗ್‌ಗಳನ್ನು ನೀಡಿದ್ದೇವೆ

ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಅಡಗಿರುವ ಚಿನ್ನದ ಗಣಿ

ಪ್ರತಿ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಅವುಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಲಕ್ಷಾಂತರ ಸಾಲುಗಳು, ಪ್ರತಿ ದಿನವೂ - ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು, ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್‌ಗಳು, ಅವಲಂಬನೆ ರೆಸಲ್ಯೂಶನ್‌ಗಳು, ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು, ಕಲಾಕೃತಿಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ರಹಸ್ಯ ದೋಷ ಸಂದೇಶಗಳು ಯಾರಾದರೂ ಓದುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿ ಸ್ಕ್ರಾಲ್ ಮಾಡುತ್ತವೆ. CI ಲಾಗ್‌ಗಳು ಆಧುನಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ನಿಷ್ಕಾಸ ಹೊಗೆಗಳಾಗಿವೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಸ್ಥೆಗಳಿಗೆ, ಅವುಗಳನ್ನು ನಿಖರವಾಗಿ ನಿಷ್ಕಾಸದಂತೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ: ಶೇಖರಣೆಯಲ್ಲಿ ಹೊರಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಮರೆತುಹೋಗುತ್ತದೆ. ಆದರೆ ಆ ಲಾಗ್‌ಗಳು ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸುವ ಮೊದಲು ಊಹಿಸಬಹುದಾದ ನಮೂನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಪ್ರತಿ ತ್ರೈಮಾಸಿಕಕ್ಕೆ ನೂರಾರು ಗಂಟೆಗಳ ವೆಚ್ಚದ ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಯಾವುದೇ ಇಂಜಿನಿಯರ್‌ಗಳು ನೋಡದ ವ್ಯವಸ್ಥಿತ ಸಮಸ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಿದರೆ ಏನು? ನಾವು ಟೆರಾಬೈಟ್‌ಗಳಷ್ಟು CI ಲಾಗ್ ಡೇಟಾವನ್ನು ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗೆ ಫೀಡ್ ಮಾಡುವ ಮೂಲಕ ಕಂಡುಹಿಡಿಯಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - ಮತ್ತು ನಾವು ಕಂಡುಹಿಡಿದದ್ದು ನಾವು DevOps ಬಗ್ಗೆ ಹೇಗೆ ಯೋಚಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಿದೆ.

ಸಾಫ್ಟ್‌ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್‌ನಲ್ಲಿ CI ಲಾಗ್‌ಗಳು ಏಕೆ ಹೆಚ್ಚು ಬಳಕೆಯಾಗದ ಡೇಟಾ

ಪರಿಪೂರ್ಣ ಪರಿಮಾಣವನ್ನು ಪರಿಗಣಿಸಿ. ಬಹು ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ದಿನಕ್ಕೆ 200 ಬಿಲ್ಡ್‌ಗಳನ್ನು ನಡೆಸುತ್ತಿರುವ ಮಧ್ಯಮ ಗಾತ್ರದ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಪ್ರತಿದಿನ ಸರಿಸುಮಾರು 2-4 GB ಕಚ್ಚಾ ಲಾಗ್ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಒಂದು ವರ್ಷದಲ್ಲಿ, ಅದು ಪ್ರತಿ ಸಂಕಲನ, ಪ್ರತಿ ಪರೀಕ್ಷಾ ಸೂಟ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಪ್ರತಿ ನಿಯೋಜನೆ ಹಂತ ಮತ್ತು ನಿಮ್ಮ ಸಿಸ್ಟಂ ಇದುವರೆಗೆ ಎದುರಿಸಿದ ಪ್ರತಿ ವೈಫಲ್ಯ ಮೋಡ್ ಅನ್ನು ಸೆರೆಹಿಡಿಯುವ ರಚನಾತ್ಮಕ ಮತ್ತು ಅರೆ-ರಚನಾತ್ಮಕ ಪಠ್ಯದ ಒಂದು ಟೆರಾಬೈಟ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು. ಇದು ನಿಮ್ಮ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಥೆಯ ಉತ್ಪಾದಕತೆಯ ಸಂಪೂರ್ಣ ಪುರಾತತ್ತ್ವ ಶಾಸ್ತ್ರದ ದಾಖಲೆಯಾಗಿದೆ - ಮತ್ತು ಬಹುತೇಕ ಯಾರೂ ಅದನ್ನು ಓದುವುದಿಲ್ಲ.

ಸಮಸ್ಯೆಯು ಡೇಟಾವು ಮೌಲ್ಯದ ಕೊರತೆಯಲ್ಲ. ಸಿಗ್ನಲ್-ಟು-ಶಬ್ದ ಅನುಪಾತವು ಕ್ರೂರವಾಗಿದೆ. ಒಂದು ವಿಶಿಷ್ಟವಾದ CI ರನ್ ಔಟ್‌ಪುಟ್‌ನ ಸಾವಿರಾರು ಸಾಲುಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಆ ಸಾಲುಗಳಲ್ಲಿ 3-5 ಕ್ರಿಯಾಶೀಲ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರಬಹುದು. ಇಂಜಿನಿಯರ್‌ಗಳು ಕೆಂಪು ಪಠ್ಯಕ್ಕಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಕಲಿಯುತ್ತಾರೆ, "ವಿಫಲವಾಗಿದೆ" ಗಾಗಿ grep, ಮತ್ತು ಮುಂದುವರಿಯಿರಿ. ಆದರೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ಮಾದರಿಗಳು - ಪ್ರತಿ ಮಂಗಳವಾರ ವಿಫಲವಾಗುವ ಫ್ಲಾಕಿ ಪರೀಕ್ಷೆ, ಪ್ರತಿ ಬಿಲ್ಡ್‌ಗೆ 40 ಸೆಕೆಂಡುಗಳನ್ನು ಸೇರಿಸುವ ಅವಲಂಬನೆ, ಮೂರು ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಳು ಏಕಕಾಲದಲ್ಲಿ ಚಲಿಸಿದಾಗ ಮಾತ್ರ ಮೇಲ್ಮೈಯಾಗುವ ಮೆಮೊರಿ ಸೋರಿಕೆ - ಆ ಮಾದರಿಗಳು ವೈಯಕ್ತಿಕ ಲಾಗ್ ಮಟ್ಟದಲ್ಲಿ ಅಗೋಚರವಾಗಿರುತ್ತವೆ. ಅವು ಪ್ರಮಾಣದಲ್ಲಿ ಮಾತ್ರ ಹೊರಹೊಮ್ಮುತ್ತವೆ.

ELK ಸ್ಟ್ಯಾಕ್‌ಗಳು ಮತ್ತು ಡೇಟಾಡಾಗ್‌ನಂತಹ ಸಾಂಪ್ರದಾಯಿಕ ಲಾಗ್ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳು ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಮೇಲ್ಮೈ ಕೀವರ್ಡ್ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಬಹುದು, ಆದರೆ ಅವು CI ಔಟ್‌ಪುಟ್‌ನ ಶಬ್ದಾರ್ಥದ ಸಂಕೀರ್ಣತೆಯೊಂದಿಗೆ ಹೋರಾಡುತ್ತವೆ. "ಪೋರ್ಟ್ 5432 ನಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸಲಾಗಿದೆ" ಮತ್ತು "ಮಾರಕ: ಬಳಕೆದಾರ 'ನಿಯೋಜನೆ'ಗಾಗಿ ಪಾಸ್‌ವರ್ಡ್ ದೃಢೀಕರಣ ವಿಫಲವಾಗಿದೆ" ಎಂದು ಓದುವ ಬಿಲ್ಡ್ ವೈಫಲ್ಯದ ಸಂದೇಶವು ಎರಡೂ ಡೇಟಾಬೇಸ್-ಸಂಬಂಧಿತ ವೈಫಲ್ಯಗಳಾಗಿವೆ, ಆದರೆ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಮೂಲ ಕಾರಣಗಳು ಮತ್ತು ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿವೆ. ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇತ್ತೀಚಿನವರೆಗೂ ಮಾನವರು ಮಾತ್ರ ಒದಗಿಸಬಹುದಾದ ಸಂದರ್ಭೋಚಿತ ತಾರ್ಕಿಕತೆಯ ಅಗತ್ಯವಿದೆ.

ಪ್ರಯೋಗ: 3.2 ಟೆರಾಬೈಟ್‌ಗಳಷ್ಟು ಬಿಲ್ಡ್ ಹಿಸ್ಟರಿಯನ್ನು LLM ಗೆ ನೀಡುವುದು

ಸೆಟಪ್ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ ನೇರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮರಣದಂಡನೆಯಲ್ಲಿ ದುಃಸ್ವಪ್ನವಾಗಿತ್ತು. 138,000 ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಿಂದ ನಾವು 14 ತಿಂಗಳ CI ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ - ಬಹು ಸೇವೆಗಳು, ಪರಿಸರಗಳು ಮತ್ತು ನಿಯೋಜನೆ ಗುರಿಗಳಾದ್ಯಂತ ಬಿಲ್ಡ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಕಚ್ಚಾ ಡೇಟಾಸೆಟ್ 3.2 ಟೆರಾಬೈಟ್‌ಗಳಿಗೆ ಬಂದಿದೆ: ಸುಮಾರು 847 ಮಿಲಿಯನ್ ವೈಯಕ್ತಿಕ ಲಾಗ್ ಲೈನ್‌ಗಳು 1.6 ಮಿಲಿಯನ್ CI ಪೈಪ್‌ಲೈನ್ ರನ್‌ಗಳನ್ನು ವ್ಯಾಪಿಸುತ್ತವೆ. ನಾವು ಈ ಡೇಟಾವನ್ನು ಭಾಗಗೊಳಿಸಿದ್ದೇವೆ, ಎಂಬೆಡ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಸೂಚಿಕೆ ಮಾಡಿದ್ದೇವೆ, ನಂತರ ನಮ್ಮ ನಿರ್ಮಾಣ ಇತಿಹಾಸದ ಕುರಿತು ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬಹುದಾದ ಮರುಪಡೆಯುವಿಕೆ-ವರ್ಧಿತ ಪೀಳಿಗೆಯ (RAG) ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ.

ಮೊದಲ ಸವಾಲು ಪೂರ್ವ ಸಂಸ್ಕರಣೆಯಾಗಿತ್ತು. CI ಲಾಗ್‌ಗಳು ಶುದ್ಧ ಪಠ್ಯವಲ್ಲ. ಅವುಗಳು ಎಎನ್‌ಎಸ್‌ಐ ಬಣ್ಣದ ಕೋಡ್‌ಗಳು, ತಮ್ಮನ್ನು ತಾವೇ ತಿದ್ದಿ ಬರೆಯುವ ಪ್ರಗತಿ ಬಾರ್‌ಗಳು, ಬೈನರಿ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಚೆಕ್‌ಸಮ್‌ಗಳು ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಯಾವ ಸಾಧನವು ಉತ್ಪಾದಿಸಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಕನಿಷ್ಠ ನಾಲ್ಕು ವಿಭಿನ್ನ ಸ್ವರೂಪಗಳಲ್ಲಿ ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಾವು ಕೇವಲ ಸಾಮಾನ್ಯೀಕರಣಕ್ಕಾಗಿ ಮೂರು ವಾರಗಳನ್ನು ಕಳೆದಿದ್ದೇವೆ - ಶಬ್ದವನ್ನು ತೆಗೆದುಹಾಕುವುದು, ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವುದು ಮತ್ತು ಪ್ರತಿ ಲಾಗ್ ವಿಭಾಗವನ್ನು ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಟ್ಯಾಗ್ ಮಾಡುವುದು ಪೈಪ್‌ಲೈನ್ ಹಂತ, ರೆಪೊಸಿಟರಿ, ಶಾಖೆ ಮತ್ತು ಪರಿಸರಕ್ಕೆ ಸೇರಿದೆ.

ಎರಡನೆಯ ಸವಾಲು ವೆಚ್ಚವಾಗಿತ್ತು. ಟೆರಾಬೈಟ್‌ಗಳ ಪಠ್ಯದ ಮೇಲೆ ನಿರ್ಣಯವನ್ನು ನಡೆಸುವುದು ಅಗ್ಗವಲ್ಲ, ಆಕ್ರಮಣಕಾರಿ ಚಂಕಿಂಗ್ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನೊಂದಿಗೆ ಸಹ. ನಮ್ಮ ಆರಂಭಿಕ ವಿಧಾನವು ತುಂಬಾ ನಿಷ್ಕಪಟವಾಗಿರುವುದರಿಂದ - ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭವನ್ನು ಕಳುಹಿಸುವುದು ಮತ್ತು ಯಾವ ಲಾಗ್ ವಿಭಾಗಗಳು ಪ್ರಸ್ತುತವಾಗಿವೆ ಎಂಬುದರ ಕುರಿತು ಸಾಕಷ್ಟು ಆಯ್ಕೆ ಮಾಡದ ಕಾರಣ ನಾವು ಮೊದಲ ತಿಂಗಳಲ್ಲೇ ಗಮನಾರ್ಹವಾದ ಕಂಪ್ಯೂಟ್ ಕ್ರೆಡಿಟ್‌ಗಳ ಮೂಲಕ ಬರೆಯುತ್ತೇವೆ. ಎರಡನೇ ತಿಂಗಳ ಅಂತ್ಯದ ವೇಳೆಗೆ, ಉತ್ತಮ ಎಂಬೆಡಿಂಗ್ ತಂತ್ರಗಳು ಮತ್ತು ಎರಡು-ಹಂತದ ಮರುಪಡೆಯುವಿಕೆ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ನಾವು ಪ್ರತಿ ಪ್ರಶ್ನೆಯ ವೆಚ್ಚವನ್ನು 87% ರಷ್ಟು ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ದೊಡ್ಡದಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು ಪೂರ್ವ-ಫಿಲ್ಟರ್ ಮಾಡಲು ಸಣ್ಣ ಮಾದರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ.

ಮನುಷ್ಯರು ಎಂದಿಗೂ ಬಯಸದ LLM ಕಂಡುಬಂದ ಐದು ಮಾದರಿಗಳು

ಪ್ರಶ್ನೆಗಳ ಚಾಲನೆಯ ಮೊದಲ ವಾರದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಒಳನೋಟಗಳನ್ನು ಹೊರತಂದಿದೆ, ಅದು ಮಾನವ ವಿಶ್ಲೇಷಕರಿಗೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇವು ಎಡ್ಜ್ ಕೇಸ್‌ಗಳು ಅಥವಾ ಕುತೂಹಲಗಳಾಗಿರಲಿಲ್ಲ - ಅವು ನೈಜ ಇಂಜಿನಿಯರಿಂಗ್ ಗಂಟೆಗಳ ರಕ್ತಸ್ರಾವದ ವ್ಯವಸ್ಥಿತ ಸಮಸ್ಯೆಗಳಾಗಿವೆ.

<ಓಲ್>

ಫ್ಯಾಂಟಮ್ ಅವಲಂಬನೆ ಕ್ಯಾಸ್ಕೇಡ್. 9 ತಿಂಗಳ ಮೊದಲು ಒಂದೇ npm ಪ್ಯಾಕೇಜ್ ನವೀಕರಣವು ಪ್ರತಿ JavaScript ಬಿಲ್ಡ್‌ಗೆ 22-ಸೆಕೆಂಡ್ ವಿಳಂಬವನ್ನು ಪರಿಚಯಿಸಿದೆ. ವಿಳಂಬವನ್ನು ಮರೆಮಾಚಲಾಗಿದೆ ಏಕೆಂದರೆ ಇದು CI ಮೂಲಸೌಕರ್ಯ ಅಪ್‌ಗ್ರೇಡ್‌ನೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಯಿತು, ಅದು ಒಟ್ಟಾರೆಯಾಗಿ ನಿರ್ಮಾಣಗಳನ್ನು ವೇಗವಾಗಿ ಮಾಡುತ್ತದೆ. ನೆಟ್-ನೆಟ್, ಬಿಲ್ಡ್‌ಗಳು ವೇಗವಾಗಿ ಕಾಣಿಸಿಕೊಂಡವು, ಆದರೆ ಅವು ಇನ್ನೂ 22 ಸೆಕೆಂಡುಗಳಷ್ಟು ವೇಗವಾಗಿರಬಹುದು. ದಿನಕ್ಕೆ 400+ JS ಬಿಲ್ಡ್‌ಗಳು, ಅದು ಪ್ರತಿದಿನ 2.4 ಗಂಟೆಗಳ ವ್ಯರ್ಥ ಕಂಪ್ಯೂಟ್ ಆಗಿದೆ.

ಸಮಯವಲಯ ಫ್ಲೇಕ್. ಪರೀಕ್ಷಾ ಸೂಟ್ 4.7% ವೈಫಲ್ಯದ ದರವನ್ನು ಹೊಂದಿದೆ - ಕಿರಿಕಿರಿಗೊಳಿಸುವಷ್ಟು ಹೆಚ್ಚು, ಅದನ್ನು ಸರಿಪಡಿಸಲು ಯಾರೂ ಆದ್ಯತೆ ನೀಡದಿರುವಷ್ಟು ಕಡಿಮೆ. ದಿನಾಂಕ-ಹೋಲಿಕೆ ಕಾರ್ಯವು ದಿನದ ಗಡಿಯನ್ನು ದಾಟಿದಾಗ 23:00 ಮತ್ತು 01:00 UTC ನಡುವೆ ಪ್ರಚೋದಿತ ಬಿಲ್ಡ್‌ಗಳೊಂದಿಗೆ ವೈಫಲ್ಯಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ ಎಂದು LLM ಗುರುತಿಸಿದೆ. ಎರಡು-ಸಾಲಿನ ಫಿಕ್ಸ್ ಫ್ಲೇಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಿತು.

ಮೂಕ ರೋಲ್‌ಬ್ಯಾಕ್ ಪ್ಯಾಟರ್ನ್. ವೇದಿಕೆಯ ನಿಯೋಜನೆಗಳು 99.2% ಸಮಯ ಯಶಸ್ವಿಯಾಗಿದೆ, ಆದರೆ 31% "ಯಶಸ್ವಿ" ಸ್ಟೇಜಿಂಗ್ ನಿಯೋಜನೆಗಳನ್ನು 45 ನಿಮಿಷಗಳಲ್ಲಿ ಅದೇ ಸೇವೆಯ ಮತ್ತೊಂದು ನಿಯೋಜನೆಯು ಅನುಸರಿಸಿದೆ ಎಂದು LLM ಗಮನಿಸಿದೆ - ಎಲ್ಲಾ ಚೆಕ್‌ಗಳನ್ನು ರವಾನಿಸಿದರೂ ಮೊದಲ ನಿಯೋಜನೆಯು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಮುರಿದುಹೋಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಇದು ಅಣಕು ಸೇವೆಯಿಂದ ಸಂಗ್ರಹವಾದ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಂದಾಗಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಯು ಉತ್ತೀರ್ಣವಾಗುತ್ತಿದೆ ಎಂದು ಪತ್ತೆಹಚ್ಚಲು ಕಾರಣವಾಯಿತು.

ಸೋಮವಾರ ಬೆಳಗಿನ ಅಡಚಣೆ. ಪ್ರತಿ ಸೋಮವಾರ ಸ್ಥಳೀಯ ಸಮಯ 9:00 ಮತ್ತು 10:30 AM ನಡುವೆ ಬಿಲ್ಡ್ ಕ್ಯೂ ಸಮಯವು 340% ಹೆಚ್ಚಾಗಿದೆ, ಏಕೆಂದರೆ ವಾರಾಂತ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ಟ್ಯಾಂಡ್‌ಅಪ್‌ಗೆ ಮುಂಚಿತವಾಗಿ ತಳ್ಳಿದರು. ಫಿಕ್ಸ್ ತಾಂತ್ರಿಕವಾಗಿರಲಿಲ್ಲ - ಇದು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿತ್ತು: ಸೋಮವಾರದ ಉಲ್ಬಣಗಳನ್ನು ನಿರೀಕ್ಷಿಸಲು CI ರನ್ನರ್ ಪೂಲ್ ಸ್ಕೇಲಿಂಗ್ ವೇಳಾಪಟ್ಟಿಯನ್ನು ದಿಗ್ಭ್ರಮೆಗೊಳಿಸುವುದು.

ಯಾರೂ ಹೊಂದಿಸದ ಕಂಪೈಲರ್ ಫ್ಲ್ಯಾಗ್. 67% C++ ಬಿಲ್ಡ್‌ಗಳು ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಕಲನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸದೆ ಚಾಲನೆಯಲ್ಲಿವೆ, ಪ್ರತಿ ಬಿಲ್ಡ್‌ಗೆ ಸರಾಸರಿ 3.8 ನಿಮಿಷಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಆನ್‌ಬೋರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ ಆದರೆ ಹಂಚಿಕೊಂಡ CI ಕಾನ್ಫಿಗರೇಶನ್ ಟೆಂಪ್ಲೇಟ್‌ಗೆ ಎಂದಿಗೂ ಸೇರಿಸಲಾಗಿಲ್ಲ.

"ಅತ್ಯಂತ ದುಬಾರಿ ಬಗ್‌ಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುವವುಗಳಲ್ಲ. ಅವುಗಳು ಪ್ರತಿ ಬಿಲ್ಡ್‌ನಿಂದ 30 ಸೆಕೆಂಡುಗಳನ್ನು ಪ್ರತಿ ದಿನ, ವರ್ಷಗಳವರೆಗೆ ಕದಿಯುತ್ತವೆ - ಯಾರಾದರೂ ಅಂತಿಮವಾಗಿ ಸರಿಯಾದ ಡೇಟಾಸೆಟ್‌ನ ಸರಿಯಾದ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವವರೆಗೆ."

ಪ್ರಾಕ್ಟಿಕಲ್ CI ಇಂಟೆಲಿಜೆನ್ಸ್ ಲೇಯರ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು

ಎಲ್‌ಎಲ್‌ಎಂ-ಚಾಲಿತ ಲಾಗ್ ವಿಶ್ಲೇಷಣೆಯು ನವೀನತೆಯಲ್ಲ - ಇದು ನಿಜವಾದ ಕಾರ್ಯಾಚರಣೆಯ ಸಾಮರ್ಥ್ಯ ಎಂದು ಪ್ರಯೋಗವು ನಮಗೆ ಮನವರಿಕೆ ಮಾಡಿದೆ. ಆದರೆ ಅದನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಮಾಡಲು ಚಿಂತನಶೀಲ ವಾಸ್ತುಶಿಲ್ಪದ ಅಗತ್ಯವಿದೆ. ನೀವು ಕೇವಲ ಚಾಟ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಕಚ್ಚಾ ಲಾಗ್‌ಗಳನ್ನು ಪೈಪ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಉಪಯುಕ್ತ ಉತ್ತರಗಳನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು. ಸಿಸ್ಟಮ್‌ಗೆ ರಚನೆಯ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಎಂಜಿನಿಯರ್‌ಗಳು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿರುವ ವರ್ಕ್‌ಫ್ಲೋಸ್‌ಗೆ ಅದನ್ನು ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ.

ನಾವು ಮೂರು ಹಂತದ ವಿಧಾನದಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ. ಮೊದಲ ಹಂತವು ಸ್ವಯಂಚಾಲಿತ ಚಿಕಿತ್ಸೆಯ ಸರದಿ ನಿರ್ಧಾರವಾಗಿದೆ: ಪ್ರತಿ ವಿಫಲ ನಿರ್ಮಾಣವನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಸ್ಕೋರ್‌ನೊಂದಿಗೆ ಮೂಲ ಕಾರಣ ವರ್ಗದಿಂದ (ಮೂಲಸೌಕರ್ಯ, ಅವಲಂಬನೆ, ಪರೀಕ್ಷಾ ತರ್ಕ, ಕಾನ್ಫಿಗರೇಶನ್ ಅಥವಾ ಫ್ಲೇಕ್) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವರ್ಗೀಕರಿಸಲಾಗುತ್ತದೆ. ಇದು ಕೇವಲ ಬಿಲ್ಡ್ ವೈಫಲ್ಯಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸರಾಸರಿ ಸಮಯವನ್ನು 34% ರಷ್ಟು ಕಡಿಮೆಗೊಳಿಸಿತು, ಏಕೆಂದರೆ ಎಂಜಿನಿಯರ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಲಾಗ್‌ಗಳನ್ನು ಓದಲು 10 ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಬೇಕಾಗಿಲ್ಲ. ಎರಡನೆಯ ಹಂತವೆಂದರೆ ಟ್ರೆಂಡ್ ಪತ್ತೆ: ಉದಯೋನ್ಮುಖ ಮಾದರಿಗಳನ್ನು ಮೇಲ್ಮೈ ಮಾಡುವ ಸಾಪ್ತಾಹಿಕ ಡೈಜೆಸ್ಟ್ - ಹೆಚ್ಚುತ್ತಿರುವ ವೈಫಲ್ಯದ ದರಗಳು, ಬೆಳೆಯುತ್ತಿರುವ ಬಿಲ್ಡ್ ಸಮಯಗಳು, ಹೊಸ ದೋಷ ಸಹಿಗಳು - ಅವುಗಳು ನಿರ್ಣಾಯಕವಾಗುವ ಮೊದಲು. ಮೂರನೇ ಹಂತವು ಇಂಟರಾಕ್ಟಿವ್ ತನಿಖೆಯಾಗಿದೆ: ಇಂಜಿನಿಯರ್‌ಗಳು ಇತಿಹಾಸ ನಿರ್ಮಿಸುವ ಕುರಿತು ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದಾದ ಇಂಟರ್‌ಫೇಸ್, "ಮಾರ್ಚ್ ಬಿಡುಗಡೆಯ ನಂತರ ಸೇವೆ X ಏಕೆ ಹೆಚ್ಚಾಗಿ ವಿಫಲವಾಗಿದೆ?" ಅಥವಾ "ಪಾವತಿ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಸಮಯ ಮೀರುವ ದೋಷಗಳ ಸಾಮಾನ್ಯ ಕಾರಣವೇನು?"

ಸಂಕೀರ್ಣ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಡೆಸುತ್ತಿರುವ ತಂಡಗಳಿಗೆ - ವಿಶೇಷವಾಗಿ CRM, ಇನ್‌ವಾಯ್ಸಿಂಗ್, ವೇತನದಾರರ ಪಟ್ಟಿ, ಮತ್ತು 207 ಇಂಟಿಗ್ರೇಟೆಡ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡುವ Mewayz ನಂತಹ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಮೂಲಕ ಅನೇಕ ವ್ಯವಹಾರ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವವರಿಗೆ - ಈ ರೀತಿಯ ವೀಕ್ಷಣೆಯು ಇನ್ನಷ್ಟು ನಿರ್ಣಾಯಕವಾಗುತ್ತದೆ. ಒಂದೇ ನಿಯೋಜನೆಯು ಗ್ರಾಹಕರು ಎದುರಿಸುತ್ತಿರುವ ಕೆಲಸದ ಹರಿವುಗಳು, ಬಿಲ್ಲಿಂಗ್ ತರ್ಕ ಮತ್ತು ಮಾನವ ಸಂಪನ್ಮೂಲ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸ್ಪರ್ಶಿಸಿದಾಗ, ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿನ ಪರಸ್ಪರ ಅವಲಂಬನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಐಚ್ಛಿಕವಾಗಿರುವುದಿಲ್ಲ. 138,000+ ಬಳಕೆದಾರರು ಅವಲಂಬಿಸಿರುವ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಇದು ಅತ್ಯಗತ್ಯ.

ಏನು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ (ಇನ್ನೂ)

ಪ್ರಚೋದನೆಗಿಂತ ಪ್ರಾಮಾಣಿಕತೆ ಮುಖ್ಯವಾಗಿದೆ. ಈ ವಿಧಾನಕ್ಕೆ ಸ್ಪಷ್ಟ ಮಿತಿಗಳಿವೆ, ಅದನ್ನು ಪರಿಗಣಿಸುವ ಯಾರಾದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. LLM ಗಳು ಭ್ರಮೆಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು CI ಲಾಗ್‌ಗಳ ಬಗ್ಗೆ ಅವರು ಭ್ರಮೆಗೊಳಿಸಿದಾಗ, ಫಲಿತಾಂಶಗಳು ಮನವರಿಕೆಯಾಗುವಂತೆ ತಪ್ಪಾಗಿರಬಹುದು. ಎಂದಿಗೂ ಅಸ್ತಿತ್ವದಲ್ಲಿರದ, ಫ್ಯಾಬ್ರಿಕೇಟೆಡ್ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾದ ಅವಲಂಬನೆ ಸಂಘರ್ಷಕ್ಕೆ ಬಿಲ್ಡ್ ವೈಫಲ್ಯವನ್ನು ಸಿಸ್ಟಂ ವಿಶ್ವಾಸದಿಂದ ಆರೋಪಿಸಿದೆ ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. RAG ಪೈಪ್‌ಲೈನ್ ಇದನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇದು ಅದನ್ನು ತೊಡೆದುಹಾಕುವುದಿಲ್ಲ. ಸಿಸ್ಟಂ ಉತ್ಪಾದಿಸುವ ಪ್ರತಿಯೊಂದು ಒಳನೋಟವು ಇನ್ನೂ ಕ್ರಿಯೆಯ ಮೊದಲು ಮಾನವ ಪರಿಶೀಲನೆಯ ಅಗತ್ಯವಿದೆ.

ಸ್ಕೇಲ್ ಒಂದು ಸವಾಲಾಗಿ ಉಳಿದಿದೆ. ಮರುಪಡೆಯುವಿಕೆ ವ್ಯವಸ್ಥೆಯು ಪ್ರಶ್ನೆಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ನಿಭಾಯಿಸಬಹುದಾದರೂ, ಹೊಸ ಲಾಗ್‌ಗಳ ಆರಂಭಿಕ ಸೂಚಿಕೆ ಮತ್ತು ಎಂಬೆಡಿಂಗ್ ಕಂಪ್ಯೂಟೇಶನಲ್ ಆಗಿ ದುಬಾರಿಯಾಗಿದೆ. ನಾವು ಪ್ರತಿದಿನ ಸರಿಸುಮಾರು 800,000 ಹೊಸ ಲಾಗ್ ಲೈನ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಸೂಚ್ಯಂಕವನ್ನು ತಾಜಾವಾಗಿಡಲು ಮೀಸಲಾದ ಮೂಲಸೌಕರ್ಯದ ಅಗತ್ಯವಿದೆ. ಸಣ್ಣ ತಂಡಗಳಿಗೆ, ವೆಚ್ಚ-ಲಾಭದ ಲೆಕ್ಕಾಚಾರವು ಈ ವಿಧಾನವನ್ನು ಬೆಂಬಲಿಸದಿರಬಹುದು - ಕನಿಷ್ಠ ಇನ್ನೂ ಅಲ್ಲ. ಮಾದರಿ ವೆಚ್ಚಗಳು ಕಡಿಮೆಯಾಗುತ್ತಿರುವುದರಿಂದ (ಸಮಾನ ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ ಕಳೆದ 18 ತಿಂಗಳುಗಳಲ್ಲಿ ಅವು ಸರಿಸುಮಾರು 90% ರಷ್ಟು ಕುಸಿದಿವೆ), ಅರ್ಥಶಾಸ್ತ್ರವು ಬದಲಾಗುತ್ತದೆ.

ಭದ್ರತೆಯ ಪ್ರಶ್ನೆಯೂ ಇದೆ. CI ಲಾಗ್‌ಗಳು ರಹಸ್ಯಗಳನ್ನು ಹೊಂದಿರಬಹುದು - API ಕೀಗಳು, ಸಂಪರ್ಕ ತಂತಿಗಳು, ಆಂತರಿಕ URL ಗಳು - ಅವುಗಳನ್ನು ಸ್ಕ್ರಬ್ ಮಾಡಲು ಉತ್ತಮ ಪ್ರಯತ್ನಗಳ ಹೊರತಾಗಿಯೂ. ಬಾಹ್ಯ LLM API ಗಳಿಗೆ ಈ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದು ಅಪಾಯವನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. ನಾವು ಇದನ್ನು ಸ್ಥಳೀಯ ಸ್ಕ್ರಬ್ಬಿಂಗ್ ಪೈಪ್‌ಲೈನ್‌ನೊಂದಿಗೆ ತಗ್ಗಿಸುತ್ತೇವೆ ಮತ್ತು ಸೂಕ್ಷ್ಮವಾದ ರೆಪೊಸಿಟರಿಗಳಿಗಾಗಿ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಮಾದರಿಗಳ ಮೇಲೆ ನಿರ್ಣಯವನ್ನು ರನ್ ಮಾಡುವ ಮೂಲಕ, ಆದರೆ ಇದು ಸಂಕೀರ್ಣತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಇದೇ ರೀತಿಯ ಯಾವುದನ್ನಾದರೂ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ತಂಡಗಳು ತಮ್ಮ ಬೆದರಿಕೆ ಮಾದರಿಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು.

ಟೆರಾಬೈಟ್‌ಗಳಿಲ್ಲದೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ

ನಿಮ್ಮ CI ಲಾಗ್‌ಗಳಿಂದ ಮೌಲ್ಯವನ್ನು ಹೊರತೆಗೆಯಲು ಪ್ರಾರಂಭಿಸಲು ನಿಮಗೆ ಬೃಹತ್ ಡೇಟಾಸೆಟ್ ಅಥವಾ ಮೀಸಲಾದ ML ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡ ಅಗತ್ಯವಿಲ್ಲ. ವಾರಕ್ಕೆ ಕೆಲವು ನೂರು ನಿರ್ಮಾಣಗಳನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ತಂಡವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಪ್ರಾಯೋಗಿಕ ಆರಂಭದ ಹಂತ ಇಲ್ಲಿದೆ:

• ವೈಫಲ್ಯ ವರ್ಗೀಕರಣದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ನಿಮ್ಮ ಕಳೆದ 90 ದಿನಗಳ ವಿಫಲ ಬಿಲ್ಡ್ ಲಾಗ್‌ಗಳನ್ನು ರಫ್ತು ಮಾಡಿ. ಪ್ರತಿಯೊಂದು ವೈಫಲ್ಯವನ್ನು ವರ್ಗಗಳಾಗಿ ವರ್ಗೀಕರಿಸಲು ಯಾವುದೇ LLM API ಅನ್ನು ಬಳಸಿ. ಸರಳವಾದ ಟ್ಯಾಕ್ಸಾನಮಿ (ಇನ್‌ಫ್ರಾ ವರ್ಸಸ್ ಕೋಡ್ ವರ್ಸಸ್. ಕಾನ್ಫಿಗ್ ವರ್ಸಸ್. ಫ್ಲೇಕ್) ಕೂಡ ಆದ್ಯತೆಗೆ ತಕ್ಷಣದ ಮೌಲ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.
• ಬಿಲ್ಡ್ ಅವಧಿಯ ಟ್ರೆಂಡ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಪ್ರತಿ ಪೈಪ್‌ಲೈನ್ ಹಂತಕ್ಕೆ ಬಿಲ್ಡ್ ಅವಧಿಗಳ ಸಮಯ-ಸರಣಿಯನ್ನು ರಚಿಸಲು ನಿಮ್ಮ ಲಾಗ್‌ಗಳಿಂದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ. ಸುತ್ತಮುತ್ತಲಿನ ಲಾಗ್ ಸಂದರ್ಭದೊಂದಿಗೆ LLM ಗೆ ವೈಪರೀತ್ಯಗಳನ್ನು ಫೀಡ್ ಮಾಡಿ ಮತ್ತು ಮೂಲ ಕಾರಣದ ಊಹೆಗಳನ್ನು ಕೇಳಿ.
• "ಸ್ಪಷ್ಟ" ಪ್ರಶ್ನೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ. ವಿಫಲವಾದ ಬಿಲ್ಡ್‌ನ ಕೊನೆಯ 500 ಸಾಲುಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್‌ನೊಂದಿಗೆ LLM ಗೆ ಕಳುಹಿಸುವ ನಂತರದ ವೈಫಲ್ಯದ ಹುಕ್ ಅನ್ನು ಹೊಂದಿಸಿ: "ಈ CI ವೈಫಲ್ಯವನ್ನು ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ಸಂಕ್ಷೇಪಿಸಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಪರಿಹಾರವನ್ನು ಸೂಚಿಸಿ." ಇದು ಕೇವಲ ತಂಡದ ಪ್ರತಿ ಇಂಜಿನಿಯರ್‌ಗೆ ಪ್ರತಿ ವೈಫಲ್ಯಕ್ಕೆ 5-10 ನಿಮಿಷಗಳನ್ನು ಉಳಿಸುತ್ತದೆ.
• ಹುಡುಕಬಹುದಾದ ಆರ್ಕೈವ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಲಾಗ್ ಇತಿಹಾಸವನ್ನು ಸ್ವಾಭಾವಿಕ ಭಾಷೆಯಿಂದ ಪ್ರಶ್ನಿಸುವಂತೆ ಮಾಡಲು ಎಂಬೆಡಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿ. LangChain ಮತ್ತು LlamaIndex ನಂತಹ ಪರಿಕರಗಳು ML ಅನುಭವವಿಲ್ಲದ ತಂಡಗಳಿಗೆ ಸಹ ಇದನ್ನು ಆಶ್ಚರ್ಯಕರವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು.

ಚಿಕ್ಕದಾಗಿ ಪ್ರಾರಂಭಿಸುವುದು, ಒಳನೋಟಗಳು ನಿಖರವಾಗಿವೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯೀಕರಿಸುವುದು ಮತ್ತು ಕ್ರಮೇಣ ವಿಸ್ತರಿಸುವುದು ಪ್ರಮುಖವಾಗಿದೆ. ಈ ರೀತಿಯ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಪರಿಕರಗಳ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ವೇಗವಾಗಿ ಪಕ್ವಗೊಳ್ಳುತ್ತಿದೆ ಮತ್ತು ಒಂದು ವರ್ಷದ ಹಿಂದೆ ಅಗತ್ಯವಿರುವ ಕಸ್ಟಮ್ ಮೂಲಸೌಕರ್ಯವು ಆಫ್-ದಿ-ಶೆಲ್ಫ್ ಘಟಕಗಳಾಗಿ ಹೆಚ್ಚು ಲಭ್ಯವಿರುತ್ತದೆ.

ಭವಿಷ್ಯವು ಕಾರ್ಯಾಚರಣೆಯ ಬುದ್ಧಿಮತ್ತೆಯಾಗಿದೆ

ನಾವು ನಿಜವಾಗಿಯೂ ಮಾತನಾಡುತ್ತಿರುವುದು ಕೇವಲ ಲಾಗ್ ವಿಶ್ಲೇಷಣೆಯ ಬಗ್ಗೆ ಅಲ್ಲ - ಇದು ಕಾರ್ಯಾಚರಣೆಯ ಬುದ್ಧಿವಂತಿಕೆಯ ಕಡೆಗೆ ಮೂಲಭೂತ ಬದಲಾವಣೆಯಾಗಿದೆ. CI ಲಾಗ್‌ಗಳಿಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅದೇ ವಿಧಾನವು ಗ್ರಾಹಕರ ಬೆಂಬಲ ಟಿಕೆಟ್‌ಗಳು, ಮಾರಾಟದ ಪೈಪ್‌ಲೈನ್ ಡೇಟಾ, ಹಣಕಾಸು ವಹಿವಾಟುಗಳು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಕೆಲಸದ ಹರಿವುಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ ಥ್ರೆಡ್ ಏನೆಂದರೆ, ಸಂಸ್ಥೆಗಳು ಕ್ರಿಯಾಶೀಲ ಮಾದರಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಅರೆ-ರಚನಾತ್ಮಕ ಪಠ್ಯ ಡೇಟಾವನ್ನು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಉತ್ಪಾದಿಸುತ್ತವೆ ಮತ್ತು LLM ಗಳು ಆ ಮಾದರಿಗಳನ್ನು ಹುಡುಕಲು ಅನನ್ಯವಾಗಿ ಸೂಕ್ತವಾಗಿವೆ.

ಇದಕ್ಕಾಗಿಯೇ ವ್ಯಾಪಾರ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸುವ ವೇದಿಕೆಗಳು ರಚನಾತ್ಮಕ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿವೆ. ನಿಮ್ಮ CRM ಡೇಟಾ, ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್, ಇನ್‌ವಾಯ್ಸಿಂಗ್, ಎಚ್‌ಆರ್ ದಾಖಲೆಗಳು ಮತ್ತು ವಿಶ್ಲೇಷಣೆಗಳು ಒಂದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಜೀವಿಸಿದಾಗ - ಮೆವೇಜ್‌ನ ಇಂಟಿಗ್ರೇಟೆಡ್ ಮಾಡ್ಯೂಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬಳಸುವ ತಂಡಗಳಿಗೆ ಮಾಡುವಂತೆ - ಕ್ರಾಸ್-ಡೊಮೇನ್ ಬುದ್ಧಿಮತ್ತೆಯ ಸಾಮರ್ಥ್ಯವು ಗುಣಿಸುತ್ತದೆ. ನಿಮ್ಮ CI ಲಾಗ್‌ಗಳಲ್ಲಿನ ಮಾದರಿಯು ಗ್ರಾಹಕರ ಮಂಥನದೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿರಬಹುದು. ಬೆಂಬಲ ಟಿಕೆಟ್‌ಗಳ ಹೆಚ್ಚಳವು ನಿಯೋಜನೆ ವೈಫಲ್ಯವನ್ನು ಊಹಿಸಬಹುದು. ಡೇಟಾವು ಪ್ರತ್ಯೇಕವಾದ ಸಿಲೋಸ್‌ಗಳಿಗಿಂತ ಸಂಪರ್ಕಿತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ವಾಸಿಸಿದಾಗ ಮಾತ್ರ ಈ ಸಂಪರ್ಕಗಳು ಗೋಚರಿಸುತ್ತವೆ.

ಮುಂದಿನ ದಶಕದಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುವ ತಂಡಗಳು ಹೆಚ್ಚು ಇಂಜಿನಿಯರ್‌ಗಳು ಅಥವಾ ದೊಡ್ಡ ಬಜೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ತಂಡಗಳಾಗಿರಬೇಕಾಗಿಲ್ಲ. ಅವರು ತಮ್ಮ ಸ್ವಂತ ಡೇಟಾವನ್ನು ಕೇಳಲು ಕಲಿಯುವವರು - ಅವರು ಎಸೆಯುತ್ತಿರುವ ಟೆರಾಬೈಟ್‌ಗಳು ಸೇರಿದಂತೆ. ನಿಮ್ಮ CI ದಾಖಲೆಗಳು ಮಾತನಾಡುತ್ತಿವೆ. ಅವರು ಏನು ಹೇಳುತ್ತಾರೆಂದು ಕೇಳಲು ನೀವು ಸಿದ್ಧರಿದ್ದೀರಾ ಎಂಬುದು ಪ್ರಶ್ನೆ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

CI ಲಾಗ್‌ಗಳಲ್ಲಿ LLMಗಳು ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತ ಮಾದರಿಗಳನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದೇ?

ಸಂಪೂರ್ಣವಾಗಿ. ಬೃಹತ್ ಭಾಷಾ ಮಾದರಿಗಳು ಬೃಹತ್ ರಚನೆಯಿಲ್ಲದ ಪಠ್ಯದಾದ್ಯಂತ ಮರುಕಳಿಸುವ ಮಾದರಿಗಳನ್ನು ಗುರುತಿಸುವಲ್ಲಿ ಉತ್ತಮವಾಗಿವೆ. CI ಲಾಗ್‌ಗಳ ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ತೋರಿಸಿದಾಗ, ಅವುಗಳು ವೈಫಲ್ಯದ ಪರಸ್ಪರ ಸಂಬಂಧಗಳು, ಫ್ಲಾಕಿ ಪರೀಕ್ಷಾ ಸಹಿಗಳು ಮತ್ತು ಮಾನವ ಎಂಜಿನಿಯರ್‌ಗಳು ಕೈಯಾರೆ ಹಿಡಿಯದ ಅವಲಂಬನೆ ಸಂಘರ್ಷಗಳನ್ನು ಮೇಲ್ಮೈ ಮಾಡಬಹುದು. ಕೀಲಿಯು ಇಂಜೆಶನ್ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸರಿಯಾಗಿ ರಚಿಸುವುದು, ಆದ್ದರಿಂದ ಮಾದರಿಯು ಕಚ್ಚಾ ಶಬ್ದಕ್ಕಿಂತ ಸರಿಯಾಗಿ ಭಾಗಿಸಿದ, ಸಂದರ್ಭೋಚಿತವಾಗಿ ಶ್ರೀಮಂತ ಲಾಗ್ ವಿಭಾಗಗಳನ್ನು ಪಡೆಯುತ್ತದೆ.

ಲಾಗ್ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಯಾವ ರೀತಿಯ CI ವೈಫಲ್ಯಗಳನ್ನು ಊಹಿಸಬಹುದು?

LLM-ಚಾಲಿತ ಲಾಗ್ ವಿಶ್ಲೇಷಣೆಯು ಮೂಲಸೌಕರ್ಯ-ಸಂಬಂಧಿತ ಅವಧಿ ಮೀರುವಿಕೆಗಳು, ಮರುಕಳಿಸುವ ಅವಲಂಬನೆ ರೆಸಲ್ಯೂಶನ್ ವೈಫಲ್ಯಗಳು, ಮೆಮೊರಿ-ಬೌಂಡ್ ಬಿಲ್ಡ್ ಕ್ರ್ಯಾಶ್‌ಗಳು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ಮಾರ್ಗಗಳಿಂದ ಪ್ರಚೋದಿಸಲ್ಪಟ್ಟ ಫ್ಲಾಕಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಊಹಿಸಬಹುದು. ಇದು ನಿಧಾನವಾಗಿ ತೆವಳುವ ಹಿಂಜರಿತಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಅಲ್ಲಿ ನಿರ್ಮಾಣ ಸಮಯವು ವಾರಗಳಲ್ಲಿ ಕ್ರಮೇಣ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಈ ವಿಧಾನವನ್ನು ಬಳಸುವ ತಂಡಗಳು ಉತ್ಪಾದನಾ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಘಟನೆಗಳನ್ನು ತಡೆಯುವ ಮೊದಲು ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯದ ಮಾದರಿಗಳನ್ನು ಎರಡರಿಂದ ಮೂರು ಸ್ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಹಿಡಿಯುತ್ತವೆ.

ವಿಶ್ಲೇಷಣೆ ಮೌಲ್ಯಯುತವಾಗುವ ಮೊದಲು ನಿಮಗೆ ಎಷ್ಟು CI ಲಾಗ್ ಡೇಟಾ ಬೇಕು?

ಅನೇಕ ಶಾಖೆಗಳಲ್ಲಿ 30 ರಿಂದ 90 ದಿನಗಳ ನಿರಂತರ ಪೈಪ್‌ಲೈನ್ ಇತಿಹಾಸವನ್ನು ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ ಅರ್ಥಪೂರ್ಣ ಮಾದರಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತವೆ. ಸಣ್ಣ ಡೇಟಾಸೆಟ್‌ಗಳು ಮೇಲ್ಮೈ ಮಟ್ಟದ ಒಳನೋಟಗಳನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ನೈಜ ಮೌಲ್ಯವು ಸಾವಿರಾರು ಬಿಲ್ಡ್ ರನ್‌ಗಳನ್ನು ಅಡ್ಡ-ಉಲ್ಲೇಖಿಸುವುದರಿಂದ ಬರುತ್ತದೆ. ತಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ಗಳ ಜೊತೆಗೆ ಸಂಕೀರ್ಣವಾದ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ನಿರ್ವಹಿಸುವ ತಂಡಗಳಿಗೆ, app.mewayz.com.

ನಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯ ಡೇಟಾವನ್ನು ಕೇಂದ್ರೀಕರಿಸಲು Mewayz ನಂತಹ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು $19/mo ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ 207 ಇಂಟಿಗ್ರೇಟೆಡ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ನೀಡುತ್ತವೆ.

ಎಲ್‌ಎಲ್‌ಎಂಗೆ CI ಲಾಗ್‌ಗಳನ್ನು ನೀಡುವುದು ಭದ್ರತಾ ಅಪಾಯವೇ?

ಅಜಾಗರೂಕತೆಯಿಂದ ನಿರ್ವಹಿಸಿದರೆ ಅದು ಆಗಿರಬಹುದು. CI ಲಾಗ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ಗಳು, API ಕೀಗಳು, ಆಂತರಿಕ URL ಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ವಿವರಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಯಾವುದೇ LLM ಮೂಲಕ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಮೊದಲು, ನೀವು ರಹಸ್ಯಗಳು, ರುಜುವಾತುಗಳು ಮತ್ತು ವೈಯಕ್ತಿಕವಾಗಿ ಗುರುತಿಸಬಹುದಾದ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುವ ದೃಢವಾದ ರಿಡಕ್ಷನ್ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಅಳವಡಿಸಬೇಕು. ಥರ್ಡ್-ಪಾರ್ಟಿ ಕ್ಲೌಡ್-ಆಧಾರಿತ ನಿರ್ಣಯದ ಅಂತಿಮ ಬಿಂದುಗಳಿಗೆ ಕಚ್ಚಾ ಲಾಗ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ಅಥವಾ ಆನ್-ಪ್ರಿಮೈಸ್ ಮಾಡೆಲ್ ನಿಯೋಜನೆಗಳು ಮಾನ್ಯತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.