ನಿರ್ವಾಹಕರು, devops, ಅಂತ್ಯವಿಲ್ಲದ ಗೊಂದಲ ಮತ್ತು ಕಂಪನಿಯೊಳಗೆ DevOps ರೂಪಾಂತರದ ಬಗ್ಗೆ

ನಿರ್ವಾಹಕರು, devops, ಅಂತ್ಯವಿಲ್ಲದ ಗೊಂದಲ ಮತ್ತು ಕಂಪನಿಯೊಳಗೆ DevOps ರೂಪಾಂತರದ ಬಗ್ಗೆ

2019 ರಲ್ಲಿ ಐಟಿ ಕಂಪನಿ ಯಶಸ್ವಿಯಾಗಲು ಏನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? ಸಮ್ಮೇಳನಗಳು ಮತ್ತು ಸಭೆಗಳಲ್ಲಿ ಉಪನ್ಯಾಸಕರು ಸಾಮಾನ್ಯ ಜನರಿಗೆ ಯಾವಾಗಲೂ ಅರ್ಥವಾಗದ ಬಹಳಷ್ಟು ಜೋರಾಗಿ ಪದಗಳನ್ನು ಹೇಳುತ್ತಾರೆ. ನಿಯೋಜನೆ ಸಮಯ, ಮೈಕ್ರೊ ಸರ್ವೀಸ್, ಏಕಶಿಲೆಯ ತ್ಯಜಿಸುವಿಕೆ, DevOps ರೂಪಾಂತರ ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳಿಗಾಗಿ ಹೋರಾಟ. ನಾವು ಮೌಖಿಕ ಸೌಂದರ್ಯವನ್ನು ತ್ಯಜಿಸಿದರೆ ಮತ್ತು ನೇರವಾಗಿ ಮತ್ತು ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಮಾತನಾಡಿದರೆ, ಅದು ಸರಳವಾದ ಪ್ರಬಂಧಕ್ಕೆ ಬರುತ್ತದೆ: ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ತಯಾರಿಸಿ ಮತ್ತು ತಂಡಕ್ಕೆ ಆರಾಮವಾಗಿ ಮಾಡಿ.

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

ಈ ಸಂಪೂರ್ಣ "ಮಾಡ್ಯುಲರ್" ಕಥೆಯು ಅದ್ಭುತವಾಗಿದೆ, ಆದರೆ... ಕೆಲವು ನಿರ್ವಾಹಕರನ್ನು ಥಟ್ಟನೆ DevOps ಎಂದು ಕರೆಯಲಾಯಿತು ಮತ್ತು DevOps ಇಂಜಿನಿಯರ್‌ಗಳು ಕನಿಷ್ಠ ಟೆಲಿಪತಿ ಮತ್ತು ಕ್ಲೈರ್‌ವಾಯನ್ಸ್‌ನ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಲು ಪ್ರಾರಂಭಿಸಿದರು.

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

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

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

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

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

ಕ್ಯಾಚ್ ಏನು?

"DevOps ಯಾರು?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಕ್ಷೇತ್ರದಲ್ಲಿರುವ ಅರ್ಧದಷ್ಟು ಕೆಲಸಗಾರರು "ಸರಿ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಇದು ನಿರ್ವಾಹಕರು ಯಾರು ..." ಮತ್ತು ಮುಂದೆ ಪಠ್ಯದಲ್ಲಿ ಉತ್ತರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಹೌದು, ಒಂದು ಕಾಲದಲ್ಲಿ, DevOps ಇಂಜಿನಿಯರ್ ವೃತ್ತಿಯು ಸೇವಾ ನಿರ್ವಹಣೆಯ ವಿಷಯದಲ್ಲಿ ಅತ್ಯಂತ ಪ್ರತಿಭಾವಂತ ನಿರ್ವಾಹಕರಿಂದ ಹೊರಹೊಮ್ಮುತ್ತಿರುವಾಗ, ಅವರ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು ಎಲ್ಲರಿಗೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಆದರೆ ಈಗ, ತಂಡದಲ್ಲಿನ devops ಮತ್ತು ನಿರ್ವಾಹಕರ ಕಾರ್ಯಗಳು ಆಮೂಲಾಗ್ರವಾಗಿ ವಿಭಿನ್ನವಾದಾಗ, ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಗೊಂದಲಗೊಳಿಸುವುದು ಅಥವಾ ಅವುಗಳನ್ನು ಸಮೀಕರಿಸುವುದು ಸಹ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ.

ಆದರೆ ವ್ಯಾಪಾರಕ್ಕೆ ಇದರ ಅರ್ಥವೇನು?

ನೇಮಕಾತಿ, ಇದು ಅದರ ಬಗ್ಗೆ ಅಷ್ಟೆ.

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

ಆದಾಗ್ಯೂ, ಅಂತಹ ಖಾಲಿ ಹುದ್ದೆಯನ್ನು ಓದುವಾಗ ಒಬ್ಬರು ಯಾವ ಅನಿಸಿಕೆ ಪಡೆಯುತ್ತಾರೆ? ಕಂಪನಿಯು ಬಹು-ಯಂತ್ರ ನಿರ್ವಾಹಕರನ್ನು ಹುಡುಕುತ್ತಿದೆ, ಅವರು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆ ಎರಡನ್ನೂ ನಿಯೋಜಿಸುತ್ತಾರೆ ಮತ್ತು ಟ್ವಿಸ್ಟರ್ ಅನ್ನು ಹಲ್ಲುಗಳಿಂದ ಹಿಂಡುತ್ತಾರೆ ...

ಆದರೆ ಕಾರ್ಮಿಕ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಮಾದಕ ವ್ಯಸನದ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸದಿರಲು, ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ಅವರ ಸರಿಯಾದ ಹೆಸರಿನಿಂದ ಕರೆಯಲು ಸಾಕು ಮತ್ತು DevOps ಎಂಜಿನಿಯರ್ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಎರಡು ವಿಭಿನ್ನ ಘಟಕಗಳು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಆದರೆ ಅಭ್ಯರ್ಥಿಗೆ ಅಗತ್ಯವಿರುವ ವಿಶಾಲವಾದ ಪಟ್ಟಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ಕೆಲವು ಉದ್ಯೋಗದಾತರ ಅದಮ್ಯ ಬಯಕೆಯು "ಕ್ಲಾಸಿಕ್" ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ತಮ್ಮ ಸುತ್ತಲೂ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಏನು, ವೃತ್ತಿಯು ರೂಪಾಂತರಗೊಳ್ಳುತ್ತಿದೆ ಮತ್ತು ಅವರು ಸಮಯದ ಹಿಂದೆ ಇದ್ದಾರೆಯೇ?

ಇಲ್ಲ ಇಲ್ಲ ಮತ್ತು ಇನ್ನೊಂದು ಬಾರಿ ಇಲ್ಲ. ಕಂಪನಿಯ ಆಂತರಿಕ ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಥವಾ L2/L3 ಬೆಂಬಲದ ಸ್ಥಾನಗಳನ್ನು ಆಕ್ರಮಿಸುವ ಮತ್ತು ಇತರ ಉದ್ಯೋಗಿಗಳಿಗೆ ಸಹಾಯ ಮಾಡುವ ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಾಹಕರು ದೂರ ಹೋಗಿಲ್ಲ ಮತ್ತು ದೂರ ಹೋಗುವುದಿಲ್ಲ.

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

ಮತ್ತೊಂದು DevOps ಸಮಸ್ಯೆ

ವಾಸ್ತವವಾಗಿ, ಎಲ್ಲವೂ ಕೇವಲ ನೇಮಕಾತಿ ಮತ್ತು ನಿರ್ವಾಹಕರು ಮತ್ತು devops ನಡುವಿನ ನಿರಂತರ ಗೊಂದಲಕ್ಕೆ ಸೀಮಿತವಾಗಿಲ್ಲ. ಕೆಲವು ಹಂತದಲ್ಲಿ, ವ್ಯಾಪಾರವು ನವೀಕರಣಗಳನ್ನು ತಲುಪಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿತು ಮತ್ತು ಅಂತಿಮ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿ ತಂಡದ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಎದುರಿಸಿತು.

ಬಹುಶಃ ಅದು ಯಾವುದೋ ಸಮ್ಮೇಳನದ ವೇದಿಕೆಯ ಮೇಲೆ ಹೊಳೆಯುವ ಕಣ್ಣುಗಳ ಚಿಕ್ಕಪ್ಪ ಎದ್ದುನಿಂತು, “ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು DevOps ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಈ ವ್ಯಕ್ತಿಗಳು ನಿಮ್ಮ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ.

ಆದಾಗ್ಯೂ, ಎಲ್ಲವನ್ನೂ ಮಾಡಬೇಕಾದಂತೆ ಕೆಲಸ ಮಾಡಲು DevOps ಇಂಜಿನಿಯರ್ ಅನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಕಂಪನಿಯು ಸಂಪೂರ್ಣ DevOps ರೂಪಾಂತರಕ್ಕೆ ಒಳಗಾಗಬೇಕು, ಅಂದರೆ, ನಮ್ಮ DevOps ಪಾತ್ರ ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ತಂಡದ ಬದಿಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಈ ವಿಷಯದ ಕುರಿತು ನಾವು "ಅದ್ಭುತ" ಕಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅದು ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ಎಲ್ಲಾ ಕ್ರೂರತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸುತ್ತದೆ.

ಪರಿಸ್ಥಿತಿ. DevOps ಆವೃತ್ತಿ ರೋಲ್‌ಬ್ಯಾಕ್ ಸಿಸ್ಟಂ ಅನ್ನು ನಿಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸದೆ. ಬಳಕೆದಾರರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮೊದಲ ಹೆಸರು, ಕೊನೆಯ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳಿವೆ ಎಂದು ಭಾವಿಸೋಣ. ಉತ್ಪನ್ನದ ಹೊಸ ಆವೃತ್ತಿಯು ಹೊರಬರುತ್ತದೆ, ಆದರೆ ಡೆವಲಪರ್‌ಗಳಿಗೆ, "ರೋಲ್‌ಬ್ಯಾಕ್" ಕೇವಲ ಮಾಯಾ ಮಾಂತ್ರಿಕದಂಡವಾಗಿದ್ದು ಅದು ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ಮುಂದಿನ ಪ್ಯಾಚ್‌ನಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ಮೊದಲ ಮತ್ತು ಕೊನೆಯ ಹೆಸರಿನ ಕ್ಷೇತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸಿದರು, ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತಂದರು, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಆವೃತ್ತಿಯು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಏನಾಗುತ್ತಿದೆ? ನಿರ್ವಹಣೆಯು devops ಗೆ ಬರುತ್ತದೆ ಮತ್ತು "ಸ್ವಿಚ್ ಅನ್ನು ಎಳೆಯಿರಿ!" ಎಂದು ಹೇಳುತ್ತದೆ, ಅಂದರೆ, ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವಂತೆ ಕೇಳುತ್ತದೆ. devops ಏನು ಮಾಡುತ್ತದೆ? ಇದು ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಆದರೆ ಡೆವಲಪರ್‌ಗಳು ಈ ರೋಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಹೇಗೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಬಯಸದ ಕಾರಣ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಹಿಂತಿರುಗಿಸಬೇಕಾಗಿದೆ ಎಂದು ಯಾರೂ ಡೆವೊಪ್ಸ್ ತಂಡಕ್ಕೆ ತಿಳಿಸಲಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲವೂ ನಮಗೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ, ಮತ್ತು ನಿಧಾನಗತಿಯ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಬದಲಾಗಿ, ಬಳಕೆದಾರರು “500” ದೋಷವನ್ನು ನೋಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಹಳೆಯ ಆವೃತ್ತಿಯು ಹೊಸ ಡೇಟಾಬೇಸ್‌ನ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. Devops ಗೆ ಇದರ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ. ಅಭಿವರ್ಧಕರು ಮೌನವಾಗಿದ್ದಾರೆ. ನಿರ್ವಹಣೆಯು ತಮ್ಮ ನರಗಳು ಮತ್ತು ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತದೆ, "ಕನಿಷ್ಠ ಏನಾದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎಂದು ಅವರಿಂದ ಹಿಂತಿರುಗಿಸಲು ನೀಡುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಬಳಕೆದಾರರು ತಮ್ಮ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಮಯದ ಅವಧಿಯಲ್ಲಿ ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ.

ಬೀಜಗಳು, ಸಹಜವಾಗಿ, "ಸರಿಯಾದ ರೋಲ್ಬ್ಯಾಕ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾಡದ" ಡೆವೊಪ್ಸ್ಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಈ ಕಥೆಯಲ್ಲಿ ಮೂಸ್ ಡೆವಲಪರ್ಗಳು ಎಂದು ಯಾರೂ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ.

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

ಮೂಲಭೂತವಾಗಿ, DevOps ನಿರ್ವಹಣೆ ಮತ್ತು ತಂತ್ರಜ್ಞಾನದ ನಡುವಿನ ಗಡಿಯಲ್ಲಿನ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಈ ಕಾಕ್ಟೈಲ್‌ನಲ್ಲಿ ನಿರ್ವಹಣೆಗಿಂತ ಹೆಚ್ಚಿನ ತಂತ್ರಜ್ಞಾನ ಇರಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ನೀವು ನಿಜವಾಗಿಯೂ ವೇಗವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಬಯಸಿದರೆ, ನಿಮ್ಮ devops ತಂಡವನ್ನು ನೀವು ನಂಬಬೇಕು. ಅವರು ಸರಿಯಾದ ಸಾಧನಗಳನ್ನು ತಿಳಿದಿದ್ದಾರೆ, ಅವರು ಇದೇ ರೀತಿಯ ಯೋಜನೆಗಳನ್ನು ಜಾರಿಗೆ ತಂದಿದ್ದಾರೆ, ಅದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಅವರಿಗೆ ತಿಳಿದಿದೆ. ಅವನಿಗೆ ಸಹಾಯ ಮಾಡಿ, ಅವನ ಸಲಹೆಯನ್ನು ಆಲಿಸಿ, ಅವನನ್ನು ಕೆಲವು ರೀತಿಯ ಸ್ವಾಯತ್ತ ಘಟಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಡಿ. ನಿರ್ವಾಹಕರು ಸ್ವಂತವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ devops ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ; ನೀವೇ ಈ ಸಹಾಯವನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸದಿದ್ದರೆ ಅವರು ನಿಮಗೆ ಉತ್ತಮವಾಗಲು ಸಹಾಯ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

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

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ