ಇತ್ತೀಚೆಗೆ, ಅಂತಹ ಜಾಹೀರಾತುಗಳು ಇಂಟರ್ನೆಟ್ ಅನ್ನು ತುಂಬಿವೆ. ಹಿತಕರ ಸಂಬಳವಿದ್ದರೂ ಒಳಗೊಳಗೆ ಕಾಡು ಪಾಷಣ ಬರೆದಿದೆ ಎಂದು ಮುಜುಗರ ಪಡದೇ ಇರಲಾರದು. ಮೊದಲಿಗೆ "DevOps" ಮತ್ತು "ಎಂಜಿನಿಯರ್" ಅನ್ನು ಹೇಗಾದರೂ ಒಂದು ಪದದಲ್ಲಿ ಒಟ್ಟಿಗೆ ಅಂಟಿಸಬಹುದು ಎಂದು ಊಹಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಅವಶ್ಯಕತೆಗಳ ಯಾದೃಚ್ಛಿಕ ಪಟ್ಟಿ ಇದೆ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು sysadmin ಖಾಲಿಯಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ನಕಲಿಸಲಾಗಿದೆ.
ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಜೀವನದ ಈ ಹಂತಕ್ಕೆ ಹೇಗೆ ಬಂದೆವು, DevOps ನಿಜವಾಗಿಯೂ ಏನು ಮತ್ತು ಈಗ ಅದನ್ನು ಏನು ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ಸ್ವಲ್ಪ ಮಾತನಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಅಂತಹ ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ಸಾಧ್ಯವಿರುವ ಎಲ್ಲ ರೀತಿಯಲ್ಲಿ ಖಂಡಿಸಬಹುದು, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಉಳಿದಿದೆ: ಅವುಗಳಲ್ಲಿ ಹಲವು ಇವೆ, ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಮಾರುಕಟ್ಟೆಯು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಾವು devops ಸಮ್ಮೇಳನವನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಬಹಿರಂಗವಾಗಿ ಘೋಷಿಸುತ್ತೇವೆ: " - DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅಲ್ಲ." ಇದು ಅನೇಕರಿಗೆ ವಿಚಿತ್ರ ಮತ್ತು ಕಾಡು ತೋರುತ್ತದೆ: ಸಂಪೂರ್ಣವಾಗಿ ವಾಣಿಜ್ಯ ಕಾರ್ಯಕ್ರಮವನ್ನು ಮಾಡುವ ಜನರು ಮಾರುಕಟ್ಟೆಯ ವಿರುದ್ಧ ಏಕೆ ಹೋಗುತ್ತಾರೆ. ಈಗ ನಾವು ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುತ್ತೇವೆ.
ಸಂಸ್ಕೃತಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳ ಬಗ್ಗೆ
DevOps ಇಂಜಿನಿಯರಿಂಗ್ ವಿಭಾಗವಲ್ಲ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ಐತಿಹಾಸಿಕವಾಗಿ ಸ್ಥಾಪಿತವಾದ ಪಾತ್ರಗಳ ವಿಭಾಗವು ಉತ್ಪನ್ನಗಳ ಗುಣಮಟ್ಟಕ್ಕಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದ ಇದು ಪ್ರಾರಂಭವಾಯಿತು. ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮಾತ್ರ ಪ್ರೋಗ್ರಾಂ ಮಾಡಿದಾಗ, ಆದರೆ ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಕೇಳಲು ಬಯಸುವುದಿಲ್ಲ, ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷಗಳಿಂದ ತುಂಬಿರುತ್ತದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಹೇಗೆ ಅಥವಾ ಏಕೆ ಬರೆಯಲಾಗಿದೆ ಎಂದು ನಿರ್ವಾಹಕರು ಕಾಳಜಿ ವಹಿಸದಿದ್ದಾಗ, ಬೆಂಬಲವು ನರಕವಾಗಿ ಬದಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮತ್ತು ಸೇವಾ ನಿರ್ವಹಣೆಗೆ SRE ವಿಧಾನದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುವುದು . ಒಳಗೆ ಆಸಕ್ತಿದಾಯಕ ಅಧ್ಯಯನಗಳನ್ನು ನಡೆಸಲಾಗಿದೆ - ಅತ್ಯುತ್ತಮ ಡೆವಲಪರ್‌ಗಳು ಹೇಗಾದರೂ ಉತ್ಪಾದನೆಗೆ ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಗಂಟೆಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ವೇಗವಾಗಿ ನಿಯೋಜಿಸಲು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅವರು ತಮ್ಮ ಕೈಗಳಿಂದ 10% ಕ್ಕಿಂತ ಹೆಚ್ಚು ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ (ಇದನ್ನು ನೋಡಬಹುದು ) ಅವರು ಇದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತಾರೆ? "ಎಕ್ಸೆಲ್ ಅಥವಾ ಡೈ" ವರದಿಯ ಶೀರ್ಷಿಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಪರೀಕ್ಷೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಈ ಅಂಕಿಅಂಶಗಳ ವಿವರವಾದ ಚರ್ಚೆಗಾಗಿ, ನೀವು ಬರುಚ್ ಸಡೋಗುರ್ಸ್ಕಿಯ ಮುಖ್ಯಾಂಶವನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು ನಮ್ಮ ಇನ್ನೊಂದು ಸಮ್ಮೇಳನದಲ್ಲಿ, ಹೈಸೆನ್‌ಬಗ್.
"ಒಡನಾಡಿಗಳ ನಡುವೆ ಯಾವುದೇ ಒಪ್ಪಂದವಿಲ್ಲದಿದ್ದಾಗ,
ಅವರಿಗೆ ವಿಷಯಗಳು ಸರಿಯಾಗಿ ನಡೆಯುವುದಿಲ್ಲ,
ಮತ್ತು ಅದರಿಂದ ಏನೂ ಹೊರಬರುವುದಿಲ್ಲ, ಕೇವಲ ಹಿಂಸೆ.
ಒಂದು ಕಾಲದಲ್ಲಿ ಹಂಸ, ಕ್ರೇಫಿಶ್ ಮತ್ತು ಪೈಕ್ ... "
ವೆಬ್ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳ ಯಾವ ಭಾಗವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅವರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಳಸುವ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ? ಅವರಲ್ಲಿ ಎಷ್ಟು ಮಂದಿ ನಿರ್ವಾಹಕರ ಬಳಿಗೆ ಹೋಗುತ್ತಾರೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ? ಮತ್ತು ಅವರಲ್ಲಿ ಯಾರು ಪರೀಕ್ಷಕರ ಬಳಿಗೆ ಹೋಗುತ್ತಾರೆ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ಸರಿಯಾಗಿ ಬರೆಯುವುದು ಹೇಗೆ ಎಂದು ಅವರಿಗೆ ಕಲಿಸಲು ಕೇಳುತ್ತಾರೆ? ಮತ್ತು ಭದ್ರತಾ ಸಿಬ್ಬಂದಿ, ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು ಮತ್ತು ಇತರ ಜನರ ಗುಂಪೂ ಇದ್ದಾರೆ.
DevOps ನ ಒಟ್ಟಾರೆ ಕಲ್ಪನೆಯು ಪಾತ್ರಗಳು ಮತ್ತು ಇಲಾಖೆಗಳ ನಡುವೆ ಸಹಯೋಗವನ್ನು ರಚಿಸುವುದು. ಮೊದಲನೆಯದಾಗಿ, ಇದನ್ನು ಕೆಲವು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ಸಾಧಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಸಂವಹನದ ಅಭ್ಯಾಸದಿಂದ. DevOps ಸಂಸ್ಕೃತಿ, ಅಭ್ಯಾಸಗಳು, ವಿಧಾನ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳ ಬಗ್ಗೆ. ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವ ಯಾವುದೇ ಎಂಜಿನಿಯರಿಂಗ್ ವಿಶೇಷತೆ ಇಲ್ಲ.
ಕೆಟ್ಟ ವೃತ್ತ
ಆಗ "ಡೆವೊಪ್ಸ್ ಎಂಜಿನಿಯರಿಂಗ್" ಶಿಸ್ತು ಎಲ್ಲಿಂದ ಬಂತು? ನಾವು ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ! DevOps ಐಡಿಯಾಗಳು ಚೆನ್ನಾಗಿದ್ದವು-ಎಷ್ಟು ಒಳ್ಳೆಯದು ಎಂದರೆ ಅವರು ತಮ್ಮ ಸ್ವಂತ ಯಶಸ್ಸಿಗೆ ಬಲಿಯಾದರು. ತಮ್ಮದೇ ಆದ ವಾತಾವರಣವನ್ನು ಹೊಂದಿರುವ ಕೆಲವು ನೆರಳು ನೇಮಕಾತಿಗಾರರು ಮತ್ತು ಮಾನವ ಕಳ್ಳಸಾಗಣೆದಾರರು ಈ ಇಡೀ ವಿಷಯದ ಸುತ್ತ ಸುತ್ತಲು ಪ್ರಾರಂಭಿಸಿದರು.
ಇಮ್ಯಾಜಿನ್: ನಿನ್ನೆ ನೀವು ಖಿಮ್ಕಿಯಲ್ಲಿ ಷಾವರ್ಮಾ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಇಂದು ನೀವು ಈಗಾಗಲೇ ದೊಡ್ಡ ವ್ಯಕ್ತಿ, ಹಿರಿಯ ನೇಮಕಾತಿ. ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಹುಡುಕುವ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡುವ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆ ಇದೆ, ಎಲ್ಲವೂ ಸುಲಭವಲ್ಲ, ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಒಂದು ವಿಭಾಗದ ಮುಖ್ಯಸ್ಥರು ಹೇಳುತ್ತಾರೆ ಎಂದು ಹೇಳೋಣ: X ನಲ್ಲಿ ತಜ್ಞರನ್ನು ಹುಡುಕಿ. ನಾವು "ಎಂಜಿನಿಯರ್" ಪದವನ್ನು X ಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಮುಗಿಸಿದ್ದೇವೆ. Linux ಬೇಕೇ? ಸರಿ, ಇದು ಖಂಡಿತವಾಗಿಯೂ ಲಿನಕ್ಸ್ ಇಂಜಿನಿಯರ್ ಆಗಿದೆ, ನೀವು DevOps ಬಯಸಿದರೆ, ನಂತರ DevOps ಇಂಜಿನಿಯರ್. ಖಾಲಿ ಹುದ್ದೆಯು ಶೀರ್ಷಿಕೆಯನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದರೆ ಕೆಲವು ಪಠ್ಯವನ್ನು ಒಳಗೆ ನಮೂದಿಸಬೇಕು. ನಿಮ್ಮ ಕಲ್ಪನೆಯ ಆಧಾರದ ಮೇಲೆ Google ನಿಂದ ಕೀವರ್ಡ್‌ಗಳ ಗುಂಪನ್ನು ನಮೂದಿಸುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. DevOps ಎರಡು ಪದಗಳನ್ನು ಒಳಗೊಂಡಿದೆ - “ಡೆವ್” ಮತ್ತು “ಆಪ್ಸ್”, ಇದರರ್ಥ ನಾವು ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ನಿರ್ವಾಹಕರಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೀವರ್ಡ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಅಂಟಿಸಬೇಕು, ಎಲ್ಲವೂ ಒಂದೇ ರಾಶಿಯಲ್ಲಿ. 42 ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ ಮತ್ತು 20 ವರ್ಷಗಳ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಸಮೂಹವನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಬಳಸುವುದರ ಕುರಿತು ಖಾಲಿ ಹುದ್ದೆಗಳು ಹೇಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಕೆಲಸದ ರೇಖಾಚಿತ್ರ.
ಒಂದು ನಿರ್ದಿಷ್ಟ "ಡೆವೊಪ್ಸ್" ಸೂಪರ್ಹೀರೋನ ಅರ್ಥಹೀನ ಮತ್ತು ದಯೆಯಿಲ್ಲದ ಚಿತ್ರವು ಜನರ ಮನಸ್ಸಿನಲ್ಲಿ ಬೇರುಬಿಟ್ಟಿದೆ, ಅವರು ಜೆಂಕಿನ್ಸ್ಗೆ ನಿಯೋಜಿಸಲು ಪ್ರತಿಯೊಬ್ಬರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಸಂತೋಷವು ಬರುತ್ತದೆ. ಓಹ್, ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದ್ದರೆ. "ಮತ್ತು ನೀವು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರನ್ನು ಹೇಗೆ ಬೇಟೆಯಾಡಬಹುದು" ಎಂದು HR ಯೋಚಿಸುತ್ತಾನೆ, "ಇದು ಫ್ಯಾಶನ್ ಪದವಾಗಿದೆ, ಕೀವರ್ಡ್‌ಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ, ಅವರು ಬೆಟ್ ತೆಗೆದುಕೊಳ್ಳಬೇಕು."
ಬೇಡಿಕೆಯು ಸರಬರಾಜನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ಕಸದ ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ಸಿಸ್ಟಂ ನಿರ್ವಾಹಕರ ಹುಚ್ಚು ಸಂಖ್ಯೆಯಿಂದ ತುಂಬಿಸಲಾಗಿದೆ: ನೀವು ಎಲ್ಲವನ್ನೂ ಮೊದಲಿನಂತೆಯೇ ಮಾಡಬಹುದು, ಆದರೆ ನಿಮ್ಮನ್ನು "ಡೆವೊಪ್ಸ್" ಎಂದು ಕರೆಯುವ ಮೂಲಕ ಹಲವಾರು ಪಟ್ಟು ಹೆಚ್ಚು ಪಡೆಯಬಹುದು. ನೀವು ಒಂದು ಸಮಯದಲ್ಲಿ SSH ಮೂಲಕ ಸರ್ವರ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಂತೆಯೇ, ನೀವು ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೀರಿ, ಆದರೆ ಈಗ ಇದು ಡೆವೊಪ್ಸ್ ಅಭ್ಯಾಸವಾಗಿದೆ. ಇದು ಕೆಲವು ರೀತಿಯ ಸಂಕೀರ್ಣ ವಿದ್ಯಮಾನವಾಗಿದೆ, ಇದು ಕ್ಲಾಸಿಕ್ ನಿರ್ವಾಹಕರ ಕಡಿಮೆ ಅಂದಾಜು ಮತ್ತು DevOps ಸುತ್ತಲಿನ ಪ್ರಚೋದನೆಗೆ ಭಾಗಶಃ ಸಂಬಂಧಿಸಿದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಏನಾಯಿತು, ಸಂಭವಿಸಿದೆ.
ಆದ್ದರಿಂದ ನಮಗೆ ಪೂರೈಕೆ ಮತ್ತು ಬೇಡಿಕೆ ಇದೆ. ತನ್ನನ್ನು ತಾನೇ ಪೋಷಿಸುವ ಕೆಟ್ಟ ವೃತ್ತ. ಇದರ ವಿರುದ್ಧ ನಾವು ಹೋರಾಡುತ್ತಿದ್ದೇವೆ (DevOops ಸಮ್ಮೇಳನವನ್ನು ರಚಿಸುವ ಮೂಲಕ).
ಸಹಜವಾಗಿ, ತಮ್ಮನ್ನು "ಡೆವೊಪ್ಸ್" ಎಂದು ಮರುಹೆಸರಿಸಿದ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಲ್ಲದೆ, ಇತರ ಭಾಗವಹಿಸುವವರು ಇದ್ದಾರೆ - ಉದಾಹರಣೆಗೆ, ವೃತ್ತಿಪರ SRE ಗಳು ಅಥವಾ ಮೂಲಸೌಕರ್ಯ-ಕೋಡ್ ಡೆವಲಪರ್‌ಗಳು.
DevOps ನಲ್ಲಿ ಜನರು ಏನು ಮಾಡುತ್ತಾರೆ (ನಿಜವಾಗಿಯೂ)
ಆದ್ದರಿಂದ ನೀವು DevOps ಅಭ್ಯಾಸಗಳನ್ನು ಕಲಿಯಲು ಮತ್ತು ಅನ್ವಯಿಸುವಲ್ಲಿ ಮುಂದೆ ಬರಲು ಬಯಸುತ್ತೀರಿ. ಆದರೆ ಇದನ್ನು ಹೇಗೆ ಮಾಡುವುದು, ಯಾವ ದಿಕ್ಕಿನಲ್ಲಿ ನೋಡಬೇಕು? ನಿಸ್ಸಂಶಯವಾಗಿ, ನೀವು ಜನಪ್ರಿಯ ಕೀವರ್ಡ್‌ಗಳನ್ನು ಕುರುಡಾಗಿ ಅವಲಂಬಿಸಬಾರದು.
ಕೆಲಸವಿದ್ದರೆ ಯಾರಾದರೂ ಮಾಡಬೇಕು. ಇವರು "ಡೆವೊಪ್ಸ್ ಎಂಜಿನಿಯರ್‌ಗಳು" ಅಲ್ಲ ಎಂದು ನಾವು ಈಗಾಗಲೇ ಕಂಡುಕೊಂಡಿದ್ದೇವೆ, ಹಾಗಾದರೆ ಯಾರು? ಸ್ಥಾನಗಳ ಪರಿಭಾಷೆಯಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಕೆಲಸದ ನಿರ್ದಿಷ್ಟ ಕ್ಷೇತ್ರಗಳ ಪರಿಭಾಷೆಯಲ್ಲಿ ಇದನ್ನು ರೂಪಿಸಲು ಹೆಚ್ಚು ಸರಿಯಾಗಿ ತೋರುತ್ತದೆ.
ಮೊದಲಿಗೆ, ನೀವು DevOps-ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸಂಸ್ಕೃತಿಯ ಹೃದಯವನ್ನು ತಿಳಿಸಬಹುದು. ಸಂಸ್ಕೃತಿಯು ನಿಧಾನ ಮತ್ತು ಕಷ್ಟಕರವಾದ ವ್ಯವಹಾರವಾಗಿದೆ, ಮತ್ತು ಇದು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ವ್ಯವಸ್ಥಾಪಕರ ಜವಾಬ್ದಾರಿಯಾಗಿದ್ದರೂ, ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಂದ ನಿರ್ವಾಹಕರವರೆಗೆ ಪ್ರತಿಯೊಬ್ಬರೂ ಒಂದಲ್ಲ ಒಂದು ರೀತಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ. ಒಂದೆರಡು ತಿಂಗಳ ಹಿಂದೆ ಟಿಮ್ ಲಿಸ್ಟರ್ :
“ಸಂಸ್ಕಾರವನ್ನು ಸಂಸ್ಥೆಯ ಮೂಲ ಮೌಲ್ಯಗಳಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಜನರು ಇದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ, ಆದರೆ ಹಲವಾರು ವರ್ಷಗಳಿಂದ ಸಮಾಲೋಚನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ನಾವು ಅದನ್ನು ಗಮನಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ನೀವು ಕಂಪನಿಯನ್ನು ನಮೂದಿಸಿ ಮತ್ತು ಅಕ್ಷರಶಃ ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ನಾವು ಇದನ್ನು "ಸುವಾಸನೆ" ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಕೆಲವೊಮ್ಮೆ ಈ ಪರಿಮಳವು ತುಂಬಾ ಒಳ್ಳೆಯದು. ಕೆಲವೊಮ್ಮೆ ಇದು ವಾಕರಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. (...) ನಿರ್ದಿಷ್ಟ ಕ್ರಿಯೆಗಳ ಹಿಂದಿನ ಮೌಲ್ಯಗಳು ಮತ್ತು ನಂಬಿಕೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವವರೆಗೆ ನೀವು ಸಂಸ್ಕೃತಿಯನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಡವಳಿಕೆಯನ್ನು ಗಮನಿಸುವುದು ಸುಲಭ, ಆದರೆ ನಂಬಿಕೆಗಳನ್ನು ಹುಡುಕುವುದು ಕಷ್ಟ. ವಿಷಯಗಳು ಹೇಗೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿವೆ ಎಂಬುದಕ್ಕೆ DevOps ಒಂದು ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ.
ಸಹಜವಾಗಿ, ಸಮಸ್ಯೆಯ ತಾಂತ್ರಿಕ ಭಾಗವೂ ಇದೆ. ನಿಮ್ಮ ಹೊಸ ಕೋಡ್ ಅನ್ನು ಒಂದು ತಿಂಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದರೆ, ಆದರೆ ಕೇವಲ ಒಂದು ವರ್ಷದ ನಂತರ ಬಿಡುಗಡೆ ಮಾಡಿದರೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ವೇಗಗೊಳಿಸಲು ಭೌತಿಕವಾಗಿ ಅಸಾಧ್ಯವಾದರೆ, ನೀವು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಿಗೆ ತಕ್ಕಂತೆ ಜೀವಿಸದಿರಬಹುದು. ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಉತ್ತಮ ಸಾಧನಗಳಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್-ಆಸ್-ಕೋಡ್ ಅನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ನೀವು AWS ಕ್ಲೌಡ್ ಫಾರ್ಮೇಷನ್ ಮತ್ತು ಟೆರಾಫಾರ್ಮ್‌ನಿಂದ ಚೆಫ್-ಅನ್ಸಿಬಲ್-ಪಪಿಟ್‌ವರೆಗೆ ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದು. ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಇದೆಲ್ಲವನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಎಂಜಿನಿಯರಿಂಗ್ ವಿಭಾಗವಾಗಿದೆ. ಪರಿಣಾಮದೊಂದಿಗೆ ಕಾರಣವನ್ನು ಗೊಂದಲಗೊಳಿಸದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ: ಮೊದಲು ನೀವು SRE ಯ ತತ್ವಗಳ ಪ್ರಕಾರ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಈ ತತ್ವಗಳನ್ನು ಕೆಲವು ನಿರ್ದಿಷ್ಟ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳ ರೂಪದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಎಸ್‌ಆರ್‌ಇ ಅತ್ಯಂತ ಸಮಗ್ರವಾದ ವಿಧಾನವಾಗಿದ್ದು ಅದು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಆದರೆ ಐದು ಮೂಲಭೂತ ತತ್ವಗಳ ಬಗ್ಗೆ:
- ಪಾತ್ರಗಳು ಮತ್ತು ಇಲಾಖೆಗಳ ನಡುವೆ ಸುಧಾರಿತ ಸಂವಹನ
- ತಪ್ಪುಗಳನ್ನು ಕೆಲಸದ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುವುದು
- ಕ್ರಮೇಣ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು
- ಉಪಕರಣ ಮತ್ತು ಇತರ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಬಳಕೆ
- ಅಳೆಯಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಅಳೆಯುವುದು
ಇದು ಕೇವಲ ಕೆಲವು ಹೇಳಿಕೆಗಳಲ್ಲ, ಆದರೆ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ . ಉದಾಹರಣೆಗೆ, ದೋಷಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಹಾದಿಯಲ್ಲಿ, ನೀವು ಅಪಾಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, SLI ನಂತಹ ಸೇವೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸೇವೆಗಳ ಲಭ್ಯತೆ ಮತ್ತು ಅಲಭ್ಯತೆಯನ್ನು ಅಳೆಯಬೇಕು () ಮತ್ತು SLO (), ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್‌ಗಳನ್ನು ಬರೆಯಲು ಕಲಿಯಿರಿ ಮತ್ತು ಅವುಗಳನ್ನು ಬರೆಯಲು ಭಯಾನಕವಾಗದಂತೆ ಮಾಡಿ.
SRE ವಿಭಾಗದಲ್ಲಿ, ಉಪಕರಣಗಳ ಬಳಕೆಯು ಯಶಸ್ಸಿನ ಒಂದು ಭಾಗವಾಗಿದೆ, ಆದರೂ ಇದು ಪ್ರಮುಖವಾಗಿದೆ. ನಾವು ನಿರಂತರವಾಗಿ ತಾಂತ್ರಿಕವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದಬೇಕು, ಜಗತ್ತಿನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ನಮ್ಮ ಕೆಲಸದಲ್ಲಿ ಹೇಗೆ ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದನ್ನು ನೋಡಿ.
ಪ್ರತಿಯಾಗಿ, ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಪರಿಹಾರಗಳು ಈಗ ಬಹಳ ಜನಪ್ರಿಯವಾಗಿವೆ. ಇಂದು ಕ್ಲೌಡ್ ನೇಟಿವ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಫೌಂಡೇಶನ್ ವ್ಯಾಖ್ಯಾನಿಸಿದಂತೆ, ಕ್ಲೌಡ್ ನೇಟಿವ್ ತಂತ್ರಜ್ಞಾನಗಳು ಸಾರ್ವಜನಿಕ, ಖಾಸಗಿ ಮತ್ತು ಹೈಬ್ರಿಡ್ ಮೋಡಗಳಂತಹ ಇಂದಿನ ಡೈನಾಮಿಕ್ ಪರಿಸರದಲ್ಲಿ ಸ್ಕೇಲೆಬಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮತ್ತು ಚಲಾಯಿಸಲು ಸಂಸ್ಥೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗಳಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳು, ಸರ್ವಿಸ್ ಮೆಶ್‌ಗಳು, ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು, ಬದಲಾಗದ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಡಿಕ್ಲೇರೇಟಿವ್ API ಗಳು ಸೇರಿವೆ. ಈ ಎಲ್ಲಾ ತಂತ್ರಗಳು ಸಡಿಲವಾಗಿ ಜೋಡಿಸಲಾದ ವ್ಯವಸ್ಥೆಗಳು ಸ್ಥಿತಿಸ್ಥಾಪಕ, ನಿರ್ವಹಿಸಬಹುದಾದ ಮತ್ತು ಹೆಚ್ಚು ಗಮನಿಸಬಹುದಾದಂತೆ ಉಳಿಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಉತ್ತಮ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಆಗಾಗ್ಗೆ ದೊಡ್ಡ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಕೆಲಸ ಮಾಡದೆಯೇ ಊಹಿಸಬಹುದಾದ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಪ್ರಸಿದ್ಧ ಪರಿಕರಗಳ ಸ್ಟಾಕ್‌ನಿಂದ ಇದೆಲ್ಲವನ್ನೂ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ.
ಈ ಪ್ರದೇಶವು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ಇದು ಸಂಕೀರ್ಣವಾದ ಮತ್ತು ವಿಶಾಲವಾದ ವ್ಯಾಖ್ಯಾನವಾಗಿದೆ. ಒಂದೆಡೆ, ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಸರಳವಾಗಿ ಸೇರಿಸಬೇಕು ಎಂದು ವಾದಿಸಲಾಗಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಸಾಫ್ಟ್‌ವೇರ್-ವ್ಯಾಖ್ಯಾನಿತ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಸಡಿಲವಾಗಿ ಸಂಯೋಜಿತ ಸೇವೆಗಳು ವಾಸಿಸುವ ಮತ್ತು ನಿರಂತರ CI/CD ಬಳಸಿಕೊಂಡು ಅಲ್ಲಿಗೆ ತಲುಪಿಸುವಂತಹ ಕಂಟೈನರೈಸ್ಡ್ ಪರಿಸರವನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಮತ್ತು ಈ ಎಲ್ಲದರ ಸುತ್ತಲೂ DevOps ಅಭ್ಯಾಸಗಳನ್ನು ನಿರ್ಮಿಸಲು - ಇದಕ್ಕೆಲ್ಲ ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿರುತ್ತದೆ. ಒಬ್ಬರು ನಾಯಿಯನ್ನು ತಿನ್ನುವುದಕ್ಕಿಂತ.
ಇದನ್ನೆಲ್ಲಾ ಏನು ಮಾಡುವುದು
ಪ್ರತಿಯೊಬ್ಬರೂ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ತಮ್ಮದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸುತ್ತಾರೆ: ಉದಾಹರಣೆಗೆ, ಕೆಟ್ಟ ವೃತ್ತವನ್ನು ಮುರಿಯಲು ನೀವು ಸಾಮಾನ್ಯ ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ಪ್ರಕಟಿಸಬಹುದು. DevOps ಮತ್ತು Cloud Native ನಂತಹ ಪದಗಳ ಅರ್ಥವನ್ನು ನೀವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಮತ್ತು ಬಿಂದುವಿಗೆ ಬಳಸಿ. ನೀವು DevOps ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಉದಾಹರಣೆಯ ಮೂಲಕ ಸರಿಯಾದ ವಿಧಾನಗಳನ್ನು ಪ್ರದರ್ಶಿಸಬಹುದು.
ನಾವು ಸಮ್ಮೇಳನ ಮಾಡುತ್ತಿದ್ದೇವೆ , ಇದು ನಾವು ಈಗಷ್ಟೇ ಮಾತನಾಡಿದ ವಿಷಯಗಳ ಬಗ್ಗೆ ಆಳವಾಗಿ ಅಧ್ಯಯನ ಮಾಡಲು ಅವಕಾಶವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದಕ್ಕಾಗಿ ಹಲವಾರು ವರದಿಗಳ ಗುಂಪುಗಳಿವೆ:
- ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸಂಸ್ಕೃತಿ;
- ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್;
- ಮೇಘ ಸ್ಥಳೀಯ;
ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ಆಯ್ಕೆ ಮಾಡುವುದು ಹೇಗೆ? ಇಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ಅಂಶವಿದೆ. ಒಂದೆಡೆ, DevOps ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಬಗ್ಗೆ, ಮತ್ತು ನೀವು ವಿಭಿನ್ನ ಬ್ಲಾಕ್‌ಗಳಿಂದ ಪ್ರಸ್ತುತಿಗಳಿಗೆ ಹಾಜರಾಗಬೇಕೆಂದು ನಾವು ನಿಜವಾಗಿಯೂ ಬಯಸುತ್ತೇವೆ. ಮತ್ತೊಂದೆಡೆ, ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಸಮ್ಮೇಳನಕ್ಕೆ ಬಂದ ಅಭಿವೃದ್ಧಿ ವ್ಯವಸ್ಥಾಪಕರಾಗಿದ್ದರೆ, ಯಾರೂ ನಿಮ್ಮನ್ನು ಮಿತಿಗೊಳಿಸುವುದಿಲ್ಲ - ನಿಸ್ಸಂಶಯವಾಗಿ, ಇದು ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸಂಸ್ಕೃತಿಯ ಬಗ್ಗೆ ಒಂದು ಬ್ಲಾಕ್ ಆಗಿರುತ್ತದೆ. ಸಮ್ಮೇಳನದ ನಂತರ (ಪ್ರತಿಕ್ರಿಯೆ ಫಾರ್ಮ್ ಅನ್ನು ಭರ್ತಿ ಮಾಡಿದ ನಂತರ) ನೀವು ರೆಕಾರ್ಡಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ ಎಂಬುದನ್ನು ಮರೆಯಬೇಡಿ, ಆದ್ದರಿಂದ ನೀವು ನಂತರ ಕಡಿಮೆ ಪ್ರಮುಖ ಪ್ರಸ್ತುತಿಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು.
ನಿಸ್ಸಂಶಯವಾಗಿ, ಸಮ್ಮೇಳನದಲ್ಲಿ ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಮೂರು ಟ್ರ್ಯಾಕ್‌ಗಳಲ್ಲಿ ಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಬಾರಿ ಸ್ಲಾಟ್‌ನಲ್ಲಿ ಪ್ರತಿ ರುಚಿಗೆ ವಿಷಯಗಳನ್ನು ಹೊಂದಿರುವ ರೀತಿಯಲ್ಲಿ ನಾವು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಆಯೋಜಿಸುತ್ತೇವೆ.
ನೀವು DevOps ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದರೆ ಏನು ಮಾಡಬೇಕೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ! ಮೊದಲಿಗೆ, ನೀವು ನಿಜವಾಗಿಯೂ ಏನು ಮಾಡುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ಅವರು ಈ ಪದವನ್ನು ಕರೆಯಲು ಇಷ್ಟಪಡುತ್ತಾರೆ:
- ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಡೆವಲಪರ್‌ಗಳು. SRE ಮತ್ತು Cloud Native ಕುರಿತು ವರದಿಗಳ ಗುಂಪುಗಳು ನಿಮಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿವೆ.
- ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು. ಇಲ್ಲಿ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. DevOops ಸಿಸ್ಟಮ್ ಆಡಳಿತದ ಬಗ್ಗೆ ಅಲ್ಲ. ಅದೃಷ್ಟವಶಾತ್, ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ವಿಷಯದ ಕುರಿತು ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಬಹಳಷ್ಟು ಅತ್ಯುತ್ತಮ ಸಮ್ಮೇಳನಗಳು, ಪುಸ್ತಕಗಳು, ಲೇಖನಗಳು, ವೀಡಿಯೊಗಳು ಇತ್ಯಾದಿಗಳಿವೆ. ಮತ್ತೊಂದೆಡೆ, ಸಂಸ್ಕೃತಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ವಿಷಯದಲ್ಲಿ ನಿಮ್ಮನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಕ್ಲೌಡ್ ತಂತ್ರಜ್ಞಾನಗಳ ಬಗ್ಗೆ ಮತ್ತು ಕ್ಲೌಡ್ ನೇಟಿವ್‌ನೊಂದಿಗೆ ಜೀವನದ ವಿವರಗಳನ್ನು ಕಲಿಯಲು, ನಾವು ನಿಮ್ಮನ್ನು ನೋಡಲು ಇಷ್ಟಪಡುತ್ತೇವೆ! ಇದರ ಬಗ್ಗೆ ಯೋಚಿಸಿ: ನೀವು ಆಡಳಿತ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ನೀವು ಏನು ಮಾಡುತ್ತೀರಿ? ಅಹಿತಕರ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಿಮ್ಮನ್ನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಂಡುಕೊಳ್ಳುವುದನ್ನು ತಪ್ಪಿಸಲು, ನೀವು ಈಗ ಕಲಿಯಬೇಕು.
ಇನ್ನೊಂದು ಆಯ್ಕೆ ಇದೆ: ನೀವು ನಿರಂತರವಾಗಿರುತ್ತೀರಿ ಮತ್ತು ನೀವು ಎಂದು ಹೇಳಿಕೊಳ್ಳುವುದನ್ನು ಮುಂದುವರಿಸಿ ನಿರ್ದಿಷ್ಟವಾಗಿ DevOps ಇಂಜಿನಿಯರ್ ಮತ್ತು ಬೇರೆ ಏನೂ ಇಲ್ಲ, ಅದರ ಅರ್ಥವೇನಾದರೂ. ನಂತರ ನಾವು ನಿಮ್ಮನ್ನು ನಿರಾಶೆಗೊಳಿಸಬೇಕಾಗಿದೆ, DevOops DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಸಮ್ಮೇಳನವಲ್ಲ!
ನಿಂದ ಸ್ಲೈಡ್ ಮಾಡಿ ಮ್ಯೂನಿಚ್‌ನಲ್ಲಿ
DevOops 2020 ಮಾಸ್ಕೋ ಏಪ್ರಿಲ್ 29-30 ರಂದು ಮಾಸ್ಕೋದಲ್ಲಿ ನಡೆಯಲಿದೆ, ಟಿಕೆಟ್‌ಗಳು ಈಗಾಗಲೇ ಲಭ್ಯವಿದೆ .
ಪರ್ಯಾಯವಾಗಿ, ನೀವು ಮಾಡಬಹುದು ಫೆಬ್ರವರಿ 8 ರವರೆಗೆ. ಫಾರ್ಮ್ ಅನ್ನು ಭರ್ತಿ ಮಾಡುವಾಗ, ನಿಮ್ಮ ವರದಿಯಿಂದ ಹೆಚ್ಚು ಪ್ರಯೋಜನ ಪಡೆಯುವ ಗುರಿ ಪ್ರೇಕ್ಷಕರನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ (ಪಟ್ಟಿಯೊಳಗೆ ಅಚ್ಚರಿಯೊಂದು ಅಡಗಿದೆ).
ಮೂಲ: www.habr.com