ಈಗ DevOps ವಿಷಯವು ಪ್ರಚಾರದಲ್ಲಿದೆ. ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ವಿತರಣಾ ಪೈಪ್ಲೈನ್ ಸಿಐ / ಸಿಡಿ ಎಲ್ಲರೂ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದಾರೆ. ಆದರೆ ಹೆಚ್ಚಿನವರು ಯಾವಾಗಲೂ CI/CD ಪೈಪ್‌ಲೈನ್‌ನ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸರಿಯಾದ ಗಮನವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಪರಿಶೀಲನೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಮತ್ತು ಅದರ "ಸ್ವಯಂ-ಗುಣಪಡಿಸುವಿಕೆ" ಗಾಗಿ ಸಂಭವನೀಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ನನ್ನ ಅನುಭವದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ.

ಮೂಲ

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

ಗ್ರಾಹಕರೊಂದಿಗಿನ ಹಲವಾರು ಸಂಭಾಷಣೆಗಳ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, CI ಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಬಿಡುಗಡೆ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣ, ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಸಮಸ್ಯೆ ಮತ್ತು ಅದರ "ಸ್ವಯಂ-ಗುಣಪಡಿಸುವಿಕೆ" (ಉದಾಹರಣೆಗೆ, ಸ್ಥಿರ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವುದು) ಸಾಧ್ಯತೆಯನ್ನು ನಾನು ಹೇಳಬಲ್ಲೆ. /CD ಪೈಪ್‌ಲೈನ್ ಅತ್ಯಂತ ರೋಮಾಂಚಕಾರಿ ಮತ್ತು ಸಂಬಂಧಿತ ವಿಷಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

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

"ಸಮಸ್ಯೆಯ ಸೂತ್ರೀಕರಣ"

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

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

CI/CD ಪೈಪ್‌ಲೈನ್‌ನ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಮತ್ತು ತುರ್ತು ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ವಿವಿಧ ಸನ್ನಿವೇಶಗಳನ್ನು ಸೇರಿಸುವುದು ಪರಿಹಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು DevOps ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಸಹ ನಾವು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ವ್ಯಾಪಾರಗಳು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಎಲ್ಲಾ ಚೆಕ್‌ಗಳು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿರಬೇಕು.

ಕಾರ್ಯವನ್ನು ಎರಡು ಘಟಕಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ:

• ಪರೀಕ್ಷೆಯ ಹಂತದಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣ (ಕಡಿಮೆ-ಗುಣಮಟ್ಟದ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ಹಿಡಿಯುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು);
• ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣ (ಸಮಸ್ಯೆಗಳ ಸ್ವಯಂಚಾಲಿತ ಪತ್ತೆಗಾಗಿ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಅವುಗಳ ಸ್ವಯಂ-ಗುಣಪಡಿಸುವಿಕೆಗೆ ಸಂಭವನೀಯ ಸನ್ನಿವೇಶಗಳು).

ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಾಧನ

ನಿಗದಿತ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು, CI/CD ಪೈಪ್‌ಲೈನ್‌ನ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಅವುಗಳನ್ನು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ವರ್ಗಾಯಿಸುವ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಅಗತ್ಯವಿದೆ. ಈ ವ್ಯವಸ್ಥೆಯು ವಿವಿಧ ತಂಡಗಳಿಗೆ ಉಪಯುಕ್ತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸಿದರೆ ಅದು ಸಕಾರಾತ್ಮಕ ವಿಷಯವಾಗಿದೆ: ಅಭಿವೃದ್ಧಿ, ಪರೀಕ್ಷೆ, ಕಾರ್ಯಾಚರಣೆ. ಮತ್ತು ಇದು ವ್ಯವಹಾರಕ್ಕೆ ಸಹ ಇದ್ದರೆ ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅದ್ಭುತವಾಗಿದೆ.

ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ನೀವು ವಿವಿಧ ಸಿಸ್ಟಮ್‌ಗಳ ಗುಂಪನ್ನು ಬಳಸಬಹುದು (ಪ್ರಮೀತಿಯಸ್, ಇಎಲ್‌ಕೆ ಸ್ಟಾಕ್, ಜಬ್ಬಿಕ್ಸ್, ಇತ್ಯಾದಿ), ಆದರೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಎಪಿಎಂ-ವರ್ಗದ ಪರಿಹಾರಗಳು ಈ ಕಾರ್ಯಗಳಿಗೆ ಸೂಕ್ತವಾಗಿವೆ (ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮಾನಿಟರಿಂಗ್), ಇದು ನಿಮ್ಮ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.

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

ಮೂಲ. ಸಿಸ್ಟಮ್ ಘಟಕಗಳ ನಡುವಿನ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳ ಸ್ವಯಂಚಾಲಿತ ನಿರ್ಮಾಣ

ಮೂಲ. ಸೇವೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಮಾರ್ಗದ ಸ್ವಯಂಚಾಲಿತ ಪತ್ತೆ ಮತ್ತು ನಿರ್ಮಾಣ

ನಾವು ವಿವಿಧ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಾಧನಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಇಲ್ಲಿ ಪರಿಹಾರವು ಅನುಕೂಲಕರ API ಅನ್ನು ಹೊಂದಿದ್ದು ಅದು ವಿವಿಧ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಈವೆಂಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಮುಂದೆ, ಡೈನಾಟ್ರೇಸ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚು ವಿವರವಾದ ನೋಟಕ್ಕೆ ಹೋಗೋಣ.

ಕಾರ್ಯ 1. ಪರೀಕ್ಷೆಯ ಹಂತದಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣದ ಆಟೊಮೇಷನ್

ಅಪ್ಲಿಕೇಶನ್ ವಿತರಣಾ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮೊದಲ ಸವಾಲು. "ಉತ್ತಮ" ಕೋಡ್ ನಿರ್ಮಾಣಗಳು ಮಾತ್ರ ಉತ್ಪಾದನೆಯನ್ನು ತಲುಪಬೇಕು. ಇದನ್ನು ಮಾಡಲು, ಪರೀಕ್ಷಾ ಹಂತದಲ್ಲಿ ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್ ನಿಮ್ಮ ಸೇವೆಗಳ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಶೀಲಿಸಲು ಹೆಚ್ಚುವರಿ ಮಾನಿಟರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರಬೇಕು.

ಇದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಮತ್ತು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ಹಂತ-ಹಂತವಾಗಿ ನೋಡೋಣ:

ಮೂಲ

ಸ್ವಯಂಚಾಲಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟ ಪರೀಕ್ಷೆಯ ಹಂತಗಳ ಹರಿವನ್ನು ಅಂಕಿ ತೋರಿಸುತ್ತದೆ:

1. ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯ ನಿಯೋಜನೆ (ಏಜೆಂಟರ ಸ್ಥಾಪನೆ);
2. ನಿಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ಣಯಿಸಲು ಈವೆಂಟ್‌ಗಳನ್ನು ಗುರುತಿಸುವುದು (ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಥ್ರೆಶೋಲ್ಡ್ ಮೌಲ್ಯಗಳು) ಮತ್ತು ಅವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ವರ್ಗಾಯಿಸುವುದು;
3. ಲೋಡ್ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಳ ಉತ್ಪಾದನೆ;
4. ಮೇಲ್ವಿಚಾರಣೆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಲಭ್ಯತೆಯ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು;
5. ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ CI/CD ಸಿಸ್ಟಮ್‌ಗೆ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಮೌಲ್ಯಮಾಪನ ಘಟನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಪರೀಕ್ಷಾ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವುದು. ಅಸೆಂಬ್ಲಿಗಳ ಸ್ವಯಂಚಾಲಿತ ವಿಶ್ಲೇಷಣೆ.

ಹಂತ 1. ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯ ನಿಯೋಜನೆ

ಮೊದಲು ನೀವು ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಏಜೆಂಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಕು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೈನಾಟ್ರೇಸ್ ಪರಿಹಾರವು ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ - ಇದು OS ನಿದರ್ಶನದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಸಾರ್ವತ್ರಿಕ ಏಜೆಂಟ್ OneAgent ಅನ್ನು ಬಳಸುತ್ತದೆ (Windows, Linux, AIX), ನಿಮ್ಮ ಸೇವೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಮಾನಿಟರಿಂಗ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರತ್ಯೇಕ ಏಜೆಂಟ್ ಅನ್ನು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಕ್ಲೌಡ್ ಮತ್ತು ಕಂಟೇನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ಪರಿಸ್ಥಿತಿ ಹೋಲುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ಏಜೆಂಟ್ ಸ್ಥಾಪನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು. ಡೈನಾಟ್ರೇಸ್ "ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ" ಪರಿಕಲ್ಪನೆಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ (ಕೋಡ್ ಅಥವಾ IaC ನಂತೆ ಮೂಲಸೌಕರ್ಯ): ಎಲ್ಲಾ ಜನಪ್ರಿಯ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ರೆಡಿಮೇಡ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಸೂಚನೆಗಳಿವೆ. ನಿಮ್ಮ ಸೇವೆಯ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ನೀವು ಏಜೆಂಟ್ ಅನ್ನು ಎಂಬೆಡ್ ಮಾಡಿ ಮತ್ತು ನೀವು ಅದನ್ನು ನಿಯೋಜಿಸಿದಾಗ, ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಏಜೆಂಟ್‌ನೊಂದಿಗೆ ನೀವು ತಕ್ಷಣ ಹೊಸ ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.

ಹಂತ 2: ನಿಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಈವೆಂಟ್‌ಗಳನ್ನು ವಿವರಿಸಿ

ಈಗ ನೀವು ಸೇವೆಗಳು ಮತ್ತು ವ್ಯಾಪಾರ ಕಾರ್ಯಾಚರಣೆಗಳ ಪಟ್ಟಿಯನ್ನು ನಿರ್ಧರಿಸಬೇಕು. ನಿಮ್ಮ ಸೇವೆಗೆ ವ್ಯವಹಾರ ನಿರ್ಣಾಯಕವಾಗಿರುವ ಬಳಕೆದಾರರ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿಖರವಾಗಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಇಲ್ಲಿ ನಾನು ವ್ಯಾಪಾರ ಮತ್ತು ಸಿಸ್ಟಮ್ ವಿಶ್ಲೇಷಕರೊಂದಿಗೆ ಸಮಾಲೋಚಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ಮುಂದೆ, ಪ್ರತಿ ಹಂತದ ವಿಮರ್ಶೆಯಲ್ಲಿ ನೀವು ಯಾವ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನೀವು ನಿರ್ಧರಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ಇದು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯ (ಸರಾಸರಿ, ಸರಾಸರಿ, ಶೇಕಡಾವಾರು, ಇತ್ಯಾದಿಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ), ದೋಷಗಳು (ತಾರ್ಕಿಕ, ಸೇವೆ, ಮೂಲಸೌಕರ್ಯ, ಇತ್ಯಾದಿ) ಮತ್ತು ವಿವಿಧ ಮೂಲಸೌಕರ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳು (ಮೆಮೊರಿ ಹೀಪ್, ಕಸ ಸಂಗ್ರಾಹಕ, ಥ್ರೆಡ್ ಎಣಿಕೆ, ಇತ್ಯಾದಿ).

DevOps ತಂಡದಿಂದ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮತ್ತು ಸುಲಭ ಬಳಕೆಗಾಗಿ, "ಮಾನಿಟರಿಂಗ್ ಆಸ್ ಕೋಡ್" ಎಂಬ ಪರಿಕಲ್ಪನೆಯು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಭರವಸೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಸರಳ JSON ಫೈಲ್ ಅನ್ನು ಡೆವಲಪರ್/ಟೆಸ್ಟರ್ ಬರೆಯಬಹುದು ಎಂಬುದು ಇದರ ಅರ್ಥವಾಗಿದೆ.

ಅಂತಹ JSON ಫೈಲ್‌ನ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಡೈನಾಟ್ರೇಸ್ API ಯಿಂದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಕೀ/ಮೌಲ್ಯ ಜೋಡಿಗಳಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (API ವಿವರಣೆಯನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು ಡೈನಾಟ್ರೇಸ್ API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ಫೈಲ್ ಸಮಯ ಸರಣಿಯ ವ್ಯಾಖ್ಯಾನಗಳ ಒಂದು ಶ್ರೇಣಿಯಾಗಿದೆ:

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

ಕೆಳಗಿನ ಚಿತ್ರವು ಅಂತಹ ಮಿತಿಗಳ ಬಳಕೆಯ ಉದಾಹರಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮೂಲ

ಹಂತ 3: ಲೋಡ್ ಉತ್ಪಾದನೆ

ನಮ್ಮ ಸೇವೆಯ ಗುಣಮಟ್ಟದ ಮಟ್ಟವನ್ನು ನಾವು ನಿರ್ಧರಿಸಿದ ನಂತರ, ನಾವು ಪರೀಕ್ಷಾ ಲೋಡ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. Jmeter, Selenium, Neotys, Gatling, ಇತ್ಯಾದಿಗಳಂತಹ ನೀವು ಆರಾಮದಾಯಕವಾದ ಯಾವುದೇ ಪರೀಕ್ಷಾ ಸಾಧನಗಳನ್ನು ನೀವು ಬಳಸಬಹುದು.

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

ಹೆಚ್ಚುವರಿ ಹೆಡರ್ ಎಕ್ಸ್-ಡೈನಾಟ್ರೇಸ್-ಟೆಸ್ಟ್ ಬಳಸಿ, ಈ ಪರೀಕ್ಷೆಯು ಕಾರ್ಟ್‌ಗೆ ಐಟಂ ಅನ್ನು ಸೇರಿಸುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಂಬಂಧಿಸಿದೆ ಎಂದು ನಾವು ಸೂಚಿಸುವ ಉದಾಹರಣೆಯನ್ನು ಕೆಳಗಿನ ಚಿತ್ರ ತೋರಿಸುತ್ತದೆ.

ಮೂಲ

ನೀವು ಪ್ರತಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದಾಗ, CI/CD ಸರ್ವರ್‌ನಿಂದ ಈವೆಂಟ್ API ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಡೈನಾಟ್ರೇಸ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಸಂದರ್ಭೋಚಿತ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ. ಈ ರೀತಿಯಾಗಿ, ಸಿಸ್ಟಮ್ ವಿವಿಧ ಪರೀಕ್ಷೆಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡಬಹುದು.

ಮೂಲ. ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪ್ರಾರಂಭದ ಬಗ್ಗೆ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಈವೆಂಟ್

ಹಂತ 4-5. ಕಾರ್ಯಕ್ಷಮತೆಯ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಡೇಟಾವನ್ನು CI/CD ವ್ಯವಸ್ಥೆಗೆ ವರ್ಗಾಯಿಸಿ

ರಚಿಸಿದ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ, ಸೇವೆಯ ಗುಣಮಟ್ಟದ ಸೂಚಕಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ ಈವೆಂಟ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ಇದು ನಮ್ಮ JSON ಫೈಲ್ ಅನ್ನು ಸಹ ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಇದು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.

ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಕಳುಹಿಸಲು CI/CD ಸರ್ವರ್‌ನಲ್ಲಿ ರಚಿಸಲಾದ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯತೆಯ ಕುರಿತು ಈವೆಂಟ್

ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ಗುಣಮಟ್ಟದ ಚೆಕ್ ಈವೆಂಟ್ ಅನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ perfSigDynatraceReport (ಕಾರ್ಯಕ್ಷಮತೆ_ಸಹಿ) - ಇದು ಸಿದ್ಧವಾಗಿದೆ ಪ್ಲಗಿನ್ ಜೆಂಕಿನ್ಸ್‌ನೊಂದಿಗೆ ಏಕೀಕರಣಕ್ಕಾಗಿ, ಇದನ್ನು ಟಿ-ಸಿಸ್ಟಮ್ಸ್ ಮಲ್ಟಿಮೀಡಿಯಾ ಸೊಲ್ಯೂಷನ್ಸ್‌ನ ವ್ಯಕ್ತಿಗಳು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ. ಪ್ರತಿ ಪರೀಕ್ಷಾ ಉಡಾವಣಾ ಈವೆಂಟ್ ಸೇವೆ, ಬಿಲ್ಡ್ ಸಂಖ್ಯೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಸಮಯದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಪ್ಲಗಿನ್ ನಿರ್ಮಾಣದ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೌಲ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಹಿಂದಿನ ನಿರ್ಮಾಣಗಳು ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕವಲ್ಲದ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ.

ನಿರ್ಮಾಣ ಗುಣಮಟ್ಟ ಪರಿಶೀಲನೆಯ ಪ್ರಾರಂಭದ ಕುರಿತು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಈವೆಂಟ್. ಮೂಲ

ಪರೀಕ್ಷೆಯು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ಣಯಿಸಲು ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಿರಂತರ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಜೆಂಕಿನ್ಸ್, ಇದು ಫಲಿತಾಂಶಗಳ ಕುರಿತು ವರದಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

CI/CD ಸರ್ವರ್‌ನಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳ ಅಂಕಿಅಂಶಗಳ ಫಲಿತಾಂಶ. ಮೂಲ

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

CI/CD ಸರ್ವರ್‌ನಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳ ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ವೀಕ್ಷಿಸಿ. ಮೂಲ

ಎರಡು ಅಸೆಂಬ್ಲಿಗಳ ವಿವರವಾದ ಹೋಲಿಕೆ

ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಡೈನಾಟ್ರೇಸ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಹೋಗಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ನಿಮ್ಮ ಪ್ರತಿಯೊಂದು ಬಿಲ್ಡ್‌ಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ನೀವು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಹೋಲಿಸಬಹುದು.

ಡೈನಾಟ್ರೇಸ್‌ನಲ್ಲಿ ಬಿಲ್ಡ್ ಅಂಕಿಅಂಶಗಳ ಹೋಲಿಕೆ. ಮೂಲ
 
ಸಂಶೋಧನೆಗಳು

ಪರಿಣಾಮವಾಗಿ, ನಿರಂತರ ಏಕೀಕರಣ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ "ಸೇವೆಯಾಗಿ ಮಾನಿಟರಿಂಗ್" ಸೇವೆಯನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಡೆವಲಪರ್ ಅಥವಾ ಪರೀಕ್ಷಕರು JSON ಫೈಲ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಮಾತ್ರ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಉಳಿದಂತೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಡೆಯುತ್ತದೆ. ನಾವು ಬಿಡುಗಡೆಗಳ ಪಾರದರ್ಶಕ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ: ಕಾರ್ಯಕ್ಷಮತೆ, ಸಂಪನ್ಮೂಲ ಬಳಕೆ ಅಥವಾ ವಾಸ್ತುಶಿಲ್ಪದ ಹಿಂಜರಿಕೆಗಳ ಬಗ್ಗೆ ಎಲ್ಲಾ ಅಧಿಸೂಚನೆಗಳು.

ಕಾರ್ಯ 2. ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣದ ಆಟೊಮೇಷನ್

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

ಆದರೆ ಕೆಟ್ಟ ಸಾಫ್ಟ್‌ವೇರ್ ಮಾರಾಟವಾದರೆ ಅಥವಾ ಏನಾದರೂ ಮುರಿದರೆ ಏನು ಮಾಡಬೇಕು. ರಾಮರಾಜ್ಯಕ್ಕಾಗಿ, ನಾವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಸಾಧ್ಯವಾದರೆ, ಕನಿಷ್ಠ ರಾತ್ರಿಯಲ್ಲಿ ಅದರ ಕಾರ್ಯವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಸಿಸ್ಟಮ್ ಸ್ವತಃ.

ಇದನ್ನು ಮಾಡಲು, ಹಿಂದಿನ ವಿಭಾಗದೊಂದಿಗೆ ಸಾದೃಶ್ಯದ ಮೂಲಕ, ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಪರಿಶೀಲನೆಗಳನ್ನು ಒದಗಿಸಲು ಮತ್ತು ಸಿಸ್ಟಮ್ ಸ್ವಯಂ-ಚಿಕಿತ್ಸೆಗಾಗಿ ಸನ್ನಿವೇಶಗಳನ್ನು ಆಧರಿಸಿ ಅವುಗಳನ್ನು ಒದಗಿಸುವ ಅಗತ್ಯವಿದೆ.

ಕೋಡ್‌ನಂತೆ ಸ್ವಯಂ ಸರಿಪಡಿಸಿ

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

ನಾನು ಮಾತನಾಡುವ ಹಲವು ತಂಡಗಳಿಂದ ಈ ಬಳಕೆಯ ಪ್ರಕರಣಗಳು ವರ್ಷಗಳಿಂದ ತಿಳಿದಿದ್ದರೂ, ಕೆಲವರು ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸಿದ್ದಾರೆ ಅಥವಾ ಹೂಡಿಕೆ ಮಾಡಿದ್ದಾರೆ.

ನೀವು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಿದರೆ, ಸ್ವಯಂ-ಗುಣಪಡಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಏನೂ ಇಲ್ಲ; ನಿಮ್ಮ ನಿರ್ವಾಹಕರ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಕೆಲಸದ ಸನ್ನಿವೇಶಗಳನ್ನು ಕೋಡ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳ ರೂಪದಲ್ಲಿ ನೀವು ಪ್ರಸ್ತುತಪಡಿಸಬೇಕಾಗಿದೆ ("ಕೋಡ್ನಂತೆ ಸ್ವಯಂ-ಫಿಕ್ಸ್" ಪರಿಕಲ್ಪನೆ) , ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ ನೀವು ಮುಂಚಿತವಾಗಿ ಬರೆದಿದ್ದೀರಿ. ಸ್ವಯಂಚಾಲಿತ ದುರಸ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸಮಸ್ಯೆಯ ಮೂಲ ಕಾರಣವನ್ನು ತೆಗೆದುಹಾಕುವ ಗುರಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಘಟನೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸರಿಯಾದ ಕ್ರಮಗಳನ್ನು ನೀವೇ ನಿರ್ಧರಿಸುತ್ತೀರಿ.

ನಿಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಯಾವುದೇ ಮೆಟ್ರಿಕ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಚೋದಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಈ ಮೆಟ್ರಿಕ್‌ಗಳು ಎಲ್ಲವೂ ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ನಿಖರವಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವು ಉತ್ಪಾದಕ ವಾತಾವರಣದಲ್ಲಿ ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಪಡೆಯಲು ಬಯಸುವುದಿಲ್ಲ.

ನೀವು ಯಾವುದೇ ಸಿಸ್ಟಮ್ ಅಥವಾ ಸಿಸ್ಟಮ್ಗಳ ಸೆಟ್ ಅನ್ನು ಬಳಸಬಹುದು: ಪ್ರಮೀತಿಯಸ್, ELK ಸ್ಟಾಕ್, ಜಬ್ಬಿಕ್ಸ್, ಇತ್ಯಾದಿ. ಆದರೆ ನಾನು APM ಪರಿಹಾರವನ್ನು ಆಧರಿಸಿ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ (ಡೈನಾಟ್ರೇಸ್ ಮತ್ತೊಮ್ಮೆ ಉದಾಹರಣೆಯಾಗಿದೆ) ಅದು ನಿಮ್ಮ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಮೊದಲನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆಯ ವಿಷಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ ಇದೆ. ಪರಿಹಾರವು ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ನೂರಾರು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಅದನ್ನು ನೀವು ಟ್ರಿಗ್ಗರ್‌ಗಳಾಗಿ ಬಳಸಬಹುದು:

• ಬಳಕೆದಾರ ಮಟ್ಟ (ಬ್ರೌಸರ್‌ಗಳು, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, IoT ಸಾಧನಗಳು, ಬಳಕೆದಾರರ ನಡವಳಿಕೆ, ಪರಿವರ್ತನೆ, ಇತ್ಯಾದಿ);
• ಸೇವೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ ಮಟ್ಟ (ಕಾರ್ಯಕ್ಷಮತೆ, ಲಭ್ಯತೆ, ದೋಷಗಳು, ಇತ್ಯಾದಿ);
• ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಸೌಕರ್ಯ ಮಟ್ಟ (ಹೋಸ್ಟ್ OS ಮೆಟ್ರಿಕ್ಸ್, JMX, MQ, ವೆಬ್-ಸರ್ವರ್, ಇತ್ಯಾದಿ);
• ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟ (ವರ್ಚುವಲೈಸೇಶನ್, ಕ್ಲೌಡ್, ಕಂಟೇನರ್, ಇತ್ಯಾದಿ).

ಡೈನಾಟ್ರೇಸ್‌ನಲ್ಲಿ ಮಾನಿಟರಿಂಗ್ ಮಟ್ಟಗಳು. ಮೂಲ

ಎರಡನೆಯದಾಗಿ, ನಾನು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಡೈನಾಟ್ರೇಸ್ ತೆರೆದ API ಅನ್ನು ಹೊಂದಿದೆ, ಇದು ವಿವಿಧ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಿಯಂತ್ರಣ ನಿಯತಾಂಕಗಳನ್ನು ಮೀರಿದಾಗ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ವ್ಯವಸ್ಥೆಗೆ ಅಧಿಸೂಚನೆಯನ್ನು ಕಳುಹಿಸುವುದು.

ಅನ್ಸಿಬಲ್ ಜೊತೆ ಸಂವಹನ ನಡೆಸಲು ಕೆಳಗೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.

ಮೂಲ

ಯಾವ ರೀತಿಯ ಯಾಂತ್ರೀಕರಣವನ್ನು ಮಾಡಬಹುದು ಎಂಬುದಕ್ಕೆ ನಾನು ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ಕೆಳಗೆ ನೀಡುತ್ತೇನೆ. ಇದು ಪ್ರಕರಣಗಳ ಒಂದು ಭಾಗವಾಗಿದೆ; ನಿಮ್ಮ ಪರಿಸರದಲ್ಲಿ ಅವರ ಪಟ್ಟಿಯನ್ನು ನಿಮ್ಮ ಕಲ್ಪನೆ ಮತ್ತು ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣಾ ಸಾಧನಗಳ ಸಾಮರ್ಥ್ಯಗಳಿಂದ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸಬಹುದು.

1. ಕೆಟ್ಟ ನಿಯೋಜನೆ - ಆವೃತ್ತಿ ರೋಲ್ಬ್ಯಾಕ್

ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ನಾವು ಎಲ್ಲವನ್ನೂ ಚೆನ್ನಾಗಿ ಪರೀಕ್ಷಿಸಿದರೂ ಸಹ, ಹೊಸ ಬಿಡುಗಡೆಯು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕೊಲ್ಲುವ ಅವಕಾಶವಿರುತ್ತದೆ. ಅದೇ ಮಾನವ ಅಂಶವನ್ನು ರದ್ದುಗೊಳಿಸಲಾಗಿಲ್ಲ.

ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ಸೇವೆಯಲ್ಲಿನ ಕಾರ್ಯಾಚರಣೆಗಳ ಮರಣದಂಡನೆಯ ಸಮಯದಲ್ಲಿ ತೀಕ್ಷ್ಣವಾದ ಜಂಪ್ ಇದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಈ ಜಂಪ್‌ನ ಆರಂಭವು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಿಯೋಜನೆಯ ಸಮಯದೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ನಾವು ಈ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಈವೆಂಟ್‌ಗಳಾಗಿ ಸ್ವಯಂಚಾಲಿತ ವ್ಯವಸ್ಥೆಗೆ ರವಾನಿಸುತ್ತೇವೆ. ನಾವು ಹೊಂದಿಸಿದ ಸಮಯದ ನಂತರ ಸೇವೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಾಮಾನ್ಯ ಸ್ಥಿತಿಗೆ ಮರಳದಿದ್ದರೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ, ಅದು ಆವೃತ್ತಿಯನ್ನು ಹಳೆಯದಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ನಿಯೋಜನೆಯ ನಂತರ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿ. ಮೂಲ

2. 100% ನಲ್ಲಿ ಸಂಪನ್ಮೂಲ ಲೋಡಿಂಗ್ - ರೂಟಿಂಗ್‌ಗೆ ನೋಡ್ ಸೇರಿಸಿ

ಕೆಳಗಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಒಂದು ಘಟಕವು 100% CPU ಲೋಡ್ ಅನ್ನು ಅನುಭವಿಸುತ್ತಿದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

CPU ಲೋಡ್ 100%
 
ಈ ಘಟನೆಗೆ ಹಲವಾರು ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳು ಸಾಧ್ಯ. ಉದಾಹರಣೆಗೆ, ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಹೆಚ್ಚುವರಿಯಾಗಿ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯು ಸೇವೆಯ ಮೇಲಿನ ಹೊರೆ ಹೆಚ್ಚಳದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಹಾಗಿದ್ದಲ್ಲಿ, ರೂಟಿಂಗ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನೋಡ್ ಅನ್ನು ಸೇರಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಒಟ್ಟಾರೆಯಾಗಿ ಸಿಸ್ಟಮ್‌ನ ಕಾರ್ಯವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ.

ಘಟನೆಯ ನಂತರ ಸ್ಕೇಲಿಂಗ್

3. ಹಾರ್ಡ್ ಡ್ರೈವಿನಲ್ಲಿ ಸ್ಥಳಾವಕಾಶದ ಕೊರತೆ - ಡಿಸ್ಕ್ ಕ್ಲೀನಿಂಗ್

ಅನೇಕ ಜನರು ಈಗಾಗಲೇ ಈ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. APM ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮುಕ್ತ ಜಾಗವನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ಯಾವುದೇ ಸ್ಥಳವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಡಿಸ್ಕ್ ನಿಧಾನವಾಗಿ ಚಲಿಸುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಅಥವಾ ಜಾಗವನ್ನು ಸೇರಿಸಲು ನಾವು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕರೆಯುತ್ತೇವೆ.

ಡಿಸ್ಕ್ ಲೋಡ್ 100%
 
4. ಕಡಿಮೆ ಬಳಕೆದಾರ ಚಟುವಟಿಕೆ ಅಥವಾ ಕಡಿಮೆ ಪರಿವರ್ತನೆ - ನೀಲಿ ಮತ್ತು ಹಸಿರು ಶಾಖೆಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವುದು

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

ಸಾಫ್ಟ್‌ವೇರ್ ಶಾಖೆಗಳ ನಡುವೆ ಬದಲಾಯಿಸಿದ ನಂತರ ಪರಿವರ್ತನೆ ದರ ಇಳಿಯುತ್ತದೆ. ಮೂಲ

ಸ್ವಯಂಚಾಲಿತ ಸಮಸ್ಯೆ ಪತ್ತೆಗಾಗಿ ಕಾರ್ಯವಿಧಾನಗಳು

ಅಂತಿಮವಾಗಿ, ನಾನು ಡೈನಾಟ್ರೇಸ್ ಅನ್ನು ಏಕೆ ಹೆಚ್ಚು ಇಷ್ಟಪಡುತ್ತೇನೆ ಎಂಬುದಕ್ಕೆ ನಾನು ನಿಮಗೆ ಇನ್ನೊಂದು ಉದಾಹರಣೆಯನ್ನು ನೀಡುತ್ತೇನೆ.

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

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

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

ವೈಫಲ್ಯದ ಮೂಲ ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸುವ ಉದಾಹರಣೆ. ಮೂಲ

ಘಟನೆಯ ಪ್ರಾರಂಭದಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೆಳಗಿನ ಅಂಕಿ ತೋರಿಸುತ್ತದೆ.

ಎಲ್ಲಾ ಘಟಕಗಳು ಮತ್ತು ಘಟನೆಗಳ ಪ್ರದರ್ಶನದೊಂದಿಗೆ ಉದಯೋನ್ಮುಖ ಸಮಸ್ಯೆಯ ದೃಶ್ಯೀಕರಣ

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸರ್ವೀಸ್ ಡೆಸ್ಕ್ ಅಥವಾ ಬಗ್ ಟ್ರ್ಯಾಕರ್‌ನೊಂದಿಗೆ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಂಯೋಜಿಸಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಸಮಸ್ಯೆ ಉಂಟಾದಾಗ, ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ ಅದನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಡೆವಲಪರ್‌ಗಳು ಸಂಪೂರ್ಣ ಮಾಹಿತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ವೀಕರಿಸುತ್ತಾರೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಅಂತರ್ನಿರ್ಮಿತ ಸ್ವಯಂಚಾಲಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಪರಿಶೀಲನೆಗಳೊಂದಿಗೆ CI/CD ಪೈಪ್‌ಲೈನ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದ್ದೇವೆ. ನಾವು ಕಡಿಮೆ-ಗುಣಮಟ್ಟದ ಅಸೆಂಬ್ಲಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ, ಒಟ್ಟಾರೆಯಾಗಿ ಸಿಸ್ಟಮ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಸಿಸ್ಟಮ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಅದನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ನಾವು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.

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

ನಿಮ್ಮ ಪ್ರಯತ್ನಗಳಲ್ಲಿ ನನ್ನ ಉದಾಹರಣೆಗಳು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಸ್ವಯಂ-ಗುಣಪಡಿಸುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಳಸುವ ಮೆಟ್ರಿಕ್‌ಗಳ ನಿಮ್ಮ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡಲು ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ.

ಮೂಲ

ಮೂಲ: www.habr.com