ರಷ್ಯಾದಲ್ಲಿ DevOps ರಾಜ್ಯ 2020

ಯಾವುದರ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ?

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

ಆದರೆ ಅಂತಹ ಅಧ್ಯಯನವನ್ನು ನಡೆಸಿದ ದಿನ ಬಂದಿದೆ, ಮತ್ತು ಇಂದು ನಾವು ಫಲಿತಾಂಶಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ರಷ್ಯಾದಲ್ಲಿ DevOps ಸ್ಥಿತಿಯನ್ನು ಕಂಪನಿಗಳು ಜಂಟಿಯಾಗಿ ಅಧ್ಯಯನ ಮಾಡಿದವು "ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42"ಮತ್ತು"ಒಂಟಿಕೊ". Express 42 ತಂತ್ರಜ್ಞಾನ ಕಂಪನಿಗಳು DevOps ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಪರಿಕರಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ರಷ್ಯಾದಲ್ಲಿ DevOps ಕುರಿತು ಮಾತನಾಡಿದ ಮೊದಲಿಗರಲ್ಲಿ ಒಬ್ಬರು. ಅಧ್ಯಯನದ ಲೇಖಕರು, ಇಗೊರ್ ಕುರೊಚ್ಕಿನ್ ಮತ್ತು ವಿಟಾಲಿ ಖಬರೋವ್ ಅವರು ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42 ನಲ್ಲಿ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಸಮಾಲೋಚನೆಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ, ಆದರೆ ವಿವಿಧ ಕಂಪನಿಗಳಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಅನುಭವದಿಂದ ತಾಂತ್ರಿಕ ಹಿನ್ನೆಲೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ. 8 ವರ್ಷಗಳಿಂದ, ಸಹೋದ್ಯೋಗಿಗಳು ಡಜನ್‌ಗಟ್ಟಲೆ ಕಂಪನಿಗಳು ಮತ್ತು ಯೋಜನೆಗಳನ್ನು ನೋಡಿದ್ದಾರೆ - ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಿಂದ ಉದ್ಯಮಗಳವರೆಗೆ - ವಿಭಿನ್ನ ಸಮಸ್ಯೆಗಳು, ಜೊತೆಗೆ ವಿಭಿನ್ನ ಸಾಂಸ್ಕೃತಿಕ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ಪ್ರಬುದ್ಧತೆ.

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

DevOps ಸಂಶೋಧನೆ

ಸಂಭಾಷಣೆಯನ್ನು ಇಗೊರ್ ಕುರೊಚ್ಕಿನ್ ಪ್ರಾರಂಭಿಸಿದರು.

DevOps ಕಾನ್ಫರೆನ್ಸ್‌ಗಳಲ್ಲಿ ನಾವು ನಿಯಮಿತವಾಗಿ ಪ್ರೇಕ್ಷಕರನ್ನು ಕೇಳುತ್ತೇವೆ, "ಈ ವರ್ಷದ DevOps ಸ್ಥಿತಿ ವರದಿಯನ್ನು ನೀವು ಓದಿದ್ದೀರಾ?" ಕೆಲವರು ತಮ್ಮ ಕೈಗಳನ್ನು ಮೇಲಕ್ಕೆತ್ತುತ್ತಾರೆ, ಮತ್ತು ನಮ್ಮ ಅಧ್ಯಯನವು ಮೂರನೆಯವರು ಮಾತ್ರ ಅವರನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಾರೆ ಎಂದು ತೋರಿಸಿದೆ. ನೀವು ಅಂತಹ ವರದಿಗಳನ್ನು ಎಂದಿಗೂ ನೋಡಿಲ್ಲದಿದ್ದರೆ, ಅವೆಲ್ಲವೂ ತುಂಬಾ ಹೋಲುತ್ತವೆ ಎಂದು ಈಗಿನಿಂದಲೇ ಹೇಳೋಣ. ಹೆಚ್ಚಾಗಿ ನುಡಿಗಟ್ಟುಗಳು ಇವೆ: "ಕಳೆದ ವರ್ಷಕ್ಕೆ ಹೋಲಿಸಿದರೆ ..."

ಇಲ್ಲಿ ನಮಗೆ ಮೊದಲ ಸಮಸ್ಯೆ ಇದೆ, ಮತ್ತು ಅದರ ನಂತರ ಇನ್ನೂ ಎರಡು:

1. ಕಳೆದ ವರ್ಷದ ಡೇಟಾ ನಮ್ಮ ಬಳಿ ಇಲ್ಲ. ರಷ್ಯಾದಲ್ಲಿ DevOps ರಾಜ್ಯವು ಯಾರಿಗೂ ಆಸಕ್ತಿಯಿಲ್ಲ;
2. ವಿಧಾನಶಾಸ್ತ್ರ. ಊಹೆಗಳನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸುವುದು, ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು, ಹೇಗೆ ವಿಶ್ಲೇಷಿಸುವುದು, ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸುವುದು, ಸಂಪರ್ಕಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ;
3. ಪರಿಭಾಷೆ. ಎಲ್ಲಾ ವರದಿಗಳು ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿವೆ, ಅನುವಾದದ ಅಗತ್ಯವಿದೆ, ಸಾಮಾನ್ಯ DevOps ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಇನ್ನೂ ಆವಿಷ್ಕರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಬರುತ್ತಾರೆ.

ಪ್ರಪಂಚದಾದ್ಯಂತ DevOps ರಾಜ್ಯದ ವಿಶ್ಲೇಷಣೆಗಳನ್ನು ಹೇಗೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಐತಿಹಾಸಿಕ ಹಿನ್ನೆಲೆ

DevOps ಸಂಶೋಧನೆಯನ್ನು 2011 ರಿಂದ ನಡೆಸಲಾಗಿದೆ. ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳ ಡೆವಲಪರ್ ಪಪೆಟ್, ಅವುಗಳನ್ನು ನಡೆಸುವಲ್ಲಿ ಮೊದಲಿಗರು. ಆ ಸಮಯದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ರೂಪದಲ್ಲಿ ವಿವರಿಸುವ ಮುಖ್ಯ ಸಾಧನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. 2013 ರವರೆಗೆ, ಈ ಅಧ್ಯಯನಗಳು ಕೇವಲ ಮುಚ್ಚಿದ ಸಮೀಕ್ಷೆಗಳು ಮತ್ತು ಯಾವುದೇ ಸಾರ್ವಜನಿಕ ವರದಿಗಳಿಲ್ಲ.

2013 ರಲ್ಲಿ, IT ಕ್ರಾಂತಿ ಕಾಣಿಸಿಕೊಂಡಿತು, DevOps ನಲ್ಲಿ ಎಲ್ಲಾ ಪ್ರಮುಖ ಪುಸ್ತಕಗಳ ಪ್ರಕಾಶಕರು. ಪಪಿಟ್ ಜೊತೆಗೆ, ಅವರು ಮೊದಲ ಸ್ಟೇಟ್ ಆಫ್ ಡೆವೊಪ್ಸ್ ಪ್ರಕಟಣೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದರು, ಅಲ್ಲಿ 4 ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು ಮೊದಲ ಬಾರಿಗೆ ಕಾಣಿಸಿಕೊಂಡವು. ಮುಂದಿನ ವರ್ಷ, ಉದ್ಯಮದ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಪರಿಕರಗಳ ಮೇಲಿನ ನಿಯಮಿತ ತಂತ್ರಜ್ಞಾನದ ರಾಡಾರ್‌ಗಳಿಗೆ ಹೆಸರುವಾಸಿಯಾದ ಸಲಹಾ ಸಂಸ್ಥೆಯಾದ ಥಾಟ್‌ವರ್ಕ್ಸ್ ತೊಡಗಿಸಿಕೊಂಡಿತು. ಮತ್ತು 2015 ರಲ್ಲಿ, ವಿಧಾನದೊಂದಿಗೆ ಒಂದು ವಿಭಾಗವನ್ನು ಸೇರಿಸಲಾಯಿತು, ಮತ್ತು ಅವರು ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು.

2016 ರಲ್ಲಿ, ಅಧ್ಯಯನದ ಲೇಖಕರು ತಮ್ಮ ಸ್ವಂತ ಕಂಪನಿ DORA (DevOps ಸಂಶೋಧನೆ ಮತ್ತು ಮೌಲ್ಯಮಾಪನ) ಅನ್ನು ರಚಿಸಿದ್ದಾರೆ, ವಾರ್ಷಿಕ ವರದಿಯನ್ನು ಪ್ರಕಟಿಸಿದರು. ಮುಂದಿನ ವರ್ಷ, DORA ಮತ್ತು ಪಪೆಟ್ ತಮ್ಮ ಕೊನೆಯ ಜಂಟಿ ವರದಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದರು.

ತದನಂತರ ಆಸಕ್ತಿದಾಯಕ ಏನೋ ಪ್ರಾರಂಭವಾಯಿತು:

2018 ರಲ್ಲಿ, ಕಂಪನಿಗಳು ಬೇರ್ಪಟ್ಟವು ಮತ್ತು ಎರಡು ಸ್ವತಂತ್ರ ವರದಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಯಿತು: ಒಂದು ಪಪಿಟ್‌ನಿಂದ, ಎರಡನೆಯದು Google ಜೊತೆಗೆ DORA ನಿಂದ. DORA ತನ್ನ ವಿಧಾನವನ್ನು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು, ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರೊಫೈಲ್‌ಗಳು ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಕಂಪನಿಯಾದ್ಯಂತದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ. ಮತ್ತು ಪಪಿಟ್ ಪ್ರಕ್ರಿಯೆಯ ವಿವರಣೆ ಮತ್ತು DevOps ನ ವಿಕಸನದೊಂದಿಗೆ ತನ್ನದೇ ಆದ ವಿಧಾನವನ್ನು ನೀಡಿತು. ಆದರೆ ಕಥೆಯು ಮೂಲವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ, 2019 ರಲ್ಲಿ ಪಪಿಟ್ ಈ ವಿಧಾನವನ್ನು ಕೈಬಿಟ್ಟಿತು ಮತ್ತು ವರದಿಗಳ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿತು, ಇದು ಪ್ರಮುಖ ಅಭ್ಯಾಸಗಳನ್ನು ಮತ್ತು ಅವರ ದೃಷ್ಟಿಕೋನದಿಂದ DevOps ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡಿದೆ. ನಂತರ ಮತ್ತೊಂದು ಘಟನೆ ಸಂಭವಿಸಿದೆ: Google DORA ಅನ್ನು ಖರೀದಿಸಿತು ಮತ್ತು ಒಟ್ಟಿಗೆ ಅವರು ಮತ್ತೊಂದು ವರದಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದರು. ನೀವು ಅವನನ್ನು ನೋಡಿರಬಹುದು.

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

ಆದರೆ DORA ಮತ್ತು Google ನಿಂದ ಇನ್ನೂ ಯಾವುದೇ ಪ್ರಕಟಣೆ ಇಲ್ಲ. ಮೇ ತಿಂಗಳಲ್ಲಿ, ಸಮೀಕ್ಷೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾರಂಭವಾದಾಗ, ಡೋರಾ ಸಂಸ್ಥಾಪಕರಲ್ಲಿ ಒಬ್ಬರಾದ ನಿಕೋಲ್ ಫೋರ್ಸ್‌ಗ್ರೆನ್ ಮತ್ತೊಂದು ಕಂಪನಿಗೆ ತೆರಳಿದ್ದಾರೆ ಎಂಬ ಮಾಹಿತಿ ಬಂದಿತು. ಆದ್ದರಿಂದ, ಈ ವರ್ಷ ಡೋರಾದಿಂದ ಯಾವುದೇ ಸಂಶೋಧನೆ ಮತ್ತು ವರದಿ ಇರುವುದಿಲ್ಲ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ.

ರಷ್ಯಾದಲ್ಲಿ ವಿಷಯಗಳು ಹೇಗಿವೆ?

ನಾವು DevOps ಸಂಶೋಧನೆಯನ್ನು ಮಾಡಿಲ್ಲ. ನಾವು ಕಾನ್ಫರೆನ್ಸ್‌ಗಳಲ್ಲಿ ಮಾತನಾಡಿದ್ದೇವೆ, ಇತರ ಜನರ ಸಂಶೋಧನೆಗಳನ್ನು ಪುನಃ ಹೇಳುತ್ತೇವೆ ಮತ್ತು ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್ 2019 ಕ್ಕೆ "ಸ್ಟೇಟ್ ಆಫ್ ಡೆವೊಪ್ಸ್" ಅನ್ನು ಅನುವಾದಿಸಿದೆ (ನೀವು ಅವರ ಪ್ರಕಟಣೆಯನ್ನು ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ಕಾಣಬಹುದು), ಅವರಿಗೆ ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ಮತ್ತು ಇದು ಎಲ್ಲಾ.

ಆದ್ದರಿಂದ, ನಾವು DORA ವಿಧಾನಗಳು ಮತ್ತು ಸಂಶೋಧನೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ರಷ್ಯಾದಲ್ಲಿ ನಮ್ಮದೇ ಆದ ಸಂಶೋಧನೆ ನಡೆಸಿದ್ದೇವೆ. ಪರಿಭಾಷೆ ಮತ್ತು ಅನುವಾದದ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸೇರಿದಂತೆ ನಮ್ಮ ಸಂಶೋಧನೆಗಾಗಿ ನಾವು ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್‌ನ ಸಹೋದ್ಯೋಗಿಗಳ ವರದಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ. ಮತ್ತು ಉದ್ಯಮ-ಸಂಬಂಧಿತ ಪ್ರಶ್ನೆಗಳನ್ನು DORA ವರದಿಗಳು ಮತ್ತು ಈ ವರ್ಷದ ಪಪಿಟ್ ಪ್ರಶ್ನಾವಳಿಯಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ.

ಸಂಶೋಧನಾ ಪ್ರಕ್ರಿಯೆ

ವರದಿ ಅಂತಿಮ ಭಾಗ ಮಾತ್ರ. ಸಂಪೂರ್ಣ ಸಂಶೋಧನಾ ಪ್ರಕ್ರಿಯೆಯು ನಾಲ್ಕು ಪ್ರಮುಖ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

ತಯಾರಿಕೆಯ ಹಂತದಲ್ಲಿ, ನಾವು ಉದ್ಯಮದ ತಜ್ಞರನ್ನು ಸಂದರ್ಶಿಸಿದೆವು ಮತ್ತು ಊಹೆಗಳ ಪಟ್ಟಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ. ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ, ಪ್ರಶ್ನೆಗಳನ್ನು ಸಂಕಲಿಸಲಾಗಿದೆ ಮತ್ತು ಇಡೀ ಆಗಸ್ಟ್‌ಗೆ ಸಮೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ನಂತರ ನಾವು ವಿಶ್ಲೇಷಿಸಿ ವರದಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ. DORA ಗಾಗಿ, ಈ ಪ್ರಕ್ರಿಯೆಯು 6 ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನಾವು 3 ತಿಂಗಳೊಳಗೆ ಭೇಟಿಯಾದೆವು, ಮತ್ತು ಈಗ ನಾವು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ: ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮಾತ್ರ ನೀವು ಯಾವ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬೇಕೆಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ.

ಭಾಗವಹಿಸುವವರು

ಎಲ್ಲಾ ವಿದೇಶಿ ವರದಿಗಳು ಭಾಗವಹಿಸುವವರ ಭಾವಚಿತ್ರದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ರಷ್ಯಾದಿಂದ ಬಂದವರಲ್ಲ. ರಷ್ಯಾದ ಪ್ರತಿಕ್ರಿಯಿಸುವವರ ಶೇಕಡಾವಾರು ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ 5 ರಿಂದ 1% ವರೆಗೆ ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇದು ಯಾವುದೇ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.

ವೇಗವರ್ಧಿತ ಸ್ಥಿತಿಯ DevOps 2019 ವರದಿಯಿಂದ ನಕ್ಷೆ:

ನಮ್ಮ ಅಧ್ಯಯನದಲ್ಲಿ, ನಾವು 889 ಜನರನ್ನು ಸಂದರ್ಶಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆ - ಇದು ಸಾಕಷ್ಟು (ಡೋರಾ ಸಮೀಕ್ಷೆಗಳು ವಾರ್ಷಿಕವಾಗಿ ಅದರ ವರದಿಗಳಲ್ಲಿ ಸಾವಿರ ಜನರು) ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಗುರಿಯನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ:

ನಿಜ, ನಮ್ಮ ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರು ಅಂತ್ಯವನ್ನು ತಲುಪಲಿಲ್ಲ: ಪೂರ್ಣಗೊಂಡ ಶೇಕಡಾವಾರು ಅರ್ಧಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಕಡಿಮೆಯಾಗಿದೆ. ಆದರೆ ಪ್ರಾತಿನಿಧಿಕ ಮಾದರಿಯನ್ನು ಪಡೆಯಲು ಮತ್ತು ವಿಶ್ಲೇಷಣೆ ನಡೆಸಲು ಇದು ಸಾಕಾಗಿತ್ತು. DORA ತನ್ನ ವರದಿಗಳಲ್ಲಿ ಭರ್ತಿ ಶೇಕಡಾವಾರುಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಯಾವುದೇ ಹೋಲಿಕೆ ಇಲ್ಲ.

ಕೈಗಾರಿಕೆಗಳು ಮತ್ತು ಸ್ಥಾನಗಳು

ನಮ್ಮ ಪ್ರತಿಸ್ಪಂದಕರು ಒಂದು ಡಜನ್ ಕೈಗಾರಿಕೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತಾರೆ. ಮಾಹಿತಿ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿ ಅರ್ಧ ಕೆಲಸ. ಇದರ ನಂತರ ಹಣಕಾಸು ಸೇವೆಗಳು, ವ್ಯಾಪಾರ, ದೂರಸಂಪರ್ಕ ಮತ್ತು ಇತರರು. ಸ್ಥಾನಗಳಲ್ಲಿ ಪರಿಣಿತರು (ಡೆವಲಪರ್, ಪರೀಕ್ಷಕ, ಕಾರ್ಯಾಚರಣೆ ಎಂಜಿನಿಯರ್) ಮತ್ತು ನಿರ್ವಹಣಾ ಸಿಬ್ಬಂದಿ (ತಂಡಗಳ ಮುಖ್ಯಸ್ಥರು, ಗುಂಪುಗಳು, ಪ್ರದೇಶಗಳು, ನಿರ್ದೇಶಕರು):

ಎರಡರಲ್ಲಿ ಒಬ್ಬರು ಮಧ್ಯಮ ಗಾತ್ರದ ಕಂಪನಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಪ್ರತಿ ಮೂರನೇ ವ್ಯಕ್ತಿ ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಹೆಚ್ಚಿನವರು 9 ಜನರ ತಂಡಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಪ್ರತ್ಯೇಕವಾಗಿ, ನಾವು ಮುಖ್ಯ ಚಟುವಟಿಕೆಗಳ ಬಗ್ಗೆ ಕೇಳಿದ್ದೇವೆ ಮತ್ತು ಹೆಚ್ಚಿನವು ಹೇಗಾದರೂ ಕಾರ್ಯಾಚರಣೆಗೆ ಸಂಬಂಧಿಸಿವೆ ಮತ್ತು ಸುಮಾರು 40% ಜನರು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ:

ಆದ್ದರಿಂದ ನಾವು ವಿವಿಧ ಕೈಗಾರಿಕೆಗಳು, ಕಂಪನಿಗಳು, ತಂಡಗಳ ಪ್ರತಿನಿಧಿಗಳ ಹೋಲಿಕೆ ಮತ್ತು ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. ನನ್ನ ಸಹೋದ್ಯೋಗಿ ವಿಟಾಲಿ ಖಬರೋವ್ ವಿಶ್ಲೇಷಣೆಯ ಬಗ್ಗೆ ಹೇಳುತ್ತಾರೆ.

ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಹೋಲಿಕೆ

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

ದುರದೃಷ್ಟವಶಾತ್, ನೀವು ಒಂದು ಕಡೆ ಪ್ರಶ್ನೆಗಳ ಪಟ್ಟಿಯನ್ನು ಮತ್ತು ಇನ್ನೊಂದೆಡೆ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಹೇಗಾದರೂ ಅವುಗಳನ್ನು ಹೋಲಿಸಿ, ಹೇಳಿ: "ಹೌದು, ಎಲ್ಲವೂ ಹಾಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಾವು ಸರಿಯಾಗಿರುತ್ತೇವೆ" ಮತ್ತು ಚದುರಿಹೋಗಿ. ಇಲ್ಲ, ನಾವು ತಪ್ಪಾಗಿಲ್ಲ ಮತ್ತು ನಮ್ಮ ತೀರ್ಮಾನಗಳು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ವಿಧಾನ ಮತ್ತು ಸಂಖ್ಯಾಶಾಸ್ತ್ರದ ವಿಧಾನಗಳು ಅಗತ್ಯವಿದೆ. ನಂತರ ನಾವು ಈ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ ನಮ್ಮ ಮುಂದಿನ ಕೆಲಸವನ್ನು ನಿರ್ಮಿಸಬಹುದು:

ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಸ್

ನಾವು DORA ವಿಧಾನವನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದನ್ನು ಅವರು "ಡೆವೊಪ್ಸ್ ಅನ್ನು ವೇಗಗೊಳಿಸಿ" ಪುಸ್ತಕದಲ್ಲಿ ವಿವರವಾಗಿ ವಿವರಿಸಿದ್ದಾರೆ. ರಷ್ಯಾದ ಮಾರುಕಟ್ಟೆಗೆ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು ಸೂಕ್ತವಾಗಿವೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ, "ರಷ್ಯಾದಲ್ಲಿನ ಉದ್ಯಮವು ವಿದೇಶಿ ಉದ್ಯಮಕ್ಕೆ ಹೇಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಡೋರಾ ಬಳಸುವ ರೀತಿಯಲ್ಲಿಯೇ ಅವುಗಳನ್ನು ಬಳಸಬಹುದೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.

ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು:

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

DORA ತನ್ನ ಸಂಶೋಧನೆಯಲ್ಲಿ ಈ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಸಾಂಸ್ಥಿಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ಕಂಡುಹಿಡಿದಿದೆ. ನಮ್ಮ ಅಧ್ಯಯನದಲ್ಲಿ ನಾವು ಅದನ್ನು ಪರೀಕ್ಷಿಸುತ್ತೇವೆ.

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

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

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

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

ಗ್ರಾಂನಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳಲು ಎಷ್ಟು?

ನಾವು ಕ್ರಮಾನುಗತ ಕ್ಲಸ್ಟರ್ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ:

• ನಾವು ಪ್ರತಿಸ್ಪಂದಕರನ್ನು n-ಆಯಾಮದ ಜಾಗದಲ್ಲಿ ವಿತರಿಸುತ್ತೇವೆ, ಅಲ್ಲಿ ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯಿಸುವವರ ನಿರ್ದೇಶಾಂಕವು ಅವರ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರವಾಗಿರುತ್ತದೆ.
• ಪ್ರತಿ ಪ್ರತಿವಾದಿಯನ್ನು ಸಣ್ಣ ಕ್ಲಸ್ಟರ್ ಎಂದು ಘೋಷಿಸಲಾಗುತ್ತದೆ.
• ನಾವು ಪರಸ್ಪರ ಹತ್ತಿರವಿರುವ ಎರಡು ಸಮೂಹಗಳನ್ನು ಒಂದು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಆಗಿ ಸಂಯೋಜಿಸುತ್ತೇವೆ.
• ನಾವು ಮುಂದಿನ ಜೋಡಿ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ.

ಈ ರೀತಿಯಾಗಿ ನಾವು ನಮ್ಮ ಎಲ್ಲ ಪ್ರತಿಸ್ಪಂದಕರನ್ನು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಗುಂಪು ಮಾಡುತ್ತೇವೆ. ಡೆಂಡ್ರೊಗ್ರಾಮ್ (ಗುಂಪುಗಳ ನಡುವಿನ ಸಂಪರ್ಕಗಳ ಮರ) ಸಹಾಯದಿಂದ, ನಾವು ಎರಡು ನೆರೆಯ ಸಮೂಹಗಳ ನಡುವಿನ ಅಂತರವನ್ನು ನೋಡುತ್ತೇವೆ. ನಮಗೆ ಉಳಿದಿರುವುದು ಈ ಸಮೂಹಗಳ ನಡುವೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಅಂತರದ ಮಿತಿಯನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಹೀಗೆ ಹೇಳುವುದು: "ಈ ಎರಡು ಗುಂಪುಗಳು ಪರಸ್ಪರ ಸಾಕಷ್ಟು ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿವೆ ಏಕೆಂದರೆ ಅವುಗಳ ನಡುವಿನ ಅಂತರವು ದೈತ್ಯವಾಗಿದೆ."

ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಗುಪ್ತ ಸಮಸ್ಯೆ ಇದೆ: ನಮಗೆ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳಿಲ್ಲ - ನಾವು 2, 3, 4, 10 ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಪಡೆಯಬಹುದು. ಮತ್ತು ಮೊದಲ ಉಪಾಯವೆಂದರೆ - DORA ಮಾಡುವಂತೆ ನಮ್ಮ ಎಲ್ಲ ಪ್ರತಿಕ್ರಿಯಿಸಿದವರನ್ನು 4 ಗುಂಪುಗಳಾಗಿ ಏಕೆ ವಿಭಜಿಸಬಾರದು. ಆದರೆ ಈ ಗುಂಪುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು ಅತ್ಯಲ್ಪವಾಗುತ್ತವೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಿಸುವವರು ನಿಜವಾಗಿಯೂ ಅವರ ಗುಂಪಿಗೆ ಸೇರಿದವರು ಮತ್ತು ನೆರೆಹೊರೆಯವರಿಗೆ ಅಲ್ಲ ಎಂದು ನಾವು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ. ನಾವು ಇನ್ನೂ ರಷ್ಯಾದ ಮಾರುಕಟ್ಟೆಯನ್ನು ನಾಲ್ಕು ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಮೂರು ಪ್ರೊಫೈಲ್‌ಗಳಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ, ಅದರ ನಡುವೆ ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ಮಹತ್ವದ ವ್ಯತ್ಯಾಸವಿದೆ:

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

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

ನಂತರ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಇದೆಲ್ಲವನ್ನೂ ಹೇಗೆ ಬಳಸುವುದು?

ಹೇಗೆ ಬಳಸುವುದು

ನಾವು ಯಾವುದೇ ತಂಡ, 4 ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಟೇಬಲ್‌ಗೆ ಅನ್ವಯಿಸಿದರೆ, 85% ಪ್ರಕರಣಗಳಲ್ಲಿ ನಾವು ಸಂಪೂರ್ಣ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪಡೆಯುವುದಿಲ್ಲ - ಇದು ಕೇವಲ ಸರಾಸರಿ ಭಾಗವಹಿಸುವವರು, ಮತ್ತು ವಾಸ್ತವದಲ್ಲಿ ಏನಲ್ಲ. ನಾವೆಲ್ಲರೂ (ಮತ್ತು ಪ್ರತಿ ತಂಡ) ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿದ್ದೇವೆ.

ನಾವು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ: ನಾವು ನಮ್ಮ ಪ್ರತಿಸ್ಪಂದಕರು ಮತ್ತು DORA ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರೊಫೈಲ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಎಷ್ಟು ಪ್ರತಿಸ್ಪಂದಕರು ಈ ಅಥವಾ ಆ ಪ್ರೊಫೈಲ್‌ಗೆ ಸರಿಹೊಂದುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೋಡಿದ್ದೇವೆ. ಪ್ರತಿಕ್ರಿಯಿಸಿದವರಲ್ಲಿ ಕೇವಲ 16% ಮಾತ್ರ ಖಂಡಿತವಾಗಿಯೂ ಪ್ರೊಫೈಲ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬಿದ್ದಿದ್ದಾರೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಉಳಿದವುಗಳೆಲ್ಲವೂ ನಡುವೆ ಎಲ್ಲೋ ಚದುರಿಹೋಗಿವೆ:

ಇದರರ್ಥ ದಕ್ಷತೆಯ ಪ್ರೊಫೈಲ್ ಸೀಮಿತ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದೆ. ಮೊದಲ ಅಂದಾಜಿನಲ್ಲಿ ನೀವು ಎಲ್ಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಈ ಕೋಷ್ಟಕವನ್ನು ಬಳಸಬಹುದು: "ಓಹ್, ನಾವು ಮಧ್ಯಮ ಅಥವಾ ಹೆಚ್ಚಿನದಕ್ಕೆ ಹತ್ತಿರವಾಗಿದ್ದೇವೆಂದು ತೋರುತ್ತದೆ!" ಮುಂದೆ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಇದು ಸಾಕಾಗಬಹುದು. ಆದರೆ ನಿಮ್ಮ ಗುರಿಯು ಸ್ಥಿರವಾಗಿದ್ದರೆ, ನಿರಂತರ ಸುಧಾರಣೆ, ಮತ್ತು ಎಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು ಮತ್ತು ಏನು ಮಾಡಬೇಕೆಂದು ನೀವು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ತಿಳಿಯಲು ಬಯಸಿದರೆ, ಹೆಚ್ಚುವರಿ ಹಣದ ಅಗತ್ಯವಿದೆ. ನಾವು ಅವುಗಳನ್ನು ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ:

• ಡೋರಾ ಕ್ಯಾಲ್ಕುಲೇಟರ್
• ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42* (ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದೆ)
• ಸ್ವಂತ ಅಭಿವೃದ್ಧಿ (ನಿಮ್ಮ ಸ್ವಂತ ಆಂತರಿಕ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಅನ್ನು ನೀವು ರಚಿಸಬಹುದು).

ಅವರು ಏನು ಅಗತ್ಯವಿದೆ? ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು:

• ನಮ್ಮ ಸಂಸ್ಥೆಯೊಳಗಿನ ತಂಡವು ನಮ್ಮ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿದೆಯೇ?
• ಇಲ್ಲದಿದ್ದರೆ, ನಮ್ಮ ಕಂಪನಿ ಹೊಂದಿರುವ ಪರಿಣತಿಯ ಚೌಕಟ್ಟಿನೊಳಗೆ ನಾವು ಅದಕ್ಕೆ ಸಹಾಯ ಮಾಡಬಹುದೇ?
• ಹಾಗಿದ್ದಲ್ಲಿ, ನಾವು ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಮಾಡಬಹುದೇ?

ಕಂಪನಿಯೊಳಗಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು:

• ನಾವು ಯಾವ ತಂಡಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ?
• ತಂಡಗಳನ್ನು ಪ್ರೊಫೈಲ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಿ;
• ನೋಡಿ: ಓಹ್, ಈ ಆಜ್ಞೆಗಳು ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ (ಅವು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಹೊರತೆಗೆಯುವುದಿಲ್ಲ), ಆದರೆ ಇವುಗಳು ತಂಪಾಗಿವೆ: ಅವರು ಪ್ರತಿದಿನ ನಿಯೋಜಿಸುತ್ತಾರೆ, ದೋಷಗಳಿಲ್ಲದೆ, ಅವರು ಒಂದು ಗಂಟೆಗಿಂತ ಕಡಿಮೆ ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

ಮತ್ತು ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಇನ್ನೂ ಸಮನಾಗಿರದ ತಂಡಗಳಿಗೆ ಅಗತ್ಯವಾದ ಪರಿಣತಿ ಮತ್ತು ಪರಿಕರಗಳಿವೆ ಎಂದು ನೀವು ಕಂಡುಹಿಡಿಯಬಹುದು.

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

ಫೈನ್. ಮತ್ತು ನೀವು DORA ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ನಲ್ಲಿ ಎಲಿಟ್ ಗುಂಪಿನಲ್ಲಿದ್ದರೆ, ನೀವು ಏನು ಮಾಡಬೇಕು? ಇಲ್ಲಿ ಯಾವುದೇ ಉತ್ತಮ ಪರಿಹಾರವಿಲ್ಲ. ನೀವು ಉದ್ಯಮದಲ್ಲಿ ಮುಂಚೂಣಿಯಲ್ಲಿರುವ ಸಾಧ್ಯತೆಯಿದೆ ಮತ್ತು ಆಂತರಿಕ ಆರ್ & ಡಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರ್ಚು ಮಾಡುವ ಮೂಲಕ ಮತ್ತಷ್ಟು ವೇಗವರ್ಧನೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆ ಸಾಧ್ಯ.

ನಾವು ಸಿಹಿಯಾದ - ಹೋಲಿಕೆಗೆ ಹೋಗೋಣ.

ಹೋಲಿಕೆ

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

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

ನಾವು ರಷ್ಯಾದ ಉದ್ಯಮದೊಳಗೆ ನೇರ ಹೋಲಿಕೆಗೆ ಹೋದರೆ, ಉನ್ನತ ಪ್ರೊಫೈಲ್ ತಂಡಗಳು ಎಲ್ಲ ರೀತಿಯಲ್ಲೂ ಉತ್ತಮವಾಗಿವೆ ಎಂದು ನಾವು ನೋಡಬಹುದು. ಈ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಸಾಂಸ್ಥಿಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ನಡುವೆ ಸಂಬಂಧವಿದೆ ಎಂಬ ನಮ್ಮ ಊಹೆಯನ್ನು ಸಹ ನಾವು ದೃಢಪಡಿಸಿದ್ದೇವೆ: ಹೈ ಪ್ರೊಫೈಲ್ ತಂಡಗಳು ಗುರಿಗಳನ್ನು ಸಾಧಿಸುವುದು ಮಾತ್ರವಲ್ಲದೆ ಅವುಗಳನ್ನು ಮೀರುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.
ನಾವು ಹೈ ಪ್ರೊಫೈಲ್ ತಂಡಗಳಾಗೋಣ ಮತ್ತು ಅಲ್ಲಿ ನಿಲ್ಲಬಾರದು:

ಆದರೆ ಈ ವರ್ಷ ವಿಶೇಷವಾಗಿದೆ, ಮತ್ತು ಸಾಂಕ್ರಾಮಿಕ ರೋಗದಲ್ಲಿ ಕಂಪನಿಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ: ಉನ್ನತ ಪ್ರೊಫೈಲ್ ತಂಡಗಳು ಉದ್ಯಮದ ಸರಾಸರಿಗಿಂತ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಮತ್ತು ಉತ್ತಮವಾಗಿದೆ:

• ಹೊಸ ಉತ್ಪನ್ನಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಸಾಧ್ಯತೆ 1,5-2 ಪಟ್ಟು ಹೆಚ್ಚು,
• ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಸೌಕರ್ಯದ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು / ಅಥವಾ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವ ಸಾಧ್ಯತೆ 2 ಪಟ್ಟು ಹೆಚ್ಚು.

ಅಂದರೆ, ಅವರು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಸಾಮರ್ಥ್ಯಗಳು ವೇಗವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದಲು, ಹೊಸ ಉತ್ಪನ್ನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಉತ್ಪನ್ನಗಳನ್ನು ಮಾರ್ಪಡಿಸಲು, ಆ ಮೂಲಕ ಹೊಸ ಮಾರುಕಟ್ಟೆಗಳನ್ನು ಮತ್ತು ಹೊಸ ಬಳಕೆದಾರರನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡಿತು:

ನಮ್ಮ ತಂಡಗಳಿಗೆ ಬೇರೆ ಏನು ಸಹಾಯ ಮಾಡಿದೆ?

ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳು

ನಾವು ಪರೀಕ್ಷಿಸಿದ ಪ್ರತಿಯೊಂದು ಅಭ್ಯಾಸದ ಗಮನಾರ್ಹ ಸಂಶೋಧನೆಗಳ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಬಹುಶಃ ಬೇರೆ ಯಾವುದೋ ತಂಡಗಳಿಗೆ ಸಹಾಯ ಮಾಡಿದೆ, ಆದರೆ ನಾವು DevOps ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಮತ್ತು DevOps ಒಳಗೆ, ನಾವು ವಿಭಿನ್ನ ಪ್ರೊಫೈಲ್‌ಗಳ ತಂಡಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡುತ್ತೇವೆ.

ಸೇವೆಯಾಗಿ ವೇದಿಕೆ

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

ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ

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

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

ಏಕೀಕರಣ ಮತ್ತು ವಿತರಣೆ

ಅತ್ಯಂತ ನೀರಸ ವಿಭಾಗ, ಏಕೆಂದರೆ ನೀವು ಹೆಚ್ಚು ಯಾಂತ್ರೀಕೃತಗೊಂಡಿದ್ದೀರಿ ಎಂದು ನಾವು ದೃಢಪಡಿಸಿದ್ದೇವೆ, ನೀವು ಕೋಡ್‌ನೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತೀರಿ, ನೀವು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.

ವಾಸ್ತುಶಿಲ್ಪ

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

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

ಇದೆಲ್ಲವನ್ನೂ ನಾವು ಹೇಗೆ ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ?

DORA ವಿಧಾನವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸಲು ನಾವು ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯಿದೆ. DORA ಸಾಕಷ್ಟು ಪ್ರಾಯೋಜಕತ್ವವನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಅವರ ಸಂಶೋಧನೆಯು ಅರ್ಧ ವರ್ಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ನಾವು ನಮ್ಮ ಸಂಶೋಧನೆಯನ್ನು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಮಾಡಿದ್ದೇವೆ. DORA ಮಾಡುವಂತೆ ನಾವು DevOps ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸಲು ಬಯಸಿದ್ದೇವೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ಅದನ್ನು ಮಾಡುತ್ತೇವೆ. ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಹೀಟ್ ಮ್ಯಾಪ್‌ಗಳಿಗೆ ನಮ್ಮನ್ನು ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ:

ನಾವು ಪ್ರತಿ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿನ ತಂಡಗಳಾದ್ಯಂತ ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳ ವಿತರಣೆಯನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಹೈ ಪ್ರೊಫೈಲ್ ತಂಡಗಳು, ಸರಾಸರಿಯಾಗಿ, ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸುವ ಸಾಧ್ಯತೆಯಿದೆ ಎಂದು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಮ್ಮಲ್ಲಿ ನೀವು ಈ ಎಲ್ಲದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು ವರದಿ.

ಬದಲಾವಣೆಗಾಗಿ, ಸಂಕೀರ್ಣ ಅಂಕಿಅಂಶಗಳಿಂದ ಸರಳವಾದವುಗಳಿಗೆ ಬದಲಾಯಿಸೋಣ.

ನಾವು ಇನ್ನೇನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ?

ಪರಿಕರಗಳು

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

ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಳಲ್ಲಿ, ಇದು ಯಾರಿಗೂ ರಹಸ್ಯವಲ್ಲ, ಕುಬರ್ನೆಟ್ಸ್ ಮುನ್ನಡೆಯಲ್ಲಿದ್ದಾರೆ (52%). ನಂತರದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಡಾಕರ್ ಸ್ವಾರ್ಮ್ (ಸುಮಾರು 12%). ಅತ್ಯಂತ ಜನಪ್ರಿಯ CI ವ್ಯವಸ್ಥೆಗಳು ಜೆಂಕಿನ್ಸ್ ಮತ್ತು GitLab. ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯು ಅನ್ಸಿಬಲ್ ಆಗಿದೆ, ನಂತರ ನಮ್ಮ ಪ್ರೀತಿಯ ಶೆಲ್.

ಅಮೆಜಾನ್ ಪ್ರಸ್ತುತ ಕ್ಲೌಡ್ ಹೋಸ್ಟಿಂಗ್ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಪ್ರಮುಖವಾಗಿದೆ. ರಷ್ಯಾದ ಮೋಡಗಳ ಪಾಲು ಕ್ರಮೇಣ ಹೆಚ್ಚುತ್ತಿದೆ. ಮುಂದಿನ ವರ್ಷ ರಷ್ಯಾದ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು ಹೇಗೆ ಭಾವಿಸುತ್ತಾರೆ, ಅವರ ಮಾರುಕಟ್ಟೆ ಪಾಲು ಹೆಚ್ಚಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನೋಡಲು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಅವುಗಳು, ಅವುಗಳನ್ನು ಬಳಸಬಹುದು, ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು:

ನಾನು ಇಗೊರ್‌ಗೆ ನೆಲವನ್ನು ಹಾದು ಹೋಗುತ್ತೇನೆ, ಅವರು ಇನ್ನೂ ಕೆಲವು ಅಂಕಿಅಂಶಗಳನ್ನು ನೀಡುತ್ತಾರೆ.

ಆಚರಣೆಗಳ ಪ್ರಸರಣ

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

ಅಗೈಲ್ ಮತ್ತು ಡೆವೊಪ್ಸ್

ಅಗೈಲ್ ಮತ್ತು ಡೆವೊಪ್ಸ್ ನಡುವಿನ ಸಂಪರ್ಕದ ಪ್ರಶ್ನೆಯನ್ನು ಉದ್ಯಮದಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಚರ್ಚಿಸಲಾಗುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು 2019/2020 ಗಾಗಿ ಸ್ಟೇಟ್ ಆಫ್ ಅಗೈಲ್ ವರದಿಯಲ್ಲಿಯೂ ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಕಂಪನಿಗಳಲ್ಲಿ ಅಗೈಲ್ ಮತ್ತು ಡೆವೊಪ್ಸ್ ಚಟುವಟಿಕೆಗಳನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಹೋಲಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಅಗೈಲ್ ಇಲ್ಲದ DevOps ಅಪರೂಪ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಪ್ರತಿಕ್ರಿಯಿಸಿದವರಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಜನರಿಗೆ, ಅಗೈಲ್‌ನ ಹರಡುವಿಕೆಯು ಬಹಳ ಹಿಂದೆಯೇ ಪ್ರಾರಂಭವಾಯಿತು, ಮತ್ತು ಸುಮಾರು 20% ಜನರು ಏಕಕಾಲಿಕ ಆರಂಭವನ್ನು ಗಮನಿಸಿದರು, ಮತ್ತು ಕಡಿಮೆ ಪ್ರೊಫೈಲ್‌ನ ಚಿಹ್ನೆಗಳಲ್ಲಿ ಒಂದು ಅಗೈಲ್ ಮತ್ತು ಡೆವೊಪ್ಸ್ ಅಭ್ಯಾಸಗಳ ಅನುಪಸ್ಥಿತಿಯಾಗಿದೆ:

ಕಮಾಂಡ್ ಟೋಪೋಲಜೀಸ್

ಕಳೆದ ವರ್ಷದ ಕೊನೆಯಲ್ಲಿ, ಪುಸ್ತಕತಂಡದ ಟೋಪೋಲಜಿಗಳು”, ಇದು ಕಮಾಂಡ್ ಟೋಪೋಲಜಿಗಳನ್ನು ವಿವರಿಸುವ ಚೌಕಟ್ಟನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ. ಇದು ರಷ್ಯಾದ ಕಂಪನಿಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆಯೇ ಎಂಬುದು ನಮಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಮತ್ತು ನಾವು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದ್ದೇವೆ: "ನೀವು ಯಾವ ಮಾದರಿಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ?".

ಪ್ರತಿಕ್ರಿಯಿಸಿದವರಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಮೂಲಸೌಕರ್ಯ ತಂಡಗಳನ್ನು ಗಮನಿಸಲಾಗಿದೆ, ಹಾಗೆಯೇ ಅಭಿವೃದ್ಧಿ, ಪರೀಕ್ಷೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಪ್ರತ್ಯೇಕ ತಂಡಗಳು. ಪ್ರತ್ಯೇಕ DevOps ತಂಡಗಳು 45% ಅನ್ನು ಗುರುತಿಸಿವೆ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಪ್ರತಿನಿಧಿಗಳು ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಮುಂದೆ ಕ್ರಾಸ್-ಫಂಕ್ಷನಲ್ ತಂಡಗಳು ಬರುತ್ತವೆ, ಇದು ಹೈನಲ್ಲಿ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಪ್ರತ್ಯೇಕ SRE ಆಜ್ಞೆಗಳು ಹೈ, ಮಧ್ಯಮ ಪ್ರೊಫೈಲ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಕಡಿಮೆ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ವಿರಳವಾಗಿ ಕಂಡುಬರುತ್ತವೆ:

DevQaOps ಅನುಪಾತ

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

2021 ರ ಯೋಜನೆಗಳು

ಮುಂದಿನ ವರ್ಷದ ಯೋಜನೆಗಳಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯಿಸಿದವರು ಈ ಕೆಳಗಿನ ಚಟುವಟಿಕೆಗಳನ್ನು ಗಮನಿಸಿದರು:

ಇಲ್ಲಿ ನೀವು DevOps ಲೈವ್ 2020 ಕಾನ್ಫರೆನ್ಸ್‌ನೊಂದಿಗೆ ಛೇದಕವನ್ನು ನೋಡಬಹುದು. ನಾವು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ:

• ಉತ್ಪನ್ನವಾಗಿ ಮೂಲಸೌಕರ್ಯ
• DevOps ರೂಪಾಂತರ
• DevOps ಅಭ್ಯಾಸಗಳ ವಿತರಣೆ
• DevSecOps
• ಕೇಸ್ ಕ್ಲಬ್‌ಗಳು ಮತ್ತು ಚರ್ಚೆಗಳು

ಆದರೆ ನಮ್ಮ ಪ್ರಸ್ತುತಿಯ ಸಮಯವು ಎಲ್ಲಾ ವಿಷಯಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ತೆರೆಮರೆಯಲ್ಲಿ ಬಿಟ್ಟು:

• ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸೇವೆಯಾಗಿ ಮತ್ತು ಉತ್ಪನ್ನವಾಗಿ;
• ಕೋಡ್, ಪರಿಸರಗಳು ಮತ್ತು ಮೋಡಗಳಂತೆ ಮೂಲಸೌಕರ್ಯ;
• ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ವಿತರಣೆ;
• ವಾಸ್ತುಶಿಲ್ಪ;
• DevSecOps ಮಾದರಿಗಳು;
• ವೇದಿಕೆ ಮತ್ತು ಅಡ್ಡ-ಕ್ರಿಯಾತ್ಮಕ ತಂಡಗಳು.

ವರದಿ ನಾವು ಬೃಹತ್, 50 ಪುಟಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡಬಹುದು.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ

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

ರಷ್ಯಾದಲ್ಲಿ DevOps ರಾಜ್ಯದ ಮೊದಲ ಅಧ್ಯಯನದ ಫಲಿತಾಂಶಗಳು:

• ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಸ್. ಅಭಿವೃದ್ಧಿ, ಪರೀಕ್ಷೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಪ್ರಕ್ರಿಯೆಗಳ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು (ವಿತರಣಾ ಸಮಯ, ನಿಯೋಜನೆ ಆವರ್ತನ, ಚೇತರಿಕೆ ಸಮಯ ಮತ್ತು ಬದಲಾವಣೆಯ ವೈಫಲ್ಯಗಳು) ಸೂಕ್ತವೆಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.
• ಪ್ರೊಫೈಲ್‌ಗಳು ಹೆಚ್ಚು, ಮಧ್ಯಮ, ಕಡಿಮೆ. ಸಂಗ್ರಹಿಸಿದ ದತ್ತಾಂಶದ ಆಧಾರದ ಮೇಲೆ, ಮೆಟ್ರಿಕ್‌ಗಳು, ಅಭ್ಯಾಸಗಳು, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಪರಿಕರಗಳ ವಿಷಯದಲ್ಲಿ ವಿಶಿಷ್ಟ ಲಕ್ಷಣಗಳೊಂದಿಗೆ ಉನ್ನತ, ಮಧ್ಯಮ, ಕಡಿಮೆ ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ವಿಭಿನ್ನ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಿದೆ. ಹೈ ಪ್ರೊಫೈಲ್‌ನ ಪ್ರತಿನಿಧಿಗಳು ಕಡಿಮೆಗಿಂತ ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸುತ್ತಾರೆ. ಅವರು ತಮ್ಮ ಗುರಿಗಳನ್ನು ಸಾಧಿಸುವ ಮತ್ತು ಮೀರುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.
• ಸೂಚಕಗಳು, ಸಾಂಕ್ರಾಮಿಕ ಮತ್ತು 2021 ರ ಯೋಜನೆಗಳು. ಈ ವರ್ಷದ ವಿಶೇಷ ಸೂಚಕವೆಂದರೆ ಕಂಪನಿಗಳು ಸಾಂಕ್ರಾಮಿಕ ರೋಗವನ್ನು ಹೇಗೆ ನಿಭಾಯಿಸಿದವು. ಉನ್ನತ ಪ್ರತಿನಿಧಿಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರು, ಹೆಚ್ಚಿದ ಬಳಕೆದಾರರ ತೊಡಗಿಸಿಕೊಳ್ಳುವಿಕೆಯನ್ನು ಅನುಭವಿಸಿದರು ಮತ್ತು ಯಶಸ್ಸಿಗೆ ಮುಖ್ಯ ಕಾರಣಗಳು ಸಮರ್ಥ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಬಲವಾದ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಕೃತಿ.
• DevOps ಅಭ್ಯಾಸಗಳು, ಪರಿಕರಗಳು ಮತ್ತು ಅವುಗಳ ಅಭಿವೃದ್ಧಿ. ಮುಂದಿನ ವರ್ಷದ ಕಂಪನಿಗಳ ಮುಖ್ಯ ಯೋಜನೆಗಳಲ್ಲಿ DevOps ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಪರಿಕರಗಳ ಅಭಿವೃದ್ಧಿ, DevSecOps ಅಭ್ಯಾಸಗಳ ಪರಿಚಯ ಮತ್ತು ಸಾಂಸ್ಥಿಕ ರಚನೆಯಲ್ಲಿ ಬದಲಾವಣೆಗಳು ಸೇರಿವೆ. ಮತ್ತು DevOps ಅಭ್ಯಾಸಗಳ ಪರಿಣಾಮಕಾರಿ ಅನುಷ್ಠಾನ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪೈಲಟ್ ಯೋಜನೆಗಳು, ಸಮುದಾಯಗಳ ರಚನೆ ಮತ್ತು ಶ್ರೇಷ್ಠತೆಯ ಕೇಂದ್ರಗಳು, ಕಂಪನಿಯ ಮೇಲಿನ ಮತ್ತು ಕೆಳಗಿನ ಹಂತಗಳಲ್ಲಿನ ಉಪಕ್ರಮಗಳ ಸಹಾಯದಿಂದ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.

ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆ, ಕಥೆಗಳು, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕೇಳಲು ನಾವು ಇಷ್ಟಪಡುತ್ತೇವೆ. ಅಧ್ಯಯನದಲ್ಲಿ ಭಾಗವಹಿಸಿದ ಎಲ್ಲರಿಗೂ ನಾವು ಧನ್ಯವಾದಗಳನ್ನು ಅರ್ಪಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಂದಿನ ವರ್ಷ ನಿಮ್ಮ ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಎದುರುನೋಡುತ್ತೇವೆ.

ಮೂಲ: www.habr.com