ನಾನು ಇತ್ತೀಚೆಗೆ DevOpsForum 2019 ಗೆ ಹಾಜರಾಗಿದ್ದೇನೆ, ಇದನ್ನು Logrocon ಆಯೋಜಿಸಿದೆ. ಈ ಸಮ್ಮೇಳನದಲ್ಲಿ, ಭಾಗವಹಿಸುವವರು ವ್ಯಾಪಾರ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಮಾಹಿತಿ ತಂತ್ರಜ್ಞಾನ ಸೇವಾ ತಜ್ಞರ ನಡುವಿನ ಪರಿಣಾಮಕಾರಿ ಸಂವಹನಕ್ಕಾಗಿ ಪರಿಹಾರಗಳು ಮತ್ತು ಹೊಸ ಸಾಧನಗಳನ್ನು ಹುಡುಕಲು ಪ್ರಯತ್ನಿಸಿದರು.
ಸಮ್ಮೇಳನವು ಯಶಸ್ವಿಯಾಗಿದೆ: ನಿಜವಾಗಿಯೂ ಸಾಕಷ್ಟು ಉಪಯುಕ್ತ ವರದಿಗಳು, ಆಸಕ್ತಿದಾಯಕ ಪ್ರಸ್ತುತಿ ಸ್ವರೂಪಗಳು ಮತ್ತು ಸ್ಪೀಕರ್‌ಗಳೊಂದಿಗೆ ಸಾಕಷ್ಟು ಸಂವಹನಗಳಿವೆ. ಮತ್ತು ಯಾರೂ ನನಗೆ ಏನನ್ನೂ ಮಾರಾಟ ಮಾಡಲು ಪ್ರಯತ್ನಿಸದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ, ದೊಡ್ಡ ಸಮ್ಮೇಳನಗಳಲ್ಲಿ ಮಾತನಾಡುವವರು ಇತ್ತೀಚೆಗೆ ತಪ್ಪಿತಸ್ಥರಾಗಿದ್ದಾರೆ.
ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್, ಅಲ್ಫಾಸ್ಟ್ರಾಖೋವಾನಿ, ಮ್ಯಾಂಗೋ ಟೆಲಿಕಾಂನ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅನುಭವ ಮತ್ತು ಕಟ್ ಅಡಿಯಲ್ಲಿ ಇತರ ವಿವರಗಳ ಭಾಷಣಗಳಿಂದ ಒಂದು ಆಯ್ದ ಭಾಗ.
ನನ್ನ ಹೆಸರು ಯಾನಾ, ನಾನು ಪರೀಕ್ಷಕನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ, ನಾನು ಆಟೊಮೇಷನ್ ಮಾಡುತ್ತೇನೆ, ಹಾಗೆಯೇ DevOps, ಮತ್ತು ನಾನು ಸಮ್ಮೇಳನಗಳು ಮತ್ತು ಸಭೆಗಳಿಗೆ ಹೋಗುವುದನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ. ಕಳೆದ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ, ನಾನು ಒಲೆಗ್ ಬುನಿನ್ ಅವರ ಸಮ್ಮೇಳನಗಳಿಗೆ (ಹೈಲೋಡ್ ++, ಟೀಮ್‌ಲೀಡ್ ಕಾನ್ಫ್), ಜಗ್ ಈವೆಂಟ್‌ಗಳು (ಹೈಸೆನ್‌ಬಗ್, ಜೆಪಾಯಿಂಟ್), ಟೆಸ್ಟ್‌ಕಾನ್ ಮಾಸ್ಕೋ, ಡೆವೊಪ್ಸ್ ಪ್ರೊ ಮಾಸ್ಕೋ, ಬಿಗ್ ಡೇಟಾ ಮಾಸ್ಕೋಗಳಿಗೆ ಹೋಗಿದ್ದೇನೆ.
ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಸಮ್ಮೇಳನದ ಕಾರ್ಯಕ್ರಮದತ್ತ ಗಮನ ಸೆಳೆಯುತ್ತೇನೆ. ವರದಿ ಏನು ಎಂಬುದರ ಬಗ್ಗೆ ನಾನು ಕಡಿಮೆ ನೋಡುತ್ತೇನೆ ಮತ್ತು ಸ್ಪೀಕರ್‌ನಲ್ಲಿ ಹೆಚ್ಚು. ವರದಿಯು ತುಂಬಾ ತಾಂತ್ರಿಕ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕವಾಗಿದ್ದರೂ ಸಹ, ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿನ ವರದಿಯಿಂದ ಕೆಲವು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ನೀವು ಅನ್ವಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂಬುದು ಸತ್ಯವಲ್ಲ. ತದನಂತರ ನಿಮಗೆ ಸ್ಪೀಕರ್ ಅಗತ್ಯವಿದೆ.
ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್‌ನಲ್ಲಿ ಪೈಪ್ಲೈನ್ನ ಕೊನೆಯಲ್ಲಿ ಬೆಳಕು
ಸಾಮಾನ್ಯವಾಗಿ, ನನಗೆ ಆಸಕ್ತಿಯಿರುವ ಸೈಡ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ನಾನು ಸ್ಪೀಕರ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತೇನೆ. DevOpsForum 2019 ರಲ್ಲಿ, ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್‌ನ ಸ್ಪೀಕರ್, ಮಿಖಾಯಿಲ್ ಬಿಜಾನ್, ನನ್ನ ಆಸಕ್ತಿಯನ್ನು ಸೆಳೆದರು. ಅವರ ಭಾಷಣದ ಸಮಯದಲ್ಲಿ, ಅವರು ಕ್ರಮೇಣ ತಮ್ಮ ತಂಡಗಳನ್ನು DevOps ನಲ್ಲಿ ಹೇಗೆ ಸೆಳೆಯುತ್ತಿದ್ದಾರೆ, ಅವರಿಗೆ ಅದು ಏಕೆ ಬೇಕು ಮತ್ತು DevOps ರೂಪಾಂತರದ ಕಲ್ಪನೆಯನ್ನು ವ್ಯಾಪಾರಕ್ಕೆ ಹೇಗೆ ಮಾರಾಟ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಿದರು. ಸರಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಪೈಪ್ಲೈನ್ನ ಕೊನೆಯಲ್ಲಿ ಬೆಳಕನ್ನು ಹೇಗೆ ನೋಡಬೇಕೆಂದು ನಾನು ಮಾತನಾಡಿದೆ.
ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್‌ನಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ನಿರ್ದೇಶಕ ಮಿಖಾಯಿಲ್ ಬಿಜಾನ್
ಈಗ ಅವರು ತಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ "DevOps" ಹೊಂದಿಲ್ಲ. ಅಂದರೆ, ಅವನು ಕೆಲಸ ಮಾಡುತ್ತಾನೆ, ಆದರೆ ಎಲ್ಲಾ ತಂಡಗಳಲ್ಲಿ ಅಲ್ಲ. DevOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಅವರು ನಿರ್ದಿಷ್ಟ ಇಂಜಿನಿಯರ್‌ಗಳ ವಿಷಯದಲ್ಲಿ ಮತ್ತು ಉತ್ಪನ್ನದ ಅಗತ್ಯತೆ ಮತ್ತು ಈ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ಮಿಸಿದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಪರಿಪಕ್ವತೆಯ ದೃಷ್ಟಿಯಿಂದ ತಂಡಗಳ ಸನ್ನದ್ಧತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತಾರೆ. DevOps ಏಕೆ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ವ್ಯಾಪಾರಕ್ಕೆ ಹೇಗೆ ವಿವರಿಸಬೇಕೆಂದು ಮಿಶಾ ಹೇಳಿದರು.
ಬ್ಯಾಂಕಿಂಗ್ ವಿಭಾಗವು ಹಲವಾರು ಬೆಳವಣಿಗೆಯ ಚಾಲಕಗಳನ್ನು ಹೊಂದಿದೆ: ಸೇವೆಗಳ ವೆಚ್ಚ ಮತ್ತು ಕ್ಲೈಂಟ್ ಬೇಸ್ನ ವಿಸ್ತರಣೆ. ಸೇವೆಗಳ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಉತ್ತಮ ಚಾಲಕವಲ್ಲ, ಆದರೆ ಕ್ಲೈಂಟ್ ಬೇಸ್ ಅನ್ನು ಬೆಳೆಸುವುದು ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿದೆ. ಪ್ರತಿಸ್ಪರ್ಧಿಗಳು ವಸ್ತುನಿಷ್ಠವಾಗಿ ತಂಪಾದ ಉತ್ಪನ್ನವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದರೆ, ಎಲ್ಲಾ ಗ್ರಾಹಕರು ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತಾರೆ, ನಂತರ ಕಾಲಾನಂತರದಲ್ಲಿ ಮಾರುಕಟ್ಟೆ ಮಟ್ಟವು ಹೊರಬರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಮಾರುಕಟ್ಟೆಗೆ ಹೊಸ ಉತ್ಪನ್ನಗಳನ್ನು ಪರಿಚಯಿಸುವುದು ಮತ್ತು ಅವುಗಳ ಪರಿಚಯದ ವೇಗವು ಬ್ಯಾಂಕುಗಳು ಕೇಂದ್ರೀಕರಿಸುವ ಮುಖ್ಯ ವಿಷಯವಾಗಿದೆ. ಇದಕ್ಕಾಗಿಯೇ DevOps ಆಗಿದೆ ಮತ್ತು ವ್ಯಾಪಾರಗಳು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ.
ಮುಂದಿನ ಪ್ರಮುಖ ಟಿಪ್ಪಣಿ: DevOps ಯಾವಾಗಲೂ ಮಾರುಕಟ್ಟೆಗೆ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. DevOps ಏಕಾಂಗಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇದು ಉತ್ಪನ್ನವನ್ನು ಅಭಿವೃದ್ಧಿಯಿಂದ ಉತ್ಪಾದನೆಗೆ (ಕೋಡ್‌ನಿಂದ ಗ್ರಾಹಕರಿಗೆ) ರಚಿಸುವ ಮತ್ತು ಮಾರುಕಟ್ಟೆಗೆ ತರುವ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗವಾಗಿದೆ. ಆದರೆ ಕೋಡ್ ಮೊದಲು ಎಲ್ಲವೂ DevOps ಗೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸಿಲ್ಲ. ಅಂದರೆ, ಮಾರಾಟಗಾರರು ಮಾರುಕಟ್ಟೆಯನ್ನು ವರ್ಷಗಳವರೆಗೆ ಅಧ್ಯಯನ ಮಾಡಬಹುದು ಮತ್ತು ತಮ್ಮ ಇಡೀ ಜೀವನವನ್ನು ಪ್ರತಿಸ್ಪರ್ಧಿಗಳೊಂದಿಗೆ ಹಿಡಿಯಬಹುದು. ಕ್ಲೈಂಟ್‌ಗೆ ಏನು ಬೇಕು ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಈ ಅಥವಾ ಆ ವೈಶಿಷ್ಟ್ಯದ ಅನುಷ್ಠಾನವನ್ನು ಯೋಜಿಸುವುದು ಅವಶ್ಯಕ - ಆಗಾಗ್ಗೆ DevOps ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಕಂಪನಿಯು ತನ್ನ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಮೊದಲನೆಯದಾಗಿ, DevOps ಅನ್ನು ಹೇಗೆ ಬಳಸಬೇಕೆಂದು ಕಲಿಯುವುದು ಅವಶ್ಯಕ ಎಂದು ರೈಫಿಸೆನ್‌ಬ್ಯಾಂಕ್ ವ್ಯವಹಾರದೊಂದಿಗೆ ಒಪ್ಪಿಕೊಂಡಿತು. ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಲುವಾಗಿ ಆಟೊಮೇಷನ್ ಹೊಸ ಗ್ರಾಹಕರ ಹೋರಾಟದಲ್ಲಿ ಹೆಚ್ಚು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ಸಾಮಾನ್ಯವಾಗಿ, DevOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ ಎಂದು ಮಿಶಾ ನಂಬುತ್ತಾರೆ, ಆದರೆ ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ. ಮತ್ತು ರೂಪಾಂತರದ ಆರಂಭದಲ್ಲಿ ತಂಡದ ಉತ್ಪಾದಕತೆ ಕುಸಿಯುತ್ತದೆ, ಅದು ಕಡಿಮೆ ಹಣವನ್ನು ಗಳಿಸುತ್ತದೆ, ಆದರೆ ನಂತರ ಅದನ್ನು ಸಮರ್ಥಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನಾವು ಸಿದ್ಧರಾಗಿರಬೇಕು.
ಮ್ಯಾಂಗೋ ಟೆಲಿಕಾಂನಲ್ಲಿ ಪರೀಕ್ಷೆಯ ಆಟೊಮೇಷನ್
ಪರೀಕ್ಷಕನಾಗಿ ನನಗೆ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವರದಿಯನ್ನು ಮ್ಯಾಂಗೋ ಟೆಲಿಕಾಂನಿಂದ ಎಗೊರ್ ಮಾಸ್ಲೋವ್ ನೀಡಿದರು. ಪ್ರಸ್ತುತಿಯನ್ನು "SCRUM ತಂಡದಲ್ಲಿ ಪೂರ್ಣ ಪರೀಕ್ಷಾ ಚಕ್ರದ ಸ್ವಯಂಚಾಲಿತ" ಎಂದು ಕರೆಯಲಾಯಿತು. DevOps ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ SCRUM ಗಾಗಿ ರಚಿಸಲಾಗಿದೆ ಎಂದು Egor ನಂಬುತ್ತಾರೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, DevOps ಅನ್ನು SCRUM ತಂಡಕ್ಕೆ ಪರಿಚಯಿಸುವುದು ಸಾಕಷ್ಟು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. SCRUM ತಂಡವು ಯಾವಾಗಲೂ ಎಲ್ಲೋ ಓಡುತ್ತಿರುವ ಕಾರಣ ಇದು ಸಂಭವಿಸುತ್ತದೆ, ನಾವೀನ್ಯತೆಗಳಿಂದ ವಿಚಲಿತರಾಗಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು ಸಮಯವಿಲ್ಲ. SCRUM ತಂಡದಲ್ಲಿನ ಉಪ-ತಂಡಗಳ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಒಳಗೊಂಡಿಲ್ಲ ಎಂಬ ಅಂಶದಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ (ಪರೀಕ್ಷಾ ತಂಡ, ಅಭಿವೃದ್ಧಿ ತಂಡ, ಮತ್ತು ಹೀಗೆ). ಅಲ್ಲದೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು, ದಸ್ತಾವೇಜನ್ನು ಅಗತ್ಯವಿದೆ, ಮತ್ತು SCRUM ನಲ್ಲಿ, ಹೆಚ್ಚಾಗಿ ಯಾವುದೇ ದಸ್ತಾವೇಜನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಇರುವುದಿಲ್ಲ - "ಕೆಲವು ರೀತಿಯ ಬರವಣಿಗೆಗಿಂತ ಉತ್ಪನ್ನವು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ."
SCRUM ಗೆ ಬದಲಾಯಿಸಿದ ನಂತರ, ಪರೀಕ್ಷಕರು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಮಾಲೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ಕ್ರಮೇಣ, ಕ್ರಿಯಾತ್ಮಕತೆಯ ಪ್ರಮಾಣವು ಹೆಚ್ಚಾಯಿತು, ಯಾವುದೇ ದಾಖಲಾತಿಗಳಿಲ್ಲ, ಮತ್ತು ಅವರು ಪರೀಕ್ಷೆಗಳಿಂದ ಒಳಗೊಳ್ಳದ ಕಾರ್ಯಚಟುವಟಿಕೆಯಲ್ಲಿ ಬಹಳಷ್ಟು ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ಪ್ರಾರಂಭಿಸಿದರು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ಯಾರು ಮತ್ತು ಯಾವಾಗ ಪರೀಕ್ಷಿಸಿದರು ಎಂಬುದು ಇನ್ನು ಮುಂದೆ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ - ಗೊಂದಲ ಮತ್ತು ಚಂಚಲತೆ. ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕರಣಕ್ಕೆ ಬದಲಾಯಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಆದರೆ ಆಗಲೂ ಸಂಪೂರ್ಣ ವಿಫಲವಾಯಿತು. ಅವರು ಹೊರಗುತ್ತಿಗೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರಿಣಿತರನ್ನು ನೇಮಿಸಿಕೊಂಡರು, ಅವರು ಆಂತರಿಕ ಪರೀಕ್ಷಕರಿಗೆ ತಿಳಿದಿಲ್ಲದ ಸ್ಟಾಕ್ನಲ್ಲಿ ಬರೆದರು. ಆಟೋಟೆಸ್ಟ್‌ಗಳ ಚೌಕಟ್ಟು ಸಹಜವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಹೊರಗುತ್ತಿಗೆದಾರರು ತೊರೆದ ನಂತರ, ಇದು ಎರಡು ವಾರಗಳ ಕಾಲ ನಡೆಯಿತು. ಮುಂದೆ ಆಟೋಟೆಸ್ಟಿಂಗ್ ಸಂಖ್ಯೆ ಎರಡನ್ನು ಪರಿಚಯಿಸುವ ಪ್ರಯತ್ನವಾಗಿತ್ತು. SCRUM ನ ಚೌಕಟ್ಟಿನೊಳಗೆ ನಿಮ್ಮದೇ ಆದ (ಸರಿಯಾದ ವೆಕ್ಟರ್: ಆಂತರಿಕವಾಗಿ ಪರಿಣತಿಯನ್ನು ನಿರ್ಮಿಸಲು) ಕಂಪನಿಯೊಳಗೆ ಎಲ್ಲವನ್ನೂ ನಿರ್ಮಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ದಾಖಲಾತಿಗಳನ್ನು ರಚಿಸಬೇಕು ಎಂಬ ಅಂಶದಿಂದ ಇದು ಪ್ರಾರಂಭವಾಯಿತು. ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸ್ಟಾಕ್ ಉತ್ಪನ್ನದ ಸ್ಟಾಕ್‌ಗೆ ಸಮನಾಗಿರಬೇಕು (ಇಲ್ಲಿ ನಾನು ಅದನ್ನು ಸೇರಿಸುತ್ತಿದ್ದೇನೆ, ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಬೇರೆ ಯಾವುದರೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಬೇಡಿ). ಸ್ಪ್ರಿಂಟ್‌ನ ಕೊನೆಯಲ್ಲಿ, ಇಡೀ ತಂಡದೊಂದಿಗೆ (ಸಹಾಯಕ) ಆಟೋಟೆಸ್ಟ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಡೆಮೊವನ್ನು ಅವರು ಮಾಡಿದರು. ಹೀಗಾಗಿ, ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಎಲ್ಲಾ ತಂಡದ ಸದಸ್ಯರ ಒಳಗೊಳ್ಳುವಿಕೆ ಹೆಚ್ಚಾಯಿತು, ಜೊತೆಗೆ ಆಟೋಟೆಸ್ಟ್‌ಗಳಲ್ಲಿ ನಂಬಿಕೆ ಮತ್ತು ಈ ಆಟೋಟೆಸ್ಟ್ ಅನ್ನು ಖಂಡಿತವಾಗಿ ಬಳಸಲಾಗುವುದು (ಮತ್ತು ನಿರಂತರ ವೈಫಲ್ಯಗಳಿಂದಾಗಿ ಒಂದು ತಿಂಗಳಲ್ಲಿ ಕಾಮೆಂಟ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ).
ಅಂದಹಾಗೆ, DevOpsForum 2019 ರಲ್ಲಿ ತೆರೆದ ಮೈಕ್ರೊಫೋನ್ ಇತ್ತು - ಇದು ದೀರ್ಘಕಾಲ ತಿಳಿದಿರುವ ಮತ್ತು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಭಾಷಣಗಳ ಉಪಯುಕ್ತ ಸ್ವರೂಪವಾಗಿದೆ. ನೀವು ಈ ರೀತಿ ಸುತ್ತಾಡುತ್ತೀರಿ, ವರದಿಗಳನ್ನು ಆಲಿಸಿ, ತದನಂತರ ಸಮ್ಮೇಳನದಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಷಯ ಅಥವಾ ಸಮಸ್ಯೆಯನ್ನು ಚರ್ಚಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಸಂಬಂಧಿತ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.
ಸಂಘಟಕರು ಕಿರು ವರದಿಗಳ ಸ್ಟ್ರೀಮ್ ಮಾಡಿರುವುದನ್ನು ನಾನು ಗಮನಿಸಿದ್ದೇನೆ. ಪ್ರತಿ ವರದಿಯು 10 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಇರುತ್ತದೆ, ನಂತರ ಪ್ರಶ್ನೆಗಳು. ಈ ರೀತಿಯಾಗಿ ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ವಿಷಯಗಳನ್ನು ಕವರ್ ಮಾಡಬಹುದು ಮತ್ತು ನಿಮಗೆ ಆಸಕ್ತಿಯಿರುವ ಸ್ಪೀಕರ್‌ಗಳಿಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು.
ಪ್ರಸ್ತುತಿಗಳ ನಡುವೆ, ನಾನು ಸಮ್ಮೇಳನದ ಪಾಲುದಾರರ ಬೂತ್‌ಗಳ ಸುತ್ತಲೂ ನಡೆದಿದ್ದೇನೆ ಮತ್ತು ಬಹಳಷ್ಟು ವಿಷಯವನ್ನು ಕದ್ದಿದ್ದೇನೆ/ಗೆಲ್ಲಿದ್ದೇನೆ. ಓಹ್, ನಾನು ಕರಪತ್ರವನ್ನು ಪ್ರೀತಿಸುತ್ತೇನೆ!
Alfastrakhovanie ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ನಿರ್ದೇಶಕರೊಂದಿಗೆ ರೌಂಡ್ ಟೇಬಲ್ ಮತ್ತು DevOps ಸಮಸ್ಯೆಗಳು
ನನಗೆ DevOpsForum 2019 ಕೇಕ್‌ನಲ್ಲಿ ಐಸಿಂಗ್‌ನೆಂದರೆ DevOps ತಜ್ಞರೊಂದಿಗೆ ಒಂದು ಗಂಟೆ ಅವಧಿಯ ಪೂರ್ಣಾವಧಿಯ ಅಧಿವೇಶನವಾಗಿದೆ. DevOps ಅನ್ನು ವಿವಿಧ ಕೋನಗಳಿಂದ ನೋಡಲು ನಾಲ್ಕು ಸೆಷನ್ ಭಾಗವಹಿಸುವವರನ್ನು ಆಹ್ವಾನಿಸಲಾಗಿದೆ: ಆಂಟನ್ ಇಸಾನಿನ್ (ಅಲ್ಫಾಸ್ಟ್ರಾಖೋವಾನಿ, ಅಭಿವೃದ್ಧಿ ನಿರ್ದೇಶಕ), ನೈಲ್ಯ ಜಮಾಶ್ಕಿನಾ (ಫಿನ್ಟೆಕ್ ಲ್ಯಾಬ್, ಆಪರೇಟಿಂಗ್ ಡೈರೆಕ್ಟರ್), ಒಲೆಗ್ ಎಗೊರ್ಕಿನ್ (ರೋಸ್ಟೆಲೆಕಾಮ್, ಅಗೈಲ್ ಕೋಚ್) ಮತ್ತು ಆಂಟನ್ ಮಾರ್ಟ್ಯಾನೋವ್ (ಸ್ವತಂತ್ರ ತಜ್ಞ, DevOps ಅನ್ನು ನೋಡಿದ್ದಾರೆ ವ್ಯವಹಾರದ ದೃಷ್ಟಿಕೋನದಿಂದ).
ತಜ್ಞರು ಜನರಿಗೆ ಹತ್ತಿರವಾಗಿ ಕುಳಿತುಕೊಂಡರು ಮತ್ತು ನಂತರ ವಿಷಯಗಳು ಸಂಭವಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು: ಇಡೀ ಗಂಟೆಯವರೆಗೆ, ಪ್ರೇಕ್ಷಕರಿಂದ ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿದರು, ಮತ್ತು ತಜ್ಞರು ರಾಪ್ ತೆಗೆದುಕೊಂಡರು. ಕೆಲವೊಮ್ಮೆ ನಿಜವಾದ ಚರ್ಚೆಗಳು ಇದ್ದವು. ಪ್ರಶ್ನೆಗಳು ತುಂಬಾ ವಿಭಿನ್ನವಾಗಿವೆ, ಉದಾಹರಣೆಗೆ: DevOps ಇಂಜಿನಿಯರ್‌ಗಳು ಎಲ್ಲರಿಗೂ ಅಗತ್ಯವಿದೆಯೇ, ಅವರು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಾಗಿ ಏಕೆ ತರಬೇತಿ ಪಡೆಯಬಾರದು, ಎಲ್ಲರಿಗೂ DevOps ಅನ್ನು ನೀಡಬೇಕೇ, ಅದರ ಮೌಲ್ಯ ಏನು, ಮತ್ತು ಹೀಗೆ.
ನಂತರ, ನಾನು ಆಂಟನ್ ಇಸಾನಿನ್ ಅವರೊಂದಿಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಮಾತನಾಡಿದೆ. DevOps ಸಂಸ್ಕೃತಿಯನ್ನು ಪ್ರತಿ ಮನೆಗೆ ತರುವ ಅಗತ್ಯವನ್ನು ನಾವು ಚರ್ಚಿಸಿದ್ದೇವೆ ಮತ್ತು DevOps ರೂಪಾಂತರದ ಕರಾಳ ಭಾಗವನ್ನು ಬಹಿರಂಗಪಡಿಸಿದ್ದೇವೆ.
ಪ್ರತಿಯೊಬ್ಬರೂ ಒಗ್ಗೂಡಿದರು ಮತ್ತು ಉತ್ಪನ್ನ ಮತ್ತು ವ್ಯಾಪಾರ ಮತ್ತು ತಂಡದಿಂದ DevOps ಅಗತ್ಯವಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿದರು ಎಂದು ಊಹಿಸೋಣ. ಅದನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರೋಣ. ಎಲ್ಲವೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬಂದವು. ನಾವು ಉಸಿರು ಬಿಟ್ಟೆವು. DevOps ನಮ್ಮನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಹತ್ತಿರ ತಂದಿದೆ, ಈಗ ನಾವು ಅವರ ಎಲ್ಲಾ ಆಸೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪೂರೈಸಬಹುದು. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮಗಳು ಮತ್ತು ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ದೊಡ್ಡ Ops ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಇದು ನಿರಂತರವಾಗಿ ಉತ್ಪನ್ನದಲ್ಲಿನ ದೋಷಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಗಳ ಗುಂಪನ್ನು ರಚಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ಕ್ಲೈಂಟ್ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಹಸಿರು ಬಣ್ಣಕ್ಕೆ ಬದಲಾಗಿ ಹಳದಿ ಬಣ್ಣವನ್ನು ಬಣ್ಣಿಸಲು ಬಯಸಿದ್ದರೂ ಸಹ, ಎಲ್ಲಾ ದೋಷಗಳನ್ನು "ತುರ್ತು" ಸ್ಥಿತಿಯನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಯೋಜನೆಯು ಬೆಳೆಯುತ್ತಿದೆ, ಬಿಡುಗಡೆಗಳ ಸಂಖ್ಯೆಯು ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಗ್ರಾಹಕರಿಂದ ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆಯ ದೋಷಗಳು ಮತ್ತು ತಪ್ಪುಗ್ರಹಿಕೆಗಳ ಸಂಖ್ಯೆ. ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲು Ops 10 ಜನರನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯು ಅವುಗಳನ್ನು ಮುಚ್ಚುವುದನ್ನು ಮುಂದುವರಿಸಲು 15 ಜನರನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪರಿಚಯಿಸುವ ಬದಲು, ತಂಡವು ಅಂತ್ಯವಿಲ್ಲದ SD ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರಿಗೆ ಮತ್ತು ಬೆಂಬಲಕ್ಕೆ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, Ops ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಎರಡೂ ವ್ಯವಹಾರದಲ್ಲಿವೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ವ್ಯಾಪಾರವು ಅತೃಪ್ತಿ ಹೊಂದಿದೆ: ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಂಟಿಕೊಂಡಿವೆ. DevOps ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ.
DevOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಗತ್ಯತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ನೇರವಾಗಿ ವ್ಯವಹಾರದ ಪ್ರಮಾಣವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಎಂದು ಆಂಟನ್ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿದ್ದಾರೆ. ವರ್ಷಕ್ಕೆ ಒಬ್ಬ ಕ್ಲೈಂಟ್ ಸೇವೆಯು ಕಂಪನಿಗೆ ಶತಕೋಟಿಯನ್ನು ತಂದರೆ, DevOps ಅಗತ್ಯವಿಲ್ಲ (ನೀವು ಈ ಕ್ಲೈಂಟ್‌ಗೆ ನಿಯಮಿತವಾಗಿ ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಹೊರತರುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಒದಗಿಸಲಾಗಿದೆ). ಎಲ್ಲವನ್ನೂ ಚಾಕೊಲೇಟ್ನಲ್ಲಿ ಮುಚ್ಚಲಾಗುತ್ತದೆ. ಆದರೆ ವ್ಯವಹಾರವು ಬೆಳೆದರೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಗ್ರಾಹಕರು ಕಾಣಿಸಿಕೊಂಡರೆ, ನೀವು ಅನುಸರಿಸಬೇಕು. ನಿಯಮದಂತೆ, ಕಂಪನಿಯಲ್ಲಿ ಆರಂಭದಲ್ಲಿ ಯಾವುದೇ ತಂಪಾದ ಓಪ್ಸ್ ಇಲ್ಲ. ಮೊದಲು ನಾವು ಉತ್ಪನ್ನವನ್ನು ಕತ್ತರಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಉತ್ಪನ್ನವು ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ನಾವು ಸರ್ವರ್‌ಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಬೇಕು ಮತ್ತು ಸರಬರಾಜುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಆಗ ಆಪ್ಸ್ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುತ್ತದೆ. Ops, ಪ್ರತ್ಯೇಕ ವಿಭಾಗವಾಗಿ, ಅಭಿವೃದ್ಧಿಗೆ ಅಡೆತಡೆಗಳ ಗುಂಪನ್ನು ಹಾಕಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ವಿತರಣೆಗಳು ಸ್ಥಗಿತಗೊಳ್ಳಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಉಳಿದಿದೆ. ಅಂದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, DevOps ಸಂಸ್ಕೃತಿಯು ಈಗಾಗಲೇ ಪ್ರಸ್ತುತವಾಗಿದೆ, ಆದರೆ ಅದರ ಡಾರ್ಕ್ ಸೈಡ್ ಬಗ್ಗೆ ನಾವು ಮರೆಯಬಾರದು.
ಮೂಲ: www.habr.com