"ಡೆವೊಪ್ಸ್ ಅನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು" ಎಂಬ ಪ್ರಶ್ನೆಯು ವರ್ಷಗಳಿಂದಲೂ ಇದೆ, ಆದರೆ ಅನೇಕ ಉತ್ತಮ ವಸ್ತುಗಳು ಇಲ್ಲ. ಕೆಲವೊಮ್ಮೆ ನೀವು ಎಷ್ಟು ಬುದ್ಧಿವಂತ ಸಲಹೆಗಾರರ ಜಾಹೀರಾತುಗಳಿಗೆ ಬಲಿಯಾಗುತ್ತೀರಿ, ಅವರು ಹೇಗೆ ಬೇಕಾದರೂ ತಮ್ಮ ಸಮಯವನ್ನು ಮಾರಾಟ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಇವುಗಳು ಮೆಗಾಕಾರ್ಪೊರೇಷನ್‌ಗಳ ಹಡಗುಗಳು ಬ್ರಹ್ಮಾಂಡದ ವಿಸ್ತಾರಗಳನ್ನು ಹೇಗೆ ಉಳುಮೆ ಮಾಡುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಅಸ್ಪಷ್ಟ, ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಪದಗಳಾಗಿವೆ. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಇದು ನಮಗೆ ಏನು ಮುಖ್ಯ? ಆತ್ಮೀಯ ಲೇಖಕರೇ, ನಿಮ್ಮ ಆಲೋಚನೆಗಳನ್ನು ಪಟ್ಟಿಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ರೂಪಿಸಬಹುದೇ?
ಕಂಪನಿಯ ಸಂಸ್ಕೃತಿಯ ರೂಪಾಂತರಗಳ ಫಲಿತಾಂಶದ ಬಗ್ಗೆ ಹೆಚ್ಚು ನೈಜ ಅಭ್ಯಾಸ ಮತ್ತು ತಿಳುವಳಿಕೆಯು ಸಂಗ್ರಹವಾಗಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದ ಇದೆಲ್ಲವೂ ಉದ್ಭವಿಸುತ್ತದೆ. ಸಂಸ್ಕೃತಿಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ದೀರ್ಘಾವಧಿಯ ವಿಷಯಗಳಾಗಿವೆ, ಅದರ ಫಲಿತಾಂಶಗಳು ಒಂದು ವಾರ ಅಥವಾ ಒಂದು ತಿಂಗಳಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ. ವರ್ಷಗಳಲ್ಲಿ ಕಂಪನಿಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ವಿಫಲವಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡುವಷ್ಟು ವಯಸ್ಸಾದ ಯಾರಾದರೂ ನಮಗೆ ಬೇಕು.
ಜಾನ್ ವಿಲ್ಲಿಸ್ - DevOps ನ ಪಿತಾಮಹರಲ್ಲಿ ಒಬ್ಬರು. ಜಾನ್ ಅವರು ಬೃಹತ್ ಸಂಖ್ಯೆಯ ಕಂಪನಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ದಶಕಗಳ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇತ್ತೀಚೆಗೆ, ಜಾನ್ ಪ್ರತಿಯೊಂದರೊಂದಿಗೂ ಕೆಲಸ ಮಾಡುವಾಗ ನಡೆಯುವ ನಿರ್ದಿಷ್ಟ ಮಾದರಿಗಳನ್ನು ಗಮನಿಸಲಾರಂಭಿಸಿದರು. ಈ ಮೂಲಮಾದರಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಜಾನ್ DevOps ರೂಪಾಂತರದ ನಿಜವಾದ ಹಾದಿಯಲ್ಲಿ ಕಂಪನಿಗಳಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುತ್ತಾನೆ. DevOops 2018 ಸಮ್ಮೇಳನದಿಂದ ಅವರ ವರದಿಯ ಅನುವಾದದಲ್ಲಿ ಈ ಮೂಲಮಾದರಿಗಳ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಿ.
ಸ್ಪೀಕರ್ ಬಗ್ಗೆ:
ಐಟಿ ನಿರ್ವಹಣೆಯಲ್ಲಿ 35 ವರ್ಷಗಳಿಗಿಂತ ಹೆಚ್ಚು, ಕ್ಯಾನೊನಿಕಲ್‌ನಲ್ಲಿ ಓಪನ್‌ಕ್ಲೌಡ್‌ನ ಪೂರ್ವವರ್ತಿ ರಚನೆಯಲ್ಲಿ ಭಾಗವಹಿಸಿದರು, 10 ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿದರು, ಅವುಗಳಲ್ಲಿ ಎರಡು ಡೆಲ್ ಮತ್ತು ಡಾಕರ್‌ಗೆ ಮಾರಾಟವಾದವು. ಪ್ರಸ್ತುತ ಅವರು SJ ಟೆಕ್ನಾಲಜೀಸ್‌ನಲ್ಲಿ DevOps ಮತ್ತು ಡಿಜಿಟಲ್ ಅಭ್ಯಾಸಗಳ ಉಪಾಧ್ಯಕ್ಷರಾಗಿದ್ದಾರೆ.
ಜಾನ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಮುಂದಿನ ಕಥೆ.
ನನ್ನ ಹೆಸರು ಜಾನ್ ವಿಲ್ಲಿಸ್ ಮತ್ತು ನನ್ನನ್ನು ಹುಡುಕಲು ಸುಲಭವಾದ ಸ್ಥಳವೆಂದರೆ Twitter ನಲ್ಲಿ, . ನಾನು Gmail ಮತ್ತು GitHub ನಲ್ಲಿ ಅದೇ ಅಲಿಯಾಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಎ ನನ್ನ ವರದಿಗಳು ಮತ್ತು ಪ್ರಸ್ತುತಿಗಳ ವೀಡಿಯೊ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳನ್ನು ನೀವು ಕಾಣಬಹುದು.
ನಾನು ವಿವಿಧ ದೊಡ್ಡ ಕಂಪನಿಗಳ CIO ಗಳೊಂದಿಗೆ ಅನೇಕ ಸಭೆಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ. DevOps ಎಂದರೇನು ಎಂದು ಅವರಿಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಎಂದು ಅವರು ಆಗಾಗ್ಗೆ ದೂರುತ್ತಾರೆ ಮತ್ತು ಅವರಿಗೆ ಅದನ್ನು ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಪ್ರತಿಯೊಬ್ಬರೂ ವಿಭಿನ್ನವಾದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾರೆ. ಮತ್ತೊಂದು ಸಾಮಾನ್ಯ ದೂರು ಎಂದರೆ DevOps ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದರೂ ನಿರ್ದೇಶಕರು ಅವರಿಗೆ ವಿವರಿಸಿದಂತೆ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದು ತೋರುತ್ತದೆ. ನಾವು ನೂರು ವರ್ಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಹಳೆಯದಾದ ದೊಡ್ಡ ಕಂಪನಿಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಅವರೊಂದಿಗೆ ಮಾತನಾಡಿದ ನಂತರ, ಅನೇಕ ಸಮಸ್ಯೆಗಳಿಗೆ, ಇದು ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಉನ್ನತ ತಂತ್ರಜ್ಞಾನವಲ್ಲ, ಆದರೆ ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ತಂತ್ರಜ್ಞಾನದ ಪರಿಹಾರಗಳು ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇನೆ. ವಾರಗಟ್ಟಲೆ ನಾನು ವಿವಿಧ ಇಲಾಖೆಗಳ ಜನರೊಂದಿಗೆ ಮಾತನಾಡಿದೆ. ಪೋಸ್ಟ್‌ನಲ್ಲಿನ ಮೊದಲ ಚಿತ್ರದಲ್ಲಿ ನೀವು ನೋಡುತ್ತಿರುವುದು ನನ್ನ ಕೊನೆಯ ಯೋಜನೆಯಾಗಿದೆ, ಇದು ಮೂರು ದಿನಗಳ ಕೆಲಸದ ನಂತರ ಕೊಠಡಿ ಹೇಗಿತ್ತು.
DevOps ಎಂದರೇನು?
ವಾಸ್ತವವಾಗಿ, ನೀವು 10 ವಿಭಿನ್ನ ಜನರನ್ನು ಕೇಳಿದರೆ, ಅವರು 10 ವಿಭಿನ್ನ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತಾರೆ. ಆದರೆ ಇಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಿದೆ: ಈ ಎಲ್ಲಾ ಹತ್ತು ಉತ್ತರಗಳು ಸರಿಯಾಗಿರುತ್ತವೆ. ಇಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪು ಉತ್ತರವಿಲ್ಲ. ನಾನು ಸುಮಾರು 10 ವರ್ಷಗಳ ಕಾಲ DevOps ನಲ್ಲಿ ಬಹಳ ಆಳವಾಗಿದ್ದೆ ಮತ್ತು ಮೊದಲ DevOpsDay ನಲ್ಲಿ ಮೊದಲ ಅಮೇರಿಕನ್ ಆಗಿದ್ದೆ. ನಾನು DevOps ನಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿರುವ ಎಲ್ಲರಿಗಿಂತ ಚುರುಕಾಗಿದ್ದೇನೆ ಎಂದು ನಾನು ಹೇಳುವುದಿಲ್ಲ, ಆದರೆ ಅದಕ್ಕಾಗಿ ಹೆಚ್ಚು ಪ್ರಯತ್ನ ಮಾಡಿದವರು ಯಾರೂ ಇಲ್ಲ. ಮಾನವ ಬಂಡವಾಳ ಮತ್ತು ತಂತ್ರಜ್ಞಾನ ಒಟ್ಟಿಗೆ ಬಂದಾಗ DevOps ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಸಂಸ್ಕೃತಿಗಳ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಮಾತನಾಡುತ್ತಿದ್ದರೂ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಮಾನವ ಆಯಾಮವನ್ನು ಮರೆತುಬಿಡುತ್ತೇವೆ.
ಈಗ ನಾವು ಸಾಕಷ್ಟು ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಐದು ವರ್ಷಗಳ ಶೈಕ್ಷಣಿಕ ಸಂಶೋಧನೆ, ಕೈಗಾರಿಕಾ ಪ್ರಮಾಣದಲ್ಲಿ ಸಿದ್ಧಾಂತಗಳ ಪರೀಕ್ಷೆ. ಈ ಅಧ್ಯಯನಗಳು ನಮಗೆ ಹೇಳುವುದೇನೆಂದರೆ, ನೀವು ಸಾಂಸ್ಥಿಕ ಸಂಸ್ಕೃತಿಯಲ್ಲಿ ಕೆಲವು ನಡವಳಿಕೆಯ ಮಾದರಿಗಳನ್ನು ಸಂಯೋಜಿಸಿದರೆ, ನೀವು 2000x ವೇಗವನ್ನು ಪಡೆಯಬಹುದು. ಈ ವೇಗವರ್ಧನೆಯು ಸ್ಥಿರತೆಯ ಸಮಾನ ಸುಧಾರಣೆಯಿಂದ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಇದು DevOps ಯಾವುದೇ ಕಂಪನಿಗೆ ತರಬಹುದಾದ ಪ್ರಯೋಜನದ ಪರಿಮಾಣಾತ್ಮಕ ಮಾಪನವಾಗಿದೆ. ಒಂದೆರಡು ವರ್ಷಗಳ ಹಿಂದೆ, ನಾನು Fortune 5000 ಕಂಪನಿಯ CEO ಗೆ DevOps ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೆ. ನಾನು ಪ್ರಸ್ತುತಿಗಾಗಿ ತಯಾರಿ ನಡೆಸುತ್ತಿದ್ದಾಗ, ನಾನು ತುಂಬಾ ಆತಂಕಗೊಂಡಿದ್ದೆ ಏಕೆಂದರೆ ನಾನು ನನ್ನ ವರ್ಷಗಳ ಅನುಭವವನ್ನು 5 ನಿಮಿಷಗಳಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಬೇಕಾಗಿತ್ತು.
ಕೊನೆಯಲ್ಲಿ ನಾನು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ನೀಡಿದ್ದೇನೆ DevOps ನ ವ್ಯಾಖ್ಯಾನ: ಇದು ಮಾನವ ಬಂಡವಾಳವನ್ನು ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಾಂಸ್ಥಿಕ ಬಂಡವಾಳವಾಗಿ ಪರಿವರ್ತಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಮಾದರಿಗಳ ಒಂದು ಗುಂಪಾಗಿದೆ. ಟೊಯೊಟಾ ಕಳೆದ 50 ಅಥವಾ 60 ವರ್ಷಗಳಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ರೀತಿ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.
(ಇನ್ನು ಮುಂದೆ, ಅಂತಹ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಉಲ್ಲೇಖದ ವಸ್ತುವಾಗಿ ಒದಗಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ವಿವರಣೆಗಳಾಗಿ ಒದಗಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಹೊಸ ಕಂಪನಿಗೆ ಅವುಗಳ ವಿಷಯವು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಚಿತ್ರವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ವೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ದೊಡ್ಡದಾಗಿಸಬಹುದು
ಅಂತಹ ಅತ್ಯಂತ ಯಶಸ್ವಿ ಆಚರಣೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಮೌಲ್ಯ ಸ್ಟ್ರೀಮ್ ಮ್ಯಾಪಿಂಗ್. ಇದರ ಬಗ್ಗೆ ಹಲವಾರು ಉತ್ತಮ ಪುಸ್ತಕಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ, ಅವುಗಳಲ್ಲಿ ಅತ್ಯಂತ ಯಶಸ್ವಿಯಾದವು ಕರೆನ್ ಮಾರ್ಟಿನ್. ಆದರೆ ಕಳೆದ ವರ್ಷದಲ್ಲಿ, ಈ ವಿಧಾನವು ತುಂಬಾ ಹೈಟೆಕ್ ಆಗಿದೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ನಾನು ಬಂದಿದ್ದೇನೆ. ಇದು ಖಂಡಿತವಾಗಿಯೂ ಅನೇಕ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಾನು ಅದನ್ನು ಸಾಕಷ್ಟು ಬಳಸಿದ್ದೇನೆ. ಆದರೆ ಸಿಇಒ ತನ್ನ ಕಂಪನಿಯು ಹೊಸ ಹಳಿಗಳಿಗೆ ಏಕೆ ಬದಲಾಯಿಸಬಾರದು ಎಂದು ಕೇಳಿದಾಗ, ಮೌಲ್ಯದ ಸ್ಟ್ರೀಮ್ ಮ್ಯಾಪಿಂಗ್ ಕುರಿತು ಮಾತನಾಡಲು ಇದು ತುಂಬಾ ಮುಂಚೆಯೇ. ಮೊದಲು ಉತ್ತರಿಸಬೇಕಾದ ಹಲವು ಮೂಲಭೂತ ಪ್ರಶ್ನೆಗಳಿವೆ.
ನನ್ನ ಅನೇಕ ಸಹೋದ್ಯೋಗಿಗಳು ಮಾಡುವ ತಪ್ಪೆಂದರೆ ಅವರು ಕಂಪನಿಗೆ ಐದು-ಪಾಯಿಂಟ್ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ನೀಡುತ್ತಾರೆ ಮತ್ತು ಆರು ತಿಂಗಳ ನಂತರ ಹಿಂತಿರುಗಿ ಮತ್ತು ಏನಾಯಿತು ಎಂದು ನೋಡುತ್ತಾರೆ. ಮೌಲ್ಯದ ಸ್ಟ್ರೀಮ್ ಮ್ಯಾಪಿಂಗ್‌ನಂತಹ ಉತ್ತಮ ಯೋಜನೆ ಕೂಡ ಬ್ಲೈಂಡ್ ಸ್ಪಾಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ಹೇಳೋಣ. ವಿವಿಧ ಕಂಪನಿಗಳ ನಿರ್ದೇಶಕರೊಂದಿಗೆ ನೂರಾರು ಸಂದರ್ಶನಗಳ ನಂತರ, ನಾನು ಸಮಸ್ಯೆಯನ್ನು ಅದರ ಘಟಕಗಳಾಗಿ ವಿಭಜಿಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಾದರಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇನೆ ಮತ್ತು ಈಗ ನಾವು ಈ ಪ್ರತಿಯೊಂದು ಘಟಕಗಳನ್ನು ಕ್ರಮವಾಗಿ ಚರ್ಚಿಸುತ್ತೇವೆ. ಯಾವುದೇ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮೊದಲು, ನಾನು ಈ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತೇನೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ನನ್ನ ಎಲ್ಲಾ ಗೋಡೆಗಳನ್ನು ರೇಖಾಚಿತ್ರಗಳಿಂದ ಮುಚ್ಚಲಾಗುತ್ತದೆ. ಇತ್ತೀಚೆಗೆ ನಾನು ಮ್ಯೂಚುವಲ್ ಫಂಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೆ ಮತ್ತು ನಾನು ಅಂತಹ 100-150 ಯೋಜನೆಗಳೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದ್ದೇನೆ.
ಕೆಟ್ಟ ಸಂಸ್ಕೃತಿಯು ಉಪಾಹಾರಕ್ಕಾಗಿ ಉತ್ತಮ ವಿಧಾನಗಳನ್ನು ತಿನ್ನುತ್ತದೆ
ಮುಖ್ಯ ಉಪಾಯವೆಂದರೆ: ಸಂಸ್ಥೆಯ ಸಂಸ್ಕೃತಿಯೇ ಕೆಟ್ಟದಾಗಿದ್ದರೆ ಯಾವುದೇ ಲೀನ್, ಅಗೈಲ್, ಸೇಫ್ ಮತ್ತು ಡೆವೊಪ್ಸ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಸ್ಕೂಬಾ ಗೇರ್ ಇಲ್ಲದೆ ಆಳಕ್ಕೆ ಧುಮುಕುವುದು ಅಥವಾ ಎಕ್ಸ್-ರೇ ಇಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಡ್ರಕ್ಕರ್ ಮತ್ತು ಡೆಮಿಂಗ್ ಅನ್ನು ಪ್ಯಾರಾಫ್ರೇಸ್ ಮಾಡಲು: ಕೆಟ್ಟ ಸಾಂಸ್ಥಿಕ ಸಂಸ್ಕೃತಿಯು ಯಾವುದೇ ಉತ್ತಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಉಸಿರುಗಟ್ಟಿಸದೆ ನುಂಗಿಹಾಕುತ್ತದೆ.
ಈ ಮುಖ್ಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಈ ಕೆಳಗಿನ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು:
- ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಗೋಚರಿಸುವಂತೆ ಮಾಡಿ: ನೀವು ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಗೋಚರಿಸುವಂತೆ ಮಾಡಬೇಕಾಗಿದೆ. ಇದು ಅಗತ್ಯವಾಗಿ ಕೆಲವು ಪರದೆಯ ಮೇಲೆ ಪ್ರದರ್ಶಿಸಬೇಕು ಎಂಬ ಅರ್ಥದಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಅದು ಗಮನಿಸಬಹುದಾದ ಅರ್ಥದಲ್ಲಿ.
- ಏಕೀಕೃತ ಕೆಲಸ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳು: ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಏಕೀಕರಿಸುವ ಅಗತ್ಯವಿದೆ. "ಬುಡಕಟ್ಟು" ಜ್ಞಾನ ಮತ್ತು ಸಾಂಸ್ಥಿಕ ಜ್ಞಾನದ ಸಮಸ್ಯೆಯಲ್ಲಿ, 9 ರಲ್ಲಿ 10 ಪ್ರಕರಣಗಳಲ್ಲಿ ಜನರು ಅಡಚಣೆಯಾಗುತ್ತಾರೆ. ಪುಸ್ತಕದಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯು ಬ್ರೆಂಟ್ ಎಂಬ ಒಬ್ಬ ವ್ಯಕ್ತಿಯೊಂದಿಗೆ ಇತ್ತು, ಅವರು ಯೋಜನೆಯು ಮೂರು ವರ್ಷಗಳ ಹಿಂದೆ ಇರುವಂತೆ ಮಾಡಿದರು. ಮತ್ತು ನಾನು ಎಲ್ಲೆಡೆ ಈ "ಬ್ರೆಂಟ್ಸ್" ಗೆ ಓಡುತ್ತೇನೆ. ಈ ಅಡಚಣೆಗಳನ್ನು ಪರಿಹರಿಸಲು, ನಮ್ಮ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಮುಂದಿನ ಎರಡು ಐಟಂಗಳನ್ನು ನಾನು ಬಳಸುತ್ತೇನೆ.
- ನಿರ್ಬಂಧಗಳ ವಿಧಾನದ ಸಿದ್ಧಾಂತ: ನಿರ್ಬಂಧಗಳ ಸಿದ್ಧಾಂತ.
- ಸಹಯೋಗದ ಭಿನ್ನತೆಗಳು: ಸಹಯೋಗ ಭಿನ್ನತೆಗಳು.
- ಟೊಯೋಟಾ ಕಟಾ (): ನಾನು ಟೊಯೋಟಾ ಕಾಟಾ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮಾತನಾಡುವುದಿಲ್ಲ. ಆಸಕ್ತಿ ಇದ್ದರೆ, ನನ್ನ ಗಿಥಬ್‌ನಲ್ಲಿ ಈ ಪ್ರತಿಯೊಂದು ವಿಷಯಗಳ ಮೇಲೆ.
- ಮಾರುಕಟ್ಟೆ ಆಧಾರಿತ ಸಂಸ್ಥೆ: ಮಾರುಕಟ್ಟೆ ಆಧಾರಿತ ಸಂಸ್ಥೆ.
- ಶಿಫ್ಟ್-ಎಡ ಲೆಕ್ಕ ಪರಿಶೋಧಕರು: ಚಕ್ರದ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ಲೆಕ್ಕಪರಿಶೋಧನೆ.
ನಾನು ಸಂಸ್ಥೆಯೊಂದಿಗೆ ಸರಳವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ: ನಾನು ಕಂಪನಿಗೆ ಹೋಗಿ ಉದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಮಾತನಾಡುತ್ತೇನೆ. ನೀವು ನೋಡುವಂತೆ, ಉನ್ನತ ತಂತ್ರಜ್ಞಾನವಿಲ್ಲ. ನಿಮಗೆ ಬೇಕಾಗಿರುವುದು ಬರೆಯಲು ಏನಾದರೂ. ನಾನು ಒಂದೇ ಕೋಣೆಯಲ್ಲಿ ಹಲವಾರು ತಂಡಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತೇನೆ ಮತ್ತು ನನ್ನ 7 ಮೂಲಮಾದರಿಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ ಅವರು ನನಗೆ ಹೇಳುವದನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇನೆ. ತದನಂತರ ನಾನು ಅವರಿಗೆ ಮಾರ್ಕರ್ ಅನ್ನು ನೀಡುತ್ತೇನೆ ಮತ್ತು ಅವರು ಇಲ್ಲಿಯವರೆಗೆ ಜೋರಾಗಿ ಹೇಳಿದ್ದನ್ನೆಲ್ಲಾ ಬೋರ್ಡ್ ಮೇಲೆ ಬರೆಯಲು ಕೇಳುತ್ತೇನೆ. ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿಯ ಸಭೆಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಬರೆಯುವ ಒಬ್ಬ ವ್ಯಕ್ತಿ ಇರುತ್ತಾನೆ ಮತ್ತು ಅತ್ಯುತ್ತಮವಾಗಿ ಅವರು ಚರ್ಚೆಯ 10% ಅನ್ನು ಬರೆಯಬಹುದು. ನನ್ನ ವಿಧಾನದೊಂದಿಗೆ, ಈ ಅಂಕಿ ಅಂಶವನ್ನು ಸುಮಾರು 40% ಗೆ ಹೆಚ್ಚಿಸಬಹುದು.
(ಈ ವಿವರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಬಹುದು )
ನನ್ನ ವಿಧಾನವು ವಿಲಿಯಂ ಷ್ನೇಯ್ಡರ್ ಅವರ ಕೆಲಸವನ್ನು ಆಧರಿಸಿದೆ. ) ಈ ವಿಧಾನವು ಯಾವುದೇ ಸಂಸ್ಥೆಯನ್ನು ನಾಲ್ಕು ಚೌಕಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಆಧರಿಸಿದೆ. ನನಗೆ ಈ ಯೋಜನೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಸ್ಥೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವಾಗ ಉದ್ಭವಿಸುವ ನೂರಾರು ಇತರ ಯೋಜನೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಫಲಿತಾಂಶವಾಗಿದೆ. ನಾವು ಉನ್ನತ ಮಟ್ಟದ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿರುವ ಸಂಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಭಾವಿಸೋಣ, ಆದರೆ ಕಡಿಮೆ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ. ಇದು ಅತ್ಯಂತ ಅನಪೇಕ್ಷಿತ ಆಯ್ಕೆಯಾಗಿದೆ: ಪ್ರತಿಯೊಬ್ಬರೂ ರೇಖೆಯನ್ನು ಅನುಸರಿಸುತ್ತಿರುವಾಗ, ಆದರೆ ಏನು ಮಾಡಬೇಕೆಂದು ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ.
ಸ್ವಲ್ಪ ಉತ್ತಮವಾದ ಆಯ್ಕೆಯು ಉನ್ನತ ಮಟ್ಟದ ನಿಯಂತ್ರಣ ಮತ್ತು ಸಾಮರ್ಥ್ಯ ಎರಡನ್ನೂ ಹೊಂದಿದೆ. ಅಂತಹ ಕಂಪನಿಯು ಲಾಭದಾಯಕವಾಗಿದ್ದರೆ, ಬಹುಶಃ ಅದಕ್ಕೆ DevOps ಅಗತ್ಯವಿಲ್ಲ. ಉನ್ನತ ಮಟ್ಟದ ನಿಯಂತ್ರಣ, ಕಡಿಮೆ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಸಹಕಾರವನ್ನು ಹೊಂದಿರುವ ಕಂಪನಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಉನ್ನತ ಮಟ್ಟದ ಸಂಸ್ಕೃತಿ (ಕೃಷಿ). ಅಂದರೆ ಕಂಪನಿಯು ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಇಷ್ಟಪಡುವ ಬಹಳಷ್ಟು ಜನರನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕಾರ್ಮಿಕ ವಹಿವಾಟು ಕಡಿಮೆಯಾಗಿದೆ.
(ಈ ವಿವರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಬಹುದು )
ಕಟ್ಟುನಿಟ್ಟಾದ ಮಾರ್ಗಸೂಚಿಗಳನ್ನು ಹೊಂದಿರುವ ವಿಧಾನಗಳು ಸತ್ಯವನ್ನು ಸಾಧಿಸುವ ರೀತಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಮೌಲ್ಯದ ಸ್ಟ್ರೀಮ್ ಮ್ಯಾಪಿಂಗ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ, ಮಾಹಿತಿಯನ್ನು ಹೇಗೆ ರಚಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಹಲವು ನಿಯಮಗಳಿವೆ. ಕೆಲಸದ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ, ನಾನು ಈಗ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ, ಈ ನಿಯಮಗಳು ಯಾರಿಗೂ ಅಗತ್ಯವಿಲ್ಲ. ತನ್ನ ಕೈಯಲ್ಲಿ ಮಾರ್ಕರ್ ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಯು ಮಂಡಳಿಯಲ್ಲಿ ಕಂಪನಿಯಲ್ಲಿನ ನೈಜ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸಿದರೆ, ವ್ಯವಹಾರಗಳ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಅತ್ಯುತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಅಂತಹ ಮಾಹಿತಿ ನಿರ್ದೇಶಕರಿಗೆ ತಲುಪುವುದಿಲ್ಲ. ಈ ಕ್ಷಣದಲ್ಲಿ, ವ್ಯಕ್ತಿಯನ್ನು ಅಡ್ಡಿಪಡಿಸುವುದು ಮತ್ತು ಅವನು ಕೆಲವು ರೀತಿಯ ಬಾಣವನ್ನು ತಪ್ಪಾಗಿ ಎಳೆದಿದ್ದಾನೆ ಎಂದು ಹೇಳುವುದು ಮೂರ್ಖತನ. ಈ ಹಂತದಲ್ಲಿ, ಸರಳ ನಿಯಮಗಳನ್ನು ಬಳಸುವುದು ಉತ್ತಮ, ಉದಾಹರಣೆಗೆ: ಬಹು-ಹಂತದ ಅಮೂರ್ತತೆಯನ್ನು ಬಹು-ಬಣ್ಣದ ಗುರುತುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸರಳವಾಗಿ ರಚಿಸಬಹುದು.
ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ, ಉನ್ನತ ತಂತ್ರಜ್ಞಾನವಿಲ್ಲ. ಕಪ್ಪು ಮಾರ್ಕರ್ ಎಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ವಸ್ತುನಿಷ್ಠ ವಾಸ್ತವತೆಯನ್ನು ಚಿತ್ರಿಸುತ್ತದೆ. ಕೆಂಪು ಮಾರ್ಕರ್ನೊಂದಿಗೆ, ಪ್ರಸ್ತುತ ವ್ಯವಹಾರಗಳ ಬಗ್ಗೆ ಜನರು ಇಷ್ಟಪಡದಿರುವದನ್ನು ಗುರುತಿಸುತ್ತಾರೆ. ಅವರು ಇದನ್ನು ಬರೆಯುವುದು ಮುಖ್ಯ, ನಾನಲ್ಲ. ಸಭೆಯ ನಂತರ ನಾನು CIO ಗೆ ಹೋದಾಗ, ಸರಿಪಡಿಸಬೇಕಾದ 10 ವಿಷಯಗಳ ಪಟ್ಟಿಯನ್ನು ನಾನು ನೀಡುವುದಿಲ್ಲ. ಕಂಪನಿಯಲ್ಲಿನ ಜನರು ಏನು ಹೇಳುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಾಬೀತಾದ ಮಾದರಿಗಳ ನಡುವಿನ ಸಂಪರ್ಕಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಅಂತಿಮವಾಗಿ, ನೀಲಿ ಮಾರ್ಕರ್ ಸಮಸ್ಯೆಗೆ ಸಂಭವನೀಯ ಪರಿಹಾರಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.
(ಈ ವಿವರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಬಹುದು )
ಈ ವಿಧಾನದ ಉದಾಹರಣೆಯನ್ನು ಈಗ ಮೇಲೆ ಚಿತ್ರಿಸಲಾಗಿದೆ. ಈ ವರ್ಷದ ಆರಂಭದಲ್ಲಿ ನಾನು ಒಂದು ಬ್ಯಾಂಕಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದೆ. ವಿನ್ಯಾಸ ಮತ್ತು ಅವಶ್ಯಕತೆಗಳ ವಿಮರ್ಶೆಗೆ ಬರಬಾರದು ಎಂದು ಅಲ್ಲಿನ ಭದ್ರತಾ ಸಿಬ್ಬಂದಿಗೆ ಮನವರಿಕೆಯಾಯಿತು.
(ಈ ವಿವರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಬಹುದು )
ತದನಂತರ ನಾವು ಇತರ ಇಲಾಖೆಗಳ ಜನರೊಂದಿಗೆ ಮಾತನಾಡಿದ್ದೇವೆ ಮತ್ತು ಸುಮಾರು 8 ವರ್ಷಗಳ ಹಿಂದೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಕೆಲಸವನ್ನು ನಿಧಾನಗೊಳಿಸಿದ್ದರಿಂದ ಭದ್ರತಾ ಸಿಬ್ಬಂದಿಯನ್ನು ವಜಾಗೊಳಿಸಿದ್ದಾರೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ತದನಂತರ ಅದು ನಿಷೇಧವಾಗಿ ಬದಲಾಯಿತು, ಅದನ್ನು ಲಘುವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. ವಾಸ್ತವದಲ್ಲಿ ಯಾವುದೇ ನಿಷೇಧವಿರಲಿಲ್ಲ.
ನಮ್ಮ ಸಭೆಯು ಅತ್ಯಂತ ಗೊಂದಲಮಯ ರೀತಿಯಲ್ಲಿ ಮುಂದುವರೆಯಿತು: ಸುಮಾರು ಮೂರು ಗಂಟೆಗಳ ಕಾಲ, ಐದು ವಿಭಿನ್ನ ತಂಡಗಳು ಕೋಡ್ ಮತ್ತು ಅಸೆಂಬ್ಲಿ ನಡುವೆ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನನಗೆ ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಮತ್ತು ಇದು ಸರಳವಾದ ವಿಷಯವೆಂದು ತೋರುತ್ತದೆ. ಹೆಚ್ಚಿನ DevOps ಸಲಹೆಗಾರರು ಪ್ರತಿಯೊಬ್ಬರೂ ಇದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದಾರೆ ಎಂದು ಊಹಿಸುತ್ತಾರೆ.
ಆಮೇಲೆ ನಾಲ್ಕು ಗಂಟೆಗಳ ಕಾಲ ಸುಮ್ಮನಿದ್ದ ಐಟಿ ಆಡಳಿತದ ಹೊಣೆ ಹೊತ್ತವರು, ಅವರ ವಿಷಯಕ್ಕೆ ಬಂದಾಗ ಥಟ್ಟನೆ ಜೀವ ಬಂದು, ಬಹಳ ಹೊತ್ತು ನಮ್ಮನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡರು. ಕೊನೆಯಲ್ಲಿ ನಾನು ಸಭೆಯ ಬಗ್ಗೆ ನಿಮ್ಮ ಅಭಿಪ್ರಾಯವನ್ನು ಕೇಳಿದೆ ಮತ್ತು ಅವರ ಉತ್ತರವನ್ನು ನಾನು ಎಂದಿಗೂ ಮರೆಯುವುದಿಲ್ಲ. ಅವರು ಹೇಳಿದರು: "ನಮ್ಮ ಬ್ಯಾಂಕ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ತಲುಪಿಸಲು ಕೇವಲ ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ, ಆದರೆ ಈಗ ಅವುಗಳಲ್ಲಿ ಐದು ಇವೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ಮೂರರ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ."
(ಈ ವಿವರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಬಹುದು )
ಈ ಬ್ಯಾಂಕಿನಲ್ಲಿ ಕೊನೆಯ ಸಭೆಯು ಹೂಡಿಕೆ ಸಾಫ್ಟ್‌ವೇರ್ ತಂಡದೊಂದಿಗೆ ಆಗಿತ್ತು. ಕಾಗದದ ಹಾಳೆಯಲ್ಲಿ ಮಾರ್ಕರ್ನೊಂದಿಗೆ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಬರೆಯುವುದು ಬೋರ್ಡ್‌ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಸ್ಮಾರ್ಟ್‌ಬೋರ್ಡ್‌ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಅವಳೊಂದಿಗೆ ಅದು ಬದಲಾಯಿತು.
ನಮ್ಮ ಸಭೆಯ ನಾಲ್ಕನೇ ದಿನದಂದು ಹೋಟೆಲ್ ಕಾನ್ಫರೆನ್ಸ್ ರೂಮ್ ಹೇಗಿತ್ತು ಎಂಬುದನ್ನು ನೀವು ನೋಡುವ ಫೋಟೋಗಳು. ಮತ್ತು ನಾವು ಮಾದರಿಗಳನ್ನು ಹುಡುಕಲು ಈ ಯೋಜನೆಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ, ಅಂದರೆ ಆರ್ಕಿಟೈಪ್ಸ್.
ಆದ್ದರಿಂದ, ನಾನು ಕಾರ್ಮಿಕರ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತೇನೆ, ಅವರು ಮೂರು ಬಣ್ಣಗಳ (ಕಪ್ಪು, ಕೆಂಪು ಮತ್ತು ನೀಲಿ) ಮಾರ್ಕರ್ಗಳೊಂದಿಗೆ ಉತ್ತರಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ. ಆರ್ಕಿಟೈಪ್‌ಗಳಿಗಾಗಿ ಅವರ ಉತ್ತರಗಳನ್ನು ನಾನು ವಿಶ್ಲೇಷಿಸುತ್ತೇನೆ. ಈಗ ಎಲ್ಲಾ ಆರ್ಕಿಟೈಪ್‌ಗಳನ್ನು ಕ್ರಮವಾಗಿ ಚರ್ಚಿಸೋಣ.
1. ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಗೋಚರಿಸುವಂತೆ ಮಾಡಿ: ಕೆಲಸವನ್ನು ಗೋಚರಿಸುವಂತೆ ಮಾಡಿ
ನಾನು ಕೆಲಸ ಮಾಡುವ ಹೆಚ್ಚಿನ ಕಂಪನಿಗಳು ಅಪರಿಚಿತ ಕೆಲಸದ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ಹೊಂದಿವೆ. ಉದಾಹರಣೆಗೆ, ಒಬ್ಬ ಉದ್ಯೋಗಿ ಇನ್ನೊಬ್ಬರಿಗೆ ಬಂದು ಏನನ್ನಾದರೂ ಮಾಡಲು ಕೇಳಿದಾಗ ಇದು. ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಲ್ಲಿ, 60% ಯೋಜಿತವಲ್ಲದ ಕೆಲಸ ಇರಬಹುದು. ಮತ್ತು 40% ವರೆಗಿನ ಕೆಲಸವನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿಲ್ಲ. ಅದು ಬೋಯಿಂಗ್ ಆಗಿದ್ದರೆ, ನಾನು ನನ್ನ ಜೀವನದಲ್ಲಿ ಮತ್ತೆ ಅವರ ವಿಮಾನವನ್ನು ಹತ್ತುವುದಿಲ್ಲ. ಅರ್ಧದಷ್ಟು ಕಾಮಗಾರಿ ಮಾತ್ರ ದಾಖಲೆಯಾಗಿದ್ದರೆ, ಈ ಕೆಲಸ ಸರಿಯಾಗಿ ಆಗುತ್ತಿದೆಯೋ ಇಲ್ಲವೋ ಗೊತ್ತಿಲ್ಲ. ಎಲ್ಲಾ ಇತರ ವಿಧಾನಗಳು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತವೆ - ಯಾವುದನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಏಕೆಂದರೆ ತಿಳಿದಿರುವ 50% ಕೆಲಸದ ಅತ್ಯಂತ ಸುಸಂಬದ್ಧ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಭಾಗವಾಗಿರಬಹುದು, ಅದರ ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಕೆಟ್ಟದು ವಿಷಯಗಳು ಅಗೋಚರ ಅರ್ಧದಲ್ಲಿವೆ. ದಾಖಲಾತಿಗಳ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ಎಲ್ಲಾ ರೀತಿಯ ಭಿನ್ನತೆಗಳು ಮತ್ತು ಗುಪ್ತ ಕೆಲಸಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಸಾಧ್ಯ, ಅಡಚಣೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಸಾಧ್ಯ, ನಾನು ಈಗಾಗಲೇ ಮಾತನಾಡಿರುವ "ಬ್ರೆಂಟ್ಸ್". ಡೊಮಿನಿಕಾ ಡಿಗ್ರಾಂಡಿಸ್ ಅವರ ಅದ್ಭುತ ಪುಸ್ತಕವಿದೆ . ಅವಳು ಬಹಿರಂಗಪಡಿಸುತ್ತಾಳೆ ಐದು ವಿಭಿನ್ನ "ಸಮಯ ಸೋರಿಕೆಗಳು" (ಸಮಯದ ಕಳ್ಳರು):
- ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ತುಂಬಾ ಕೆಲಸ (WIP)
- ಅಜ್ಞಾತ ಅವಲಂಬನೆಗಳು
- ಯೋಜಿತವಲ್ಲದ ಕೆಲಸ
- ಸಂಘರ್ಷದ ಆದ್ಯತೆಗಳು
- ನಿರ್ಲಕ್ಷ್ಯದ ಕೆಲಸ
ಇದು ಬಹಳ ಮೌಲ್ಯಯುತವಾದ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ ಮತ್ತು ಪುಸ್ತಕವು ಅದ್ಭುತವಾಗಿದೆ, ಆದರೆ ಕೇವಲ 50% ಡೇಟಾ ಗೋಚರಿಸಿದರೆ ಈ ಎಲ್ಲಾ ಸಲಹೆ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. 90% ಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ನಿಖರತೆಯನ್ನು ಸಾಧಿಸಿದರೆ ಡೊಮಿನಿಕಾ ಪ್ರಸ್ತಾಪಿಸಿದ ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು. ಬಾಸ್ ಅಧೀನಕ್ಕೆ 15 ನಿಮಿಷಗಳ ಕೆಲಸವನ್ನು ನೀಡುವ ಸಂದರ್ಭಗಳ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ, ಆದರೆ ಅದು ಅವನಿಗೆ ಮೂರು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ; ಆದರೆ ಈ ಅಧೀನ ಅಧಿಕಾರಿಯು ನಾಲ್ಕು ಅಥವಾ ಐದು ಇತರ ಜನರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ಬಾಸ್‌ಗೆ ನಿಜವಾಗಿಯೂ ತಿಳಿದಿಲ್ಲ.
ಫೀನಿಕ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಮೂರು ವರ್ಷಗಳ ತಡವಾದ ಯೋಜನೆಯ ಬಗ್ಗೆ ಅದ್ಭುತ ಕಥೆಯಾಗಿದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ ಒಂದು ಪಾತ್ರವು ವಜಾಗೊಳಿಸುವಿಕೆಯನ್ನು ಎದುರಿಸುತ್ತದೆ, ಮತ್ತು ಅವರು ಸಾಕ್ರಟೀಸ್‌ನಂತೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಮತ್ತೊಂದು ಪಾತ್ರವನ್ನು ಭೇಟಿಯಾಗುತ್ತಾರೆ. ನಿಖರವಾಗಿ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಅವನು ಸಹಾಯ ಮಾಡುತ್ತಾನೆ. ಕಂಪನಿಯು ಒಬ್ಬ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅವರ ಹೆಸರು ಬ್ರೆಂಟ್, ಮತ್ತು ಎಲ್ಲಾ ಕೆಲಸಗಳು ಹೇಗಾದರೂ ಅವನ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ಸಭೆಯೊಂದರಲ್ಲಿ, ಅಧೀನ ಅಧಿಕಾರಿಗಳಲ್ಲಿ ಒಬ್ಬರನ್ನು ಕೇಳಲಾಗುತ್ತದೆ: ಪ್ರತಿ ಅರ್ಧ ಘಂಟೆಯ ಕಾರ್ಯವು ಒಂದು ವಾರ ಏಕೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? ಉತ್ತರವು ಕ್ಯೂಯಿಂಗ್ ಸಿದ್ಧಾಂತ ಮತ್ತು ಲಿಟಲ್ಸ್ ಕಾನೂನಿನ ಅತ್ಯಂತ ಸರಳೀಕೃತ ಪ್ರಸ್ತುತಿಯಾಗಿದೆ, ಮತ್ತು ಈ ಪ್ರಸ್ತುತಿಯಲ್ಲಿ 90% ಆಕ್ಯುಪೆನ್ಸಿಯಲ್ಲಿ, ಪ್ರತಿ ಗಂಟೆಯ ಕೆಲಸವು 9 ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ತಿರುಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಕೆಲಸವನ್ನು ಇತರ ಏಳು ಜನರಿಗೆ ಕಳುಹಿಸಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ಆ ಗಂಟೆಯು 63 ಗಂಟೆಗಳು, 7 ಬಾರಿ 9 ಆಗುತ್ತದೆ. ನಾನು ಹೇಳುತ್ತಿರುವುದು ಲಿಟಲ್ಸ್ ಲಾ ಅಥವಾ ಯಾವುದೇ ಸಂಕೀರ್ಣ ಕ್ಯೂಯಿಂಗ್ ಸಿದ್ಧಾಂತವನ್ನು ಬಳಸಲು, ನೀವು ಕನಿಷ್ಟ ಡೇಟಾವನ್ನು ಹೊಂದಿರಬೇಕು.
ಹಾಗಾಗಿ ನಾನು ಗೋಚರತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ಎಲ್ಲವೂ ಪರದೆಯ ಮೇಲೆ ಇದೆ ಎಂದು ನಾನು ಅರ್ಥವಲ್ಲ, ಆದರೆ ನೀವು ಕನಿಷ್ಟ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಅವರು ಮಾಡಿದಾಗ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಬ್ರೆಂಟ್ ಯಾವುದೇ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಹೇಗೋ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಎಂದು ಯೋಜಿತವಲ್ಲದ ಕೆಲಸ ಬಹಳ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಎಂದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಬ್ರೆಂಟ್ ಒಬ್ಬ ಮಹಾನ್ ವ್ಯಕ್ತಿ, ಅವನು ಎಂದಿಗೂ ಇಲ್ಲ ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಆದರೆ ಅವನು ತನ್ನ ಕೆಲಸವನ್ನು ಹೇಗೆ ಮಾಡುತ್ತಾನೆ ಎಂದು ಯಾರಿಗೂ ಹೇಳುವುದಿಲ್ಲ.
ಕೆಲಸವು ಗೋಚರಿಸಿದಾಗ, ಡೇಟಾವನ್ನು ಅಂದವಾಗಿ ವರ್ಗೀಕರಿಸಬಹುದು (ಅದನ್ನು ಡೊಮಿನಿಕಾ ಫೋಟೋದಲ್ಲಿ ಮಾಡುತ್ತಿದ್ದಾರೆ), ಐದು ಬಾರಿ ಸೋರಿಕೆಗಳ ಅಮೂರ್ತತೆಯನ್ನು ಅನ್ವಯಿಸಬಹುದು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತತೆಯನ್ನು ಅನ್ವಯಿಸಬಹುದು.
2. ವರ್ಕ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಏಕೀಕರಿಸಿ: ಕಾರ್ಯ ನಿರ್ವಹಣೆ
ನಾನು ಮಾತನಾಡುತ್ತಿರುವ ಆರ್ಕಿಟೈಪ್‌ಗಳು ಒಂದು ರೀತಿಯ ಪಿರಮಿಡ್‌ಗಳಾಗಿವೆ. ಮೊದಲನೆಯದನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಎರಡನೆಯದು ಈಗಾಗಲೇ ಒಂದು ರೀತಿಯ ಆಡ್-ಆನ್ ಆಗಿದೆ. ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಫಾರ್ಚೂನ್ 5000 ನಂತಹ ದೊಡ್ಡ ಕಂಪನಿಗಳಿಗೆ ಅವುಗಳನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು. ನಾನು ಕೊನೆಯದಾಗಿ ಕೆಲಸ ಮಾಡಿದ ಕಂಪನಿಯು 10 ಟಿಕೆಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಹೊಂದಿತ್ತು. ಒಂದು ತಂಡವು ಪರಿಹಾರವನ್ನು ಹೊಂದಿತ್ತು, ಇನ್ನೊಂದು ತನ್ನದೇ ಆದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬರೆದಿದೆ, ಮೂರನೆಯದು ಜಿರಾವನ್ನು ಬಳಸಿತು, ಮತ್ತು ಕೆಲವರು ಇಮೇಲ್ ಮೂಲಕ ಮಾಡಿದರು. ಕಂಪನಿಯು 30 ವಿಭಿನ್ನ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದೇ ಸಮಸ್ಯೆ ಉಂಟಾಗುತ್ತದೆ, ಆದರೆ ಅಂತಹ ಎಲ್ಲಾ ಪ್ರಕರಣಗಳನ್ನು ಚರ್ಚಿಸಲು ನನಗೆ ಸಮಯವಿಲ್ಲ.
ಟಿಕೆಟ್‌ಗಳನ್ನು ಹೇಗೆ ರಚಿಸಲಾಗಿದೆ, ಮುಂದೆ ಅವರಿಗೆ ಏನಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ತಪ್ಪಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಜನರೊಂದಿಗೆ ನಿಖರವಾಗಿ ಚರ್ಚಿಸುತ್ತೇನೆ. ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ನಮ್ಮ ಸಭೆಗಳಲ್ಲಿ ಜನರು ಸಾಕಷ್ಟು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮಾತನಾಡುತ್ತಾರೆ. ಎಷ್ಟು ಜನರು "ಮೈನರ್ / ನೋ ಇಂಪ್ಯಾಕ್ಟ್" ಅನ್ನು ಟಿಕೆಟ್‌ಗಳ ಮೇಲೆ ಹಾಕುತ್ತಾರೆ ಎಂದು ನಾನು ಕೇಳಿದೆ, ಅದು ನಿಜವಾಗಿ "ಪ್ರಮುಖ ಪರಿಣಾಮ" ನೀಡಬೇಕು. ಬಹುತೇಕ ಎಲ್ಲರೂ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ನಾನು ಖಂಡನೆಯಲ್ಲಿ ತೊಡಗುವುದಿಲ್ಲ ಮತ್ತು ಜನರನ್ನು ಗುರುತಿಸದಿರಲು ಸಾಧ್ಯವಿರುವ ಎಲ್ಲ ರೀತಿಯಲ್ಲಿ ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಅವರು ಪ್ರಾಮಾಣಿಕವಾಗಿ ನನಗೆ ಏನನ್ನಾದರೂ ಒಪ್ಪಿಕೊಂಡಾಗ, ನಾನು ವ್ಯಕ್ತಿಯನ್ನು ಬಿಟ್ಟುಕೊಡುವುದಿಲ್ಲ. ಆದರೆ ಬಹುತೇಕ ಎಲ್ಲರೂ ವ್ಯವಸ್ಥೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಿದಾಗ, ಎಲ್ಲಾ ಭದ್ರತೆಯು ಮೂಲಭೂತವಾಗಿ ವಿಂಡೋ ಡ್ರೆಸ್ಸಿಂಗ್ ಆಗಿದೆ ಎಂದರ್ಥ. ಆದ್ದರಿಂದ, ಈ ವ್ಯವಸ್ಥೆಯ ಡೇಟಾದಿಂದ ಯಾವುದೇ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ.
ಟಿಕೆಟ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಒಂದು ಮುಖ್ಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಜೀರಾ ಬಳಸಿದರೆ, ಅದನ್ನು ಜೀರಾ ಇರಿಸಿಕೊಳ್ಳಿ. ಪರ್ಯಾಯ ಯಾವುದಾದರೂ ಇದ್ದರೆ, ಅದು ಒಂದೇ ಆಗಿರಲಿ. ಟಿಕೆಟ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಮತ್ತೊಂದು ಹಂತವಾಗಿ ನೋಡಬೇಕು ಎಂಬುದು ಬಾಟಮ್ ಲೈನ್. ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯು ಟಿಕೆಟ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು, ಅದು ಅಭಿವೃದ್ಧಿ ಕೆಲಸದ ಹರಿವಿನ ಮೂಲಕ ಹರಿಯಬೇಕು. ಟಿಕೆಟ್‌ಗಳನ್ನು ತಂಡಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಅದು ಅವುಗಳನ್ನು ಸ್ಟೋರಿಬೋರ್ಡ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವರ ಜವಾಬ್ದಾರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಇದು ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆ ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಇಲಾಖೆಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವ್ಯವಹಾರಗಳ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಕನಿಷ್ಠ ಕೆಲವು ತೋರಿಕೆಯ ಕಲ್ಪನೆಯನ್ನು ರೂಪಿಸಲು ಸಾಧ್ಯವಿದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಯಾರು ಜವಾಬ್ದಾರರು ಎಂಬುದನ್ನು ಗುರುತಿಸುವುದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸುಲಭವಾಗುತ್ತದೆ. ಏಕೆಂದರೆ ಈಗ ನಾವು 50% ಅಲ್ಲ, ಆದರೆ 98% ಹೊಸ ಸೇವೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಈ ಕೋರ್ ಪ್ರಕ್ರಿಯೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೆ, ಸಿಸ್ಟಮ್ ಉದ್ದಕ್ಕೂ ನಿಖರತೆ ಸುಧಾರಿಸುತ್ತದೆ.
ಸೇವೆಗಳ ಪೈಪ್ಲೈನ್
ಇದು ಮತ್ತೆ ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ಹೊಸ ಕ್ಷೇತ್ರದಲ್ಲಿ ಹೊಸ ಕಂಪನಿಯಾಗಿದ್ದರೆ, ನಿಮ್ಮ ತೋಳುಗಳನ್ನು ಸುತ್ತಿಕೊಳ್ಳಿ ಮತ್ತು ನಿಮ್ಮ ಟ್ರಾವಿಸ್ CI ಅಥವಾ CircleCI ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿ. ಫಾರ್ಚೂನ್ 5000 ಕಂಪನಿಗಳ ವಿಷಯಕ್ಕೆ ಬಂದರೆ, ನಾನು ಕೆಲಸ ಮಾಡಿದ ಬ್ಯಾಂಕ್‌ನಲ್ಲಿ ನಡೆದ ಒಂದು ಪ್ರಕರಣ. ಗೂಗಲ್ ಅವರ ಬಳಿಗೆ ಬಂದಿತು ಮತ್ತು ಅವರಿಗೆ ಹಳೆಯ IBM ಸಿಸ್ಟಮ್‌ಗಳ ರೇಖಾಚಿತ್ರಗಳನ್ನು ತೋರಿಸಲಾಯಿತು. ಗೂಗಲ್‌ನ ವ್ಯಕ್ತಿಗಳು ಗೊಂದಲದಲ್ಲಿ ಕೇಳಿದರು - ಇದಕ್ಕೆ ಮೂಲ ಕೋಡ್ ಎಲ್ಲಿದೆ? ಆದರೆ ಯಾವುದೇ ಮೂಲ ಕೋಡ್ ಇಲ್ಲ, GUI ಕೂಡ ಇಲ್ಲ. ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳು ವ್ಯವಹರಿಸಬೇಕಾದ ವಾಸ್ತವತೆ ಇದು: ಪುರಾತನ ಮೇನ್‌ಫ್ರೇಮ್‌ನಲ್ಲಿ 40 ವರ್ಷ ವಯಸ್ಸಿನ ಬ್ಯಾಂಕ್ ದಾಖಲೆಗಳು. ನನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಮಾದರಿಗಳೊಂದಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಜೊತೆಗೆ ಚೋಸ್ ಮಂಕಿ, ಎಲ್ಲವನ್ನೂ ಕೀಬ್ಯಾಂಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಬಳಸುತ್ತಾರೆ. ಆದರೆ ಈ ಕಂಟೈನರ್‌ಗಳು ಅಂತಿಮವಾಗಿ COBOL ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ.
Google ನ ವ್ಯಕ್ತಿಗಳು ನನ್ನ ಕ್ಲೈಂಟ್‌ನ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ ಎಂದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಶ್ವಾಸ ಹೊಂದಿದ್ದರು ಮತ್ತು ನಂತರ ಅವರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದರು: IBM ಡೇಟಾಪೈಪ್ ಎಂದರೇನು? ಅವರಿಗೆ ಹೇಳಲಾಗುತ್ತದೆ: ಇದು ಕನೆಕ್ಟರ್ ಆಗಿದೆ. ಇದು ಯಾವುದಕ್ಕೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ? ಸ್ಪೆರ್ರಿ ವ್ಯವಸ್ಥೆಗೆ. ಮತ್ತು ಅದು ಏನು? ಮತ್ತು ಇತ್ಯಾದಿ. ಮೊದಲ ನೋಟದಲ್ಲಿ ಇದು ತೋರುತ್ತದೆ: ಯಾವ ರೀತಿಯ DevOps ಇರಬಹುದು? ಆದರೆ ವಾಸ್ತವವಾಗಿ, ಇದು ಸಾಧ್ಯ. ವಿತರಣಾ ತಂಡಗಳಿಗೆ ಕೆಲಸದ ಹರಿವನ್ನು ಹಸ್ತಾಂತರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಿವೆ.
3. ನಿರ್ಬಂಧಗಳ ಸಿದ್ಧಾಂತ: ನಿರ್ಬಂಧಗಳ ಸಿದ್ಧಾಂತ
ನಾವು ಮೂರನೇ ಮೂಲಮಾದಿಗೆ ಹೋಗೋಣ: ಸಾಂಸ್ಥಿಕ/"ಬುಡಕಟ್ಟು" ಜ್ಞಾನ. ನಿಯಮದಂತೆ, ಯಾವುದೇ ಸಂಸ್ಥೆಯಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ತಿಳಿದಿರುವ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ನಿರ್ವಹಿಸುವ ಹಲವಾರು ಜನರಿದ್ದಾರೆ. ಇವರು ಸಂಸ್ಥೆಯಲ್ಲಿ ದೀರ್ಘಾವಧಿಯವರೆಗೆ ಇದ್ದವರು ಮತ್ತು ಎಲ್ಲಾ ಪರಿಹಾರೋಪಾಯಗಳನ್ನು ತಿಳಿದವರು.
ಇದು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಬಂದಾಗ, ನಾನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಂತಹ ಜನರನ್ನು ಮಾರ್ಕರ್ನೊಂದಿಗೆ ಸುತ್ತುತ್ತೇನೆ: ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಸಭೆಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಲೌ ಇರುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಇದು ನನಗೆ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಇದು ಸ್ಥಳೀಯ ಬ್ರೆಂಟ್. CIO ನನ್ನ ನಡುವೆ ಟಿ-ಶರ್ಟ್ ಮತ್ತು ಸ್ನೀಕರ್ಸ್ ಮತ್ತು ಸೂಟ್‌ನಲ್ಲಿ IBM ನ ಹುಡುಗನನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಾಗ, ನಾನು ಆಯ್ಕೆಯಾಗಿದ್ದೇನೆ ಏಕೆಂದರೆ ಇತರ ವ್ಯಕ್ತಿ ಹೇಳದ ಮತ್ತು ನಿರ್ದೇಶಕರು ಕೇಳಲು ಇಷ್ಟಪಡದ ವಿಷಯಗಳನ್ನು ನಾನು ನಿರ್ದೇಶಕರಿಗೆ ಹೇಳಬಲ್ಲೆ . ಅವರ ಕಂಪನಿಯಲ್ಲಿ ಯಾರೋ ಒಬ್ಬರು ಫ್ರೆಡ್ ಮತ್ತು ಲೌ ಎಂಬ ಹೆಸರಿನವರು ಎಂದು ನಾನು ಅವರಿಗೆ ಹೇಳುತ್ತೇನೆ. ಈ ಅಡಚಣೆಯನ್ನು ಬಿಡಿಸಬೇಕು, ಅವರ ಜ್ಞಾನವನ್ನು ಅವರಿಂದ ಒಂದಲ್ಲ ಒಂದು ರೀತಿಯಲ್ಲಿ ಪಡೆಯಬೇಕು.
ಈ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಉದಾಹರಣೆಗೆ, ಸ್ಲಾಕ್ ಅನ್ನು ಬಳಸಲು ನಾನು ಸಲಹೆ ನೀಡಬಹುದು. ಒಬ್ಬ ಬುದ್ಧಿವಂತ ನಿರ್ದೇಶಕ ಕೇಳುತ್ತಾನೆ - ಏಕೆ? ವಿಶಿಷ್ಟವಾಗಿ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, DevOps ಸಲಹೆಗಾರರು ಉತ್ತರಿಸುತ್ತಾರೆ: ಏಕೆಂದರೆ ಎಲ್ಲರೂ ಇದನ್ನು ಮಾಡುತ್ತಿದ್ದಾರೆ. ನಿರ್ದೇಶಕರು ನಿಜವಾಗಿಯೂ ಬುದ್ಧಿವಂತರಾಗಿದ್ದರೆ, ಅವರು ಹೇಳುತ್ತಾರೆ: ಹಾಗಾದರೆ ಏನು. ಮತ್ತು ಇಲ್ಲಿ ಸಂಭಾಷಣೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಇದಕ್ಕೆ ನನ್ನ ಉತ್ತರ ಹೀಗಿದೆ: ಏಕೆಂದರೆ ಕಂಪನಿಯಲ್ಲಿ ನಾಲ್ಕು ಅಡಚಣೆಗಳಿವೆ, ಫ್ರೆಡ್, ಲೌ, ಸೂಸಿ ಮತ್ತು ಜೇನ್. ಅವರ ಜ್ಞಾನವನ್ನು ಸಾಂಸ್ಥಿಕಗೊಳಿಸಲು, ಒಬ್ಬರು ಮೊದಲು ಸ್ಲಾಕ್ ಅನ್ನು ಪರಿಚಯಿಸಬೇಕು. ನಿಮ್ಮ ಎಲ್ಲಾ ವಿಕಿಗಳು ಸಂಪೂರ್ಣ ಅಸಂಬದ್ಧವಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಫ್ರಂಟ್ ಎಂಡ್ ಮತ್ತು ಬ್ಯಾಕ್ ಎಂಡ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರೆ ಮತ್ತು ಅವರು ಫ್ರಂಟ್-ಎಂಡ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಟೀಮ್ ಅಥವಾ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ತಂಡವನ್ನು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು ಎಂದು ಪ್ರತಿಯೊಬ್ಬರೂ ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ಆಗ ಲೌ ಅಥವಾ ಫ್ರೆಡ್ ಬಹುಶಃ ವಿಕಿಯನ್ನು ಸೇರಲು ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ತದನಂತರ ಸ್ಲಾಕ್‌ನಲ್ಲಿ ಯಾರಾದರೂ ಏಕೆ, ಹಂತ 5 ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂದು ಕೇಳಬಹುದು ಮತ್ತು ನಂತರ ಲೌ ಅಥವಾ ಫ್ರೆಡ್ ವಿಕಿಯಲ್ಲಿನ ಸೂಚನೆಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತಾರೆ. ನೀವು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಾಪಿಸಿದರೆ, ನಂತರ ಬಹಳಷ್ಟು ವಿಷಯಗಳು ತಮ್ಮದೇ ಆದ ಸ್ಥಳದಲ್ಲಿ ಬೀಳುತ್ತವೆ.
ಇದು ನನ್ನ ಮುಖ್ಯ ಅಂಶವಾಗಿದೆ: ಯಾವುದೇ ಉನ್ನತ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡಲು, ನೀವು ಮೊದಲು ಅವರಿಗೆ ಅಡಿಪಾಯವನ್ನು ಕ್ರಮವಾಗಿ ಹಾಕಬೇಕು ಮತ್ತು ಇದನ್ನು ಈಗ ವಿವರಿಸಿದ ಕಡಿಮೆ ತಂತ್ರಜ್ಞಾನದ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಮಾಡಬಹುದು. ನೀವು ಉನ್ನತ ತಂತ್ರಜ್ಞಾನಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದರೆ ಮತ್ತು ಅವು ಏಕೆ ಬೇಕು ಎಂದು ವಿವರಿಸದಿದ್ದರೆ, ನಿಯಮದಂತೆ, ಇದು ಚೆನ್ನಾಗಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ. ನಮ್ಮ ಗ್ರಾಹಕರಲ್ಲಿ ಒಬ್ಬರು Azure ML ಅನ್ನು ಬಳಸುತ್ತಾರೆ, ಇದು ಅತ್ಯಂತ ಅಗ್ಗದ ಮತ್ತು ಸರಳ ಪರಿಹಾರವಾಗಿದೆ. ಅವರ ಸುಮಾರು 30% ಪ್ರಶ್ನೆಗಳಿಗೆ ಸ್ವಯಂ-ಕಲಿಕೆ ಯಂತ್ರದಿಂದಲೇ ಉತ್ತರಿಸಲಾಗಿದೆ. ಮತ್ತು ಈ ವಿಷಯವನ್ನು ದತ್ತಾಂಶ ವಿಜ್ಞಾನ, ಅಂಕಿಅಂಶಗಳು ಅಥವಾ ಗಣಿತದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳದ ನಿರ್ವಾಹಕರು ಬರೆದಿದ್ದಾರೆ. ಇದು ಗಮನಾರ್ಹವಾಗಿದೆ. ಅಂತಹ ಪರಿಹಾರದ ವೆಚ್ಚವು ಕಡಿಮೆಯಾಗಿದೆ.
4. ಸಹಯೋಗ ಭಿನ್ನತೆಗಳು: ಸಹಯೋಗ ಭಿನ್ನತೆಗಳು
ನಾಲ್ಕನೆಯ ಮೂಲಮಾದರಿಯು ಪ್ರತ್ಯೇಕತೆಯ ವಿರುದ್ಧ ಹೋರಾಡುವ ಅಗತ್ಯತೆಯಾಗಿದೆ. ಹೆಚ್ಚಿನ ಜನರು ಇದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದಾರೆ: ಪ್ರತ್ಯೇಕತೆಯು ಹಗೆತನವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವಿಭಾಗವು ತನ್ನದೇ ಆದ ಮಹಡಿಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ಜನರು ಎಲಿವೇಟರ್ ಅನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಛೇದಿಸದಿದ್ದರೆ, ಅವುಗಳ ನಡುವೆ ಹಗೆತನವು ಬಹಳ ಸುಲಭವಾಗಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಆದರೆ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಜನರು ಪರಸ್ಪರ ಒಂದೇ ಕೋಣೆಯಲ್ಲಿದ್ದರೆ, ಅವಳು ತಕ್ಷಣ ಹೊರಡುತ್ತಾಳೆ. ಯಾರಾದರೂ ಕೆಲವು ಸಾಮಾನ್ಯ ಆರೋಪಗಳನ್ನು ಹೊರಹಾಕಿದಾಗ, ಉದಾಹರಣೆಗೆ, ಅಂತಹ ಮತ್ತು ಅಂತಹ ಇಂಟರ್ಫೇಸ್ ಎಂದಿಗೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಅಂತಹ ಆರೋಪವನ್ನು ಪುನರ್ನಿರ್ಮಿಸಲು ಸುಲಭವಾದ ಏನೂ ಇಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬರೆದ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ, ಮತ್ತು ಇದು ಶೀಘ್ರದಲ್ಲೇ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು ಉಪಕರಣವನ್ನು ತಪ್ಪಾಗಿ ಬಳಸುತ್ತಿದ್ದಾರೆ.
ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಜಯಿಸಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ. ಒಮ್ಮೆ ಆಸ್ಟ್ರೇಲಿಯಾದಲ್ಲಿ ಬ್ಯಾಂಕ್‌ಗೆ ಸಲಹೆ ಕೇಳಲು ನನ್ನನ್ನು ಕೇಳಲಾಯಿತು, ಆದರೆ ನನಗೆ ಇಬ್ಬರು ಮಕ್ಕಳು ಮತ್ತು ಹೆಂಡತಿ ಇರುವುದರಿಂದ ನಾನು ಅದನ್ನು ಮಾಡಲು ನಿರಾಕರಿಸಿದೆ. ಅವರಿಗೆ ಸಹಾಯ ಮಾಡಲು ನಾನು ಮಾಡಬಹುದಾದದ್ದು ಚಿತ್ರಾತ್ಮಕ ಕಥೆ ಹೇಳುವಿಕೆಯನ್ನು ಶಿಫಾರಸು ಮಾಡುವುದು. ಇದು ಕೆಲಸ ಮಾಡಲು ಸಾಬೀತಾಗಿರುವ ವಿಷಯ. ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ಮಾರ್ಗವೆಂದರೆ ನೇರ ಕಾಫಿ ಸಭೆಗಳು. ದೊಡ್ಡ ಸಂಸ್ಥೆಯಲ್ಲಿ, ಜ್ಞಾನವನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ಇದು ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು ಆಂತರಿಕ ಡೆವೊಪ್‌ಡೇಸ್, ಹ್ಯಾಕಥಾನ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ನಡೆಸಬಹುದು.
5. ಕೋಚಿಂಗ್ ಕಾಟಾ
ನಾನು ಬಹಳ ಆರಂಭದಲ್ಲಿ ಎಚ್ಚರಿಸಿದಂತೆ, ನಾನು ಇಂದು ಈ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ನಿಮಗೆ ಆಸಕ್ತಿ ಇದ್ದರೆ, ನೀವು ನೋಡಬಹುದು .
ಮೈಕ್ ರೋಥರ್ ಅವರಿಂದ ಈ ವಿಷಯದ ಬಗ್ಗೆ ಉತ್ತಮ ಚರ್ಚೆಯೂ ಇದೆ:
6. ಮಾರುಕಟ್ಟೆ ಆಧಾರಿತ: ಮಾರುಕಟ್ಟೆ ಆಧಾರಿತ ಸಂಸ್ಥೆ
ಇಲ್ಲಿ ವಿವಿಧ ಸಮಸ್ಯೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, "I" ಜನರು, "T" ಜನರು ಮತ್ತು "E" ಜನರು. "ನಾನು" ಜನರು ಒಂದೇ ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡುವವರು. ವಿಶಿಷ್ಟವಾಗಿ ಅವರು ಪ್ರತ್ಯೇಕ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿರುವ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತಾರೆ. "ಟಿ" ಎಂದರೆ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಒಂದು ವಿಷಯದಲ್ಲಿ ಉತ್ತಮ ಆದರೆ ಇತರ ಕೆಲವು ವಿಷಯಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಅನೇಕ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವಾಗ "ಇ" ಅಥವಾ "ಬಾಚಣಿಗೆ" ಕೂಡ.
ಕಾನ್ವೇ ಕಾನೂನು ಇಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (), ಇದನ್ನು ಅತ್ಯಂತ ಸರಳೀಕೃತ ರೂಪದಲ್ಲಿ ಈ ಕೆಳಗಿನಂತೆ ಹೇಳಬಹುದು: ಮೂರು ತಂಡಗಳು ಕಂಪೈಲರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರೆ, ಫಲಿತಾಂಶವು ಮೂರು ಭಾಗಗಳ ಕಂಪೈಲರ್ ಆಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಂಸ್ಥೆಯೊಳಗೆ ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಪ್ರತ್ಯೇಕತೆಯಿದ್ದರೆ, ಈ ಸಂಸ್ಥೆಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್, API ವಿಸ್ತರಣೆ ಮತ್ತು ಇತರ ಅಲಂಕಾರಿಕ ವಸ್ತುಗಳನ್ನು ಸಹ ಸಂಸ್ಥೆಯ ರೀತಿಯಲ್ಲಿಯೇ ಜೋಡಿಸಲಾಗುತ್ತದೆ. ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಕಾನ್ವೇ ಪ್ರಕಾರ ಮತ್ತು ಎಲ್ಲಾ ಯುವ ಗೀಕ್‌ಗಳ ಹೊರತಾಗಿಯೂ.
ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಹಲವು ಬಾರಿ ವಿವರಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಫರ್ನಾಂಡೋ ಫೆರ್ನಾಂಡಿಸ್ ವಿವರಿಸಿದ ಸಾಂಸ್ಥಿಕ ಮೂಲಮಾದರಿಗಳಿವೆ. ನಾನು ಈಗಷ್ಟೇ ಮಾತನಾಡಿರುವ ಸಮಸ್ಯಾತ್ಮಕ ವಾಸ್ತುಶಿಲ್ಪವು ಪ್ರತ್ಯೇಕತೆಯೊಂದಿಗೆ ಕಾರ್ಯ-ಆಧಾರಿತ ವಾಸ್ತುಶಿಲ್ಪವಾಗಿದೆ. ಎರಡನೆಯ ವಿಧವು ಕೆಟ್ಟದಾಗಿದೆ, ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್, ಇತರ ಎರಡರ ಅವ್ಯವಸ್ಥೆ. ಮೂರನೆಯದು ಹೆಚ್ಚಿನ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಲ್ಲಿ ಕಂಡುಬರುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಕಂಪನಿಗಳು ಸಹ ಈ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿವೆ. ಇದು ಮಾರುಕಟ್ಟೆ ಆಧಾರಿತ ಸಂಸ್ಥೆಯಾಗಿದೆ. ಗ್ರಾಹಕರ ವಿನಂತಿಗಳಿಗೆ ವೇಗವಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಾಧಿಸಲು ನಾವು ಇಲ್ಲಿ ಆಪ್ಟಿಮೈಜ್ ಮಾಡುತ್ತೇವೆ. ಇದನ್ನು ಕೆಲವೊಮ್ಮೆ ಫ್ಲಾಟ್ ಸಂಸ್ಥೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ಅನೇಕ ಜನರು ಈ ರಚನೆಯನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸುತ್ತಾರೆ, ನಾನು ಪದಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ ತಂಡಗಳನ್ನು ನಿರ್ಮಿಸಿ/ರನ್ ಮಾಡಿ, Amazon ನಲ್ಲಿ ಅವರು ಅದನ್ನು ಕರೆಯುತ್ತಾರೆ ಎರಡು ಪಿಜ್ಜಾ ತಂಡಗಳು. ಈ ರಚನೆಯಲ್ಲಿ, ಎಲ್ಲಾ ಪ್ರಕಾರದ "I" ಜನರನ್ನು ಒಂದು ಸೇವೆಯ ಸುತ್ತಲೂ ಗುಂಪು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ರಮೇಣ ಅವರು "T" ಟೈಪ್‌ಗೆ ಹತ್ತಿರವಾಗುತ್ತಾರೆ ಮತ್ತು ಸರಿಯಾದ ನಿರ್ವಹಣೆಯು ಸ್ಥಳದಲ್ಲಿದ್ದರೆ, ಅವರು "E" ಆಗಬಹುದು. ಇಲ್ಲಿ ಮೊದಲ ಪ್ರತಿವಾದವೆಂದರೆ ಅಂತಹ ರಚನೆಯು ಅನಗತ್ಯ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ನೀವು ಪರೀಕ್ಷಕರ ವಿಶೇಷ ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದರೆ ಪ್ರತಿ ವಿಭಾಗದಲ್ಲಿ ಪರೀಕ್ಷಕರು ಏಕೆ ಬೇಕು? ಇದಕ್ಕೆ ನಾನು ಉತ್ತರಿಸುತ್ತೇನೆ: ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚಗಳು ಭವಿಷ್ಯದಲ್ಲಿ "E" ಟೈಪ್ ಆಗಲು ಇಡೀ ಸಂಸ್ಥೆಗೆ ಬೆಲೆಯಾಗಿದೆ. ಈ ರಚನೆಯಲ್ಲಿ, ಪರೀಕ್ಷಕ ಕ್ರಮೇಣ ಜಾಲಗಳು, ವಾಸ್ತುಶಿಲ್ಪ, ವಿನ್ಯಾಸ ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಕಲಿಯುತ್ತಾನೆ. ಪರಿಣಾಮವಾಗಿ, ಸಂಸ್ಥೆಯ ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು ಸಂಸ್ಥೆಯಲ್ಲಿ ನಡೆಯುವ ಎಲ್ಲದರ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿರುತ್ತಾರೆ. ಉದ್ಯಮದಲ್ಲಿ ಈ ಯೋಜನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ಓದಿ .
7. ಶಿಫ್ಟ್-ಲೆಫ್ಟ್ ಆಡಿಟರ್‌ಗಳು: ಚಕ್ರದ ಆರಂಭದಲ್ಲಿ ಆಡಿಟ್ ಮಾಡಿ. ಪ್ರದರ್ಶನದಲ್ಲಿ ಸುರಕ್ಷತಾ ನಿಯಮಗಳ ಅನುಸರಣೆ
ನಿಮ್ಮ ಕ್ರಿಯೆಗಳು ವಾಸನೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗದಿದ್ದಾಗ, ಮಾತನಾಡಲು ಇದು ಸಂಭವಿಸುತ್ತದೆ. ನಿಮ್ಮ ಪರವಾಗಿ ಕೆಲಸ ಮಾಡುವವರು ಮೂರ್ಖರಲ್ಲ. ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ, ಅವರು ಎಲ್ಲೆಡೆ ಸಣ್ಣ / ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರದಿದ್ದರೆ, ಇದು ಮೂರು ವರ್ಷಗಳ ಕಾಲ ನಡೆಯಿತು ಮತ್ತು ಯಾರೂ ಏನನ್ನೂ ಗಮನಿಸದಿದ್ದರೆ, ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂದು ಎಲ್ಲರಿಗೂ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ. ಅಥವಾ ಇನ್ನೊಂದು ಉದಾಹರಣೆ - ಬದಲಾವಣೆ ಸಲಹಾ ಮಂಡಳಿ, ಅಲ್ಲಿ ವರದಿಗಳನ್ನು ಪ್ರತಿ ಸಲ್ಲಿಸಬೇಕು, ಬುಧವಾರ ಹೇಳಬೇಕು. ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಜನರ ಗುಂಪು ಇದೆ (ಅತ್ಯಂತ ಉತ್ತಮ ಸಂಬಳವಿಲ್ಲ) ಅವರು ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಒಟ್ಟಾರೆಯಾಗಿ ಸಿಸ್ಟಮ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿದಿರಬೇಕು. ಮತ್ತು ಕಳೆದ ಐದು ವರ್ಷಗಳಲ್ಲಿ, ನಮ್ಮ ವ್ಯವಸ್ಥೆಗಳು ನಂಬಲಾಗದಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿವೆ ಎಂದು ನೀವು ಬಹುಶಃ ಗಮನಿಸಿದ್ದೀರಿ. ಮತ್ತು ಐದು ಅಥವಾ ಆರು ಜನರು ತಾವು ಮಾಡದ ಮತ್ತು ಅವರಿಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲದ ಬದಲಾವಣೆಯ ಬಗ್ಗೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.
ಸಹಜವಾಗಿ, ಈ ವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಈ ಜನ ವ್ಯವಸ್ಥೆಯನ್ನು ರಕ್ಷಿಸುತ್ತಿಲ್ಲ ಎಂಬ ಕಾರಣಕ್ಕೆ ನಾನು ಅಂತಹ ವಿಷಯಗಳನ್ನು ತೊಡೆದುಹಾಕಬೇಕಾಗಿದೆ. ನಿರ್ಧಾರವನ್ನು ತಂಡವು ಸ್ವತಃ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ ತಂಡವು ಅದರ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಇಲ್ಲದಿದ್ದರೆ, ತನ್ನ ಜೀವನದಲ್ಲಿ ಎಂದಿಗೂ ಕೋಡ್ ಅನ್ನು ಬರೆಯದ ಮ್ಯಾನೇಜರ್ ಪ್ರೋಗ್ರಾಮರ್ಗೆ ಕೋಡ್ ಬರೆಯಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂದು ಹೇಳಿದಾಗ ವಿರೋಧಾಭಾಸದ ಪರಿಸ್ಥಿತಿ ಉಂಟಾಗುತ್ತದೆ. ನಾನು ಕೆಲಸ ಮಾಡಿದ ಒಂದು ಕಂಪನಿಯು ಆರ್ಕಿಟೆಕ್ಚರ್ ಬೋರ್ಡ್, ಉತ್ಪನ್ನ ಬೋರ್ಡ್ ಇತ್ಯಾದಿಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯನ್ನು ಪರಿಶೀಲಿಸುವ 7 ವಿಭಿನ್ನ ಬೋರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿತ್ತು. ಕಡ್ಡಾಯ ಕಾಯುವ ಅವಧಿ ಕೂಡ ಇತ್ತು, ಆದರೂ ಒಬ್ಬ ಉದ್ಯೋಗಿ ನನಗೆ ಹೇಳಿದರೂ ಹತ್ತು ವರ್ಷಗಳ ಕೆಲಸದಲ್ಲಿ, ಈ ಕಡ್ಡಾಯ ಅವಧಿಯಲ್ಲಿ ಈ ವ್ಯಕ್ತಿಯು ಮಾಡಿದ ಬದಲಾವಣೆಯನ್ನು ಯಾರೂ ತಿರಸ್ಕರಿಸಲಿಲ್ಲ.
ಲೆಕ್ಕಪರಿಶೋಧಕರನ್ನು ನಮ್ಮೊಂದಿಗೆ ಸೇರಲು ಆಹ್ವಾನಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಅವರನ್ನು ತೊಡೆದುಹಾಕಲು ಅಲ್ಲ. ಅವರು ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾದರೆ, ಶಾಶ್ವತವಾಗಿ ಬದಲಾಗದೆ ಉಳಿಯಲು ನೀವು ಬದಲಾಗದ ಬೈನರಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಬರೆಯುತ್ತೀರಿ ಎಂದು ಅವರಿಗೆ ತಿಳಿಸಿ. ನೀವು ಕೋಡ್‌ನಂತೆ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಹೊಂದಿರುವಿರಿ ಮತ್ತು ಅದರ ಅರ್ಥವನ್ನು ವಿವರಿಸಿ ಎಂದು ಅವರಿಗೆ ತಿಳಿಸಿ. ಅವರಿಗೆ ಈ ಕೆಳಗಿನ ಸ್ಕೀಮ್ ಅನ್ನು ತೋರಿಸಿ: ಎಲ್ಲಾ ದುರ್ಬಲತೆ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗುವ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಬದಲಾಗದ ಓದಲು-ಮಾತ್ರ ಬೈನರಿ; ತದನಂತರ ಯಾರೂ ಅದನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ ಮಾತ್ರವಲ್ಲ, ಪೈಪ್ಲೈನ್ ಅನ್ನು ರಚಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಹ ಅವರು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಲಾಗಿದೆ. ನಾನು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ, ಕ್ಯಾಪಿಟಲ್ ಒನ್, ಅವರು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಂತಹದನ್ನು ರಚಿಸಲು ವಾಲ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ. ಆಡಿಟರ್ ಬಾಣಸಿಗರಿಂದ "ಪಾಕವಿಧಾನಗಳನ್ನು" ತೋರಿಸಬೇಕಾಗಿಲ್ಲ; ಬ್ಲಾಕ್‌ಚೈನ್ ಅನ್ನು ತೋರಿಸಲು ಸಾಕು, ಇದರಿಂದ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಜಿರಾ ಟಿಕೆಟ್‌ಗೆ ಏನಾಯಿತು ಮತ್ತು ಅದಕ್ಕೆ ಯಾರು ಜವಾಬ್ದಾರರು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ಪ್ರಕಾರ , 2018 ರಲ್ಲಿ Sonatype ಮೂಲಕ ರಚಿಸಲಾಗಿದೆ, 2017 ರಲ್ಲಿ 87 ಬಿಲಿಯನ್ OSS ಡೌನ್‌ಲೋಡ್ ವಿನಂತಿಗಳು ಇದ್ದವು.
ದುರ್ಬಲತೆಗಳಿಂದ ಉಂಟಾದ ನಷ್ಟಗಳು ನಿಷಿದ್ಧ. ಇದಲ್ಲದೆ, ನೀವು ಈಗ ಮೇಲೆ ನೋಡುತ್ತಿರುವ ಅಂಕಿಅಂಶಗಳು ಅವಕಾಶ ವೆಚ್ಚಗಳನ್ನು ಒಳಗೊಂಡಿಲ್ಲ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ DevSecOps ಎಂದರೇನು? ಈ ಹೆಸರು ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಲು ನನಗೆ ಆಸಕ್ತಿಯಿಲ್ಲ ಎಂದು ಈಗಿನಿಂದಲೇ ಹೇಳುತ್ತೇನೆ. ವಿಷಯವೆಂದರೆ DevOps ತುಂಬಾ ಯಶಸ್ವಿಯಾಗಿರುವುದರಿಂದ, ನಾವು ಆ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಭದ್ರತೆಯನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು.
ಈ ಅನುಕ್ರಮದ ಉದಾಹರಣೆ:
ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನಗಳಿಗೆ ಇದು ಶಿಫಾರಸು ಅಲ್ಲ, ಆದರೂ ನಾನು ಎಲ್ಲವನ್ನೂ ಇಷ್ಟಪಡುತ್ತೇನೆ. ಆರಂಭದಲ್ಲಿ ಉದ್ಯಮದಲ್ಲಿನ ಸಾಂಸ್ಥಿಕ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿದ DevOps, ಉತ್ಪನ್ನದ ಪ್ರತಿಯೊಂದು ಹಂತದ ಕೆಲಸವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸಲು ನಾನು ಅವುಗಳನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಉಲ್ಲೇಖಿಸಿದೆ.
ಮತ್ತು ನಾವು ಭದ್ರತೆಗೆ ಅದೇ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಿರಲು ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ.
ಫಲಿತಾಂಶ
ತೀರ್ಮಾನವಾಗಿ, ನಾನು DevSecOps ಗಾಗಿ ಕೆಲವು ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು ಲೆಕ್ಕಪರಿಶೋಧಕರನ್ನು ಸೇರಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅವರಿಗೆ ಶಿಕ್ಷಣ ನೀಡಲು ಸಮಯವನ್ನು ಕಳೆಯಬೇಕು. ನೀವು ಲೆಕ್ಕಪರಿಶೋಧಕರೊಂದಿಗೆ ಸಹಕರಿಸಬೇಕು. ಮುಂದೆ, ನೀವು ತಪ್ಪು ಧನಾತ್ಮಕ ವಿರುದ್ಧ ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ದಯ ಹೋರಾಟವನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ಸಿಗ್ನಲ್-ಟು-ಶಬ್ದ ಅನುಪಾತ ಏನು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಅತ್ಯಂತ ದುಬಾರಿ ದುರ್ಬಲತೆ ಸ್ಕ್ಯಾನಿಂಗ್ ಉಪಕರಣದೊಂದಿಗೆ ಸಹ, ನಿಮ್ಮ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ನೀವು ಕೆಟ್ಟ ಅಭ್ಯಾಸಗಳನ್ನು ರಚಿಸಬಹುದು. ಡೆವಲಪರ್‌ಗಳು ಈವೆಂಟ್‌ಗಳಿಂದ ಮುಳುಗುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಅಳಿಸುತ್ತಾರೆ. ನೀವು ಈಕ್ವಿಫ್ಯಾಕ್ಸ್ ಕಥೆಯ ಬಗ್ಗೆ ಕೇಳಿದರೆ, ಅಲ್ಲಿ ಏನಾಯಿತು, ಅಲ್ಲಿ ಹೆಚ್ಚಿನ ಎಚ್ಚರಿಕೆಯ ಮಟ್ಟವನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ದುರ್ಬಲತೆಗಳು ವ್ಯವಹಾರದ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸಬೇಕಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಈಕ್ವಿಫ್ಯಾಕ್ಸ್ ಕಥೆಯಲ್ಲಿರುವಂತೆಯೇ ಇದು ದುರ್ಬಲತೆಯಾಗಿದೆ ಎಂದು ನೀವು ಹೇಳಬಹುದು. ಭದ್ರತಾ ದೋಷಗಳನ್ನು ಇತರ ಸಾಫ್ಟ್‌ವೇರ್ ಸಮಸ್ಯೆಗಳಂತೆಯೇ ಪರಿಗಣಿಸಬೇಕು, ಅಂದರೆ, ಅವುಗಳನ್ನು ಒಟ್ಟಾರೆ DevOps ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸೇರಿಸಬೇಕು. ಜಿರಾ, ಕಾನ್ಬನ್ ಇತ್ಯಾದಿಗಳ ಮೂಲಕ ನೀವು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಬೇರೊಬ್ಬರು ಇದನ್ನು ಮಾಡುತ್ತಾರೆ ಎಂದು ಡೆವಲಪರ್‌ಗಳು ಭಾವಿಸಬಾರದು - ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಇದನ್ನು ಮಾಡಬೇಕು. ಅಂತಿಮವಾಗಿ, ಜನರಿಗೆ ತರಬೇತಿ ನೀಡಲು ನೀವು ಶಕ್ತಿಯನ್ನು ವ್ಯಯಿಸಬೇಕಾಗಿದೆ.
ಉಪಯುಕ್ತ ಕೊಂಡಿಗಳು
Devoops ಕಾನ್ಫರೆನ್ಸ್‌ನಿಂದ ನಿಮಗೆ ಉಪಯುಕ್ತವಾದ ಕೆಲವು ಮಾತುಕತೆಗಳು ಇಲ್ಲಿವೆ:
- ಸೆರ್ಗೆ ಬರ್ಡ್ನಿಕೋವ್, ಆರ್ಟಿಯೋಮ್ ಕಲಿಚ್ಕಿನ್ - ಯಶಸ್ಸಿನ ಕಥೆ, ಅಥವಾ "Dev+DevOps+Ops" (, )
- ಬರೂಚ್ ಸಡೋಗುರ್ಸ್ಕಿ, ಲಿಯೊನಿಡ್ ಇಗೊಲ್ನಿಕ್ - ಡೆವೊಪ್ಸ್ ಆನ್ ಎ ಸ್ಕೇಲ್: ಮೂರು ಕೃತ್ಯಗಳಲ್ಲಿ ಗ್ರೀಕ್ ದುರಂತ (, )
- ಅಲೆಕ್ಸಾಂಡರ್ ಟಿಟೊವ್, ಕಿರಿಲ್ ಟೋಲ್ಕಾಚೆವ್ -
- ತಿಮೋತಿ ಲಿಸ್ಟರ್ -
ಒಳಗೆ ನೋಡಿ Devoops 2020 ಮಾಸ್ಕೋ - ಅಲ್ಲಿ ಸಾಕಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳಿವೆ.
ಮೂಲ: www.habr.com