ಕಾಕತಾಳೀಯಗಳು ಯಾದೃಚ್ಛಿಕವಾಗಿರುತ್ತವೆ, ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಇದು ಮತ್ತೊಂದು ಗ್ರಹದಲ್ಲಿ ...
ಬ್ಯಾಕೆಂಡ್ ಡೆವಲಪರ್ ನಿರ್ವಾಹಕರೊಂದಿಗೆ ತಂಡದಲ್ಲಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಮೂರು ಯಶಸ್ಸು ಮತ್ತು ವೈಫಲ್ಯದ ಕಥೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಕಥೆ ಒಂದು.
ವೆಬ್ ಸ್ಟುಡಿಯೋ, ಉದ್ಯೋಗಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಒಂದು ಕೈಯಿಂದ ಎಣಿಸಬಹುದು. ಇಂದು ನೀವು ಲೇಔಟ್ ಡಿಸೈನರ್, ನಾಳೆ ನೀವು ಬ್ಯಾಕೆಂಡರ್, ನಾಳೆಯ ಮರುದಿನ ನೀವು ನಿರ್ವಾಹಕರು. ಒಂದೆಡೆ, ನೀವು ಅದ್ಭುತ ಅನುಭವವನ್ನು ಪಡೆಯಬಹುದು. ಮತ್ತೊಂದೆಡೆ, ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಸಾಮರ್ಥ್ಯದ ಕೊರತೆಯಿದೆ. ಕೆಲಸದ ಮೊದಲ ದಿನವನ್ನು ನಾನು ಇನ್ನೂ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ, ನಾನು ಇನ್ನೂ ಹಸಿರು, ಬಾಸ್ ಹೇಳುತ್ತಾರೆ: "ಓಪನ್ ಪುಟ್ಟಿ," ಆದರೆ ಅದು ಏನೆಂದು ನನಗೆ ಗೊತ್ತಿಲ್ಲ. ನಿರ್ವಾಹಕರೊಂದಿಗಿನ ಸಂವಹನವನ್ನು ಹೊರಗಿಡಲಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವೇ ನಿರ್ವಾಹಕರು. ಈ ಪರಿಸ್ಥಿತಿಯ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಪರಿಗಣಿಸೋಣ.
+ ಎಲ್ಲಾ ಶಕ್ತಿ ನಿಮ್ಮ ಕೈಯಲ್ಲಿದೆ.
+ ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶಕ್ಕಾಗಿ ಯಾರನ್ನೂ ಬೇಡಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ.
+ ಎಲ್ಲಾ ದಿಕ್ಕುಗಳಲ್ಲಿ ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ.
+ ಕೌಶಲ್ಯಗಳನ್ನು ಚೆನ್ನಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ.
+ ಉತ್ಪನ್ನದ ವಾಸ್ತುಶಿಲ್ಪದ ಸಂಪೂರ್ಣ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಿ.
- ಹೆಚ್ಚಿನ ಜವಾಬ್ದಾರಿ.
- ಉತ್ಪಾದನೆಯನ್ನು ಮುರಿಯುವ ಅಪಾಯ.
- ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಉತ್ತಮ ತಜ್ಞರಾಗುವುದು ಕಷ್ಟ.
ಆಸಕ್ತಿ ಇಲ್ಲ, ಮುಂದೆ ಹೋಗೋಣ
ಎರಡನೆಯ ಕಥೆ.
ದೊಡ್ಡ ಕಂಪನಿ, ದೊಡ್ಡ ಯೋಜನೆ. 5-7 ನೌಕರರು ಮತ್ತು ಹಲವಾರು ಅಭಿವೃದ್ಧಿ ಗುಂಪುಗಳೊಂದಿಗೆ ಆಡಳಿತ ವಿಭಾಗವಿದೆ. ನೀವು ಅಂತಹ ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಬಂದಾಗ, ಪ್ರತಿ ನಿರ್ವಾಹಕರು ನೀವು ಉತ್ಪನ್ನದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಇಲ್ಲಿಗೆ ಬಂದಿಲ್ಲ, ಆದರೆ ಏನನ್ನಾದರೂ ಮುರಿಯಲು ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಸಹಿ ಮಾಡಿದ ಎನ್‌ಡಿಎ ಅಥವಾ ಸಂದರ್ಶನದಲ್ಲಿ ಆಯ್ಕೆಯು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಸೂಚಿಸುವುದಿಲ್ಲ. ಇಲ್ಲ, ಈ ಮನುಷ್ಯ ನಮ್ಮ ಚುಂಬನ ಉತ್ಪಾದನೆಯನ್ನು ಹಾಳುಮಾಡಲು ತನ್ನ ಕೊಳಕು ಕೈಗಳಿಂದ ಇಲ್ಲಿಗೆ ಬಂದನು. ಆದ್ದರಿಂದ, ಅಂತಹ ವ್ಯಕ್ತಿಯೊಂದಿಗೆ ನಿಮಗೆ ಕನಿಷ್ಠ ಸಂವಹನ ಬೇಕು; ಕನಿಷ್ಠ, ನೀವು ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸ್ಟಿಕ್ಕರ್ ಅನ್ನು ಎಸೆಯಬಹುದು. ಪ್ರಾಜೆಕ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕುರಿತು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಡಿ. ತಂಡದ ನಾಯಕ ಕೇಳುವವರೆಗೂ ಪ್ರವೇಶವನ್ನು ನೀಡದಿರುವುದು ಸೂಕ್ತ. ಮತ್ತು ಅವನು ಕೇಳಿದಾಗ, ಅವರು ಕೇಳಿದ್ದಕ್ಕಿಂತ ಕಡಿಮೆ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ಅದನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತಾನೆ. ಅಂತಹ ನಿರ್ವಾಹಕರೊಂದಿಗಿನ ಎಲ್ಲಾ ಸಂವಹನವು ಅಭಿವೃದ್ಧಿ ಇಲಾಖೆ ಮತ್ತು ಆಡಳಿತ ವಿಭಾಗದ ನಡುವಿನ ಕಪ್ಪು ಕುಳಿಯಿಂದ ಹೀರಲ್ಪಡುತ್ತದೆ. ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸುವುದು ಅಸಾಧ್ಯ. ಆದರೆ ನೀವು ವೈಯಕ್ತಿಕವಾಗಿ ಬರಲು ಸಾಧ್ಯವಿಲ್ಲ - ನಿರ್ವಾಹಕರು 24/7 ತುಂಬಾ ಕಾರ್ಯನಿರತರಾಗಿದ್ದಾರೆ. (ನೀವು ನಿರಂತರವಾಗಿ ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ?) ಕೆಲವು ಕಾರ್ಯಕ್ಷಮತೆ ಗುಣಲಕ್ಷಣಗಳು:
- ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸರಾಸರಿ ನಿಯೋಜನೆ ಸಮಯ 4-5 ಗಂಟೆಗಳು
- ಉತ್ಪಾದನೆಯಲ್ಲಿ ಗರಿಷ್ಠ ನಿಯೋಜನೆ ಸಮಯ 9 ಗಂಟೆಗಳು
- ಡೆವಲಪರ್‌ಗೆ, ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ನಂತೆಯೇ ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿದೆ. ಒಟ್ಟು ಎಷ್ಟು ಇವೆ?
- ಕಡಿಮೆ ಗುಣಮಟ್ಟದ ಬಿಡುಗಡೆಗಳು, ಆಗಾಗ್ಗೆ ದೋಷಗಳು
- ಡೆವಲಪರ್ ಬಿಡುಗಡೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ
ಸರಿ, ನಾನು ಏನನ್ನು ನಿರೀಕ್ಷಿಸಿದೆ, ಸಹಜವಾಗಿ, ಹೊಸ ಜನರನ್ನು ಉತ್ಪಾದನೆಗೆ ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ. ಸರಿ, ತಾಳ್ಮೆಯನ್ನು ಗಳಿಸಿದ ನಂತರ, ನಾವು ಇತರರ ವಿಶ್ವಾಸವನ್ನು ಗಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ನಿರ್ವಾಹಕರೊಂದಿಗೆ ವಿಷಯಗಳು ತುಂಬಾ ಸರಳವಾಗಿಲ್ಲ.
ಕಾಯಿದೆ 1. ನಿರ್ವಾಹಕರು ಅದೃಶ್ಯರಾಗಿದ್ದಾರೆ.
ಬಿಡುಗಡೆಯ ದಿನ, ಡೆವಲಪರ್ ಮತ್ತು ನಿರ್ವಾಹಕರು ಸಂವಹನ ಮಾಡುವುದಿಲ್ಲ. ನಿರ್ವಾಹಕರು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಆದರೆ ಏಕೆ ಎಂದು ನಂತರ ನಿಮಗೆ ಅರ್ಥವಾಗುತ್ತದೆ. ನಿರ್ವಾಹಕರು ತತ್ವಬದ್ಧ ವ್ಯಕ್ತಿಯಾಗಿದ್ದಾರೆ, ಸಂದೇಶವಾಹಕರನ್ನು ಹೊಂದಿಲ್ಲ, ಅವರ ಫೋನ್ ಸಂಖ್ಯೆಯನ್ನು ಯಾರಿಗೂ ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಸಾಮಾಜಿಕ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಹೊಂದಿಲ್ಲ. ಅವನ ಫೋಟೋ ಎಲ್ಲೂ ಇಲ್ಲ, ನೀನು ಹೇಗಿದ್ದೀಯಾ? ಈ ವಾಯೇಜರ್ 15 ನೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಸ್ಥಾಪಿಸಲು ನಾವು ಸುಮಾರು 1 ನಿಮಿಷಗಳ ಕಾಲ ದಿಗ್ಭ್ರಮೆಗೊಂಡಿರುವ ಜವಾಬ್ದಾರಿಯುತ ವ್ಯವಸ್ಥಾಪಕರೊಂದಿಗೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತೇವೆ, ನಂತರ ಅವರು ಮುಗಿಸಿದ ಕಾರ್ಪೊರೇಟ್ ಇಮೇಲ್‌ನಲ್ಲಿ ಸಂದೇಶವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಾವು ಮೇಲ್ ಮೂಲಕ ಪತ್ರವ್ಯವಹಾರ ಮಾಡಲಿದ್ದೇವೆಯೇ? ಯಾಕಿಲ್ಲ? ಅನುಕೂಲಕರ, ಅಲ್ಲವೇ? ಸರಿ, ತಣ್ಣಗಾಗೋಣ. ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿದೆ, ಹಿಂತಿರುಗಿ ಇಲ್ಲ. ಸಂದೇಶವನ್ನು ಮತ್ತೊಮ್ಮೆ ಓದಿ. "ನಾನು ಮುಗಿಸಿದೆ". ನೀವು ಏನು ಮುಗಿಸಿದ್ದೀರಿ? ಎಲ್ಲಿ? ನಾನು ನಿನ್ನನ್ನು ಎಲ್ಲಿ ಹುಡುಕಬೇಕು? ಬಿಡುಗಡೆಗೆ 4 ಗಂಟೆಗಳ ಕಾಲ ಏಕೆ ಸಾಮಾನ್ಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ನಾವು ಅಭಿವೃದ್ಧಿ ಆಘಾತವನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಆದರೆ ನಾವು ಬಿಡುಗಡೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ. ಇನ್ನು ಬಿಡುಗಡೆಯ ಆಸೆಯೂ ಇಲ್ಲ.
ಕಾಯಿದೆ 2. ಆ ಆವೃತ್ತಿಯಲ್ಲ.
ಮುಂದಿನ ಬಿಡುಗಡೆ. ಅನುಭವವನ್ನು ಪಡೆದ ನಂತರ, ನಾವು ನಿರ್ವಾಹಕರಿಗಾಗಿ ಸರ್ವರ್‌ಗೆ ಅಗತ್ಯವಾದ ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ಲೈಬ್ರರಿಗಳ ಪಟ್ಟಿಗಳನ್ನು ರಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ಕೆಲವು ಆವೃತ್ತಿಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಯಾವಾಗಲೂ, ನಿರ್ವಾಹಕರು ಅಲ್ಲಿ ಏನನ್ನಾದರೂ ಮುಗಿಸಿದ್ದಾರೆ ಎಂಬ ದುರ್ಬಲ ರೇಡಿಯೊ ಸಿಗ್ನಲ್ ಅನ್ನು ನಾವು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಯು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಅದು ಸ್ವತಃ ಸುಮಾರು ಒಂದು ಗಂಟೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಒಂದು ನಿರ್ಣಾಯಕ ದೋಷವಿದೆ. ಪ್ರಮುಖ ಕಾರ್ಯವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮುಂದಿನ ಕೆಲವು ಗಂಟೆಗಳಲ್ಲಿ ಟ್ಯಾಂಬೊರಿನ್‌ಗಳೊಂದಿಗೆ ನೃತ್ಯ ಮಾಡುವುದು, ಕಾಫಿ ಮೈದಾನದಲ್ಲಿ ಅದೃಷ್ಟ ಹೇಳುವುದು ಮತ್ತು ಪ್ರತಿ ಕೋಡ್‌ನ ವಿವರವಾದ ವಿಮರ್ಶೆ. ಅಡ್ಮಿನ್ ಅವರು ಎಲ್ಲವನ್ನೂ ಮಾಡಿದ್ದಾರೆ ಎಂದು ಹೇಳುತ್ತಾರೆ. ವಕ್ರ ಡೆವಲಪರ್‌ಗಳು ಬರೆದ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸರ್ವರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅವನಿಗೆ ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳು? ಒಂದು ಗಂಟೆಯ ಕೊನೆಯಲ್ಲಿ, ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಲೈಬ್ರರಿಯ ಆವೃತ್ತಿಯನ್ನು ಚಾಟ್ ಮತ್ತು ಬಿಂಗೊಗೆ ಕಳುಹಿಸಲು ನಾವು ನಿರ್ವಾಹಕರನ್ನು ಪಡೆಯುತ್ತೇವೆ - ಇದು ನಮಗೆ ಅಗತ್ಯವಿರುವುದಲ್ಲ. ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸಲು ನಾವು ನಿರ್ವಾಹಕರನ್ನು ಕೇಳುತ್ತೇವೆ, ಆದರೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ OS ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಈ ಆವೃತ್ತಿಯ ಅನುಪಸ್ಥಿತಿಯ ಕಾರಣದಿಂದಾಗಿ ಅವರು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಾವು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಇಲ್ಲಿ, ಅವರ ಮೆಮೊರಿಯ ಹಿನ್ಸರಿತಗಳಿಂದ, ಮ್ಯಾನೇಜರ್ ಮತ್ತೊಂದು ನಿರ್ವಾಹಕರು ಈಗಾಗಲೇ ಕೈಯಿಂದ ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯನ್ನು ಸರಳವಾಗಿ ಜೋಡಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದಾರೆ ಎಂದು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಆದರೆ ಇಲ್ಲ, ನಮ್ಮವರು ಇದನ್ನು ಮಾಡುವುದಿಲ್ಲ. ನಿಯಮಗಳು ನಿಷೇಧಿಸುತ್ತವೆ. ಕಾರ್ಲ್, ನಾವು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಇಲ್ಲಿ ಕುಳಿತಿದ್ದೇವೆ, ಸಮಯದ ಮಿತಿ ಏನು?! ನಾವು ಮತ್ತೊಂದು ಆಘಾತವನ್ನು ಅನುಭವಿಸುತ್ತೇವೆ ಮತ್ತು ಹೇಗಾದರೂ ಬಿಡುಗಡೆಯನ್ನು ಮುಗಿಸುತ್ತೇವೆ.
ಕಾಯಿದೆ 3, ಚಿಕ್ಕದು
ತುರ್ತು ಟಿಕೆಟ್, ಉತ್ಪಾದನೆಯಲ್ಲಿರುವ ಬಳಕೆದಾರರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಪ್ರಮುಖ ಕಾರ್ಯವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಾವು ಒಂದೆರಡು ಗಂಟೆಗಳ ಕಾಲ ಇರಿಯುತ್ತೇವೆ ಮತ್ತು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಅಭಿವೃದ್ಧಿಯ ವಾತಾವರಣದಲ್ಲಿ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. php-fpm ಲಾಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಒಳ್ಳೆಯದು ಎಂಬ ಸ್ಪಷ್ಟ ತಿಳುವಳಿಕೆ ಇದೆ. ಆ ಸಮಯದಲ್ಲಿ ಯೋಜನೆಯಲ್ಲಿ ELK ಅಥವಾ Prometheus ನಂತಹ ಯಾವುದೇ ಲಾಗ್ ವ್ಯವಸ್ಥೆಗಳು ಇರಲಿಲ್ಲ. ನಾವು ಆಡಳಿತ ವಿಭಾಗಕ್ಕೆ ಟಿಕೆಟ್ ತೆರೆಯುತ್ತೇವೆ ಇದರಿಂದ ಅವರು ಸರ್ವರ್‌ನಲ್ಲಿ php-fpm ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತಾರೆ. ನಾವು ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಪ್ರವೇಶವನ್ನು ಕೇಳುತ್ತಿದ್ದೇವೆ ಎಂದು ಇಲ್ಲಿ ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಕಪ್ಪು ಕುಳಿ ಮತ್ತು ನಿರ್ವಾಹಕರು 24/7 ಕಾರ್ಯನಿರತರಾಗಿರುವ ಬಗ್ಗೆ ನಿಮಗೆ ನೆನಪಿಲ್ಲವೇ? ಲಾಗ್‌ಗಳನ್ನು ಸ್ವತಃ ನೋಡಲು ನೀವು ಅವರನ್ನು ಕೇಳಿದರೆ, ಇದು “ಈ ಜೀವನದಲ್ಲಿ ಅಲ್ಲ” ಆದ್ಯತೆಯ ಕಾರ್ಯವಾಗಿದೆ. ಟಿಕೆಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, ಆಡಳಿತ ವಿಭಾಗದ ಮುಖ್ಯಸ್ಥರಿಂದ ನಾವು ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ: "ನಿಮಗೆ ಉತ್ಪಾದನಾ ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶ ಅಗತ್ಯವಿಲ್ಲ, ದೋಷಗಳಿಲ್ಲದೆ ಬರೆಯಿರಿ." ಒಂದು ಪರದೆ.
ಕಾಯಿದೆ 4 ಮತ್ತು ನಂತರ
ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು, ಕಾನ್ಫಿಗರ್ ಮಾಡದ ಸಾಫ್ಟ್‌ವೇರ್, ಸಿದ್ಧವಿಲ್ಲದ ಸರ್ವರ್ ಲೋಡ್‌ಗಳು ಮತ್ತು ಇತರ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ನಾವು ಇನ್ನೂ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಡಜನ್ಗಟ್ಟಲೆ ಸಮಸ್ಯೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಿದ್ದೇವೆ. ಸಹಜವಾಗಿ, ಕೋಡ್ ದೋಷಗಳು ಸಹ ಇವೆ, ಎಲ್ಲಾ ಪಾಪಗಳಿಗಾಗಿ ನಾವು ನಿರ್ವಾಹಕರನ್ನು ದೂಷಿಸುವುದಿಲ್ಲ, ಆ ಯೋಜನೆಗಾಗಿ ನಾವು ಇನ್ನೊಂದು ವಿಶಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತೇವೆ. ನಾವು ಮೇಲ್ವಿಚಾರಕರ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಲಾದ ಸಾಕಷ್ಟು ಹಿನ್ನೆಲೆ ಕೆಲಸಗಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕೆಲವು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕ್ರಾನ್‌ಗೆ ಸೇರಿಸಬೇಕಾಗಿತ್ತು. ಕೆಲವೊಮ್ಮೆ ಇದೇ ಕಾರ್ಮಿಕರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದರು. ಕ್ಯೂ ಸರ್ವರ್‌ನಲ್ಲಿನ ಲೋಡ್ ಮಿಂಚಿನ ವೇಗದಲ್ಲಿ ಬೆಳೆಯಿತು ಮತ್ತು ದುಃಖದ ಬಳಕೆದಾರರು ತಿರುಗುವ ಲೋಡರ್ ಅನ್ನು ನೋಡಿದರು. ಅಂತಹ ಕಾರ್ಮಿಕರನ್ನು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸಲು, ಅವುಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಸಾಕು, ಆದರೆ ಮತ್ತೆ, ನಿರ್ವಾಹಕರು ಮಾತ್ರ ಇದನ್ನು ಮಾಡಬಹುದು. ಅಂತಹ ಮೂಲಭೂತ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಡೆಸುತ್ತಿರುವಾಗ, ಇಡೀ ದಿನವು ಹಾದುಹೋಗಬಹುದು. ಇಲ್ಲಿ, ಸಹಜವಾಗಿ, ವಕ್ರ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಕಾರ್ಮಿಕರನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡದಂತೆ ಬರೆಯಬೇಕು ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ, ಆದರೆ ಅವರು ಬಿದ್ದಾಗ, ಉತ್ಪಾದನೆಗೆ ಪ್ರವೇಶದ ಕೊರತೆಯಿಂದಾಗಿ ಕೆಲವೊಮ್ಮೆ ಅಸಾಧ್ಯವಾದ ಕಾರಣವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು. ಕೋರ್ಸ್, ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಡೆವಲಪರ್ನಿಂದ ಲಾಗ್ಗಳ ಕೊರತೆ.
ರೂಪಾಂತರ.
ಇದೆಲ್ಲವನ್ನೂ ಬಹಳ ಸಮಯದಿಂದ ಸಹಿಸಿಕೊಂಡ ನಂತರ, ತಂಡದೊಂದಿಗೆ ನಾವು ನಮಗೆ ಹೆಚ್ಚು ಯಶಸ್ವಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಮುನ್ನಡೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ?
- ಅಭಿವರ್ಧಕರು ಮತ್ತು ಆಡಳಿತ ವಿಭಾಗದ ನಡುವೆ ಗುಣಮಟ್ಟದ ಸಂವಹನದ ಕೊರತೆ
- ನಿರ್ವಾಹಕರು, ಇದು ತಿರುಗುತ್ತದೆ(!), ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ರಚಿಸಲಾಗಿದೆ, ಅದು ಯಾವ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಾಗಿಲ್ಲ.
- ಉತ್ಪಾದನಾ ಪರಿಸರವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಡೆವಲಪರ್‌ಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
- ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯು ತುಂಬಾ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
- ಅಸ್ಥಿರ ಬಿಡುಗಡೆಗಳು.
ನಾವೇನು ಮಾಡಿದ್ದೇವೆ?
ಪ್ರತಿ ಬಿಡುಗಡೆಗೆ, ಬಿಡುಗಡೆ ಟಿಪ್ಪಣಿಗಳ ಪಟ್ಟಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ, ಇದು ಮುಂದಿನ ಬಿಡುಗಡೆ ಕೆಲಸ ಮಾಡಲು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾಡಬೇಕಾದ ಕೆಲಸದ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಪಟ್ಟಿಯು ಹಲವಾರು ವಿಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ನಿರ್ವಾಹಕರು, ಬಿಡುಗಡೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ವ್ಯಕ್ತಿ ಮತ್ತು ಡೆವಲಪರ್ ನಿರ್ವಹಿಸಬೇಕಾದ ಕೆಲಸ. ಡೆವಲಪರ್‌ಗಳು ಎಲ್ಲಾ ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಿಗೆ ರೂಟ್-ಅಲ್ಲದ ಪ್ರವೇಶವನ್ನು ಪಡೆದರು, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅಭಿವೃದ್ಧಿಯನ್ನು ವೇಗಗೊಳಿಸಿತು ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳು ಉತ್ಪಾದನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಯಾವ ಸೇವೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಎಲ್ಲಿ ಮತ್ತು ಎಷ್ಟು ಪ್ರತಿಕೃತಿಗಳ ವೆಚ್ಚದ ಬಗ್ಗೆ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿದೆ. ಕೆಲವು ಯುದ್ಧ ಲೋಡ್‌ಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ, ಇದು ನಿಸ್ಸಂದೇಹವಾಗಿ ಕೋಡ್‌ನ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಬಿಡುಗಡೆ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ ಸಂವಹನವು ತ್ವರಿತ ಸಂದೇಶವಾಹಕರ ಚಾಟ್‌ನಲ್ಲಿ ನಡೆಯಿತು. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಎಲ್ಲಾ ಕ್ರಿಯೆಗಳ ಲಾಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಸಂವಹನವು ಹತ್ತಿರದ ವಾತಾವರಣದಲ್ಲಿ ನಡೆಯಿತು. ಕ್ರಿಯೆಗಳ ಇತಿಹಾಸವನ್ನು ಹೊಂದಿರುವ ಹೊಸ ಉದ್ಯೋಗಿಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ವೇಗವಾಗಿ ಪರಿಹರಿಸಲು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿದ್ದಾರೆ. ಇದು ವಿರೋಧಾಭಾಸವಾಗಿದೆ, ಆದರೆ ಇದು ಆಗಾಗ್ಗೆ ನಿರ್ವಾಹಕರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಾನು ಖಚಿತವಾಗಿ ಹೇಳಲು ಕೈಗೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಯೋಜನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ವಾಹಕರು ಹೆಚ್ಚು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ್ದಾರೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ನಾವು ಕೆಲವು ವಿವರಗಳನ್ನು ಪರಸ್ಪರ ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ. ಸರಾಸರಿ ಬಿಡುಗಡೆಯ ಸಮಯವನ್ನು ಒಂದು ಗಂಟೆಗೆ ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ನಾವು 30-40 ನಿಮಿಷಗಳಲ್ಲಿ ಮುಗಿಸಿದ್ದೇವೆ. ದೋಷಗಳ ಸಂಖ್ಯೆ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ, ಇಲ್ಲದಿದ್ದರೆ ಹತ್ತು ಪಟ್ಟು. ಸಹಜವಾಗಿ, ಆಟೋಟೆಸ್ಟ್‌ಗಳಂತಹ ಬಿಡುಗಡೆಯ ಸಮಯದ ಕಡಿತದ ಮೇಲೆ ಇತರ ಅಂಶಗಳು ಪ್ರಭಾವ ಬೀರಿವೆ. ಪ್ರತಿ ಬಿಡುಗಡೆಯ ನಂತರ, ನಾವು ಪೂರ್ವಾವಲೋಕನಗಳನ್ನು ನಡೆಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಇದರಿಂದ ಇಡೀ ತಂಡಕ್ಕೆ ಹೊಸದೇನಿದೆ, ಏನನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಮತ್ತು ಏನನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ನಿರ್ವಾಹಕರು ಯಾವಾಗಲೂ ಅವರ ಬಳಿಗೆ ಬರುತ್ತಿರಲಿಲ್ಲ, ಅಲ್ಲದೆ, ನಿರ್ವಾಹಕರು ಕಾರ್ಯನಿರತರಾಗಿದ್ದಾರೆ ... ಡೆವಲಪರ್ ಆಗಿ ನನ್ನ ಕೆಲಸದ ತೃಪ್ತಿ ನಿಸ್ಸಂದೇಹವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ. ನಿಮ್ಮ ಸಾಮರ್ಥ್ಯದ ಪ್ರದೇಶದಲ್ಲಿನ ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ನೀವು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸಿದಾಗ, ನೀವು ಮೇಲಿರುವಿರಿ. ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ನಾವು ಡೆವೊಪ್ಸ್ ಸಂಸ್ಕೃತಿಯನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ ಎಂದು ನಂತರ ನಾನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇನೆ, ಸಂಪೂರ್ಣವಾಗಿ ಅಲ್ಲ, ಆದರೆ ರೂಪಾಂತರದ ಆರಂಭವೂ ಸಹ ಪ್ರಭಾವಶಾಲಿಯಾಗಿದೆ.
ಕಥೆ ಮೂರು
ಪ್ರಾರಂಭ. ಒಬ್ಬ ನಿರ್ವಾಹಕ, ಸಣ್ಣ ಅಭಿವೃದ್ಧಿ ಇಲಾಖೆ. ಆಗಮನದ ನಂತರ ನಾನು ಸಂಪೂರ್ಣ ಶೂನ್ಯ, ಏಕೆಂದರೆ... ಮೇಲ್ ಹೊರತುಪಡಿಸಿ ನನಗೆ ಎಲ್ಲಿಯೂ ಪ್ರವೇಶವಿಲ್ಲ. ನಾವು ನಿರ್ವಾಹಕರಿಗೆ ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಪ್ರವೇಶವನ್ನು ಕೇಳುತ್ತೇವೆ. ಜೊತೆಗೆ, ಅವರು ಹೊಸ ಉದ್ಯೋಗಿ ಮತ್ತು ಲಾಗಿನ್‌ಗಳು / ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನೀಡುವ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ ತಿಳಿದಿದ್ದಾರೆ ಎಂಬ ಮಾಹಿತಿ ಇದೆ. ಅವರು ರೆಪೊಸಿಟರಿ ಮತ್ತು VPN ನಿಂದ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತಾರೆ. ವಿಕಿ, ಟೀಮ್‌ಸಿಟಿ, ರನ್‌ಡೆಸ್ಕ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಏಕೆ ನೀಡಬೇಕು? ಸಂಪೂರ್ಣ ಬ್ಯಾಕೆಂಡ್ ಭಾಗವನ್ನು ಬರೆಯಲು ಕರೆದ ವ್ಯಕ್ತಿಗೆ ಅನುಪಯುಕ್ತ ವಿಷಯಗಳು. ಕಾಲಾನಂತರದಲ್ಲಿ ಮಾತ್ರ ನಾವು ಕೆಲವು ಸಾಧನಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆಗಮನವು ಸಹಜವಾಗಿ ಅಪನಂಬಿಕೆಯನ್ನು ಎದುರಿಸಿತು. ಚಾಟ್‌ಗಳು ಮತ್ತು ಪ್ರಮುಖ ಪ್ರಶ್ನೆಗಳ ಮೂಲಕ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಮೂಲಸೌಕರ್ಯವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಧಾನವಾಗಿ ಭಾವನೆಯನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇನೆ. ಮೂಲತಃ ನಾನು ಏನನ್ನೂ ಗುರುತಿಸುವುದಿಲ್ಲ. ಉತ್ಪಾದನೆಯು ಮೊದಲಿನಂತೆಯೇ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿದೆ. ಆದರೆ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ, ಪರೀಕ್ಷೆಗೆ ಬಳಸುವ ಸ್ಟೇಜ್ ಸರ್ವರ್‌ಗಳು ಸಹ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿದೆ. ನಾವು ಅಲ್ಲಿ Git ನಿಂದ ಶಾಖೆಯನ್ನು ನಿಯೋಜಿಸುವುದನ್ನು ಬಿಟ್ಟು ಬೇರೇನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಾವು .env ಫೈಲ್‌ಗಳಂತೆ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂತಹ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡಲಾಗುವುದಿಲ್ಲ. ಪರೀಕ್ಷಾ ಸರ್ವರ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂರಚನೆಯಲ್ಲಿ ರೇಖೆಯನ್ನು ಬದಲಾಯಿಸಲು ನೀವು ಬೇಡಿಕೊಳ್ಳಬೇಕು. (ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ನಿರ್ವಾಹಕರು ತಮ್ಮನ್ನು ತಾವು ಮುಖ್ಯವೆಂದು ಭಾವಿಸುವುದು ಅತ್ಯಗತ್ಯ ಎಂಬ ಸಿದ್ಧಾಂತವಿದೆ; ಸಂರಚನೆಯಲ್ಲಿ ಸಾಲುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಅವರನ್ನು ಕೇಳದಿದ್ದರೆ, ಅವರು ಸರಳವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ). ಒಳ್ಳೆಯದು, ಯಾವಾಗಲೂ, ಇದು ಅನುಕೂಲಕರವಾಗಿಲ್ಲವೇ? ಇದು ಬೇಗನೆ ನೀರಸವಾಗುತ್ತದೆ, ನಿರ್ವಾಹಕರೊಂದಿಗಿನ ನೇರ ಸಂಭಾಷಣೆಯ ನಂತರ ಡೆವಲಪರ್‌ಗಳು ಕೆಟ್ಟ ಕೋಡ್ ಬರೆಯಲು ಹುಟ್ಟಿದ್ದಾರೆ ಎಂದು ನಾವು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ, ಸ್ವಭಾವತಃ ಅಸಮರ್ಥ ವ್ಯಕ್ತಿಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಉತ್ಪಾದನೆಯಿಂದ ದೂರವಿಡುವುದು ಉತ್ತಮ. ಆದರೆ ಇಲ್ಲಿ ಪರೀಕ್ಷಾ ಸರ್ವರ್‌ಗಳಿಂದಲೂ, ಕೇವಲ ಸಂದರ್ಭದಲ್ಲಿ. ಸಂಘರ್ಷವು ತ್ವರಿತವಾಗಿ ಉಲ್ಬಣಗೊಳ್ಳುತ್ತಿದೆ. ನಿರ್ವಾಹಕರೊಂದಿಗೆ ಯಾವುದೇ ಸಂವಹನವಿಲ್ಲ. ಅವನು ಒಬ್ಬಂಟಿಯಾಗಿರುವುದರ ಮೂಲಕ ಪರಿಸ್ಥಿತಿಯು ಉಲ್ಬಣಗೊಂಡಿದೆ. ಕೆಳಗಿನವು ಒಂದು ವಿಶಿಷ್ಟ ಚಿತ್ರವಾಗಿದೆ. ಬಿಡುಗಡೆ. ಕೆಲವು ಕ್ರಿಯಾತ್ಮಕತೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮಗೆ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಡೆವಲಪರ್‌ಗಳಿಂದ ವಿವಿಧ ಆಲೋಚನೆಗಳನ್ನು ಚಾಟ್‌ಗೆ ಎಸೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಿರ್ವಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ಡೆವಲಪರ್‌ಗಳನ್ನು ದೂರುತ್ತಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ನಂತರ ಅವರು ಚಾಟ್‌ನಲ್ಲಿ ಬರೆಯುತ್ತಾರೆ, ನಿರೀಕ್ಷಿಸಿ, ನಾನು ಅವನನ್ನು ಸರಿಪಡಿಸಿದೆ. ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕಥೆಯನ್ನು ಬಿಡಲು ಕೇಳಿದಾಗ, ನಾವು ವಿಷಕಾರಿ ಮನ್ನಿಸುವಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಹಾಗೆ, ನಿಮ್ಮ ಮೂಗು ಸೇರದ ಸ್ಥಳದಲ್ಲಿ ಅಂಟಿಕೊಳ್ಳಬೇಡಿ. ಡೆವಲಪರ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕು. ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿನ ಅನೇಕ ದೇಹದ ಚಲನೆಗಳು ಒಬ್ಬ ವ್ಯಕ್ತಿಯ ಮೂಲಕ ಹೋದಾಗ ಮತ್ತು ಎಲ್ಲರಿಗೂ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಲು ಅವನಿಗೆ ಮಾತ್ರ ಪ್ರವೇಶವಿರುವಾಗ ಪರಿಸ್ಥಿತಿ ಅತ್ಯಂತ ದುಃಖಕರವಾಗಿದೆ. ಅಂತಹ ವ್ಯಕ್ತಿಯು ಭಯಾನಕ ಅಡಚಣೆಯಾಗಿದೆ. ಡೆವೊಪ್ಸ್ ಐಡಿಯಾಗಳು ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಅಂತಹ ಜನರು ಡೆವೊಪ್ಸ್ ಕಲ್ಪನೆಗಳ ಕೆಟ್ಟ ಶತ್ರುಗಳು. ದುರದೃಷ್ಟವಶಾತ್, ಇಲ್ಲಿ ಪರದೆ ಮುಚ್ಚುತ್ತದೆ.
PS ಜನರೊಂದಿಗೆ ಚಾಟ್‌ಗಳಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳ ವಿರುದ್ಧ ನಿರ್ವಾಹಕರ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮಾತನಾಡಿದ ನಂತರ, ನನ್ನ ನೋವನ್ನು ಹಂಚಿಕೊಂಡ ಜನರನ್ನು ನಾನು ಭೇಟಿಯಾದೆ. ಆದರೆ ಈ ರೀತಿಯ ಯಾವುದನ್ನೂ ಎದುರಿಸಿಲ್ಲ ಎಂದು ಹೇಳುವವರೂ ಇದ್ದರು. ಒಂದು devops ಸಮ್ಮೇಳನದಲ್ಲಿ, ನಾನು ಆಂಟನ್ ಇಸಾನಿನ್ (ಆಲ್ಫಾ ಬ್ಯಾಂಕ್) ಅವರನ್ನು ನಿರ್ವಾಹಕರ ರೂಪದಲ್ಲಿ ಅಡಚಣೆಯ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ನಿಭಾಯಿಸಿದರು ಎಂದು ಕೇಳಿದೆ, ಅದಕ್ಕೆ ಅವರು ಹೇಳಿದರು: "ನಾವು ಅವುಗಳನ್ನು ಗುಂಡಿಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ." ಅಂದಹಾಗೆ ಅವನ ಭಾಗವಹಿಸುವಿಕೆಯೊಂದಿಗೆ. ಶತ್ರುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಉತ್ತಮ ನಿರ್ವಾಹಕರು ಇದ್ದಾರೆ ಎಂದು ನಾನು ನಂಬಲು ಬಯಸುತ್ತೇನೆ. ಮತ್ತು ಹೌದು, ಆರಂಭದಲ್ಲಿ ಚಿತ್ರವು ನಿಜವಾದ ಪತ್ರವ್ಯವಹಾರವಾಗಿದೆ.
ಮೂಲ: www.habr.com