DevOps ಯಾರು?

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

ನಾವು ಇನ್ನೂ ಸಹೋದ್ಯೋಗಿಗಳಿಗಾಗಿ ಹುಡುಕುತ್ತಿದ್ದೇವೆ, ಏಕೆಂದರೆ DevOps ಲೇಬಲ್‌ನ ಹಿಂದೆ ವಿವಿಧ ರೀತಿಯ ಇಂಜಿನಿಯರ್‌ಗಳ ದೊಡ್ಡ ಪದರವು ಅಡಗಿದೆ.

ಕೆಳಗೆ ಬರೆದಿರುವ ಎಲ್ಲವೂ ನನ್ನ ವೈಯಕ್ತಿಕ ಅಭಿಪ್ರಾಯವಾಗಿದೆ, ನೀವು ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ಇದು ವಿಷಯಕ್ಕೆ ನಿಮ್ಮ ವರ್ತನೆಗೆ ಸ್ವಲ್ಪ ಬಣ್ಣವನ್ನು ಸೇರಿಸುತ್ತದೆ ಎಂದು ನಾನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇನೆ. ಪರವಾಗಿ ಬೀಳುವ ಅಪಾಯದ ಹೊರತಾಗಿಯೂ, ನಾನು ನನ್ನ ಅಭಿಪ್ರಾಯವನ್ನು ಪ್ರಕಟಿಸುತ್ತೇನೆ ಏಕೆಂದರೆ ಅದಕ್ಕೆ ಒಂದು ಸ್ಥಳವಿದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ.

DevOps ಇಂಜಿನಿಯರ್‌ಗಳು ಯಾರು ಎಂಬುದರ ಕುರಿತು ಕಂಪನಿಗಳು ವಿಭಿನ್ನ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಸಂಪನ್ಮೂಲವನ್ನು ತ್ವರಿತವಾಗಿ ನೇಮಿಸಿಕೊಳ್ಳುವ ಸಲುವಾಗಿ, ಅವರು ಈ ಲೇಬಲ್ ಅನ್ನು ಪ್ರತಿಯೊಬ್ಬರ ಮೇಲೆ ಸ್ಥಗಿತಗೊಳಿಸುತ್ತಾರೆ. ಪರಿಸ್ಥಿತಿಯು ತುಂಬಾ ವಿಚಿತ್ರವಾಗಿದೆ, ಏಕೆಂದರೆ ಕಂಪನಿಗಳು ಈ ಜನರಿಗೆ ಅವಾಸ್ತವಿಕ ಸಂಭಾವನೆಗಳನ್ನು ಪಾವತಿಸಲು ಸಿದ್ಧವಾಗಿವೆ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅವರಿಗೆ ಸಾಧನ ನಿರ್ವಾಹಕರನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ.

ಹಾಗಾದರೆ DevOps ಇಂಜಿನಿಯರ್‌ಗಳು ಯಾರು?

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

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

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

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

ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲದ ಪರಿಣಿತ ಜ್ಞಾನದ ಮಟ್ಟದಲ್ಲಿ ಇದೇ ರೀತಿಯ "ಸ್ವಿಂಗ್ಸ್" ಇಂದಿಗೂ ಮುಂದುವರೆದಿದೆ. ಆದರೆ ನಾವು ಸ್ವಲ್ಪ ದೂರ ಹೋಗುತ್ತೇವೆ, ಹೈಲೈಟ್ ಮಾಡಲು ಯೋಗ್ಯವಾದ ಹಲವು ಅಂಶಗಳಿವೆ.

ಬಿಲ್ಡ್ ಇಂಜಿನಿಯರ್/ಬಿಡುಗಡೆ ಇಂಜಿನಿಯರ್

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

ಆಪ್ಸ್ ತುಂಬಾ ವಿಭಿನ್ನವಾಗಿದೆ

ದೊಡ್ಡ ಶ್ರೇಣಿಯ ಜವಾಬ್ದಾರಿಗಳ ಉಪಸ್ಥಿತಿ ಮತ್ತು ಅರ್ಹ ಸಿಬ್ಬಂದಿಯ ಕೊರತೆಯು ನಮ್ಮನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ ವಿಶೇಷತೆಯತ್ತ ತಳ್ಳುತ್ತದೆ, ಮಳೆಯ ನಂತರ ಅಣಬೆಗಳಂತೆ, ವಿವಿಧ ಕಾರ್ಯಾಚರಣೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ:

• TechOps - enikey ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಅಕಾ ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್ ಇಂಜಿನಿಯರ್
• LiveOps - ಸಿಸ್ಟಂ ನಿರ್ವಾಹಕರು ಪ್ರಾಥಮಿಕವಾಗಿ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ
• CloudOps - ಸಾರ್ವಜನಿಕ ಕ್ಲೌಡ್‌ಗಳಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು Azure, AWS, GCP, ಇತ್ಯಾದಿ.
• PlatOps/InfraOps/SysOps - ಮೂಲಸೌಕರ್ಯ ವ್ಯವಸ್ಥೆಯ ನಿರ್ವಾಹಕರು.
• NetOps - ನೆಟ್ವರ್ಕ್ ನಿರ್ವಾಹಕರು
• SecOps - ಮಾಹಿತಿ ಭದ್ರತೆಯಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು - PCI ಅನುಸರಣೆ, CIS ಅನುಸರಣೆ, ಪ್ಯಾಚಿಂಗ್, ಇತ್ಯಾದಿ.

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

ಈ ರೀತಿಯ ಕೆಲಸ ಮತ್ತು ಜವಾಬ್ದಾರಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು, ಈ ವ್ಯಕ್ತಿಯು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಉತ್ಪನ್ನದ ಮೂಲಸೌಕರ್ಯದ ನಿರ್ವಹಣೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸುವ ವಿಧಾನವನ್ನು ಹೊಂದಿರಬೇಕು. ಈ ತಿಳುವಳಿಕೆಯಲ್ಲಿ DevOps IT, ಅಥವಾ R&D, ಅಥವಾ PMO ಯಲ್ಲಿಯೂ ನೆಲೆಗೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ; ಇದು ಈ ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಪ್ರಭಾವವನ್ನು ಹೊಂದಿರಬೇಕು - ಕಂಪನಿಯ ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕ, ಮುಖ್ಯ ತಾಂತ್ರಿಕ ಅಧಿಕಾರಿ.

ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಇದು ನಿಜವೇ? - ನನಗೆ ಅನುಮಾನವಿದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇದು IT ಅಥವಾ R&D ಆಗಿರುತ್ತದೆ.

ನಿಧಿಯ ಕೊರತೆ ಮತ್ತು ಚಟುವಟಿಕೆಯ ಈ ಮೂರು ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದನ್ನು ಪ್ರಭಾವಿಸುವ ಸಾಮರ್ಥ್ಯವು ಸಮಸ್ಯೆಗಳ ತೂಕವನ್ನು ಈ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಸುಲಭವಾದ ಕಡೆಗೆ ಬದಲಾಯಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ "ಡರ್ಟಿ" ಕೋಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಬಿಡುಗಡೆಗಳ ಮೇಲೆ ತಾಂತ್ರಿಕ ನಿರ್ಬಂಧಗಳ ಅನ್ವಯವು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ವಿಶ್ಲೇಷಕ ವ್ಯವಸ್ಥೆಗಳು. ಅಂದರೆ, PMO ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಬಿಡುಗಡೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಗಡುವನ್ನು ನಿಗದಿಪಡಿಸಿದಾಗ, R&D ಈ ಗಡುವಿನೊಳಗೆ ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ಫಲಿತಾಂಶವನ್ನು ಉತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ ಉತ್ಪಾದಿಸುತ್ತದೆ, ನಂತರ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಬಿಟ್ಟು, IT ಗೆ ಸಂಬಂಧಿಸಿದ DevOps ತಾಂತ್ರಿಕ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬಿಡುಗಡೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ. . ಪರಿಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಅಧಿಕಾರದ ಕೊರತೆ, ಜವಾಬ್ದಾರಿಯುತ ಉದ್ಯೋಗಿಗಳ ವಿಷಯದಲ್ಲಿ, ಅವರು ಪ್ರಭಾವ ಬೀರಲು ಸಾಧ್ಯವಾಗದಿರುವಿಕೆಗೆ ಹೆಚ್ಚಿನ ಜವಾಬ್ದಾರಿಯ ಅಭಿವ್ಯಕ್ತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಈ ಉದ್ಯೋಗಿಗಳು ತಪ್ಪುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ಮತ್ತು ನೋಡಿದರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು - "ಆನಂದವು ಅಜ್ಞಾನ", ಮತ್ತು ಈ ಉದ್ಯೋಗಿಗಳ ಸುಡುವಿಕೆ ಮತ್ತು ನಷ್ಟದ ಪರಿಣಾಮವಾಗಿ.

DevOps ಸಂಪನ್ಮೂಲ ಮಾರುಕಟ್ಟೆ

ವಿವಿಧ ಕಂಪನಿಗಳಿಂದ DevOps ಹುದ್ದೆಗಳಿಗಾಗಿ ಹಲವಾರು ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ನೋಡೋಣ.

ನೀವು ಇದ್ದರೆ ನಾವು ನಿಮ್ಮನ್ನು ಭೇಟಿ ಮಾಡಲು ಸಿದ್ಧರಿದ್ದೇವೆ:

1. ನೀವು ಜಬ್ಬಿಕ್ಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಪ್ರಮೀತಿಯಸ್ ಏನೆಂದು ತಿಳಿದಿರುತ್ತೀರಿ;
2. ಇಪ್ಟೇಬಲ್ಸ್;
3. BASH ಪಿಎಚ್‌ಡಿ ವಿದ್ಯಾರ್ಥಿ;
4. ಪ್ರೊಫೆಸರ್ ಅನ್ಸಿಬಲ್;
5. ಲಿನಕ್ಸ್ ಗುರು;
6. ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ (php/java/python) ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿಯಿರಿ;
7. ರೂಟಿಂಗ್ ನಿಮ್ಮನ್ನು ಉನ್ಮಾದಗೊಳಿಸುವುದಿಲ್ಲ;
8. ಸಿಸ್ಟಮ್ ಭದ್ರತೆಗೆ ಗಮನಾರ್ಹ ಗಮನ ಕೊಡಿ;
9. "ಯಾವುದಾದರೂ ಮತ್ತು ಎಲ್ಲವನ್ನೂ" ಬ್ಯಾಕಪ್ ಮಾಡಿ, ಮತ್ತು ಈ "ಯಾವುದಾದರೂ ಮತ್ತು ಎಲ್ಲವನ್ನೂ" ಯಶಸ್ವಿಯಾಗಿ ಮರುಸ್ಥಾಪಿಸಿ;
10. ಕನಿಷ್ಠದಿಂದ ಗರಿಷ್ಠವನ್ನು ಪಡೆಯುವ ರೀತಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ;
11. Postgres ಮತ್ತು MySQL ನಲ್ಲಿ ಮಲಗುವ ಮೊದಲು ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸಿ;
12. CI/CD ಅನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಹೊಂದಿಸುವುದು ನಿಮಗೆ ಉಪಹಾರ/ಮಧ್ಯಾಹ್ನ/ಭೋಜನದಂತೆ ಅವಶ್ಯಕವಾಗಿದೆ.
13. AWS ನೊಂದಿಗೆ ಅನುಭವವನ್ನು ಹೊಂದಿರಿ;
14. ಕಂಪನಿಯೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಿದ್ಧವಾಗಿದೆ;

ಆದ್ದರಿಂದ:

• 1 ರಿಂದ 6 ರವರೆಗೆ - ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 7 - ಸ್ವಲ್ಪ ನೆಟ್‌ವರ್ಕ್ ಆಡಳಿತ, ಇದು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್, ಮಧ್ಯಮ ಮಟ್ಟಕ್ಕೆ ಸಹ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ
• 8 - ಸ್ವಲ್ಪ ಭದ್ರತೆ, ಇದು ಮಧ್ಯಮ ಮಟ್ಟದ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಗೆ ಕಡ್ಡಾಯವಾಗಿದೆ
• 9-11 - ಮಧ್ಯಮ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 12 — ನಿಯೋಜಿತ ಕಾರ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಮಧ್ಯಮ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಅಥವಾ ಬಿಲ್ಡ್ ಇಂಜಿನಿಯರ್
• 13 - ವರ್ಚುವಲೈಸೇಶನ್ - ಮಿಡಲ್ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್, ಅಥವಾ ಕ್ಲೌಡ್‌ಆಪ್ಸ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ, ನಿರ್ದಿಷ್ಟ ಹೋಸ್ಟಿಂಗ್ ಸೈಟ್‌ನ ಸೇವೆಗಳ ಸುಧಾರಿತ ಜ್ಞಾನ, ನಿಧಿಯ ಸಮರ್ಥ ಬಳಕೆಗಾಗಿ ಮತ್ತು ನಿರ್ವಹಣೆಯ ಮೇಲಿನ ಹೊರೆ ಕಡಿಮೆ ಮಾಡಲು

ಈ ಖಾಲಿ ಹುದ್ದೆಯನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಹುಡುಗರಿಗೆ ಮಧ್ಯಮ / ಹಿರಿಯ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಸಾಕು ಎಂದು ನಾವು ಹೇಳಬಹುದು.

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

ಇನ್ನೊಂದು ಖಾಲಿ ಹುದ್ದೆಯನ್ನು ಪರಿಗಣಿಸೋಣ:

1. ಹೆಚ್ಚಿನ ಹೊರೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುವಲ್ಲಿ ಅನುಭವ;
2. Linux OS, ಸಾಮಾನ್ಯ ಸಿಸ್ಟಮ್ ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ವೆಬ್ ಸ್ಟಾಕ್‌ನ ಅತ್ಯುತ್ತಮ ಜ್ಞಾನ (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. ವರ್ಚುವಲೈಸೇಶನ್ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ ಅನುಭವ (KVM, VMWare, LXC/Docker);
4. ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ;
5. ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ ನೆಟ್ವರ್ಕ್ಗಳ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವಗಳ ತಿಳುವಳಿಕೆ;
6. ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುವ ತತ್ವಗಳ ತಿಳುವಳಿಕೆ;
7. ಸ್ವಾತಂತ್ರ್ಯ ಮತ್ತು ಉಪಕ್ರಮ;

ನೋಡೋಣ:

• 1 - ಹಿರಿಯ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 2 - ಈ ಸ್ಟ್ಯಾಕ್‌ಗೆ ಹಾಕಲಾದ ಅರ್ಥವನ್ನು ಅವಲಂಬಿಸಿ - ಮಧ್ಯಮ/ಹಿರಿಯ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 3 - ಕೆಲಸದ ಅನುಭವವನ್ನು ಒಳಗೊಂಡಂತೆ, ಇದರರ್ಥ - "ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿಲ್ಲ, ಆದರೆ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲಾಗಿದೆ, ಒಂದು ಡಾಕರ್ ಹೋಸ್ಟ್ ಇತ್ತು, ಕಂಟೇನರ್‌ಗಳಿಗೆ ಪ್ರವೇಶ ಲಭ್ಯವಿಲ್ಲ" - ಮಧ್ಯಮ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 4 - ಜೂನಿಯರ್ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ - ಹೌದು, ಮೂಲ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಹೇಗೆ ಬರೆಯಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲದ ನಿರ್ವಾಹಕರು, ಭಾಷೆಯ ಹೊರತಾಗಿಯೂ, ನಿರ್ವಾಹಕರಲ್ಲ - enikey.
• 5 - ಮಧ್ಯಮ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 6 - ಹಿರಿಯ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು

ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳಲು - ಮಧ್ಯಮ/ಹಿರಿಯ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು

ಮತ್ತೊಂದು:

1. ಅನುಭವವನ್ನು ನೀಡುತ್ತದೆ;
2. CI/CD ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸಲು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಉತ್ಪನ್ನಗಳನ್ನು ಬಳಸುವ ಅನುಭವ. Gitlab CI ಒಂದು ಪ್ರಯೋಜನವಾಗಿದೆ;
3. ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು ವರ್ಚುವಲೈಸೇಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು; ನೀವು ಡಾಕರ್ ಅನ್ನು ಬಳಸಿದ್ದರೆ, ಒಳ್ಳೆಯದು, ಆದರೆ ನೀವು k8s ಅನ್ನು ಬಳಸಿದರೆ, ಅದ್ಭುತವಾಗಿದೆ!
4. ಚುರುಕುಬುದ್ಧಿಯ ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಅನುಭವ;
5. ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಜ್ಞಾನ;

ನೋಡೋಣ:

• 1 - ಹಾಂ... ಹುಡುಗರ ಅರ್ಥವೇನು? =) ಹೆಚ್ಚಾಗಿ ಅದರ ಹಿಂದೆ ಏನು ಅಡಗಿದೆ ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿಲ್ಲ
• 2 - ಬಿಲ್ಡ್ ಇಂಜಿನಿಯರ್
• 3 - ಮಧ್ಯಮ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು
• 4 - ಮೃದು ಕೌಶಲ್ಯ, ನಾವು ಇದೀಗ ಅದನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಆದರೂ ಚುರುಕುಬುದ್ಧಿಯ ಮತ್ತೊಂದು ವಿಷಯವೆಂದರೆ ಅದನ್ನು ಅನುಕೂಲಕರ ರೀತಿಯಲ್ಲಿ ಅರ್ಥೈಸಲಾಗುತ್ತದೆ.
• 5 - ತುಂಬಾ ಮಾತಿನ - ಇದು ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆ ಅಥವಾ ಕಂಪೈಲ್ ಆಗಿರಬಹುದು. ಶಾಲೆಯಲ್ಲಿ ಪಾಸ್ಕಲ್ ಮತ್ತು ಬೇಸಿಕ್ ಬರೆಯುವುದು ಅವರಿಗೆ ಸರಿಹೊಂದುತ್ತದೆಯೇ ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ? =)

ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ನಿಂದ ಈ ಅಂಶವನ್ನು ಏಕೆ ಆವರಿಸಲಾಗಿದೆ ಎಂಬ ತಿಳುವಳಿಕೆಯನ್ನು ಬಲಪಡಿಸಲು ನಾನು ಪಾಯಿಂಟ್ 3 ರ ಬಗ್ಗೆ ಟಿಪ್ಪಣಿಯನ್ನು ಬಿಡಲು ಬಯಸುತ್ತೇನೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕೇವಲ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಆಗಿದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಡ್ರೈವರ್‌ಗಳು ಮತ್ತು ವರ್ಚುವಲೈಸೇಶನ್/ಐಸೋಲೇಶನ್ ಹೋಸ್ಟ್‌ಗಳಿಗೆ ನೇರ ಆಜ್ಞೆಗಳನ್ನು ಸುತ್ತುವ ಸಾಧನವಾಗಿದೆ ಮತ್ತು ಅವರೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಅಮೂರ್ತವಾಗಿ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅಷ್ಟೆ. ಉದಾಹರಣೆಗೆ, 'ಬಿಲ್ಡ್ ಫ್ರೇಮ್‌ವರ್ಕ್' ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ, ಇದು ಮೂಲಕ, ನಾನು ಚೌಕಟ್ಟನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಹೌದು, ಎಲ್ಲಿ ಬೇಕಾದರೂ ಮೇಕ್ ಅನ್ನು ನೂಕುವ ಫ್ಯಾಶನ್ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿದೆ, ಅಲ್ಲಿ ಅದು ಅಗತ್ಯ ಮತ್ತು ಅಗತ್ಯವಿಲ್ಲ - ಮಾವೆನ್ ಅನ್ನು ಮೇಕ್ನಲ್ಲಿ ಸುತ್ತುವುದು, ಉದಾಹರಣೆಗೆ, ಗಂಭೀರವಾಗಿ?
ಮೂಲಭೂತವಾಗಿ, ಮೇಕ್ ಎನ್ನುವುದು ಶೆಲ್‌ನ ಮೇಲಿನ ಹೊದಿಕೆಯಾಗಿದೆ, ಇದು k8s ನಂತೆ ಸಂಕಲನ, ಲಿಂಕ್ ಮತ್ತು ಸಂಕಲನ ಪರಿಸರದ ಆಜ್ಞೆಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ.

ಒಮ್ಮೆ, ನಾನು ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ತನ್ನ ಕೆಲಸದಲ್ಲಿ k8 ಗಳನ್ನು ಬಳಸಿದ ವ್ಯಕ್ತಿಯನ್ನು ಸಂದರ್ಶಿಸಿದೆ, ಮತ್ತು ಅವನು ಅದರಲ್ಲಿ ಸೇವೆಗಳನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಿದನು ಎಂಬುದರ ಕುರಿತು ಅವನು ಮಾತನಾಡಿದನು, ಆದಾಗ್ಯೂ, ನಾನು ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ಬಗ್ಗೆ ಕೇಳಿದಾಗ, ಅದನ್ನು ನಿರ್ವಹಿಸಲಾಗಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್‌ನಿಂದ ಬೆಳೆಸಲಾಗಿದೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ನಿರ್ವಾಹಕರು. ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ವ್ಯಕ್ತಿಯು, ಅವನ ಹಿಂದೆ ಯಾವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ, k8 ಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ನಿಜವಾಗಿಯೂ ಭಾವಿಸುತ್ತೀರಾ? =)
ಈ ಅರ್ಜಿದಾರರು ವಾಸ್ತವವಾಗಿ DevOps ಅಲ್ಲ, ಆದರೆ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮತ್ತು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ವಾಹಕರು.

ಮತ್ತೊಮ್ಮೆ ಸಾರಾಂಶ ಮಾಡೋಣ - ಮಧ್ಯಮ/ಹಿರಿಯ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಅವರಿಗೆ ಸಾಕಾಗುತ್ತದೆ.

ಗ್ರಾಂನಲ್ಲಿ ಎಷ್ಟು ತೂಗಬೇಕು

ಸೂಚಿಸಲಾದ ಖಾಲಿ ಹುದ್ದೆಗಳಿಗೆ ಪ್ರಸ್ತಾವಿತ ವೇತನಗಳ ವ್ಯಾಪ್ತಿಯು 90k-200k ಆಗಿದೆ
ಈಗ ನಾನು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ಗಳು ಮತ್ತು DevOps ಇಂಜಿನಿಯರ್‌ಗಳ ವಿತ್ತೀಯ ಪ್ರತಿಫಲಗಳ ನಡುವೆ ಸಮಾನಾಂತರವನ್ನು ಸೆಳೆಯಲು ಬಯಸುತ್ತೇನೆ.

ತಾತ್ವಿಕವಾಗಿ, ವಿಷಯಗಳನ್ನು ಸರಳೀಕರಿಸಲು, ನೀವು ಕೆಲಸದ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಶ್ರೇಣಿಗಳನ್ನು ಚದುರಿಸಬಹುದು, ಆದರೂ ಇದು ನಿಖರವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಲೇಖನದ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಇದು ಸಾಕಷ್ಟು ಇರುತ್ತದೆ.

ಒಂದು ಅನುಭವ:

1. 3 ವರ್ಷಗಳವರೆಗೆ - ಜೂನಿಯರ್
2. 6 ವರ್ಷ ವಯಸ್ಸಿನವರೆಗೆ - ಮಧ್ಯಮ
3. 6 ಕ್ಕಿಂತ ಹೆಚ್ಚು - ಹಿರಿಯ

ಉದ್ಯೋಗಿ ಹುಡುಕಾಟ ಸೈಟ್ ನೀಡುತ್ತದೆ:
ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು:

1. ಜೂನಿಯರ್ - 2 ವರ್ಷಗಳು - 50 ಕೆ ರಬ್.
2. ಮಧ್ಯಮ - 5 ವರ್ಷಗಳು - 70 ಕೆ ರಬ್.
3. ಹಿರಿಯ - 11 ವರ್ಷಗಳು - 100 ಕೆ ರಬ್.

DevOps ಇಂಜಿನಿಯರ್‌ಗಳು:

1. ಜೂನಿಯರ್ - 2 ವರ್ಷಗಳು - 100 ಕೆ ರಬ್.
2. ಮಧ್ಯಮ - 3 ವರ್ಷಗಳು - 160 ಕೆ ರಬ್.
3. ಹಿರಿಯ - 6 ವರ್ಷಗಳು - 220 ಕೆ ರಬ್.

"DevOps" ನ ಅನುಭವದ ಪ್ರಕಾರ, ಕನಿಷ್ಠ ಹೇಗಾದರೂ SDLC ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಅನುಭವವನ್ನು ಬಳಸಲಾಗಿದೆ.

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

DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ತರಬೇತಿ ನೀಡುವ ಪ್ರಕ್ರಿಯೆಯು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳು, ಉಪಯುಕ್ತತೆಗಳ ಗುಂಪಿಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಅವುಗಳ ಅವಲಂಬನೆಗಳ ಸಾಮಾನ್ಯ ತಿಳುವಳಿಕೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಫ್ಲುಯೆಂಟ್ ಸೈಡ್‌ಕಾರ್ ಮತ್ತು 10 ನಿಮಿಷಗಳಲ್ಲಿ ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಾಗಿ AWS ELK ಸ್ಟಾಕ್‌ನೊಂದಿಗೆ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು AWS EKS ಅನ್ನು ನಿಯೋಜಿಸಿದಾಗ ಅದು ಖಂಡಿತವಾಗಿಯೂ ಒಳ್ಳೆಯದು, ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಕೇವಲ ಒಂದು ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ, ಆದರೆ ಅವನಿಗೆ ಅರ್ಥವಾಗದಿದ್ದರೆ ಲಾಗ್‌ಗಳನ್ನು ಸ್ವತಃ ಸಂಸ್ಕರಿಸುವ ತತ್ವ ಮತ್ತು ಅವು ಏನು ಬೇಕು, ಅವುಗಳ ಮೇಲೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಸೇವೆಯ ಅವನತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಕೆಲವು ಉಪಯುಕ್ತತೆಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ತಿಳಿದಿರುವ ಅದೇ ಎನಿಕಿ ಆಗಿರುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ಬೇಡಿಕೆಯು ಪೂರೈಕೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು DevOps ಸ್ಥಾನಕ್ಕಾಗಿ ನಾವು ಹೆಚ್ಚು ಬಿಸಿಯಾದ ಮಾರುಕಟ್ಟೆಯನ್ನು ನೋಡುತ್ತೇವೆ, ಅಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳು ನಿಜವಾದ ಪಾತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಆದರೆ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮಾತ್ರ ಹೆಚ್ಚು ಗಳಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ.

ಹಾಗಾದರೆ ಅವರು ಯಾರು? DevOps ಅಥವಾ ದುರಾಸೆಯ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು? =)

ಬದುಕನ್ನು ಮುಂದುವರಿಸುವುದು ಹೇಗೆ?

ಉದ್ಯೋಗದಾತರು ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ರೂಪಿಸಬೇಕು ಮತ್ತು ಅಗತ್ಯವಿರುವವರನ್ನು ನಿಖರವಾಗಿ ನೋಡಬೇಕು ಮತ್ತು ಲೇಬಲ್‌ಗಳನ್ನು ಎಸೆಯಬಾರದು. DevOps ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ - ಆ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮಗೆ ಅವುಗಳ ಅಗತ್ಯವಿಲ್ಲ.

ಕೆಲಸಗಾರರು - ಕಲಿಯಿರಿ. ನಿಮ್ಮ ಜ್ಞಾನವನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಿ, ಪ್ರಕ್ರಿಯೆಗಳ ಒಟ್ಟಾರೆ ಚಿತ್ರವನ್ನು ನೋಡಿ ಮತ್ತು ನಿಮ್ಮ ಗುರಿಯ ಹಾದಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ನೀವು ಯಾರು ಬೇಕಾದರೂ ಆಗಬಹುದು, ನೀವು ಪ್ರಯತ್ನಿಸಬೇಕು.

ಮೂಲ: www.habr.com