DevOps ನ ವ್ಯಾಖ್ಯಾನವು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಪ್ರತಿ ಬಾರಿಯೂ ಅದರ ಬಗ್ಗೆ ಮತ್ತೆ ಚರ್ಚೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು. ಹಬ್ರೆಯಲ್ಲಿ ಮಾತ್ರ ಈ ವಿಷಯದ ಕುರಿತು ಸಾವಿರ ಪ್ರಕಟಣೆಗಳಿವೆ. ಆದರೆ ನೀವು ಇದನ್ನು ಓದುತ್ತಿದ್ದರೆ, DevOps ಎಂದರೇನು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರಬಹುದು. ಏಕೆಂದರೆ ನಾನು ಅಲ್ಲ. ನಮಸ್ಕಾರ ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಾಂಡರ್ ಟಿಟೊವ್ (@), ಮತ್ತು ನಾವು DevOps ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು ನಾನು ನನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ.
ನನ್ನ ಕಥೆಯನ್ನು ಹೇಗೆ ಉಪಯುಕ್ತವಾಗಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನಾನು ಬಹಳ ಸಮಯದಿಂದ ಯೋಚಿಸುತ್ತಿದ್ದೇನೆ, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಬಹಳಷ್ಟು ಪ್ರಶ್ನೆಗಳಿವೆ - ನಾನು ನನ್ನನ್ನು ಕೇಳಿಕೊಳ್ಳುವ ಮತ್ತು ನಮ್ಮ ಕಂಪನಿಯ ಗ್ರಾಹಕರಿಗೆ ನಾನು ಕೇಳುವ ಪ್ರಶ್ನೆಗಳು. ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವ ಮೂಲಕ, ತಿಳುವಳಿಕೆ ಉತ್ತಮವಾಗುತ್ತದೆ. ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ DevOps ಏಕೆ ಬೇಕು, ಮತ್ತೊಮ್ಮೆ, ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಅದು ಏನು ಮತ್ತು ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನೀವು ಮತ್ತೆ DevOps ಕಡೆಗೆ ಚಲಿಸುತ್ತಿರುವಿರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಕೊನೆಯ ಅಂಶವು ಪ್ರಶ್ನೆಗಳ ಮೂಲಕ ಇರುತ್ತದೆ. ಅವರಿಗೆ ನೀವೇ ಉತ್ತರಿಸುವ ಮೂಲಕ, ನಿಮ್ಮ ಕಂಪನಿ DevOps ಕಡೆಗೆ ಚಲಿಸುತ್ತಿದೆಯೇ ಅಥವಾ ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆಯೇ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಒಂದು ಸಮಯದಲ್ಲಿ ನಾನು ವಿಲೀನಗಳು ಮತ್ತು ಸ್ವಾಧೀನಗಳ ಅಲೆಗಳ ಮೇಲೆ ಸವಾರಿ ಮಾಡುತ್ತಿದ್ದೆ. ಮೊದಲಿಗೆ, ನಾನು ಕಿಕ್ ಎಂಬ ಸಣ್ಣ ಪ್ರಾರಂಭಕ್ಕಾಗಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ, ನಂತರ ಅದನ್ನು ಸ್ವಲ್ಪ ದೊಡ್ಡದಾದ ಸ್ಕೈಪ್ ಕಂಪನಿ ಖರೀದಿಸಿತು, ನಂತರ ಅದನ್ನು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಎಂಬ ಸ್ವಲ್ಪ ದೊಡ್ಡ ಕಂಪನಿ ಖರೀದಿಸಿತು. ಆ ಕ್ಷಣದಲ್ಲಿ, ವಿವಿಧ ಗಾತ್ರದ ಕಂಪನಿಗಳಲ್ಲಿ DevOps ಕಲ್ಪನೆಯು ಹೇಗೆ ರೂಪಾಂತರಗೊಳ್ಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಾನು ನೋಡಲಾರಂಭಿಸಿದೆ. ಅದರ ನಂತರ, ನಾನು DevOps ಅನ್ನು ಮಾರುಕಟ್ಟೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡಲು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ ಮತ್ತು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳು ಮತ್ತು ನಾನು ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42 ಕಂಪನಿಯನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ. 6 ವರ್ಷಗಳಿಂದ ನಾವು ಮಾರುಕಟ್ಟೆಯ ಅಲೆಗಳ ಉದ್ದಕ್ಕೂ ಚಲಿಸುತ್ತಿದ್ದೇವೆ.
ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ನಾನು DevOps ಮಾಸ್ಕೋ ಸಮುದಾಯದ ಸಂಘಟಕರಲ್ಲಿ ಒಬ್ಬ ಮತ್ತು DevOps-Days 2017 ರ ಸಂಘಟಕನಾಗಿದ್ದೇನೆ, ಆದರೆ ನಾನು 2018 ಅನ್ನು ಸಂಘಟಿಸಲಿಲ್ಲ. ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42 ಅನೇಕ ಕಂಪನಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಾವು ಅಲ್ಲಿ DevOps ಅನ್ನು ಬೆಳೆಸುತ್ತೇವೆ, ಅದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವೀಕ್ಷಿಸುತ್ತೇವೆ, ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ, ನಮ್ಮ ತೀರ್ಮಾನಗಳನ್ನು ಎಲ್ಲರಿಗೂ ತಿಳಿಸುತ್ತೇವೆ ಮತ್ತು DevOps ಅಭ್ಯಾಸಗಳಲ್ಲಿ ಜನರಿಗೆ ತರಬೇತಿ ನೀಡುತ್ತೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಈ ವಿಷಯದಲ್ಲಿ ನಮ್ಮ ಅನುಭವ ಮತ್ತು ಪರಿಣತಿಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ನಮ್ಮ ಕೈಲಾದಷ್ಟು ಮಾಡುತ್ತಿದ್ದೇವೆ.
ಏಕೆ DevOps
ಎಲ್ಲರನ್ನೂ ಸದಾ ಕಾಡುವ ಮೊದಲ ಪ್ರಶ್ನೆ - ಏಕೆ? DevOps ಕೇವಲ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅಥವಾ ಪ್ರತಿ ಕಂಪನಿಯು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಒಂದೇ ರೀತಿಯ ವಿಷಯ ಎಂದು ಅನೇಕ ಜನರು ಭಾವಿಸುತ್ತಾರೆ.
— ನಾವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಇದರರ್ಥ ನಾವು ಈಗಾಗಲೇ DevOps ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ವಿಷಯಗಳು ಏಕೆ ಬೇಕು? ಅವರು ವಿದೇಶದಲ್ಲಿ ಮೋಜು ಮಾಡುತ್ತಿದ್ದಾರೆ, ಆದರೆ ಅವರು ನಮ್ಮನ್ನು ಕೆಲಸ ಮಾಡದಂತೆ ತಡೆಯುತ್ತಿದ್ದಾರೆ!
ಸಮುದಾಯ ಮತ್ತು ವಿಧಾನದ ಅಭಿವೃದ್ಧಿಯ 9 ವರ್ಷಗಳಲ್ಲಿ, ಇದು ಇನ್ನೂ ಮಾರ್ಕೆಟಿಂಗ್ ಗ್ಲಿಟರ್ ಅಲ್ಲ ಎಂದು ಈಗಾಗಲೇ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ಇದು ಏಕೆ ಬೇಕು ಎಂಬುದು ಇನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಯಾವುದೇ ಸಾಧನ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಂತೆ, DevOps ನಿರ್ದಿಷ್ಟ ಗುರಿಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದು ಅಂತಿಮವಾಗಿ ಸಾಧಿಸುತ್ತದೆ.
ಜಗತ್ತು ಬದಲಾಗುತ್ತಿರುವುದೇ ಇದಕ್ಕೆಲ್ಲ ಕಾರಣ. ಅವರು ಎಂಟರ್‌ಪ್ರೈಸ್ ವಿಧಾನದಿಂದ ದೂರ ಸರಿಯುತ್ತಾರೆ, ಕಂಪನಿಗಳು ನೇರವಾಗಿ ಕನಸಿನ ಕಡೆಗೆ ಚಲಿಸಿದಾಗ, ನಮ್ಮ ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್ ಕ್ಲಾಸಿಕ್ ಹಾಡಿದಂತೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ತಂತ್ರದ ಪ್ರಕಾರ ಪಾಯಿಂಟ್ ಬಿ ವರೆಗೆ ಬಿ ವರೆಗೆ, ಇದಕ್ಕಾಗಿ ನಿರ್ಮಿಸಲಾದ ನಿರ್ದಿಷ್ಟ ರಚನೆಯೊಂದಿಗೆ.
ತಾತ್ವಿಕವಾಗಿ, ಐಟಿಯಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಈ ವಿಧಾನದ ಪ್ರಕಾರ ನಿರ್ಮಿಸಬೇಕು. ಇಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಐಟಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಆಗಾಗ್ಗೆ ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕಂಪನಿಯು ಚೆನ್ನಾಗಿ ಮೆಟ್ಟಿಲು ಹತ್ತಿದಾಗ, ಬದಲಾಯಿಸಲು ಏನಿದೆ? ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ - ಅದನ್ನು ಮುಟ್ಟಬೇಡಿ. ಈಗ ಪ್ರಪಂಚದ ವಿಧಾನಗಳು ಬದಲಾಗುತ್ತಿವೆ ಮತ್ತು ಅಗೈಲ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ಬಿಂದು ಬಿ ತಕ್ಷಣವೇ ಗೋಚರಿಸುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
ಕಂಪನಿಯು ಮಾರುಕಟ್ಟೆಯ ಮೂಲಕ ಹೋದಾಗ, ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಅದು ನಿರಂತರವಾಗಿ ಮಾರುಕಟ್ಟೆಯನ್ನು ಪರಿಶೋಧಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ ಬಿಂದುವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ B. ಇದಲ್ಲದೆ, ಕಂಪನಿಯು ಹೆಚ್ಚು ಬಾರಿ ತನ್ನ ದಿಕ್ಕನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಕೊನೆಯಲ್ಲಿ ಅದು ಹೆಚ್ಚು ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಹೆಚ್ಚು ಮಾರುಕಟ್ಟೆಯನ್ನು ಆರಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಗೂಡುಗಳು.
ನಾನು ಇತ್ತೀಚೆಗೆ ಕಲಿತ ಆಸಕ್ತಿದಾಯಕ ಕಂಪನಿಯಿಂದ ತಂತ್ರವನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗಿದೆ. ಒನ್ ಬಾಕ್ಸ್ ಶೇವ್ ಎನ್ನುವುದು ರೇಜರ್‌ಗಳಿಗೆ ಮತ್ತು ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಶೇವಿಂಗ್ ಬಿಡಿಭಾಗಗಳಿಗೆ ಚಂದಾದಾರಿಕೆ ವಿತರಣಾ ಸೇವೆಯಾಗಿದೆ. ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಿಗಾಗಿ ತಮ್ಮ "ಬಾಕ್ಸ್" ಅನ್ನು ಹೇಗೆ ಕಸ್ಟಮೈಸ್ ಮಾಡಬೇಕೆಂದು ಅವರಿಗೆ ತಿಳಿದಿದೆ. ಇದನ್ನು ನಿರ್ದಿಷ್ಟ ಸಾಫ್ಟ್ವೇರ್ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ, ಅದು ನಂತರ ಸರಕುಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಕೊರಿಯನ್ ಕಾರ್ಖಾನೆಗೆ ಆದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
ಈ ಉತ್ಪನ್ನವನ್ನು ಯೂನಿಲಿವರ್ $1 ಶತಕೋಟಿಗೆ ಖರೀದಿಸಿತು. ಇದು ಈಗ ಜಿಲೆಟ್‌ನೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸುತ್ತದೆ ಮತ್ತು ಅಮೆರಿಕನ್ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಗ್ರಾಹಕರ ಗಮನಾರ್ಹ ಪಾಲನ್ನು ತೆಗೆದುಕೊಂಡಿದೆ. ಒಂದು ಬಾಕ್ಸ್ ಶೇವ್ ಹೇಳುತ್ತಾರೆ:
- 4 ಬ್ಲೇಡ್ಗಳು? ನೀವು ಗಂಭೀರವಾಗಿರುತ್ತೀರಾ? ನಿಮಗೆ ಇದು ಏಕೆ ಬೇಕು - ಇದು ಕ್ಷೌರದ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸುವುದಿಲ್ಲ. ವಿಶೇಷವಾಗಿ ಆಯ್ಕೆಮಾಡಿದ ಕೆನೆ, ಸುಗಂಧ ಮತ್ತು ಎರಡು ಬ್ಲೇಡ್‌ಗಳೊಂದಿಗೆ ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ರೇಜರ್ ಆ ಮೂರ್ಖ 4 ಜಿಲೆಟ್ ಬ್ಲೇಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ! ನಾವು ಶೀಘ್ರದಲ್ಲೇ 10 ಅನ್ನು ಪಡೆಯುತ್ತೇವೆಯೇ?
ಜಗತ್ತು ಬದಲಾಗುವುದು ಹೀಗೆ. ಯೂನಿಲಿವರ್ ಅವರು ತಂಪಾದ ಐಟಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದು ಅದು ನಿಮಗೆ ಇದನ್ನು ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಕೊನೆಯಲ್ಲಿ ಇದು ಪರಿಕಲ್ಪನೆಯಂತೆ ಕಾಣುತ್ತದೆ ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಗೆ, ಯಾರೂ ಈಗಾಗಲೇ ಮಾತನಾಡಿಲ್ಲ.
ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಗೆ ನಾವು ಎಷ್ಟು ಬಾರಿ ನಿಯೋಜಿಸುತ್ತೇವೆ ಎಂಬುದು ಅಲ್ಲ. ನೀವು ಆಗಾಗ್ಗೆ ನಿಯೋಜಿಸಬಹುದು, ಆದರೆ ಬಿಡುಗಡೆಯ ಚಕ್ರಗಳು ದೀರ್ಘವಾಗಿರುತ್ತದೆ. ಮೂರು-ತಿಂಗಳ ಬಿಡುಗಡೆಯ ಚಕ್ರಗಳನ್ನು ಒಂದರ ಮೇಲೊಂದು ಜೋಡಿಸಿದರೆ, ಅವುಗಳನ್ನು ಒಂದು ವಾರದವರೆಗೆ ಬದಲಾಯಿಸಿದರೆ, ಕಂಪನಿಯು ವಾರಕ್ಕೊಮ್ಮೆ ನಿಯೋಜಿಸುತ್ತಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಮತ್ತು ಕಲ್ಪನೆಯಿಂದ ಅಂತಿಮ ಅನುಷ್ಠಾನಕ್ಕೆ ಇದು 3 ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಟೈಮ್-ಟು-ಮಾರ್ಕೆಟ್ ಎನ್ನುವುದು ಕಲ್ಪನೆಯಿಂದ ಅಂತಿಮ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಾಫ್ಟ್ವೇರ್ ಮಾರುಕಟ್ಟೆಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಒನ್ ಬಾಕ್ಸ್ ಶೇವ್ ವೆಬ್‌ಸೈಟ್ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಅವರು ಮಾರಾಟಗಾರರನ್ನು ಹೊಂದಿಲ್ಲ - ಸಂದರ್ಶಕರು ಕ್ಲಿಕ್ ಮಾಡಿ ಮತ್ತು ಶುಭಾಶಯಗಳನ್ನು ಬಿಡುವ ವೆಬ್‌ಸೈಟ್. ಅಂತೆಯೇ, ಹೊಸದನ್ನು ನಿರಂತರವಾಗಿ ಸೈಟ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಬೇಕು ಮತ್ತು ಶುಭಾಶಯಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ನವೀಕರಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ದಕ್ಷಿಣ ಕೊರಿಯಾದಲ್ಲಿ ಅವರು ರಷ್ಯಾಕ್ಕಿಂತ ವಿಭಿನ್ನವಾಗಿ ಕ್ಷೌರ ಮಾಡುತ್ತಾರೆ, ಮತ್ತು ಅವರು ಪೈನ್‌ನ ಪರಿಮಳವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಆದರೆ, ಉದಾಹರಣೆಗೆ, ಕ್ಯಾರೆಟ್ ಮತ್ತು ವೆನಿಲ್ಲಾ.
ಸೈಟ್ನ ವಿಷಯವನ್ನು ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ ಕಾರಣ, ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯು ಮಹತ್ತರವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಸಾಫ್ಟ್ವೇರ್ ಮೂಲಕ ನಾವು ಕ್ಲೈಂಟ್ ಏನು ಬಯಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ಹಿಂದೆ, ನಾವು ಇದನ್ನು ಕೆಲವು ಸುತ್ತಿನ ಮಾರ್ಗಗಳ ಮೂಲಕ ಕಲಿತಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ, ವ್ಯಾಪಾರ ನಿರ್ವಹಣೆಯ ಮೂಲಕ. ನಂತರ ನಾವು ಅದನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ, ಐಟಿ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ತಂಪಾಗಿದೆ. ಈಗ ಇದು ವಿಭಿನ್ನವಾಗಿದೆ - ಎಂಜಿನಿಯರ್‌ಗಳು ಸೇರಿದಂತೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದಾರೆ, ಏಕೆಂದರೆ ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಮೂಲಕ ಅವರು ಮಾರುಕಟ್ಟೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಲಿಯುತ್ತಾರೆ ಮತ್ತು ವ್ಯಾಪಾರದೊಂದಿಗೆ ತಮ್ಮ ಒಳನೋಟಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ.
ಉದಾಹರಣೆಗೆ, ಕ್ವಿಕ್‌ನಲ್ಲಿ ಜನರು ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕ ಪಟ್ಟಿಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಟ್ಟಿದ್ದಾರೆ ಎಂದು ನಾವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ತಿಳಿದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಅವರು ನಮಗೆ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸರಬರಾಜು ಮಾಡಿದರು. ಆರಂಭದಲ್ಲಿ ನಾವು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಲಿಲ್ಲ. ಕ್ಲಾಸಿಕ್ ಕಂಪನಿಯಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಇದು ದೋಷ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಿದ್ದರು, ಏಕೆಂದರೆ ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಮೊಣಕಾಲಿನ ಮೇಲೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂದು ಸ್ಪೆಕ್ ಹೇಳಲಿಲ್ಲ, ಅವರು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಆಫ್ ಮಾಡಿ ಮತ್ತು ಹೀಗೆ ಹೇಳಿದರು: “ಯಾರಿಗೂ ಇದು ಅಗತ್ಯವಿಲ್ಲ, ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಮುಖ್ಯ ಕಾರ್ಯವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ” ಮತ್ತು ತಂತ್ರಜ್ಞಾನ ಕಂಪನಿಯು ಇದನ್ನು ಅವಕಾಶವಾಗಿ ನೋಡುತ್ತದೆ ಮತ್ತು ಇದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
1968 ರಲ್ಲಿ, ಒಬ್ಬ ದಾರ್ಶನಿಕ ವ್ಯಕ್ತಿ, ಮೆಲ್ವಿನ್ ಕಾನ್ವೇ, ಈ ಕೆಳಗಿನ ಕಲ್ಪನೆಯನ್ನು ರೂಪಿಸಿದರು.
ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವ ಸಂಸ್ಥೆಯು ಆ ಸಂಸ್ಥೆಯ ಸಂವಹನ ರಚನೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವ ವಿನ್ಯಾಸದಿಂದ ನಿರ್ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ.
ಹೆಚ್ಚು ವಿವರವಾಗಿ, ವಿಭಿನ್ನ ಪ್ರಕಾರದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಉತ್ಪಾದಿಸಲು, ನೀವು ಬೇರೆ ರೀತಿಯ ಕಂಪನಿಯೊಳಗೆ ಸಂವಹನ ರಚನೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ನಿಮ್ಮ ಸಂವಹನ ರಚನೆಯು ಉನ್ನತ-ಶ್ರೇಣೀಕೃತವಾಗಿದ್ದರೆ, ಇದು ಹೆಚ್ಚಿನ ಸಮಯ-ಮಾರುಕಟ್ಟೆ ಸೂಚಕವನ್ನು ಒದಗಿಸುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ.
ಓದು ಮಾಡಬಹುದು . DevOps ಸಂಸ್ಕೃತಿ ಅಥವಾ ತತ್ವಶಾಸ್ತ್ರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ DevOps ನಲ್ಲಿ ಮೂಲಭೂತವಾಗಿ ಬದಲಾಗುವ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ತಂಡಗಳ ನಡುವಿನ ಸಂವಹನದ ರಚನೆ.
ಪ್ರಕ್ರಿಯೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ, DevOps ಮೊದಲು, ಎಲ್ಲಾ ಹಂತಗಳು: ವಿಶ್ಲೇಷಣೆ, ಅಭಿವೃದ್ಧಿ, ಪರೀಕ್ಷೆ, ಕಾರ್ಯಾಚರಣೆ, ರೇಖಾತ್ಮಕವಾಗಿತ್ತು.
DevOps ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳು ಏಕಕಾಲದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.
ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಗೆ ಮಾತ್ರ ಇದನ್ನು ಮಾಡಬಹುದಾಗಿದೆ. ಹಳೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಜನರಿಗೆ, ಇದು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಕಾಸ್ಮಿಕ್ ಆಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಹಾಗೆ.
ಹಾಗಾದರೆ ನಿಮಗೆ DevOps ಏಕೆ ಬೇಕು?
ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಗಾಗಿ. ನಿಮ್ಮ ಕಂಪನಿಯು ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, DevOps ಅಗತ್ಯವಿಲ್ಲ - ಇದು ತುಂಬಾ ಮುಖ್ಯವಾಗಿದೆ.
DevOps ಅನುಕ್ರಮ ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪಾದನೆಯ ವೇಗ ಮಿತಿಗಳನ್ನು ಮೀರಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳು ಏಕಕಾಲದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.
ಕಷ್ಟ ಹೆಚ್ಚಾಗುತ್ತದೆ. DevOps ಸುವಾರ್ತಾಬೋಧಕರು ನಿಮಗೆ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಇದು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಎಂದು ಹೇಳಿದಾಗ, ಇದು ಅಸಂಬದ್ಧವಾಗಿದೆ.
DevOps ನೊಂದಿಗೆ, ವಿಷಯಗಳು ಹೆಚ್ಚು ಜಟಿಲವಾಗುತ್ತವೆ.
ಅವಿಟೊ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ನಡೆದ ಸಮ್ಮೇಳನದಲ್ಲಿ, ಡಾಕರ್ ಕಂಟೇನರ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಹೇಗೆ ಎಂದು ನೀವು ನೋಡಬಹುದು - ಇದು ಅವಾಸ್ತವಿಕ ಕಾರ್ಯ. ಸಂಕೀರ್ಣತೆಯು ನಿಷೇಧಿತವಾಗುತ್ತದೆ; ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅನೇಕ ಚೆಂಡುಗಳನ್ನು ಕಣ್ಕಟ್ಟು ಮಾಡಬೇಕಾಗುತ್ತದೆ.
DevOps ಕಂಪನಿಯಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಸಂಘಟನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ - ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಇದು ಬದಲಾಗುವುದು DevOps ಅಲ್ಲ, ಆದರೆ ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನವಾಗಿದೆ. DevOps ಗೆ ಬರಲು, ನೀವು ಇನ್ನೂ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ.
ತಜ್ಞರಿಗೆ ಪ್ರಶ್ನೆಗಳು
ನಿಮ್ಮ ಬಳಿ ಏನು ಇದೆ? ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಮತ್ತು ತಜ್ಞರಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವಾಗ ನೀವೇ ಕೇಳಿಕೊಳ್ಳಬಹುದಾದ ಪ್ರಶ್ನೆಗಳು.
ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸಲು ನೀವು ತಂತ್ರವನ್ನು ಹೊಂದಿದ್ದೀರಾ? ಇದ್ದರೆ, ಅದು ಈಗಾಗಲೇ ಒಳ್ಳೆಯದು. ಇದರರ್ಥ ನಿಮ್ಮ ಕಂಪನಿಯು DevOps ಕಡೆಗೆ ಚಲಿಸುತ್ತಿದೆ.
ನಿಮ್ಮ ಕಂಪನಿಯು ಈಗಾಗಲೇ ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸುತ್ತಿದೆಯೇ? ಇದರರ್ಥ ನೀವು ಇನ್ನೊಂದು ಹಂತವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿ ಕೆಲಸಗಳನ್ನು ಮಾಡಬಹುದು - ಮತ್ತೊಮ್ಮೆ DevOps ದೃಷ್ಟಿಕೋನದಿಂದ. ನಾನು ಈ ದೃಷ್ಟಿಕೋನದಿಂದ ಮಾತ್ರ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ.
ನಿಮ್ಮ ಕಂಪನಿಯು ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನ ಸ್ಥಾಪಿತ ಮಾರುಕಟ್ಟೆಯ ನಾಯಕರಲ್ಲಿ ಒಬ್ಬರೇ? Spotify, Yandex, Uber ಈಗ ತಾಂತ್ರಿಕ ಪ್ರಗತಿಯ ಉತ್ತುಂಗದಲ್ಲಿರುವ ಕಂಪನಿಗಳಾಗಿವೆ.
ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ ಮತ್ತು ಎಲ್ಲಾ ಉತ್ತರಗಳು ಇಲ್ಲ ಎಂದಾದರೆ, ಬಹುಶಃ ನೀವು ಈ ಕಂಪನಿಯಲ್ಲಿ DevOps ಅನ್ನು ಮಾಡಬಾರದು. DevOps ವಿಷಯವು ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಆಸಕ್ತಿದಾಯಕವಾಗಿದ್ದರೆ, ಬಹುಶಃ... ನೀವು ಇನ್ನೊಂದು ಕಂಪನಿಗೆ ಹೋಗಬೇಕೇ? ನಿಮ್ಮ ಕಂಪನಿ DevOps ಗೆ ಹೋಗಲು ಬಯಸಿದರೆ, ಆದರೆ ನೀವು ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳಿಗೆ "ಇಲ್ಲ" ಎಂದು ಉತ್ತರಿಸಿದರೆ, ಅದು ಎಂದಿಗೂ ಬದಲಾಗದ ಸುಂದರ ಘೇಂಡಾಮೃಗದಂತಿದೆ.
ಸಂಸ್ಥೆಯ
ನಾನು ಹೇಳಿದಂತೆ, ಕಾನ್ವೇಯ ಕಾನೂನಿನ ಪ್ರಕಾರ, ಕಂಪನಿಯ ಸಂಘಟನೆಯು ಬದಲಾಗುತ್ತದೆ. ಸಾಂಸ್ಥಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ ಕಂಪನಿಯೊಳಗೆ DevOps ನುಸುಳುವುದನ್ನು ತಡೆಯುವುದನ್ನು ನಾನು ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ.
"ಬಾವಿಗಳ" ಸಮಸ್ಯೆ
ಇಂಗ್ಲಿಷ್ ಪದ "ಸಿಲೋ" ಅನ್ನು ಇಲ್ಲಿ ರಷ್ಯನ್ ಭಾಷೆಗೆ "ವೆಲ್" ಎಂದು ಅನುವಾದಿಸಲಾಗಿದೆ. ಈ ಸಮಸ್ಯೆಯ ಅಂಶವೆಂದರೆ ಅದು ತಂಡಗಳ ನಡುವೆ ಯಾವುದೇ ಮಾಹಿತಿ ವಿನಿಮಯವಿಲ್ಲ. ಪ್ರತಿ ತಂಡವು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ಸಾಮಾನ್ಯ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸದೆ ಅದರ ಪರಿಣತಿಯನ್ನು ಆಳವಾಗಿ ಅಗೆಯುತ್ತದೆ.
ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಇದು ಮಾಸ್ಕೋಗೆ ಬಂದ ವ್ಯಕ್ತಿಯನ್ನು ನೆನಪಿಸುತ್ತದೆ ಮತ್ತು ಮೆಟ್ರೋ ನಕ್ಷೆಯನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ. ಮಸ್ಕೋವೈಟ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಪ್ರದೇಶವನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಮಾಸ್ಕೋದಾದ್ಯಂತ ಅವರು ಮೆಟ್ರೋ ನಕ್ಷೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಬಹುದು. ನೀವು ಮೊದಲ ಬಾರಿಗೆ ಮಾಸ್ಕೋಗೆ ಬಂದಾಗ, ನೀವು ಈ ಕೌಶಲ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ನೀವು ಕೇವಲ ದಿಗ್ಭ್ರಮೆಗೊಂಡಿದ್ದೀರಿ.
ಈ ದಿಗ್ಭ್ರಮೆಯ ಕ್ಷಣದಿಂದ ಹೊರಬರಲು DevOps ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಸಂವಾದ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸಲು ಎಲ್ಲಾ ವಿಭಾಗಗಳು ಒಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
ಎರಡು ಅಂಶಗಳು ಇದಕ್ಕೆ ಅಡ್ಡಿಯಾಗುತ್ತವೆ.
ಕಾರ್ಪೊರೇಟ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯ ಪರಿಣಾಮ. ಇದನ್ನು ಪ್ರತ್ಯೇಕ ಕ್ರಮಾನುಗತ "ಬಾವಿಗಳಲ್ಲಿ" ನಿರ್ಮಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಕಂಪನಿಗಳಲ್ಲಿ ಕೆಲವು KPI ಗಳು ಇವೆ. ಮತ್ತೊಂದೆಡೆ, ತಮ್ಮ ಪರಿಣತಿಯ ಗಡಿಗಳನ್ನು ಮೀರಿ ಹೋಗಲು ಮತ್ತು ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ಕಷ್ಟಪಡುವ ವ್ಯಕ್ತಿಯ ಮೆದುಳು ದಾರಿಯಲ್ಲಿ ಸಿಗುತ್ತದೆ. ಇದು ಕೇವಲ ಅಹಿತಕರವಾಗಿದೆ. ನೀವು ಬ್ಯಾಂಕಾಕ್ ವಿಮಾನ ನಿಲ್ದಾಣದಲ್ಲಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ - ನೀವು ಬೇಗನೆ ನಿಮ್ಮ ದಾರಿಯನ್ನು ಕಂಡುಕೊಳ್ಳುವುದಿಲ್ಲ. DevOps ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವುದು ಸಹ ಕಷ್ಟ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಜನರು ಅಲ್ಲಿಗೆ ಹೋಗಲು ನೀವು ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಎಂದು ಹೇಳುತ್ತಾರೆ.
ಆದರೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ, ಡೆವೊಪ್ಸ್‌ನ ಉತ್ಸಾಹದಿಂದ ತುಂಬಿರುವ, ಫೌಲರ್ ಮತ್ತು ಇತರ ಪುಸ್ತಕಗಳ ಗುಂಪನ್ನು ಓದಿರುವ ಎಂಜಿನಿಯರ್‌ಗೆ “ಬಾವಿಗಳ” ಸಮಸ್ಯೆ ವ್ಯಕ್ತವಾಗುತ್ತದೆ. "ಬಾವಿಗಳು" ನಿಮಗೆ "ಸ್ಪಷ್ಟ" ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. DevOps ಮಾಸ್ಕೋದ ನಂತರ ನಾವು ಆಗಾಗ್ಗೆ ಒಟ್ಟಿಗೆ ಸೇರುತ್ತೇವೆ, ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು ಜನರು ದೂರು ನೀಡುತ್ತಾರೆ:
- ನಾವು CI ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಯಸಿದ್ದೇವೆ, ಆದರೆ ನಿರ್ವಹಣೆಗೆ ಇದು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು.
ಇದು ನಿಖರವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ ಏಕೆಂದರೆ CI и ನಿರಂತರ ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆ ಅನೇಕ ಪರೀಕ್ಷೆಗಳ ಗಡಿಯಲ್ಲಿವೆ. ಸಾಂಸ್ಥಿಕ ಮಟ್ಟದಲ್ಲಿ "ಬಾವಿಗಳ" ಸಮಸ್ಯೆಯನ್ನು ಸರಳವಾಗಿ ನಿವಾರಿಸದೆ, ನೀವು ಏನು ಮಾಡಿದರೂ ಮತ್ತು ಎಷ್ಟೇ ದುಃಖವಾಗಿದ್ದರೂ ನೀವು ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಕಂಪನಿಯಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಪ್ರತಿಯೊಬ್ಬರು: ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗದ ಡೆವಲಪರ್‌ಗಳು, ಪರೀಕ್ಷೆ, ಡಿಬಿಎ, ಕಾರ್ಯಾಚರಣೆ, ನೆಟ್‌ವರ್ಕ್, ತಮ್ಮದೇ ಆದ ದಿಕ್ಕಿನಲ್ಲಿ ಅಗೆಯುತ್ತಾರೆ ಮತ್ತು ನಿರ್ವಾಹಕರನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾರೂ ಸಾಮಾನ್ಯ ನಕ್ಷೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಅವರು ಹೇಗಾದರೂ ಅವರನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು "ವಿಭಜನೆ" ಬಳಸಿ ನಿರ್ವಹಿಸುತ್ತಾರೆ. ಮತ್ತು ವಶಪಡಿಸಿಕೊಳ್ಳಲು" ವಿಧಾನ.
ಜನರು ಕೆಲವು ನಕ್ಷತ್ರಗಳು ಅಥವಾ ಧ್ವಜಗಳಿಗಾಗಿ ಹೋರಾಡುತ್ತಿದ್ದಾರೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮ ಪರಿಣತಿಯನ್ನು ಅಗೆಯುತ್ತಿದ್ದಾರೆ.
ಪರಿಣಾಮವಾಗಿ, ಈ ಎಲ್ಲವನ್ನು ಒಟ್ಟಿಗೆ ಸಂಪರ್ಕಿಸುವ ಮತ್ತು ಸಾಮಾನ್ಯ ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಕಾರ್ಯವು ಉದ್ಭವಿಸಿದಾಗ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ನಕ್ಷತ್ರಗಳು ಮತ್ತು ಧ್ವಜಗಳಿಗಾಗಿ ಹೋರಾಡುವ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ - ಹೇಗಾದರೂ ಏನು ಮಾಡಬೇಕು? ನಾವು ಹೇಗಾದರೂ ಒಪ್ಪಂದಕ್ಕೆ ಬರಬೇಕು, ಆದರೆ ಶಾಲೆಯಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಯಾರೂ ನಮಗೆ ಕಲಿಸಲಿಲ್ಲ. ಶಾಲೆಯಿಂದ ನಮಗೆ ಕಲಿಸಲಾಗಿದೆ: ಎಂಟನೇ ತರಗತಿ - ವಾಹ್! - ಏಳನೇ ತರಗತಿಗೆ ಹೋಲಿಸಿದರೆ! ಇಲ್ಲಿಯೂ ಹಾಗೆಯೇ.
ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿಯೂ ಇದೇ ಆಗಿದೆಯೇ?
ಇದನ್ನು ಪರಿಶೀಲಿಸಲು, ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು.
ತಂಡಗಳು ಸಾಮಾನ್ಯ ಪರಿಕರಗಳನ್ನು ಬಳಸುತ್ತವೆಯೇ ಮತ್ತು ಆ ಸಾಮಾನ್ಯ ಪರಿಕರಗಳಿಗೆ ಬದಲಾವಣೆಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡುತ್ತವೆಯೇ?
ಎಷ್ಟು ಬಾರಿ ತಂಡಗಳು ಮರುಸಂಘಟಿಸುತ್ತವೆ-ಒಂದು ತಂಡದಿಂದ ಕೆಲವು ತಜ್ಞರು ಇನ್ನೊಂದು ತಂಡಕ್ಕೆ ತೆರಳುತ್ತಾರೆ? DevOps ಪರಿಸರದಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕೆಲವೊಮ್ಮೆ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಪರಿಣತಿಯ ಮತ್ತೊಂದು ಕ್ಷೇತ್ರ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅವರು ಮತ್ತೊಂದು ವಿಭಾಗಕ್ಕೆ ತೆರಳುತ್ತಾರೆ, ಈ ಇಲಾಖೆಯೊಂದಿಗೆ ದೃಷ್ಟಿಕೋನ ಮತ್ತು ಸಂವಹನದ ನಕ್ಷೆಯನ್ನು ಸ್ವತಃ ರಚಿಸಲು ಎರಡು ವಾರಗಳ ಕಾಲ ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಬದಲಾವಣೆ ಸಮಿತಿಯನ್ನು ರಚಿಸಿ ವಿಷಯಗಳನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವೇ? ಅಥವಾ ಇದಕ್ಕೆ ಉನ್ನತ ನಿರ್ವಹಣೆ ಮತ್ತು ನಿರ್ದೇಶನದ ಬಲವಾದ ಕೈ ಅಗತ್ಯವಿದೆಯೇ? ನಾನು ಇತ್ತೀಚೆಗೆ ಫೇಸ್‌ಬುಕ್‌ನಲ್ಲಿ ಬರೆದಿದ್ದೇನೆ, ಕಡಿಮೆ-ಪ್ರಸಿದ್ಧ ಬ್ಯಾಂಕ್ ಆದೇಶಗಳ ಮೂಲಕ ಸಾಧನಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದೆ: ನಾವು ಆದೇಶವನ್ನು ಬರೆಯುತ್ತೇವೆ, ನಾವು ಅದನ್ನು ಒಂದು ವರ್ಷದವರೆಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡುತ್ತೇವೆ. ಇದು ಸಹಜವಾಗಿ ದೀರ್ಘ ಮತ್ತು ದುಃಖಕರವಾಗಿದೆ.
ಕಂಪನಿಯ ಸಾಧನೆಗಳನ್ನು ಪರಿಗಣಿಸದೆ ವೈಯಕ್ತಿಕ ಸಾಧನೆಗಳನ್ನು ಪಡೆಯುವುದು ವ್ಯವಸ್ಥಾಪಕರಿಗೆ ಎಷ್ಟು ಮುಖ್ಯ?
ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ನೀವೇ ಉತ್ತರಿಸಿದರೆ, ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಅಂತಹ ಸಮಸ್ಯೆ ಇದೆಯೇ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ
ಈ ಸಮಸ್ಯೆಯನ್ನು ಅಂಗೀಕರಿಸಿದ ನಂತರ, ಮೊದಲ ಪ್ರಮುಖ ಅಭ್ಯಾಸ, ಇದು ಇಲ್ಲದೆ DevOps ನಲ್ಲಿ ಮತ್ತಷ್ಟು ಮುಂದುವರಿಯುವುದು ಕಷ್ಟ ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ.
ಹೆಚ್ಚಾಗಿ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ಆಗಿ ಈ ಕೆಳಗಿನಂತೆ ಗ್ರಹಿಸಲಾಗುತ್ತದೆ:
— ಬ್ಯಾಷ್‌ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸೋಣ, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ನಮ್ಮನ್ನು ಆವರಿಸಿಕೊಳ್ಳೋಣ ಇದರಿಂದ ನಿರ್ವಾಹಕರು ಕಡಿಮೆ ಕೈಯಿಂದ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ!
ಆದರೆ ಅದು ನಿಜವಲ್ಲ.
ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ ಎಂದರೆ ಅದರ ಸ್ಥಿತಿಯನ್ನು ನಿರಂತರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನೀವು ಕೆಲಸ ಮಾಡುವ ಐಟಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಕೋಡ್‌ನ ರೂಪದಲ್ಲಿ ವಿವರಿಸುತ್ತೀರಿ.
ಇತರ ತಂಡಗಳೊಂದಿಗೆ, ನೀವು ಪ್ರತಿಯೊಬ್ಬರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದಾದ ಮತ್ತು ನ್ಯಾವಿಗೇಟ್ ಮತ್ತು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಬಹುದಾದ ಕೋಡ್ ರೂಪದಲ್ಲಿ ನಕ್ಷೆಯನ್ನು ರಚಿಸುತ್ತೀರಿ. ಇದು ಏನು ಮಾಡಲ್ಪಟ್ಟಿದೆ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ - ಬಾಣಸಿಗ, ಅನ್ಸಿಬಲ್, ಉಪ್ಪು, ಅಥವಾ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ YAML ಫೈಲ್‌ಗಳನ್ನು ಬಳಸುವುದು - ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ.
ಸಮ್ಮೇಳನದಲ್ಲಿ, 2GIS ನ ಸಹೋದ್ಯೋಗಿ ಅವರು ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ ತಮ್ಮ ಆಂತರಿಕ ವಿಷಯವನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದಾರೆಂದು ಹೇಳಿದರು, ಇದು ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳ ರಚನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. 500 ಸಿಸ್ಟಂಗಳನ್ನು ವಿವರಿಸಲು, ಅವರಿಗೆ ಈ ವಿವರಣೆಯನ್ನು ಉತ್ಪಾದಿಸುವ ಪ್ರತ್ಯೇಕ ಉಪಕರಣದ ಅಗತ್ಯವಿದೆ. ಈ ವಿವರಣೆಯು ಇದ್ದಾಗ, ಪ್ರತಿಯೊಬ್ಬರೂ ಪರಸ್ಪರ ಪರಿಶೀಲಿಸಬಹುದು, ಬದಲಾವಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ಅದನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಸುಧಾರಿಸುವುದು, ಏನು ಕಾಣೆಯಾಗಿದೆ.
ಒಪ್ಪಿಕೊಳ್ಳಿ, ವೈಯಕ್ತಿಕ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಈ ತಿಳುವಳಿಕೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ನಾನು ಕೆಲಸ ಮಾಡಿದ ಕಂಪನಿಯೊಂದರಲ್ಲಿ, "ಬರೆಯಲು ಮಾತ್ರ" ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಹೆಸರೂ ಇತ್ತು - ಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯುವಾಗ, ಆದರೆ ಅದನ್ನು ಓದಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಇದು ನಿಮಗೂ ಪರಿಚಿತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ ಮೂಲಸೌಕರ್ಯದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸುವ ಕೋಡ್. ಅನೇಕ ಉತ್ಪನ್ನ, ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಸೇವಾ ತಂಡಗಳು ಈ ಕೋಡ್‌ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಈ ಕೋಡ್ ನಿಜವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವರೆಲ್ಲರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಉತ್ತಮ ಕೋಡ್ ಅಭ್ಯಾಸಗಳ ಪ್ರಕಾರ ಕೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ: ಜಂಟಿ ಅಭಿವೃದ್ಧಿ, ಕೋಡ್ ವಿಮರ್ಶೆ, XP- ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಪರೀಕ್ಷೆ, ಪುಲ್ ವಿನಂತಿಗಳು, ಕೋಡ್ ಮೂಲಸೌಕರ್ಯಗಳಿಗಾಗಿ CI - ಇವೆಲ್ಲವೂ ಸೂಕ್ತವಾಗಿದೆ ಮತ್ತು ಬಳಸಬಹುದು.
ಕೋಡ್ ಎಲ್ಲಾ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯ ಭಾಷೆಯಾಗುತ್ತದೆ.
ಕೋಡ್‌ನಲ್ಲಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬದಲಾಯಿಸುವುದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಹೌದು, ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಸಹ ಹೊಂದಿರಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ತಂಡಗಳು "ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ಆಗಿ" ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ಒಂದೂವರೆ ವರ್ಷದ ನಂತರ ಅದನ್ನು ಎದುರಿಸುತ್ತಾರೆ, ಅವರು ಸ್ಪಾಗೆಟ್ಟಿ ಕೋಡ್‌ನಂತೆ ಬರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ರೂಪದಲ್ಲಿ ಅಥವಾ ಅನ್ಸಿಬಲ್ ರೂಪದಲ್ಲಿ, ಮತ್ತು ಅವರು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಮಿಶ್ರಣಕ್ಕೆ ಎಸೆಯುತ್ತಾರೆ!
ಪ್ರಮುಖ: ನೀವು ಇನ್ನೂ ಈ ವಿಷಯವನ್ನು ಪ್ರಯತ್ನಿಸದಿದ್ದರೆ, ಅದನ್ನು ನೆನಪಿಡಿ ಅನ್ಸಿಬಲ್ ಬ್ಯಾಷ್ ಅಲ್ಲ! ದಸ್ತಾವೇಜನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಿ, ಅವರು ಅದರ ಬಗ್ಗೆ ಏನು ಬರೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ.
ಮೂಲಸೌಕರ್ಯವು ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಪದರಗಳಾಗಿ ಬೇರ್ಪಡಿಸುವುದು.
ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ, ನಾವು 3 ಮೂಲಭೂತ ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ, ಅದು ತುಂಬಾ ಸ್ಪಷ್ಟ ಮತ್ತು ಸರಳವಾಗಿದೆ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಇರಬಹುದು. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಅನ್ನು ನೀವು ನೋಡಬಹುದು ಮತ್ತು ನೀವು ಈ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿದ್ದೀರಾ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ಹೇಳಬಹುದು. ಯಾವುದೇ ಲೇಯರ್‌ಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡದಿದ್ದರೆ, ನೀವು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಸ್ವಲ್ಪ ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ತಳ ಪದರ - OS, ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಮತ್ತು ಇತರ ಕೆಳಮಟ್ಟದ ವಿಷಯಗಳನ್ನು ಈ ರೀತಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಮೂಲ ಮಟ್ಟದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ.
ಸೇವಾ ಮಟ್ಟ - ಇವುಗಳು ನೀವು ಡೆವಲಪರ್‌ಗೆ ಒದಗಿಸುವ ಸೇವೆಗಳಾಗಿವೆ: ಸೇವೆಯಾಗಿ ಲಾಗಿಂಗ್, ಸೇವೆಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ, ಸೇವೆಯಾಗಿ ಡೇಟಾಬೇಸ್, ಸೇವೆಯಾಗಿ ಬ್ಯಾಲೆನ್ಸರ್, ಸೇವೆಯಾಗಿ ಸರತಿ, ಸೇವೆಯಾಗಿ ನಿರಂತರ ವಿತರಣೆ - ಪ್ರತ್ಯೇಕ ತಂಡಗಳ ಸೇವೆಗಳ ಸಮೂಹ ಅಭಿವೃದ್ಧಿಗೆ ಒದಗಿಸಬಹುದು. ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಇದೆಲ್ಲವನ್ನೂ ವಿವರಿಸಬೇಕಾಗಿದೆ.
ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮಾಡಿದ ಪದರ ಮತ್ತು ಹಿಂದಿನ ಎರಡು ಪದರಗಳ ಮೇಲೆ ಅವು ಹೇಗೆ ತೆರೆದುಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.
ನಿಯಂತ್ರಣ ಪ್ರಶ್ನೆಗಳು
ನಿಮ್ಮ ಕಂಪನಿಯು ಸಾಮಾನ್ಯ ಮೂಲಸೌಕರ್ಯ ಭಂಡಾರವನ್ನು ಹೊಂದಿದೆಯೇ? ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ನೀವು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೀರಾ? ನೀವು ಮೂಲಸೌಕರ್ಯ ಭಂಡಾರದಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸುತ್ತೀರಾ? ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ಪದರಗಳಾಗಿ ಕತ್ತರಿಸಲಾಗಿದೆಯೇ? ನೀವು ಮೂಲ-ಸೇವೆ-APP ರೇಖಾಚಿತ್ರವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಬದಲಾವಣೆ ಮಾಡುವುದು ಎಷ್ಟು ಕಷ್ಟ?
ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಒಂದೂವರೆ ದಿನ ತೆಗೆದುಕೊಂಡಿದೆ ಎಂದು ನೀವು ಅನುಭವಿಸಿದರೆ, ಇದರರ್ಥ ನೀವು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಕೋಡ್‌ನಲ್ಲಿ ನೀವು ತಾಂತ್ರಿಕ ಸಾಲದ ರೇಕ್‌ನಲ್ಲಿ ಎಡವಿದ್ದೀರಿ. ಕೆಲವು ಸಿಸಿಟಿಎಲ್ ಅನ್ನು ಬದಲಾಯಿಸಲು, ನೀವು ಅರ್ಧದಷ್ಟು ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಅನ್ನು ಪುನಃ ಬರೆಯಬೇಕಾದಾಗ ನಾನು ಅಂತಹ ಅನೇಕ ಕಥೆಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ, ಏಕೆಂದರೆ ಸೃಜನಶೀಲತೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಬಯಕೆಯು ಎಲ್ಲವನ್ನೂ ಎಲ್ಲೆಡೆ ತುಕ್ಕು ಹಿಡಿದಿದೆ, ಎಲ್ಲಾ ಹ್ಯಾಂಡಲ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಮತ್ತು ಮರುಪರಿಶೀಲನೆ ಮಾಡುವುದು ಅವಶ್ಯಕ.
ನಿರಂತರ ವಿತರಣೆ
ಡೆಬಿಟ್ ಅನ್ನು ಕ್ರೆಡಿಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸೋಣ. ಮೊದಲಿಗೆ ಮೂಲಸೌಕರ್ಯದ ವಿವರಣೆ ಬರುತ್ತದೆ, ಅದು ಸಾಕಷ್ಟು ಮೂಲಭೂತವಾಗಿರಬಹುದು. ನೀವು ಎಲ್ಲವನ್ನೂ ವಿವರವಾಗಿ ವಿವರಿಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ಕೆಲವು ಮೂಲಭೂತ ವಿವರಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಆದ್ದರಿಂದ ನೀವು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಮುಂದೆ ನಿರಂತರ ವಿತರಣೆಯೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ನೀವು DevOps ಗೆ ಬಂದಾಗ ಈ ಎಲ್ಲಾ ಅಭ್ಯಾಸಗಳು ಏಕಕಾಲದಲ್ಲಿ ತೆರೆದುಕೊಳ್ಳುತ್ತವೆ, ಆದರೆ ನೀವು ಏನನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದರೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದು ನಿಖರವಾಗಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಅಭ್ಯಾಸವಾಗಿದೆ.
ನೀವು ಅದನ್ನು ಹೊಂದಿರುವಿರಿ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾದ ನಂತರ, ಡೆವಲಪರ್ ಕೋಡ್ ಅನ್ನು ಎಷ್ಟು ಸಾಧ್ಯವೋ ಅಷ್ಟು ಬೇಗ ಉತ್ಪಾದನೆಗೆ ಹೇಗೆ ಕಳುಹಿಸುವುದು ಎಂದು ನೀವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ನನ್ನ ಪ್ರಕಾರ ಡೆವಲಪರ್‌ನೊಂದಿಗೆ - “ಬಾವಿಗಳ” ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ನಾವು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇವೆ, ಅಂದರೆ, ಇದರೊಂದಿಗೆ ಬರುವುದು ವೈಯಕ್ತಿಕ ಜನರಲ್ಲ, ಆದರೆ ಒಂದು ತಂಡ.
ನಾವು ಜೊತೆಯಲ್ಲಿರುವಾಗ ವನ್ಯಾ ಎವ್ಟುಖೋವಿಚ್ ಮೊದಲ ಪುಸ್ತಕವನ್ನು ನೋಡಿದೆ ಜೆಜ್ ಹಂಬಲ್ ಮತ್ತು ಲೇಖಕರ ಗುಂಪುಗಳು "ನಿರಂತರ ವಿತರಣೆ", 2009 ರಲ್ಲಿ ಬಿಡುಗಡೆಯಾಯಿತು, ಅದರ ಶೀರ್ಷಿಕೆಯನ್ನು ರಷ್ಯನ್ ಭಾಷೆಗೆ ಹೇಗೆ ಅನುವಾದಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ದೀರ್ಘಕಾಲ ಯೋಚಿಸಿದ್ದೇವೆ. ಅವರು ಅದನ್ನು "ನಿರಂತರವಾಗಿ ವಿತರಿಸಲು" ಎಂದು ಭಾಷಾಂತರಿಸಲು ಬಯಸಿದ್ದರು, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಅದನ್ನು "ನಿರಂತರ ವಿತರಣೆ" ಎಂದು ಅನುವಾದಿಸಲಾಗಿದೆ. ನಮ್ಮ ಹೆಸರಿನಲ್ಲಿ ಏನೋ ರಷ್ಯನ್ ಇದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ, ಒತ್ತಡದಿಂದ.
ನಿರಂತರವಾಗಿ ತಲುಪಿಸುವ ಅರ್ಥ
ಉತ್ಪನ್ನ ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಯಾವಾಗಲೂ ಉತ್ಪಾದನೆಗೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು. ಅವನು ಉಬ್ಬಿಕೊಳ್ಳದಿರಬಹುದು, ಆದರೆ ಅವನು ಯಾವಾಗಲೂ ಅದಕ್ಕೆ ಸಿದ್ಧನಾಗಿರುತ್ತಾನೆ. ಅಂತೆಯೇ, ನೀವು ಯಾವಾಗಲೂ ನಿಮ್ಮ ಬಾಲದ ಕೆಳಗೆ ಸ್ವಲ್ಪ ಆತಂಕದ ಭಾವನೆಯೊಂದಿಗೆ ವಿವರಿಸಲು ಕಷ್ಟವಾದ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೀರಿ. ನೀವು ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಅನ್ನು ರೋಲ್ ಮಾಡಿದಾಗ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಕೆಲವು ಆತಂಕದ ಈ ಭಾವನೆಯು ಪ್ರಸ್ತುತವಾಗಿರಬೇಕು - ಇದು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಮೆದುಳಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ಇದನ್ನು ಅಭಿವೃದ್ಧಿಯೊಳಗಿನ ನಿಯಮಗಳಲ್ಲಿ ದಾಖಲಿಸಬೇಕು.
ಸ್ಥಿರವಾಗಿ ತಲುಪಿಸಲು, ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯಾದ್ಯಂತ ಚಲಿಸುವ ಕಲಾಕೃತಿಯ ಸ್ವರೂಪದ ಅಗತ್ಯವಿದೆ. ನೀವು ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯಾದ್ಯಂತ ವಿವಿಧ ಸ್ವರೂಪಗಳ "ಜೀವನ ತ್ಯಾಜ್ಯ" ಎಸೆದರೆ, ಅದು ಏಕೀಕೃತವಾಗುತ್ತದೆ, ಅದನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟ, ಮತ್ತು ತಾಂತ್ರಿಕ ಸಾಲದ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಕಲಾಕೃತಿಯ ಸ್ವರೂಪವನ್ನು ಜೋಡಿಸಬೇಕಾಗಿದೆ - ಇದು ಸಹ ಒಂದು ಸಾಮೂಹಿಕ ಕಾರ್ಯವಾಗಿದೆ: ನಾವೆಲ್ಲರೂ ಒಗ್ಗೂಡಬೇಕು, ನಮ್ಮ ಮಿದುಳನ್ನು ರಸ್ಟಲ್ ಮಾಡಬೇಕು ಮತ್ತು ಈ ಸ್ವರೂಪದೊಂದಿಗೆ ಬರಬೇಕು.
ಕಲಾಕೃತಿಯನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿತರಣಾ ಪೈಪ್ಲೈನ್ ಮೂಲಕ ಚಲಿಸುವಾಗ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಸರಿಹೊಂದುವಂತೆ ಬದಲಾಗುತ್ತದೆ. ಒಂದು ಕಲಾಕೃತಿಯು ಪೈಪ್‌ಲೈನ್‌ನ ಉದ್ದಕ್ಕೂ ಚಲಿಸಿದಾಗ, ಅದು ನಿರಂತರವಾಗಿ ಕೆಲವು ಅನನುಕೂಲವಾದ ವಿಷಯಗಳನ್ನು ಎದುರಿಸುತ್ತದೆ, ಅದು ನೀವು ಉತ್ಪಾದನೆಗೆ ಹಾಕುವ ಕಲಾಕೃತಿಯು ಎದುರಿಸುವಂತೆಯೇ ಇರುತ್ತದೆ. ಶಾಸ್ತ್ರೀಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಇದನ್ನು ರೋಲ್‌ಔಟ್ ಮಾಡುವ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮಾಡಿದರೆ, DevOps ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇದು ಸಾರ್ವಕಾಲಿಕ ಸಂಭವಿಸುತ್ತದೆ: ಇಲ್ಲಿ ಅವರು ಅದನ್ನು ಕೆಲವು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿದರು, ಇಲ್ಲಿ ಅವರು ಅದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಎಸೆದರು, ಅದು ಹೆಚ್ಚು ಕಡಿಮೆ ಹೋಲುತ್ತದೆ. ಉತ್ಪಾದನೆಗೆ, ನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅವರು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದರು.
ಇದು ಪ್ಯಾಕ್-ಮ್ಯಾನ್ ಆಟವನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ನೆನಪಿಸುತ್ತದೆ - ಕಲಾಕೃತಿಯು ಕೆಲವು ರೀತಿಯ ಕಥೆಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೋಡ್ ನಿಜವಾಗಿ ಕಥೆಯ ಮೂಲಕ ಹೋಗುತ್ತದೆಯೇ ಮತ್ತು ಅದು ನಿಮ್ಮ ಉತ್ಪಾದನೆಗೆ ಹೇಗಾದರೂ ಸಂಬಂಧಿಸಿದೆಯೇ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಉತ್ಪಾದನೆಯ ಕಥೆಗಳನ್ನು ನಿರಂತರ ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆಗೆ ಎಳೆಯಬಹುದು: ಏನಾದರೂ ಬಿದ್ದಾಗ ಅದು ಹೀಗಿತ್ತು, ಈಗ ಈ ಸನ್ನಿವೇಶವನ್ನು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ಮಾಡೋಣ. ಪ್ರತಿ ಬಾರಿಯೂ ಕೋಡ್ ಈ ಸನ್ನಿವೇಶದ ಮೂಲಕ ಹೋಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಬಾರಿ ನೀವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಅನ್ನು ತಲುಪುವುದಕ್ಕಿಂತ ಮುಂಚೆಯೇ ನೀವು ಅದರ ಬಗ್ಗೆ ಕಲಿಯುವಿರಿ.
ವಿಭಿನ್ನ ನಿಯೋಜನೆ ತಂತ್ರಗಳು. ಉದಾಹರಣೆಗೆ, ನೀವು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪರೀಕ್ಷಿಸಲು AB ಪರೀಕ್ಷೆ ಅಥವಾ ಕ್ಯಾನರಿ ನಿಯೋಜನೆಗಳನ್ನು ಬಳಸುತ್ತೀರಿ, ಕೋಡ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳಿ ಮತ್ತು ಅದನ್ನು 100 ಮಿಲಿಯನ್ ಬಳಕೆದಾರರಿಗೆ ಹೊರತಂದಿದ್ದಕ್ಕಿಂತ ಮುಂಚೆಯೇ.
"ಸ್ಥಿರವಾಗಿ ತಲುಪಿಸಿ" ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ಡೆಲಿವರಿ ಪ್ರಕ್ರಿಯೆ Dev, CI, Test, PreProd, Prod ಒಂದು ಪ್ರತ್ಯೇಕ ಪರಿಸರವಲ್ಲ, ಇವುಗಳು ನಿಮ್ಮ ಕಲಾಕೃತಿ ಹಾದುಹೋಗುವ ಅಗ್ನಿ ನಿರೋಧಕ ಮೊತ್ತವನ್ನು ಹೊಂದಿರುವ ಹಂತಗಳು ಅಥವಾ ನಿಲ್ದಾಣಗಳಾಗಿವೆ.
ನೀವು ಮೂಲ ಸೇವಾ APP ಎಂದು ವಿವರಿಸಲಾದ ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಹೊಂದಿದ್ದರೆ ಅದು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಲ್ಲಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಮರೆಯಬೇಡಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಈ ಕಲಾಕೃತಿಗಾಗಿ ಕೋಡ್ ಎಂದು ಬರೆಯಿರಿ, ಕಲಾಕೃತಿಯನ್ನು ಉತ್ತೇಜಿಸಿ ಮತ್ತು ನೀವು ಹೋಗುತ್ತಿರುವಾಗ ಅದನ್ನು ಬದಲಾಯಿಸಿ.
ಸ್ವಯಂ ಪರೀಕ್ಷೆಯ ಪ್ರಶ್ನೆಗಳು
ವೈಶಿಷ್ಟ್ಯ ವಿವರಣೆಯಿಂದ 95% ಪ್ರಕರಣಗಳಲ್ಲಿ ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆ ಮಾಡುವ ಸಮಯವು ಒಂದು ವಾರಕ್ಕಿಂತ ಕಡಿಮೆಯೇ? ಪೈಪ್‌ಲೈನ್‌ನ ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಕಲಾಕೃತಿಯ ಗುಣಮಟ್ಟ ಸುಧಾರಿಸುತ್ತದೆಯೇ? ಅದು ಹಾದುಹೋಗುವ ಕಥೆ ಇದೆಯೇ? ನೀವು ವಿಭಿನ್ನ ನಿಯೋಜನೆ ತಂತ್ರಗಳನ್ನು ಬಳಸುತ್ತೀರಾ?
ಎಲ್ಲಾ ಉತ್ತರಗಳು ಹೌದು ಎಂದಾದರೆ, ನೀವು ನಂಬಲಾಗದಷ್ಟು ತಂಪಾಗಿರುವಿರಿ! ನಿಮ್ಮ ಉತ್ತರಗಳನ್ನು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ - ನನಗೆ ಸಂತೋಷವಾಗುತ್ತದೆ).
ಪ್ರತಿಕ್ರಿಯೆ
ಇದು ಎಲ್ಲಕ್ಕಿಂತ ಕಷ್ಟಕರವಾದ ಅಭ್ಯಾಸವಾಗಿದೆ. DevOpsConf ಸಮ್ಮೇಳನದಲ್ಲಿ, Infobip ನ ಸಹೋದ್ಯೋಗಿಯೊಬ್ಬರು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾ, ಅವರ ಮಾತುಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಗೊಂದಲಕ್ಕೊಳಗಾದರು, ಏಕೆಂದರೆ ನೀವು ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾದ ಅಂಶದ ಬಗ್ಗೆ ಇದು ನಿಜವಾಗಿಯೂ ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಅಭ್ಯಾಸವಾಗಿದೆ!
ಉದಾಹರಣೆಗೆ, ಬಹಳ ಹಿಂದೆಯೇ, ನಾನು Qik ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಮತ್ತು ನಾವು ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು. ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಈಗ Zabbix ನಲ್ಲಿ 150 ಐಟಂಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು ಭಯಾನಕವಾಗಿತ್ತು, ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕರು ತಮ್ಮ ದೇವಾಲಯದ ಕಡೆಗೆ ಬೆರಳನ್ನು ತಿರುಗಿಸಿದರು:
- ಹುಡುಗರೇ, ನೀವು ಅಸ್ಪಷ್ಟವಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಏಕೆ ಅತ್ಯಾಚಾರ ಮಾಡುತ್ತಿದ್ದೀರಿ?
ಆದರೆ ಇದು ನಿಜವಾಗಿಯೂ ತುಂಬಾ ತಂಪಾದ ತಂತ್ರ ಎಂದು ತೋರಿಸುವ ಒಂದು ಘಟನೆ ಸಂಭವಿಸಿದೆ.
ಸೇವೆಗಳಲ್ಲಿ ಒಂದು ನಿರಂತರವಾಗಿ ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ಆರಂಭದಲ್ಲಿ, ಇದು ಕ್ರ್ಯಾಶ್ ಆಗಲಿಲ್ಲ, ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಕೋಡ್ ಅನ್ನು ಅಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಮೂಲಭೂತ ಬ್ರೋಕರ್ ಆಗಿದ್ದು, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಯಾವುದೇ ವ್ಯವಹಾರ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ - ಇದು ಕೇವಲ ವೈಯಕ್ತಿಕ ಸೇವೆಗಳ ನಡುವೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಿತು. ಸೇವೆಯು 4 ತಿಂಗಳವರೆಗೆ ಬದಲಾಗಲಿಲ್ಲ, ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅದು "ವಿಭಾಗದ ದೋಷ" ದೋಷದೊಂದಿಗೆ ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು.
ನಾವು ಆಘಾತಕ್ಕೊಳಗಾಗಿದ್ದೇವೆ, ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿ ನಮ್ಮ ಚಾರ್ಟ್‌ಗಳನ್ನು ತೆರೆದಿದ್ದೇವೆ ಮತ್ತು ಒಂದೂವರೆ ವಾರದ ಹಿಂದೆ, ಈ ಬ್ರೋಕರ್ ಬಳಸುವ API ಸೇವೆಯಲ್ಲಿನ ವಿನಂತಿಗಳ ವರ್ತನೆಯು ಮಹತ್ತರವಾಗಿ ಬದಲಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಮುಂದೆ ನಾವು ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಆವರ್ತನ ಬದಲಾಗಿದೆ ಎಂದು ನೋಡಿದೆವು. ಇವುಗಳು ಆಂಡ್ರಾಯ್ಡ್ ಕ್ಲೈಂಟ್‌ಗಳು ಎಂದು ನಂತರ ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಕೇಳಿದೆವು:
- ಹುಡುಗರೇ, ಒಂದೂವರೆ ವಾರದ ಹಿಂದೆ ನಿಮಗೆ ಏನಾಯಿತು?
ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, ಅವರು UI ಅನ್ನು ಹೇಗೆ ಮರುವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಆಸಕ್ತಿದಾಯಕ ಕಥೆಯನ್ನು ಕೇಳಿದ್ದೇವೆ. ಅವರು HTTP ಲೈಬ್ರರಿಯನ್ನು ಬದಲಾಯಿಸಿದ್ದಾರೆ ಎಂದು ಯಾರಾದರೂ ತಕ್ಷಣವೇ ಹೇಳುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. Android ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ, ಇದು ಬಾತ್ರೂಮ್‌ನಲ್ಲಿ ಸೋಪ್ ಅನ್ನು ಬದಲಾಯಿಸುವಂತಿದೆ - ಅವರಿಗೆ ನೆನಪಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, 40 ನಿಮಿಷಗಳ ಸಂಭಾಷಣೆಯ ನಂತರ, ಅವರು HTTP ಲೈಬ್ರರಿಯನ್ನು ಬದಲಾಯಿಸಿದ್ದಾರೆ ಮತ್ತು ಅದರ ಡೀಫಾಲ್ಟ್ ಸಮಯಗಳು ಬದಲಾಗಿವೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಇದು API ಸರ್ವರ್‌ನಲ್ಲಿನ ಟ್ರಾಫಿಕ್ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ಕಾರಣವಾಯಿತು, ಇದು ಬ್ರೋಕರ್‌ನಲ್ಲಿ ಓಟವನ್ನು ಉಂಟುಮಾಡುವ ಪರಿಸ್ಥಿತಿಗೆ ಕಾರಣವಾಯಿತು ಮತ್ತು ಅದು ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು.
ಆಳವಾದ ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲದೆ ಇದನ್ನು ತೆರೆಯಲು ಸಾಮಾನ್ಯವಾಗಿ ಅಸಾಧ್ಯ. ಸಂಸ್ಥೆಯು ಇನ್ನೂ "ಬಾವಿಗಳ" ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಪರಸ್ಪರ ಹಣವನ್ನು ಎಸೆದಾಗ, ಇದು ವರ್ಷಗಳವರೆಗೆ ಬದುಕಬಹುದು. ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಅಸಾಧ್ಯವಾದ ಕಾರಣ ನೀವು ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ. ನೀವು ಹೊಂದಿರುವ ಎಲ್ಲಾ ಈವೆಂಟ್‌ಗಳನ್ನು ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದಾಗ, ಟ್ರ್ಯಾಕ್ ಮಾಡಿದಾಗ, ಟ್ರ್ಯಾಕ್ ಮಾಡಿದಾಗ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಪರೀಕ್ಷೆಯಾಗಿ ಬಳಸಿದಾಗ - ಕೋಡ್ ಬರೆಯಿರಿ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕೆಂದು ತಕ್ಷಣವೇ ಸೂಚಿಸಿ, ಕೋಡ್ ರೂಪದಲ್ಲಿ (ನಾವು ಈಗಾಗಲೇ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಹೊಂದಿದ್ದೇವೆ), ಎಲ್ಲವೂ ಹೇಗೆ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ ಅಂಗೈ ಮೇಲೆ. ಅಂತಹ ಸಂಕೀರ್ಣ ಸಮಸ್ಯೆಗಳನ್ನು ಸಹ ಸುಲಭವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ.
ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆಯ ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಕಲಾಕೃತಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ - ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಲ್ಲ.
ಮಾನಿಟರಿಂಗ್ ಅನ್ನು CI ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಕೆಲವು ಮೂಲಭೂತ ವಿಷಯಗಳು ಈಗಾಗಲೇ ಅಲ್ಲಿ ಗೋಚರಿಸುತ್ತವೆ. ನಂತರ ನೀವು ಅವುಗಳನ್ನು ಪರೀಕ್ಷೆ, PredProd ಮತ್ತು ಲೋಡ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ನೋಡುತ್ತೀರಿ. ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ, ಮೆಟ್ರಿಕ್ಸ್, ಅಂಕಿಅಂಶಗಳು ಮಾತ್ರವಲ್ಲದೆ ಲಾಗ್‌ಗಳು: ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಹೊರಹೊಮ್ಮಿತು, ವೈಪರೀತ್ಯಗಳು - ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸಿ.
ಇಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ. DevOps ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದ್ದೇನೆ. ಈ ಸಂಕೀರ್ಣತೆಯನ್ನು ನಿಭಾಯಿಸಲು, ನೀವು ಸಾಮಾನ್ಯ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೊಂದಿರಬೇಕು.
ಸ್ವಯಂ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಪ್ರಶ್ನೆಗಳು
ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಲಾಗಿಂಗ್ ನಿಮಗೆ ಅಭಿವೃದ್ಧಿ ಸಾಧನವಾಗಿದೆಯೇ? ಕೋಡ್ ಬರೆಯುವಾಗ, ನಿಮ್ಮನ್ನು ಒಳಗೊಂಡಂತೆ ನಿಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಅದನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕೆಂದು ಯೋಚಿಸುತ್ತಾರೆಯೇ?
ಗ್ರಾಹಕರಿಂದ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ನೀವು ಕೇಳುತ್ತೀರಾ? ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಲಾಗಿಂಗ್‌ನಿಂದ ನೀವು ಕ್ಲೈಂಟ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ? ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಲಾಗಿಂಗ್‌ನಿಂದ ನೀವು ಸಿಸ್ಟಮ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ? ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಪ್ರವೃತ್ತಿಯು ಬೆಳೆಯುತ್ತಿರುವುದನ್ನು ನೀವು ನೋಡಿದ ಕಾರಣ ನೀವು ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಾ ಮತ್ತು ಇನ್ನೊಂದು 3 ವಾರಗಳಲ್ಲಿ ಎಲ್ಲವೂ ಸಾಯುತ್ತದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ?
ಒಮ್ಮೆ ನೀವು ಈ ಮೂರು ಘಟಕಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ಯಾವ ರೀತಿಯ ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂಬುದರ ಕುರಿತು ನೀವು ಯೋಚಿಸಬಹುದು.
ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆ
ಪ್ರತಿ ಕಂಪನಿಯು ಹೊಂದಿರುವ ವಿಭಿನ್ನ ಸಾಧನಗಳ ಒಂದು ಸೆಟ್ ಎಂಬುದು ಪಾಯಿಂಟ್ ಅಲ್ಲ.
ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯ ಅಂಶವೆಂದರೆ ಎಲ್ಲಾ ತಂಡಗಳು ಈ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತವೆ.
ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯ ಪ್ರತ್ಯೇಕ ತುಣುಕುಗಳ ಅಭಿವೃದ್ಧಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಪ್ರತ್ಯೇಕ ತಂಡಗಳಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯ ಅಭಿವೃದ್ಧಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಪ್ರಚಾರದ ಜವಾಬ್ದಾರಿಯನ್ನು ಪ್ರತಿಯೊಬ್ಬ ಇಂಜಿನಿಯರ್ ಹೊರುತ್ತಾನೆ. ಆಂತರಿಕ ಮಟ್ಟದಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯ ಸಾಧನವಾಗುತ್ತದೆ.
ಎಲ್ಲಾ ತಂಡಗಳು ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತವೆ ಮತ್ತು ಅದನ್ನು ತಮ್ಮದೇ ಆದ IDE ನಂತೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಗಣಿಸುತ್ತವೆ. ನಿಮ್ಮ IDE ಯಲ್ಲಿ ನೀವು ಎಲ್ಲವನ್ನೂ ಉತ್ತಮವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಮಾಡಲು ವಿಭಿನ್ನ ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ಹಾಟ್‌ಕೀಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ನೀವು ಸಬ್ಲೈಮ್, ಆಟಮ್ ಅಥವಾ ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋ ಕೋಡ್ ಅನ್ನು ತೆರೆದಾಗ, ಕೋಡ್ ದೋಷಗಳು ಸುರಿಯುತ್ತಿವೆ ಮತ್ತು ಕೆಲಸ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ನೀವು ಅರಿತುಕೊಂಡರೆ, ನೀವು ತಕ್ಷಣ ದುಃಖಿತರಾಗುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ IDE ಅನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಓಡುತ್ತೀರಿ.
ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಗಣಿಸಿ. ಅದರಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಅದನ್ನು ನೀವೇ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ವಿನಂತಿಯನ್ನು ಬಿಡಿ. ಏನಾದರೂ ಸರಳವಾಗಿದ್ದರೆ, ಅದನ್ನು ನೀವೇ ಸಂಪಾದಿಸಿ, ಪುಲ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ, ಹುಡುಗರು ಅದನ್ನು ಪರಿಗಣಿಸುತ್ತಾರೆ ಮತ್ತು ಸೇರಿಸುತ್ತಾರೆ. ಡೆವಲಪರ್‌ನ ತಲೆಯಲ್ಲಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ಪರಿಕರಗಳಿಗೆ ಇದು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ವಿಧಾನವಾಗಿದೆ.
ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯು ಗುಣಮಟ್ಟದಲ್ಲಿ ನಿರಂತರ ಸುಧಾರಣೆಯೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿಯಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಕಲಾಕೃತಿಯ ವರ್ಗಾವಣೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೋಡ್‌ಗೆ ಸಂಭವಿಸುವ ಕಥೆಗಳ ಗುಂಪಿನೊಂದಿಗೆ IP ಅನ್ನು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಲಾಗಿದೆ. ಅಭಿವೃದ್ಧಿಯ ವರ್ಷಗಳಲ್ಲಿ, ಈ ಕಥೆಗಳು ಬಹಳಷ್ಟು ಇವೆ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಅನನ್ಯವಾಗಿವೆ ಮತ್ತು ನಿಮಗೆ ಮಾತ್ರ ಸಂಬಂಧಿಸಿವೆ - ಅವುಗಳನ್ನು ಗೂಗಲ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
ಈ ಹಂತದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯು ನಿಮ್ಮ ಸ್ಪರ್ಧಾತ್ಮಕ ಪ್ರಯೋಜನವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಸ್ಪರ್ಧಿಗಳ ಸಾಧನದಲ್ಲಿಲ್ಲದ ಯಾವುದನ್ನಾದರೂ ಅದರಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ನಿಮ್ಮ ಐಪಿ ಆಳವಾಗಿ, ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ನಿಮ್ಮ ಸ್ಪರ್ಧಾತ್ಮಕ ಪ್ರಯೋಜನವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮಾರಾಟಗಾರರ ಲಾಕ್ ಸಮಸ್ಯೆ: ನೀವು ಬೇರೊಬ್ಬರ ವೇದಿಕೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಬೇರೊಬ್ಬರ ಅನುಭವವನ್ನು ಬಳಸಿಕೊಂಡು, ಅದು ನಿಮಗೆ ಎಷ್ಟು ಪ್ರಸ್ತುತವಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಹೌದು, ಪ್ರತಿ ಕಂಪನಿಯು ಅಮೆಜಾನ್‌ನಂತಹ ವೇದಿಕೆಯನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಕಂಪನಿಯ ಅನುಭವವು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಅದರ ಸ್ಥಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿರುವ ಕಠಿಣ ಮಾರ್ಗವಾಗಿದೆ ಮತ್ತು ನೀವು ಅಲ್ಲಿ ಮಾರಾಟಗಾರರ ಲಾಕ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಈ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ.
ಯೋಜನೆ
ಇದು ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯ ಮೂಲ ರೇಖಾಚಿತ್ರವಾಗಿದ್ದು ಅದು DevOps ಕಂಪನಿಯಲ್ಲಿ ಎಲ್ಲಾ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಅದು ಏನನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ಸಂಪನ್ಮೂಲ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ವ್ಯವಸ್ಥೆ, ಇದು CPU, ಮೆಮೊರಿ, ಡಿಸ್ಕ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಇತರ ಸೇವೆಗಳಿಗೆ ಒದಗಿಸುತ್ತದೆ. ಇದರ ಮೇಲೆ - ಕಡಿಮೆ ಮಟ್ಟದ ಸೇವೆಗಳು: ಮೇಲ್ವಿಚಾರಣೆ, ಲಾಗಿಂಗ್, CI/CD ಎಂಜಿನ್, ಕಲಾಕೃತಿ ಸಂಗ್ರಹಣೆ, ಸಿಸ್ಟಮ್ ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ.
ಉನ್ನತ ಮಟ್ಟದ ಸೇವೆಗಳು: ಡೇಟಾಬೇಸ್ ಸೇವೆಯಾಗಿ, ಸರತಿ ಸಾಲುಗಳು, ಸೇವೆಯಾಗಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸ್, ಸೇವೆಯಾಗಿ ಇಮೇಜ್ ಮರುಗಾತ್ರಗೊಳಿಸುವಿಕೆ, ಸೇವೆಯಾಗಿ ಬಿಗ್ ಡೇಟಾ ಫ್ಯಾಕ್ಟರಿ. ಇದರ ಮೇಲೆ - ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ಗೆ ನಿರಂತರವಾಗಿ ಮಾರ್ಪಡಿಸಿದ ಕೋಡ್ ಅನ್ನು ತಲುಪಿಸುವ ಪೈಪ್ಲೈನ್.
ಕ್ಲೈಂಟ್‌ಗಾಗಿ ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಅದನ್ನು ಬದಲಾಯಿಸಿ, ಈ ಕೋಡ್ ಅನ್ನು ಮತ್ತೆ ಪೂರೈಸಿ, ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ - ಮತ್ತು ಆದ್ದರಿಂದ ನೀವು ನಿರಂತರವಾಗಿ ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆ ಮತ್ತು ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ ಎರಡನ್ನೂ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೀರಿ.
ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ವಿತರಣಾ ಪೈಪ್ಲೈನ್ ಅನೇಕ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಆದರೆ ಇದು ಸ್ಕೀಮ್ಯಾಟಿಕ್ ರೇಖಾಚಿತ್ರವಾಗಿದ್ದು ಅದನ್ನು ಉದಾಹರಣೆಯಾಗಿ ನೀಡಲಾಗಿದೆ - ಅದನ್ನು ಒಂದೊಂದಾಗಿ ಪುನರಾವರ್ತಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಹಂತಗಳು ಸೇವೆಗಳಂತೆ ಸೇವೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಪ್ರತಿಯೊಂದು ಇಟ್ಟಿಗೆ ತನ್ನದೇ ಆದ ಕಥೆಯನ್ನು ಹೊಂದಿದೆ: ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಹಂಚಲಾಗುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಬದಲಾವಣೆಗಳು.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಪ್ರತಿಯೊಂದು ಭಾಗವು ಕಥೆಯನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ, ಮತ್ತು ಈ ಇಟ್ಟಿಗೆ ಯಾವ ಕಥೆಯನ್ನು ಒಯ್ಯುತ್ತದೆ ಎಂದು ನಿಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳಿ, ಬಹುಶಃ ಅದನ್ನು ಎಸೆಯಬೇಕು ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಯೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ಇಟ್ಟಿಗೆ ಬದಲಿಗೆ ಓಕ್ಮೀಟರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವೇ? ಬಹುಶಃ ಹುಡುಗರು ಈಗಾಗಲೇ ಈ ಪರಿಣತಿಯನ್ನು ನಮಗಿಂತ ಹೆಚ್ಚು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ. ಆದರೆ ಬಹುಶಃ ಅಲ್ಲ - ಬಹುಶಃ ನಾವು ಅನನ್ಯ ಪರಿಣತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು.
ವೇದಿಕೆಯ ರಚನೆ
ಇದು ಸಂಕೀರ್ಣ ಸಂವಹನ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ನೀವು ಮೂಲಭೂತ ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ನೀವು ಅಗತ್ಯತೆಗಳು ಮತ್ತು ಮಾನದಂಡಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ವಿವಿಧ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ತಜ್ಞರ ನಡುವೆ ಸಂವಹನವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ ಮತ್ತು ಅವುಗಳನ್ನು ವಿವಿಧ ಪರಿಕರಗಳು ಮತ್ತು ವಿಧಾನಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಬದಲಾಯಿಸುತ್ತೀರಿ. DevOps ನಲ್ಲಿ ನಾವು ಹೊಂದಿರುವ ಸಂಸ್ಕೃತಿ ಇಲ್ಲಿ ಮುಖ್ಯವಾಗಿದೆ.
ಸಂಸ್ಕೃತಿಯೊಂದಿಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ - ಇದು ಸಹಯೋಗ ಮತ್ತು ಸಂವಹನದ ಬಗ್ಗೆ, ಅಂದರೆ, ಪರಸ್ಪರ ಸಾಮಾನ್ಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಬಯಕೆ, ಒಂದು ವಾದ್ಯವನ್ನು ಒಟ್ಟಿಗೆ ಬಳಸುವ ಬಯಕೆ. ಇಲ್ಲಿ ಯಾವುದೇ ರಾಕೆಟ್ ವಿಜ್ಞಾನವಿಲ್ಲ - ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ, ನೀರಸವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಾವೆಲ್ಲರೂ ಪ್ರವೇಶದ್ವಾರದಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಸ್ವಚ್ಛವಾಗಿರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ - ಅಂತಹ ಸಂಸ್ಕೃತಿಯ ಮಟ್ಟ.
ನಿಮ್ಮ ಬಳಿ ಏನು ಇದೆ?
ಮತ್ತೆ, ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವೇ ಕೇಳಬಹುದು.
ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆ ಸಮರ್ಪಿತವಾಗಿದೆಯೇ? ಅದರ ಅಭಿವೃದ್ಧಿಗೆ ಯಾರು ಹೊಣೆ? ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯ ಸ್ಪರ್ಧಾತ್ಮಕ ಪ್ರಯೋಜನಗಳನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ?
ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವು ನಿರಂತರವಾಗಿ ನಿಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳಬೇಕು. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳಿಗೆ ಏನನ್ನಾದರೂ ವರ್ಗಾಯಿಸಬಹುದಾದರೆ, ಅದನ್ನು ವರ್ಗಾಯಿಸಬೇಕು; ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಯು ನಿಮ್ಮ ಚಲನೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಂತರ ನೀವು ನಿಮ್ಮೊಳಗೆ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿಕೊಳ್ಳಬೇಕು.
ಆದ್ದರಿಂದ, DevOps...
... ಇದು ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಇದು ಹೊಂದಿರಬೇಕು:
- ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನ.
- ಈ ಡಿಜಿಟಲ್ ಉತ್ಪನ್ನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ವ್ಯಾಪಾರ ಮಾಡ್ಯೂಲ್‌ಗಳು.
- ಕೋಡ್ ಬರೆಯುವ ಉತ್ಪನ್ನ ತಂಡಗಳು.
- ನಿರಂತರ ವಿತರಣಾ ಅಭ್ಯಾಸಗಳು.
- ಸೇವೆಯಾಗಿ ವೇದಿಕೆಗಳು.
- ಸೇವೆಯಾಗಿ ಮೂಲಸೌಕರ್ಯ.
- ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ.
- DevOps ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಪ್ರತ್ಯೇಕ ಅಭ್ಯಾಸಗಳು.
- ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುವ ಪ್ರತಿಕ್ರಿಯೆ ಅಭ್ಯಾಸ.
ನೀವು ಈ ರೇಖಾಚಿತ್ರವನ್ನು ಬಳಸಬಹುದು, ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ಈಗಾಗಲೇ ಕೆಲವು ರೂಪದಲ್ಲಿ ಹೊಂದಿರುವುದನ್ನು ಹೈಲೈಟ್ ಮಾಡಬಹುದು: ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಅಥವಾ ಇನ್ನೂ ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗಿದೆ.
ಇದು ಒಂದೆರಡು ವಾರಗಳಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ . RIT++ ನ ಭಾಗವಾಗಿ. ಕಾನ್ಫರೆನ್ಸ್‌ಗೆ ಬನ್ನಿ, ಅಲ್ಲಿ ನೀವು ನಿರಂತರ ವಿತರಣೆ, ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು DevOps ರೂಪಾಂತರದ ಕುರಿತು ಅನೇಕ ತಂಪಾದ ವರದಿಗಳನ್ನು ಕಾಣಬಹುದು. , ಕೊನೆಯ ಬೆಲೆಯ ಗಡುವು ಮೇ 20 ಆಗಿದೆ
ಮೂಲ: www.habr.com