ನಾವು ಅರ್ಥವಾಗುವ ಭಾಷೆಯಲ್ಲಿ DevOps ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ

DevOps ಕುರಿತು ಮಾತನಾಡುವಾಗ ಮುಖ್ಯ ಅಂಶವನ್ನು ಗ್ರಹಿಸುವುದು ಕಷ್ಟವೇ? ನಾವು ನಿಮಗಾಗಿ ಎದ್ದುಕಾಣುವ ಸಾದೃಶ್ಯಗಳು, ಗಮನಾರ್ಹವಾದ ಸೂತ್ರೀಕರಣಗಳು ಮತ್ತು ತಜ್ಞರಿಂದ ಸಲಹೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ, ಅದು ತಜ್ಞರಲ್ಲದವರಿಗೆ ಸಹ ವಿಷಯಕ್ಕೆ ಬರಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕೊನೆಯಲ್ಲಿ, ಬೋನಸ್ Red Hat ಉದ್ಯೋಗಿಗಳ ಸ್ವಂತ DevOps ಆಗಿದೆ.

ನಾವು ಅರ್ಥವಾಗುವ ಭಾಷೆಯಲ್ಲಿ DevOps ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ

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

ಆದ್ದರಿಂದ, ನೀವು ಆಗಾಗ್ಗೆ DevOps ಕುರಿತು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು, ಇದು ಚುರುಕುಬುದ್ಧಿಯಂತೆಯೇ ಇದೆಯೇ? ಅಥವಾ ಇದು ಯಾವುದಾದರೂ ವಿಶೇಷ ವಿಧಾನವೇ? ಅಥವಾ ಇದು "ಸಹಯೋಗ" ಎಂಬ ಪದಕ್ಕೆ ಮತ್ತೊಂದು ಸಮಾನಾರ್ಥಕವಾಗಿದೆಯೇ?

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

DevOps ಎಂದರೇನು: 6 ವ್ಯಾಖ್ಯಾನಗಳು ಮತ್ತು ಸಾದೃಶ್ಯಗಳು

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

1. DevOps ಒಂದು ಸಾಂಸ್ಕೃತಿಕ ಚಳುವಳಿಯಾಗಿದೆ

"DevOps ಒಂದು ಸಾಂಸ್ಕೃತಿಕ ಆಂದೋಲನವಾಗಿದೆ, ಇದರಲ್ಲಿ ಎರಡೂ ಪಕ್ಷಗಳು (ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಐಟಿ ಸಿಸ್ಟಮ್ ಆಪರೇಟಿಂಗ್ ತಜ್ಞರು) ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಯಾರಾದರೂ ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವವರೆಗೆ ಅದು ನಿಜವಾದ ಪ್ರಯೋಜನಗಳನ್ನು ತರುವುದಿಲ್ಲ ಎಂದು ಗುರುತಿಸುತ್ತದೆ: ಗ್ರಾಹಕರು, ಗ್ರಾಹಕರು, ಉದ್ಯೋಗಿಗಳು, ಪಾಯಿಂಟ್ ಅಲ್ಲ" ಎಂದು ಹಿರಿಯ ಸಂಶೋಧನೆಯ ಎವೆಲಿನ್ ಓಹ್ರ್ಲಿಚ್ ಹೇಳುತ್ತಾರೆ. DevOps ಸಂಸ್ಥೆಯಲ್ಲಿ ವಿಶ್ಲೇಷಕ. "ಆದ್ದರಿಂದ, ಈ ಎರಡೂ ಪಕ್ಷಗಳು ಜಂಟಿಯಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ವೇಗದ ಮತ್ತು ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ವಿತರಣೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತವೆ."

2. DevOps ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಧಿಕಾರ ನೀಡುವುದಾಗಿದೆ.

"DevOps ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊಂದಲು, ಅವುಗಳನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಪ್ರಾರಂಭದಿಂದ ಅಂತ್ಯದವರೆಗೆ ವಿತರಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ."

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

3. DevOps ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಮತ್ತು ವಿತರಿಸುವಲ್ಲಿ ಸಹಯೋಗವನ್ನು ಹೊಂದಿದೆ.

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

4. DevOps ಒಂದು ಪೈಪ್‌ಲೈನ್ ಆಗಿದೆ

"ಎಲ್ಲಾ ಭಾಗಗಳು ಒಟ್ಟಿಗೆ ಹೊಂದಿಕೊಂಡರೆ ಮಾತ್ರ ಕನ್ವೇಯರ್ ಜೋಡಣೆ ಸಾಧ್ಯ."

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

ವ್ಯಾಪಾರ ತರ್ಕ ಅಥವಾ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ರಚಿಸುವ ಡೆವಲಪರ್ ಗ್ರಾಹಕರ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಡೇಟಾಬೇಸ್, ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಲು ಭದ್ರತಾ ಕ್ರಮಗಳು ಮತ್ತು ಸೇವೆಯು ದೊಡ್ಡದಾದ, ಬಹುಶಃ ಬಹು-ಮಿಲಿಯನ್-ಡಾಲರ್ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಇವೆಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸಬೇಕು. ."

"ಜನರು ತಮ್ಮ ಸ್ವಂತ ಕಾರ್ಯಗಳ ಮೇಲೆ ಮಾತ್ರ ಕೇಂದ್ರೀಕರಿಸುವ ಬದಲು ಇತರರು ಮಾಡುತ್ತಿರುವ ಕೆಲಸದ ಭಾಗಗಳ ಬಗ್ಗೆ ಸಹಕರಿಸಲು ಮತ್ತು ಯೋಚಿಸುವಂತೆ ಮಾಡುವುದು ಜಯಿಸಲು ದೊಡ್ಡ ಅಡಚಣೆಯಾಗಿದೆ. ನೀವು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ನಿಮಗೆ ಡಿಜಿಟಲ್ ರೂಪಾಂತರದ ಅತ್ಯುತ್ತಮ ಅವಕಾಶವಿದೆ, ”ಗುರ್ ಸಿಬ್ಬಂದಿ ಸೇರಿಸುತ್ತಾರೆ.

5. DevOps ಜನರು, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸರಿಯಾದ ಸಂಯೋಜನೆಯಾಗಿದೆ

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

6. DevOps ಎಂದರೆ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಫಾರ್ಮುಲಾ 1 ತಂಡದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ

"ಓಟವನ್ನು ಪ್ರಾರಂಭದಿಂದ ಮುಗಿಸಲು ಯೋಜಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಮುಕ್ತಾಯದಿಂದ ಆರಂಭಕ್ಕೆ."

"DevOps ಉಪಕ್ರಮದಿಂದ ಏನನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡುವಾಗ, ನಾನು NASCAR ಅಥವಾ ಫಾರ್ಮುಲಾ 1 ರೇಸಿಂಗ್ ತಂಡವನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಪರಿಗಣಿಸುತ್ತೇನೆ" ಎಂದು Red Hat ನಲ್ಲಿ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಾರ್ಕೆಟಿಂಗ್‌ನ ಹಿರಿಯ ವ್ಯವಸ್ಥಾಪಕ ಮತ್ತು DevOps'ish ಸುದ್ದಿಪತ್ರದ ಪ್ರಕಾಶಕ ಕ್ರಿಸ್ ಶಾರ್ಟ್ ಹೇಳುತ್ತಾರೆ. - ಅಂತಹ ತಂಡದ ನಾಯಕನು ಒಂದು ಗುರಿಯನ್ನು ಹೊಂದಿದ್ದಾನೆ: ತಂಡಕ್ಕೆ ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಅದಕ್ಕೆ ಎದುರಾಗುವ ಸವಾಲುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಓಟದ ಕೊನೆಯಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಿನ ಸ್ಥಾನವನ್ನು ಪಡೆದುಕೊಳ್ಳುವುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಓಟವನ್ನು ಪ್ರಾರಂಭದಿಂದ ಮುಗಿಸಲು ಯೋಜಿಸಲಾಗಿದೆ, ಆದರೆ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಮುಕ್ತಾಯದಿಂದ ಆರಂಭಕ್ಕೆ. ಮೊದಲಿಗೆ, ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ಗುರಿಯನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಅದನ್ನು ಸಾಧಿಸುವ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ನಂತರ ಅವುಗಳನ್ನು ಉಪಕಾರ್ಯಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ತಂಡದ ಸದಸ್ಯರಿಗೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

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

"ಇದು 'ಸರಿಯಾದ ಕೆಲಸವನ್ನು' ಮಾಡುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ," ಶಾರ್ಟ್ ಸೇರಿಸುತ್ತದೆ, "ಇದು ಅಪೇಕ್ಷಿತ ಫಲಿತಾಂಶದ ರೀತಿಯಲ್ಲಿ ನಿಲ್ಲುವ ಸಾಧ್ಯವಾದಷ್ಟು ವಿಷಯಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು. ನೈಜ ಸಮಯದಲ್ಲಿ ನೀವು ಸ್ವೀಕರಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಆಧರಿಸಿ ಸಹಕರಿಸಿ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳಿ. ವೈಪರೀತ್ಯಗಳಿಗೆ ಸಿದ್ಧರಾಗಿರಿ ಮತ್ತು ನಿಮ್ಮ ಗುರಿಯತ್ತ ಪ್ರಗತಿಯ ಮೇಲೆ ಅವುಗಳ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ಕೆಲಸ ಮಾಡಿ. DevOps ಜಗತ್ತಿನಲ್ಲಿ ಇದು ನಮಗೆ ಕಾಯುತ್ತಿದೆ.

ನಾವು ಅರ್ಥವಾಗುವ ಭಾಷೆಯಲ್ಲಿ DevOps ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ

DevOps ಅನ್ನು ಅಳೆಯುವುದು ಹೇಗೆ: ತಜ್ಞರಿಂದ 10 ಸಲಹೆಗಳು

DevOps ಮತ್ತು ಸಾಮೂಹಿಕ DevOps ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಷಯಗಳಾಗಿವೆ. ಮೊದಲನೆಯದರಿಂದ ಎರಡನೆಯದಕ್ಕೆ ದಾರಿಯಲ್ಲಿ ಅಡೆತಡೆಗಳನ್ನು ಹೇಗೆ ಜಯಿಸುವುದು ಎಂದು ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ.

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

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

ಫಲಿತಾಂಶವು "ನಮ್ಮ" ಮತ್ತು "ಅವರ" ನಡುವಿನ ವಿಭಜನೆಯ ಸಂಸ್ಕೃತಿಯಾಗಿದೆ ಎಂದು ನೋಡುವುದು ಸುಲಭ.

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

"ಮತ್ತು ಈ ಸಾಂಸ್ಕೃತಿಕ ಸಮಸ್ಯೆಯು DevOps ಅನ್ನು ಅಳೆಯಲು ಕಷ್ಟಕರವಾದ ಕಾರಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. DevOps ತಂಡಗಳು ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ IT-ಮೊದಲ ಕಂಪನಿಗಳ ವಿಶಿಷ್ಟವಾದ ಹೆಚ್ಚಿದ ತಾಂತ್ರಿಕ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುತ್ತಿವೆ ”ಎಂದು ಸ್ಕೇಲಿರ್‌ನ ಸಂಸ್ಥಾಪಕ ಮತ್ತು ಅಧ್ಯಕ್ಷ ಸ್ಟೀವ್ ನ್ಯೂಮನ್ ಹೇಳಿದರು.

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

ಮೇಲೆ ವಿವರಿಸಿದ ಈ ಸವಾಲುಗಳನ್ನು ಹೇಗೆ ಜಯಿಸುವುದು ಮತ್ತು ದೊಡ್ಡ ಸಂಸ್ಥೆಯಲ್ಲಿ DevOps ಅನ್ನು ಸಾಮೂಹಿಕವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ? ನಿಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಚಕ್ರ ಮತ್ತು ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ವೇಗಗೊಳಿಸುವುದು ನಿಮ್ಮ ಅಂತಿಮ ಗುರಿಯಾಗಿದ್ದರೂ ಸಹ ತಜ್ಞರು ತಾಳ್ಮೆಯನ್ನು ಕೋರುತ್ತಾರೆ.

1. ಸಂಸ್ಕೃತಿ ಬದಲಾವಣೆ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ.

ಜೇನ್ ಗ್ರೋಲ್, ಕಾರ್ಯನಿರ್ವಾಹಕ ನಿರ್ದೇಶಕ, DevOps ಸಂಸ್ಥೆ: “ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, DevOps ನ ವಿಸ್ತರಣೆಯು ಚುರುಕುಬುದ್ಧಿಯ ಬೆಳವಣಿಗೆಯಂತೆ ಹೆಚ್ಚುತ್ತಿರುವ ಮತ್ತು ಪುನರಾವರ್ತಿತವಾಗಿರಬೇಕು (ಮತ್ತು ಸಂಸ್ಕೃತಿಯ ಮೇಲೆ ಸಮಾನವಾಗಿ ಸ್ಪರ್ಶಿಸುವುದು). ಅಗೈಲ್ ಮತ್ತು DevOps ಸಣ್ಣ ತಂಡಗಳಿಗೆ ಒತ್ತು ನೀಡುತ್ತವೆ. ಆದರೆ ಈ ತಂಡಗಳು ಸಂಖ್ಯೆಯಲ್ಲಿ ಮತ್ತು ಏಕೀಕರಣದಲ್ಲಿ ಬೆಳೆದಂತೆ, ನಾವು ಹೆಚ್ಚು ಜನರು ಕೆಲಸ ಮಾಡುವ ಹೊಸ ವಿಧಾನಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದರೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ಬೃಹತ್ ಸಾಂಸ್ಕೃತಿಕ ರೂಪಾಂತರವಿದೆ.

2. ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಯೋಜಿಸಿ ಮತ್ತು ವೇದಿಕೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಳ್ಳಿ

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

“ನಂತರ ಏಕೀಕರಣ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಹಂತವು ಬರುತ್ತದೆ, ಅಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸ್ಕೇಲೆಬಲ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಈಗಾಗಲೇ ಅಗತ್ಯವಿದೆ. DevOps ತಂಡಗಳು ತಮ್ಮ ಕೌಶಲ್ಯ ಮಟ್ಟ ಮತ್ತು ಯೋಜನೆಯ ಅಂತಿಮ ಗುರಿಗಳಿಗೆ ಸೂಕ್ತವಾದ ಸರಿಯಾದ ವೇದಿಕೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಇಲ್ಲಿ ಮುಖ್ಯವಾಗಿದೆ.

ಮುಂದಿನ ಹಂತವು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆಯಾಗಿದೆ ಮತ್ತು ಇದನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಉಪಕರಣಗಳು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು. DevOps (ಉತ್ಪಾದನೆ ಸಿಮ್ಯುಲೇಟರ್, QA ಪರಿಸರ ಮತ್ತು ನಿಜವಾದ ಉತ್ಪಾದನಾ ಪರಿಸರ) ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ವರ್ಚುವಲೈಸ್ಡ್ ಪರಿಸರವನ್ನು ಹೊಂದಲು ಮುಖ್ಯವಾಗಿದೆ ಮತ್ತು ಸಂಬಂಧಿತ ತೀರ್ಮಾನಗಳನ್ನು ಪಡೆಯಲು ಯಾವಾಗಲೂ ಇತ್ತೀಚಿನ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷೆಗಳಿಗೆ ಬಳಸಿ. Analytics ಸ್ಮಾರ್ಟ್ ಆಗಿರಬೇಕು ಮತ್ತು ವೇಗವಾದ ಮತ್ತು ಕ್ರಿಯೆಯ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ದೊಡ್ಡ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು.

3. ಜವಾಬ್ದಾರಿಯಿಂದ ತಪ್ಪನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.

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

4. ಮುಂದೆ ಮಾರ್ಗವನ್ನು ತೆರವುಗೊಳಿಸಿ

ಬೆನ್ ಗ್ರಿನ್ನೆಲ್, ವ್ಯವಸ್ಥಾಪಕ ನಿರ್ದೇಶಕ ಮತ್ತು ಕನ್ಸಲ್ಟೆನ್ಸಿ ನಾರ್ತ್ ಹೈಲ್ಯಾಂಡ್‌ನಲ್ಲಿ ಡಿಜಿಟಲ್ ಮುಖ್ಯಸ್ಥ: "ಪ್ರಮಾಣವನ್ನು ಸಾಧಿಸಲು, ಪ್ರವರ್ತಕ ಯೋಜನೆಗಳೊಂದಿಗೆ "ಪಾತ್ ಕ್ಲಿಯರಿಂಗ್" ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಈ ಕಾರ್ಯಕ್ರಮದ ಗುರಿಯು DevOps ಪ್ರವರ್ತಕರು ಬಿಟ್ಟುಹೋಗುವ ಕಸವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು, ಹಳೆಯ ನಿಯಮಗಳು ಮತ್ತು ಅದರಂತಹ ವಿಷಯಗಳು, ಇದರಿಂದ ಮುಂದಿನ ಹಾದಿಯು ಸ್ಪಷ್ಟವಾಗಿ ಉಳಿಯುತ್ತದೆ.

"ಹೊಸ ಕೆಲಸ ವಿಧಾನಗಳ ಯಶಸ್ಸನ್ನು ವ್ಯಾಪಕವಾಗಿ ಆಚರಿಸುವ ಮೂಲಕ ಪ್ರವರ್ತಕ ಗುಂಪನ್ನು ಮೀರಿದ ಸಂವಹನದ ಮೂಲಕ ಜನರಿಗೆ ಸಾಂಸ್ಥಿಕ ಬೆಂಬಲ ಮತ್ತು ಆವೇಗವನ್ನು ನೀಡಿ. DevOps ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಮುಂದಿನ ತರಂಗದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿರುವ ಮತ್ತು ಮೊದಲ ಬಾರಿಗೆ DevOps ಅನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ಭಯಪಡುವ ಜನರಿಗೆ ತರಬೇತಿ ನೀಡಿ. ಮತ್ತು ಈ ಜನರು ಪ್ರವರ್ತಕರಿಂದ ತುಂಬಾ ಭಿನ್ನರಾಗಿದ್ದಾರೆಂದು ನೆನಪಿಡಿ.

5. ಪರಿಕರಗಳನ್ನು ಪ್ರಜಾಪ್ರಭುತ್ವಗೊಳಿಸಿ

ಸ್ಟೀವ್ ನ್ಯೂಮನ್, ಸ್ಕಾಲಿರ್‌ನ ಸಂಸ್ಥಾಪಕ ಮತ್ತು ಅಧ್ಯಕ್ಷ: "ಪರಿಕರಗಳನ್ನು ಜನರಿಂದ ಮರೆಮಾಡಬಾರದು ಮತ್ತು ಸಮಯವನ್ನು ಹಾಕಲು ಸಿದ್ಧರಿರುವ ಯಾರಾದರೂ ಕಲಿಯಲು ತುಲನಾತ್ಮಕವಾಗಿ ಸುಲಭವಾಗಿರಬೇಕು. ಲಾಗ್‌ಗಳನ್ನು ಪ್ರಶ್ನಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಮೂರು ಜನರಿಗೆ "ಪ್ರಮಾಣೀಕರಿಸಿದ" ಸಾಧನವನ್ನು ಬಳಸಲು ನಿರ್ಬಂಧಿಸಿದರೆ, ನೀವು ದೊಡ್ಡ ಕಂಪ್ಯೂಟಿಂಗ್ ಪರಿಸರವನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ, ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು ನೀವು ಯಾವಾಗಲೂ ಗರಿಷ್ಠ ಮೂರು ಜನರನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಗಂಭೀರವಾದ (ವ್ಯಾಪಾರ) ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದಾದ ಒಂದು ಅಡಚಣೆಯಿದೆ.

6. ತಂಡದ ಕೆಲಸಕ್ಕಾಗಿ ಆದರ್ಶ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ರಚಿಸಿ

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

7. ಕಾನ್ವೇಸ್ ಲಾ ಮತ್ತು ಕಾನ್ಬನ್ ಬೋರ್ಡ್‌ಗಳ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ

Logan Daigle, CollabNetVersionOne ನಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಡೆಲಿವರಿ ಮತ್ತು DevOps ಸ್ಟ್ರಾಟಜಿ ನಿರ್ದೇಶಕ: "ಕಾನ್ವೇಯ ಕಾನೂನಿನ ಪರಿಣಾಮಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ. ನನ್ನ ಸಡಿಲವಾದ ಪ್ಯಾರಾಫ್ರೇಸ್‌ನಲ್ಲಿ, DevOps ಸೇರಿದಂತೆ ನಾವು ರಚಿಸುವ ಉತ್ಪನ್ನಗಳು ಮತ್ತು ಹಾಗೆ ಮಾಡಲು ನಾವು ಬಳಸುವ ಪ್ರಕ್ರಿಯೆಗಳು ನಮ್ಮ ಸಂಸ್ಥೆಯಂತೆಯೇ ರಚನೆಯಾಗುತ್ತವೆ ಎಂದು ಈ ಕಾನೂನು ಹೇಳುತ್ತದೆ.

“ಸಂಸ್ಥೆಯಲ್ಲಿ ಸಾಕಷ್ಟು ಸಿಲೋಗಳು ಇದ್ದರೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಯೋಜಿಸುವಾಗ, ನಿರ್ಮಿಸುವಾಗ ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡುವಾಗ ನಿಯಂತ್ರಣವು ಹಲವು ಬಾರಿ ಕೈಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಸ್ಕೇಲಿಂಗ್‌ನ ಪರಿಣಾಮವು ಶೂನ್ಯವಾಗಿರುತ್ತದೆ ಅಥವಾ ಅಲ್ಪಕಾಲಿಕವಾಗಿರುತ್ತದೆ. ಒಂದು ಸಂಸ್ಥೆಯು ಮಾರುಕಟ್ಟೆಯ ಗಮನವನ್ನು ಹೊಂದಿರುವ ಉತ್ಪನ್ನಗಳ ಸುತ್ತಲೂ ಅಡ್ಡ-ಕ್ರಿಯಾತ್ಮಕ ತಂಡಗಳನ್ನು ನಿರ್ಮಿಸಿದರೆ, ಯಶಸ್ಸಿನ ಸಾಧ್ಯತೆಗಳು ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.

“ಸ್ಕೇಲಿಂಗ್‌ನ ಇನ್ನೊಂದು ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಕಾನ್ಬನ್ ಬೋರ್ಡ್‌ಗಳಲ್ಲಿ ಎಲ್ಲಾ ಕೆಲಸಗಳು ಪ್ರಗತಿಯಲ್ಲಿದೆ (WIP, ವರ್ಕ್‌ಇನ್‌ಪ್ರೆಗ್ಸ್) ಅನ್ನು ಪ್ರದರ್ಶಿಸುವುದು. ಒಂದು ಸಂಸ್ಥೆಯು ಜನರು ಈ ವಿಷಯಗಳನ್ನು ನೋಡುವ ಸ್ಥಳವನ್ನು ಹೊಂದಿರುವಾಗ, ಇದು ಸಹಯೋಗವನ್ನು ಹೆಚ್ಚು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ, ಇದು ಸ್ಕೇಲಿಂಗ್‌ನ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

8. ಹಳೆಯ ಗುರುತುಗಳನ್ನು ನೋಡಿ

ಮ್ಯಾನುಯೆಲ್ ಪೈಸ್, DevOps ಸಲಹೆಗಾರ ಮತ್ತು ಟೀಮ್ ಟೋಪೋಲಜೀಸ್‌ನ ಸಹ-ಲೇಖಕ: "Dev ಮತ್ತು Ops ಅನ್ನು ಮೀರಿ DevOps ಅಭ್ಯಾಸಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಇತರ ಕಾರ್ಯಗಳಿಗೆ ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಅಷ್ಟೇನೂ ಸೂಕ್ತ ವಿಧಾನವಲ್ಲ. ಇದು ಖಂಡಿತವಾಗಿಯೂ ಕೆಲವು ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಹಸ್ತಚಾಲಿತ ನಿಯಂತ್ರಣವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಮೂಲಕ), ಆದರೆ ನಾವು ವಿತರಣೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದರೆ ಹೆಚ್ಚಿನದನ್ನು ಸಾಧಿಸಬಹುದು.

"ಸಂಸ್ಥೆಯ ಐಟಿ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಹಳೆಯ ಗುರುತುಗಳಿದ್ದರೆ - ಹಿಂದಿನ ಘಟನೆಗಳ ಪರಿಣಾಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ನಿರ್ವಹಣಾ ಕಾರ್ಯವಿಧಾನಗಳು, ಆದರೆ ಅವುಗಳ ಪ್ರಸ್ತುತತೆಯನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದರೆ (ಉತ್ಪನ್ನಗಳು, ತಂತ್ರಜ್ಞಾನಗಳು ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಂದಾಗಿ) - ನಂತರ ಅವುಗಳನ್ನು ಖಂಡಿತವಾಗಿಯೂ ತೆಗೆದುಹಾಕಬೇಕಾಗಿದೆ. ಅಥವಾ ಅಸಮರ್ಥ ಅಥವಾ ಅನಗತ್ಯ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಬದಲು ಸುಗಮಗೊಳಿಸಲಾಗಿದೆ.

9. DevOps ಆಯ್ಕೆಗಳನ್ನು ತಳಿ ಮಾಡಬೇಡಿ

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

10. DevOps ನ ವ್ಯವಹಾರ ಮೌಲ್ಯವನ್ನು ಬೋಧಿಸಿ

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

ಬೋನಸ್

ಮೇಲೆ ರೆಡ್ ಹ್ಯಾಟ್ ಫೋರಮ್ ರಷ್ಯಾ ನಮ್ಮದೇ ಆದ DevOps ಸೆಪ್ಟೆಂಬರ್ 13 ರಂದು ಆಗಮಿಸಲಿದೆ - ಹೌದು, Red Hat, ಸಾಫ್ಟ್‌ವೇರ್ ತಯಾರಕರಾಗಿ, ತನ್ನದೇ ಆದ DevOps ತಂಡಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ.

ಸಂಸ್ಥೆಯಾದ್ಯಂತ ಇತರ ಗುಂಪುಗಳಿಗೆ ಆಂತರಿಕ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸೇವೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ನಮ್ಮ ಇಂಜಿನಿಯರ್ ಮಾರ್ಕ್ ಬಿರ್ಗರ್ ತನ್ನ ಸ್ವಂತ ಕಥೆಯನ್ನು ಸ್ಪಷ್ಟ ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಹೇಳುತ್ತಾನೆ - Red Hat DevOps ತಂಡವು ಹ್ಯಾಟ್ ವರ್ಚುವಲೈಸೇಶನ್ ವರ್ಚುವಲ್ ಪರಿಸರದಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ಸ್ಥಳಾಂತರಿಸಿತು ಎಂಬುದನ್ನು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಕಂಟೈನರ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗೆ ಆನ್‌ಸಿಬಲ್ ನಿರ್ವಹಿಸುತ್ತದೆ OpenShift ವೇದಿಕೆ.

ಆದರೆ ಅದು ಅಷ್ಟಿಷ್ಟಲ್ಲ:

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

ಮೂಲ: www.habr.com

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