ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಮೇಲ್ವಿಚಾರಣಾ ವಿಭಾಗದ ತನ್ನ ಸಹೋದ್ಯೋಗಿಗಳ ವ್ಯರ್ಥ ಪ್ರಯತ್ನಗಳ ಬಗ್ಗೆ ಇವಾನ್ ಆಗಾಗ್ಗೆ ನಕ್ಕರು. ಕಂಪನಿಯ ಆಡಳಿತವು ಸಾಧಿಸಲು ಆದೇಶಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅವರು ಹೆಚ್ಚಿನ ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಿದರು. ಬೇರೆಯವರು ಏನನ್ನೂ ಮಾಡಬಾರದು ಎಂದು ಅವರು ತುಂಬಾ ಕಾರ್ಯನಿರತರಾಗಿದ್ದರು.
ಆದರೆ ನಿರ್ವಹಣೆಗೆ ಇದು ಸಾಕಾಗಲಿಲ್ಲ - ಅವರು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆದೇಶಿಸಿದರು, ಹಿಂದೆ ಮಾಡಿದ್ದನ್ನು ಬಳಸುವುದನ್ನು ತ್ವರಿತವಾಗಿ ನಿಲ್ಲಿಸಿದರು.
ಇತ್ತೀಚೆಗೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಲೀಡ್‌ಟೈಮ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದಾರೆ - ವ್ಯಾಪಾರ ವೈಶಿಷ್ಟ್ಯಗಳ ವಿತರಣೆಯ ಸಮಯ. ಮೆಟ್ರಿಕ್ ಕ್ರೇಜಿ ಸಂಖ್ಯೆಯನ್ನು ತೋರಿಸಿದೆ - ಒಂದು ಕೆಲಸವನ್ನು ನೀಡಲು 200 ದಿನಗಳು. ಎಲ್ಲರೂ ಹೇಗೆ ಓಹ್ ಮತ್ತು ಆಹ್ಡ್ ಮತ್ತು ತಮ್ಮ ಕೈಗಳನ್ನು ಆಕಾಶಕ್ಕೆ ಎತ್ತಿದರು!
ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಶಬ್ದವು ಕ್ರಮೇಣ ಕಡಿಮೆಯಾಯಿತು ಮತ್ತು ಇನ್ನೊಂದು ಮೆಟ್ರಿಕ್ ಅನ್ನು ರಚಿಸಲು ಆಡಳಿತವು ಆದೇಶವನ್ನು ಪಡೆಯಿತು.
ಹೊಸ ಮೆಟ್ರಿಕ್ ಕತ್ತಲೆಯಾದ ಮೂಲೆಯಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ಸಾಯುತ್ತದೆ ಎಂದು ಇವಾನ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿತ್ತು.
ವಾಸ್ತವವಾಗಿ, ಇವಾನ್ ಯೋಚಿಸಿದನು, ಸಂಖ್ಯೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಯಾರಿಗೂ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. 200 ದಿನಗಳು ಅಥವಾ 2 ದಿನಗಳು - ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ, ಏಕೆಂದರೆ ಸಂಖ್ಯೆಯಿಂದ ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸಲು ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದ್ದೇ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ.
ಇದು ಮೆಟ್ರಿಕ್‌ಗಳ ವಿಶಿಷ್ಟ ಬಲೆಯಾಗಿದೆ: ಹೊಸ ಮೆಟ್ರಿಕ್ ಅಸ್ತಿತ್ವದ ಸಾರವನ್ನು ಹೇಳುತ್ತದೆ ಮತ್ತು ಕೆಲವು ರಹಸ್ಯ ರಹಸ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಇದಕ್ಕಾಗಿ ತುಂಬಾ ಆಶಿಸುತ್ತಾರೆ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಏನೂ ಆಗುವುದಿಲ್ಲ. ಹೌದು, ಏಕೆಂದರೆ ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ರಹಸ್ಯವನ್ನು ಕಂಡುಹಿಡಿಯಬಾರದು!
ಇವಾನ್‌ಗೆ, ಇದು ಹಾದುಹೋಗುವ ಹಂತವಾಗಿತ್ತು. ಅದು ಅವನಿಗೆ ಅರ್ಥವಾಯಿತು ಅಳತೆಗಳಿಗಾಗಿ, ಮತ್ತು ಎಲ್ಲಾ ರಹಸ್ಯಗಳನ್ನು ಹುಡುಕಬೇಕು , ಅಂದರೆ ಈ ಮೆಟ್ರಿಕ್ ರೂಪುಗೊಂಡಿದೆ.
ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್‌ಗಾಗಿ, ಪ್ರಭಾವದ ವಸ್ತುವು ಹಣವನ್ನು ತರುವ ಅದರ ಕ್ಲೈಂಟ್‌ಗಳಾಗಿರುತ್ತದೆ ಮತ್ತು DevOps ಗಾಗಿ, ಇದು ಪೈಪ್‌ಲೈನ್ ಬಳಸಿ ವಿತರಣೆಗಳನ್ನು ರಚಿಸುವ ಮತ್ತು ಹೊರತರುವ ತಂಡಗಳಾಗಿರುತ್ತದೆ.
ಒಂದು ದಿನ, ಸಭಾಂಗಣದಲ್ಲಿ ಆರಾಮದಾಯಕವಾದ ಕುರ್ಚಿಯಲ್ಲಿ ಕುಳಿತು, ಇವಾನ್ ಅವರು ಡೆವೊಪ್ಸ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೇಗೆ ನೋಡಬೇಕೆಂದು ಎಚ್ಚರಿಕೆಯಿಂದ ಯೋಚಿಸಲು ನಿರ್ಧರಿಸಿದರು, ಪ್ರಭಾವದ ವಸ್ತುವು ತಂಡಗಳು ಎಂಬ ಅಂಶವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರು.
DevOps ಮೆಟ್ರಿಕ್‌ಗಳ ಉದ್ದೇಶ
ಪ್ರತಿಯೊಬ್ಬರೂ ವಿತರಣಾ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. 200 ದಿನಗಳು ಖಂಡಿತವಾಗಿಯೂ ಒಳ್ಳೆಯದಲ್ಲ.
ಆದರೆ ಹೇಗೆ, ಅದು ಪ್ರಶ್ನೆ?
ಕಂಪನಿಯು ನೂರಾರು ತಂಡಗಳನ್ನು ನೇಮಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಸಾವಿರಾರು ವಿತರಣೆಗಳು ಪ್ರತಿದಿನ DevOps ಪೈಪ್‌ಲೈನ್ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ನಿಜವಾದ ವಿತರಣಾ ಸಮಯವು ವಿತರಣೆಯಾಗಿ ಗೋಚರಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ತಂಡವು ತನ್ನದೇ ಆದ ಸಮಯ ಮತ್ತು ತನ್ನದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಈ ಅವ್ಯವಸ್ಥೆಯ ನಡುವೆ ನೀವು ಏನನ್ನಾದರೂ ಹೇಗೆ ಕಂಡುಹಿಡಿಯಬಹುದು?
ಉತ್ತರವು ಸ್ವಾಭಾವಿಕವಾಗಿ ಹುಟ್ಟಿಕೊಂಡಿತು - ನಾವು ಸಮಸ್ಯೆಯ ತಂಡಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ಅವರೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ಅದು ಏಕೆ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು "ಒಳ್ಳೆಯ" ತಂಡಗಳಿಂದ ಕಲಿಯಬೇಕು. ಮತ್ತು ಇದನ್ನು ಮಾಡಲು, ನೀವು ಪ್ರತಿಯೊಂದು DevOps ಸ್ಟ್ಯಾಂಡ್‌ಗಳಲ್ಲಿ ತಂಡಗಳು ಕಳೆದ ಸಮಯವನ್ನು ಅಳೆಯುವ ಅಗತ್ಯವಿದೆ:
"ಸಿಸ್ಟಮ್‌ನ ಉದ್ದೇಶವು ತಂಡಗಳನ್ನು ಅವರು ಸ್ಟ್ಯಾಂಡ್‌ಗಳನ್ನು ಹಾದುಹೋಗುವ ಸಮಯವನ್ನು ಆಧರಿಸಿ ಆಯ್ಕೆ ಮಾಡುವುದು, ಅಂದರೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಆಯ್ಕೆಮಾಡಿದ ಸಮಯದೊಂದಿಗೆ ಆಜ್ಞೆಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಬೇಕು, ಮತ್ತು ಸಂಖ್ಯೆಯಲ್ಲ.
ಒಟ್ಟಾರೆಯಾಗಿ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಎಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ ಮತ್ತು ಸ್ಟ್ಯಾಂಡ್‌ಗಳ ನಡುವೆ ಅಲಭ್ಯತೆಯಲ್ಲಿ ಎಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡರೆ, ನಾವು ತಂಡಗಳನ್ನು ಹುಡುಕಬಹುದು, ಅವರನ್ನು ಕರೆದು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಕಾರಣಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ತೊಡೆದುಹಾಕಬಹುದು, ”ಎಂದು ಇವಾನ್ ಭಾವಿಸಿದರು.
DevOps ಗಾಗಿ ಡೆಲಿವರಿ ಸಮಯವನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕುವುದು
ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, DevOps ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಅದರ ಸಾರವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.
ಕಂಪನಿಯು ಸೀಮಿತ ಸಂಖ್ಯೆಯ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ಅವರಿಂದ ಮಾತ್ರ ಪಡೆಯಬಹುದು ಮತ್ತು ಬೇರೆಲ್ಲಿಯೂ ಇಲ್ಲ.
ಕಂಪನಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಜಿರಾದಲ್ಲಿ ನೋಂದಾಯಿಸಲಾಗಿದೆ. ಕಾರ್ಯವನ್ನು ಕೈಗೆತ್ತಿಕೊಂಡಾಗ, ಅದಕ್ಕಾಗಿ ಒಂದು ಶಾಖೆಯನ್ನು ರಚಿಸಲಾಯಿತು ಮತ್ತು ಅನುಷ್ಠಾನದ ನಂತರ, ಬಿಟ್‌ಬಕೆಟ್ ಮತ್ತು ಪುಲ್ ವಿನಂತಿಗೆ ಬದ್ಧತೆಯನ್ನು ಮಾಡಲಾಯಿತು. PR (ಪುಲ್ ವಿನಂತಿ) ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ವಿತರಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು Nexus ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
ಮುಂದೆ, ರೋಲ್‌ಔಟ್, ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆಯ ಸರಿಯಾದತೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹಲವಾರು ಸ್ಟ್ಯಾಂಡ್‌ಗಳಲ್ಲಿ ವಿತರಣೆಯನ್ನು ಹೊರತರಲಾಯಿತು:
ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಸಮಯವನ್ನು ಲೆಕ್ಕಹಾಕಲು ಯಾವ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಯಾವ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ಇವಾನ್ ವಿವರಿಸಿದ್ದಾರೆ:
- Nexus ನಿಂದ - ವಿತರಣಾ ರಚನೆಯ ಸಮಯ ಮತ್ತು ಕಮಾಂಡ್ ಕೋಡ್ ಹೊಂದಿರುವ ಫೋಲ್ಡರ್‌ನ ಹೆಸರು
- ಜೆಂಕಿನ್ಸ್‌ನಿಂದ - ಪ್ರಾರಂಭದ ಸಮಯ, ಅವಧಿ ಮತ್ತು ಪ್ರತಿ ಕೆಲಸದ ಫಲಿತಾಂಶ, ಸ್ಟ್ಯಾಂಡ್ ಹೆಸರು (ಕೆಲಸದ ನಿಯತಾಂಕಗಳಲ್ಲಿ), ಹಂತಗಳು (ಕೆಲಸದ ಹಂತಗಳು), ನೆಕ್ಸಸ್‌ನಲ್ಲಿ ವಿತರಣೆಗೆ ಲಿಂಕ್ ಮಾಡಿ.
- ಜಿರಾ ಮತ್ತು ಬಿಟ್‌ಬಕೆಟ್ ಅನ್ನು ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಸೇರಿಸದಿರಲು ಇವಾನ್ ನಿರ್ಧರಿಸಿದರು, ಏಕೆಂದರೆ... ಅವು ಅಭಿವೃದ್ಧಿಯ ಹಂತಕ್ಕೆ ಹೆಚ್ಚು ಸಂಬಂಧಿಸಿವೆ ಮತ್ತು ಸ್ಟ್ಯಾಂಡ್‌ಗಳಲ್ಲಿ ಸಿದ್ಧಪಡಿಸಿದ ವಿತರಣೆಯನ್ನು ಹೊರತರಲು ಅಲ್ಲ.
ಲಭ್ಯವಿರುವ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ಈ ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ಚಿತ್ರಿಸಲಾಗಿದೆ:
ವಿತರಣೆಗಳನ್ನು ರಚಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಎಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದರಿಂದ, ಸಂಪೂರ್ಣ DevOps ಪೈಪ್‌ಲೈನ್ (ಪೂರ್ಣ ಚಕ್ರ) ಮೂಲಕ ಹೋಗುವ ಒಟ್ಟು ವೆಚ್ಚವನ್ನು ನೀವು ಸುಲಭವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು.
ಇವಾನ್ ಕೊನೆಗೊಂಡ DevOps ಮೆಟ್ರಿಕ್‌ಗಳು ಇಲ್ಲಿವೆ:
- ರಚಿಸಲಾದ ವಿತರಣೆಗಳ ಸಂಖ್ಯೆ
- ಸ್ಟ್ಯಾಂಡ್‌ಗೆ "ಬಂದ" ಮತ್ತು ಸ್ಟ್ಯಾಂಡ್ ಅನ್ನು "ಪಾಸ್" ಮಾಡಿದ ವಿತರಣೆಗಳ ಹಂಚಿಕೆ
- ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಕಳೆದ ಸಮಯ (ಸ್ಟ್ಯಾಂಡ್ ಸೈಕಲ್)
- ಪೂರ್ಣ ಚಕ್ರ (ಎಲ್ಲಾ ಸ್ಟ್ಯಾಂಡ್‌ಗಳಿಗೆ ಒಟ್ಟು ಸಮಯ)
- ಕೆಲಸದ ಅವಧಿ
- ಸ್ಟ್ಯಾಂಡ್‌ಗಳ ನಡುವೆ ಅಲಭ್ಯತೆ
- ಅದೇ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಉದ್ಯೋಗ ಲಾಂಚ್‌ಗಳ ನಡುವೆ ಡೌನ್‌ಟೈಮ್
ಒಂದೆಡೆ, ಮೆಟ್ರಿಕ್‌ಗಳು ಸಮಯದ ಪರಿಭಾಷೆಯಲ್ಲಿ DevOps ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ನಿರೂಪಿಸುತ್ತವೆ, ಮತ್ತೊಂದೆಡೆ, ಅವುಗಳನ್ನು ತುಂಬಾ ಸರಳವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.
ಉತ್ತಮವಾಗಿ ಮಾಡಿದ ಕೆಲಸದಿಂದ ತೃಪ್ತರಾದ ಇವಾನ್ ಪ್ರಸ್ತುತಿಯನ್ನು ಮಾಡಿದರು ಮತ್ತು ಅದನ್ನು ನಿರ್ವಹಣೆಗೆ ಪ್ರಸ್ತುತಪಡಿಸಲು ಹೋದರು.
ಅವನು ಕತ್ತಲೆಯಾದ ಮತ್ತು ತನ್ನ ಕೈಗಳಿಂದ ಹಿಂತಿರುಗಿದನು.
"ಇದು ಒಂದು ವೈಫಲ್ಯ, ಸಹೋದರ," ವ್ಯಂಗ್ಯ ಸಹೋದ್ಯೋಗಿ ಮುಗುಳ್ನಕ್ಕು ...
ಲೇಖನದಲ್ಲಿ ಇನ್ನಷ್ಟು ಓದಿ "».
ಮೂಲ: www.habr.com