ಎಲ್ಲರಿಗೂ ಶುಕ್ರವಾರದ ಶುಭಾಶಯಗಳು! ಸ್ನೇಹಿತರೇ, ಇಂದು ನಾವು ಕೋರ್ಸ್‌ಗೆ ಮೀಸಲಾಗಿರುವ ಪ್ರಕಟಣೆಗಳ ಸರಣಿಯನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ , ಏಕೆಂದರೆ ಕೋರ್ಸ್‌ಗಾಗಿ ಹೊಸ ಗುಂಪಿನಲ್ಲಿ ತರಗತಿಗಳು ಮುಂದಿನ ವಾರದ ಕೊನೆಯಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ಆದ್ದರಿಂದ, ಪ್ರಾರಂಭಿಸೋಣ!
ಮಾನಿಟರಿಂಗ್ ಆಗಿದೆ ಕೇವಲ. ಇದು ಗೊತ್ತಿರುವ ಸತ್ಯ. Nagios ಅನ್ನು ತರಲು, ರಿಮೋಟ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ NRPE ಅನ್ನು ರನ್ ಮಾಡಿ, NRPE TCP ಪೋರ್ಟ್ 5666 ನಲ್ಲಿ Nagios ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು ನೀವು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ.
ಇದು ತುಂಬಾ ಸುಲಭ, ಅದು ಆಸಕ್ತಿದಾಯಕವಲ್ಲ. ಈಗ ನೀವು CPU ಸಮಯ, ಡಿಸ್ಕ್ ಸಬ್‌ಸಿಸ್ಟಮ್, RAM ಗಾಗಿ ಮೂಲಭೂತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಇದನ್ನು ನ್ಯಾಜಿಯೋಸ್ ಮತ್ತು NRPE ಗೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ. ಆದರೆ ಇದು ವಾಸ್ತವವಾಗಿ "ಮೇಲ್ವಿಚಾರಣೆ" ಅಲ್ಲ. ಇದು ಆರಂಭವಷ್ಟೇ.
(ಸಾಮಾನ್ಯವಾಗಿ ಅವರು PNP4Nagios, RRDtool ಮತ್ತು Thruk ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತಾರೆ, Slack ನಲ್ಲಿ ಅಧಿಸೂಚನೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ ಮತ್ತು ನೇರವಾಗಿ nagiosexchange ಗೆ ಹೋಗುತ್ತಾರೆ, ಆದರೆ ಇದೀಗ ಅದನ್ನು ಬಿಡೋಣ).
ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣೆ ವಾಸ್ತವವಾಗಿ ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ, ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆಂತರಿಕ ಅಂಶಗಳನ್ನು ನೀವು ನಿಜವಾಗಿಯೂ ತಿಳಿದುಕೊಳ್ಳಬೇಕು.
ಮೇಲ್ವಿಚಾರಣೆ ಕಷ್ಟವೇ?
ಯಾವುದೇ ಸರ್ವರ್, ಅದು ಲಿನಕ್ಸ್ ಅಥವಾ ವಿಂಡೋಸ್ ಆಗಿರಲಿ, ವ್ಯಾಖ್ಯಾನದಿಂದ ಕೆಲವು ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ. ಅಪಾಚೆ, ಸಾಂಬಾ, ಟಾಮ್‌ಕ್ಯಾಟ್, ಫೈಲ್ ಸಂಗ್ರಹಣೆ, ಎಲ್‌ಡಿಎಪಿ - ಈ ಎಲ್ಲಾ ಸೇವೆಗಳು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವಿಷಯಗಳಲ್ಲಿ ಹೆಚ್ಚು ಕಡಿಮೆ ಅನನ್ಯವಾಗಿವೆ. ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ, ತನ್ನದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ. ಸರ್ವರ್ ಲೋಡ್ ಆಗಿರುವಾಗ ನಿಮಗೆ ಆಸಕ್ತಿದಾಯಕವಾದ ಮೆಟ್ರಿಕ್‌ಗಳು, KPI ಗಳು (ಪ್ರಮುಖ ಕಾರ್ಯಕ್ಷಮತೆ ಸೂಚಕಗಳು) ಪಡೆಯಲು ವಿವಿಧ ಮಾರ್ಗಗಳಿವೆ.
ಫೋಟೋ ಲೇಖಕ ಮೇಲೆ
(ನನ್ನ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ನಿಯಾನ್ ನೀಲಿ ಬಣ್ಣದ್ದಾಗಿರಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ - ಸ್ವಪ್ನವಾಗಿ ನಿಟ್ಟುಸಿರು ಬಿಡುತ್ತಿದೆ -... ಹ್ಮ್...)
ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ಯಾವುದೇ ಸಾಫ್ಟ್‌ವೇರ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ಅಪಾಚೆ ಮಾಡ್ಯೂಲ್ ಹೊಂದಿದೆ mod-status, ಸರ್ವರ್ ಸ್ಥಿತಿ ಪುಟವನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತಿದೆ. Nginx ಹೊಂದಿದೆ - stub_status. ಟಾಮ್‌ಕ್ಯಾಟ್ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತೋರಿಸುವ JMX ಅಥವಾ ಕಸ್ಟಮ್ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. MySQL "ಜಾಗತಿಕ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸು" ಇತ್ಯಾದಿ ಆಜ್ಞೆಯನ್ನು ಹೊಂದಿದೆ.
ಆದ್ದರಿಂದ ಡೆವಲಪರ್‌ಗಳು ಅವರು ರಚಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಏಕೆ ನಿರ್ಮಿಸುವುದಿಲ್ಲ?
ಅಭಿವರ್ಧಕರು ಮಾತ್ರ ಇದನ್ನು ಮಾಡುತ್ತಿದ್ದಾರೆಯೇ?
ಮೆಟ್ರಿಕ್ಸ್ ಎಂಬೆಡಿಂಗ್‌ಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಟ್ಟದ ಉದಾಸೀನತೆಯು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ. ನಾನು ಟಾಮ್‌ಕ್ಯಾಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಕಂಪನಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಟಾಮ್‌ಕ್ಯಾಟ್ ದೋಷ ಲಾಗ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ತಮ್ಮದೇ ಆದ ಯಾವುದೇ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸಿಲ್ಲ, ಸೇವಾ ಚಟುವಟಿಕೆಯ ಯಾವುದೇ ಲಾಗ್‌ಗಳನ್ನು ಒದಗಿಸಿಲ್ಲ. ಕೆಲವು ಡೆವಲಪರ್‌ಗಳು ಬಹಳಷ್ಟು ಲಾಗ್‌ಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಅದು ಸಿಸ್ಟಂ ನಿರ್ವಾಹಕರಿಗೆ ಏನೂ ಅರ್ಥವಾಗುವುದಿಲ್ಲ, ಅವರು ಬೆಳಿಗ್ಗೆ 3:15 ಕ್ಕೆ ಅವುಗಳನ್ನು ಓದಲು ಸಾಕಷ್ಟು ದುರದೃಷ್ಟಕರ.
ಫೋಟೋ ಲೇಖಕ ಮೇಲೆ
ಅಂತಹ ಉತ್ಪನ್ನಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಸಿಸ್ಟಂ ಇಂಜಿನಿಯರ್‌ಗಳು ಸಹ ಪರಿಸ್ಥಿತಿಗೆ ಕೆಲವು ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಕೆಲವು ಸಿಸ್ಟಮ್‌ಗಳ ಎಂಜಿನಿಯರ್‌ಗಳು ಲಾಗ್‌ಗಳಿಂದ ಅರ್ಥಪೂರ್ಣ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಲು ಪ್ರಯತ್ನಿಸಲು ಸಮಯ ಅಥವಾ ಕಾಳಜಿಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ, ಆ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂದರ್ಭವಿಲ್ಲದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಟುವಟಿಕೆಯ ಬೆಳಕಿನಲ್ಲಿ ಅವುಗಳನ್ನು ಅರ್ಥೈಸುವ ಸಾಮರ್ಥ್ಯವಿಲ್ಲ. "ಏನೋ ಪ್ರಸ್ತುತ (ಅಥವಾ ಶೀಘ್ರದಲ್ಲೇ) ತಪ್ಪಾಗಿದೆ" ಸೂಚಕಗಳನ್ನು ಹೊರತುಪಡಿಸಿ, ಅದರಿಂದ ಅವರು ಹೇಗೆ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನು ಕೆಲವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಮೆಟ್ರಿಕ್‌ಗಳ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ ಚಿಂತನೆಯಲ್ಲಿ ಬದಲಾವಣೆಯು ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಸಿಸ್ಟಮ್ ಎಂಜಿನಿಯರ್‌ಗಳಲ್ಲಿಯೂ ಸಂಭವಿಸಬೇಕು.
ಯಾವುದೇ ಸಿಸ್ಟಂ ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ನಿರ್ಣಾಯಕ ಘಟನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ಅವು ಸಂಭವಿಸದಂತೆ ನೋಡಿಕೊಳ್ಳಬೇಕು, ಮೆಟ್ರಿಕ್‌ಗಳ ಕೊರತೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಹಾಗೆ ಮಾಡಲು ಅಡ್ಡಿಯಾಗುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಸಿಸ್ಟಂ ಎಂಜಿನಿಯರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಕಂಪನಿಗೆ ಹಣ ಗಳಿಸಲು ಕೋಡ್‌ನೊಂದಿಗೆ ಟಿಂಕರ್ ಮಾಡುವುದಿಲ್ಲ. ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸುವಲ್ಲಿ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಅರಿವು ಮೂಡಿಸುವಲ್ಲಿ ಸಿಸ್ಟಮ್ಸ್ ಎಂಜಿನಿಯರ್‌ನ ಜವಾಬ್ದಾರಿಯ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಮುಖ ಡೆವಲಪರ್‌ಗಳು ಅವರಿಗೆ ಅಗತ್ಯವಿದೆ.
ಇದು ವಿಷಯವನ್ನು ವಿಭಜಿಸುತ್ತದೆ
ಡೆವಪ್ಸ್ ಮನಸ್ಥಿತಿಯು ಅಭಿವೃದ್ಧಿ (ಡೆವ್) ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ (ಆಪ್ಸ್) ಚಿಂತನೆಯ ನಡುವಿನ ಸಿನರ್ಜಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. "Devops" ಎಂದು ಹೇಳಿಕೊಳ್ಳುವ ಯಾವುದೇ ಕಂಪನಿಯು ಕಡ್ಡಾಯವಾಗಿ:
- ಅವರು ಬಹುಶಃ ಮಾಡದ ವಿಷಯಗಳನ್ನು ಹೇಳುವುದು (ದಿ ಪ್ರಿನ್ಸೆಸ್ ಬ್ರೈಡ್ ಮೆಮೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿ - "ಇದರ ಅರ್ಥವೇನೆಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ!")
- ನಿರಂತರ ಉತ್ಪನ್ನ ಸುಧಾರಣೆಯ ಮನೋಭಾವವನ್ನು ಪ್ರೋತ್ಸಾಹಿಸಿ.
ನೀವು ಉತ್ಪನ್ನವನ್ನು ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಅದು ಪ್ರಸ್ತುತ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಸುಧಾರಿಸಲಾಗಿದೆ ಎಂದು ತಿಳಿಯಿರಿ. ಉತ್ಪನ್ನದ ಘಟಕಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಅದು ಅವಲಂಬಿಸಿರುವ ಸೇವೆಗಳು, ಅದರ ಮುಖ್ಯ ನೋವು ಅಂಶಗಳು ಮತ್ತು ಅಡಚಣೆಗಳು ನಿಮಗೆ ಅರ್ಥವಾಗದಿದ್ದರೆ ಉತ್ಪನ್ನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಸಂಭಾವ್ಯ ಅಡಚಣೆಗಳಿಗಾಗಿ ನೀವು ವೀಕ್ಷಿಸದಿದ್ದರೆ, ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್ ಬರೆಯುವಾಗ ನೀವು ಐದು ವೈಸ್ ತಂತ್ರವನ್ನು ಅನುಸರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಉತ್ಪನ್ನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಅಥವಾ ಅದು "ಸಾಮಾನ್ಯ ಮತ್ತು ಸಂತೋಷ" ಹೇಗಿದೆ ಎಂದು ತಿಳಿಯಲು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಪರದೆಯಲ್ಲಿ ಇರಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಎಡಕ್ಕೆ ಶಿಫ್ಟ್ ಮಾಡಿ, ಎಡಕ್ಕೆ, ನಾನು LEEEE ಎಂದು ಹೇಳಿದೆ-
ನನಗೆ, ಡೆವೊಪ್ಸ್‌ನ ಪ್ರಮುಖ ತತ್ವಗಳಲ್ಲಿ ಒಂದು "ಎಡಕ್ಕೆ ಶಿಫ್ಟ್" ಆಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಎಡಕ್ಕೆ ಶಿಫ್ಟ್ ಎಂದರೆ ಸಾಧ್ಯತೆಯನ್ನು ಬದಲಾಯಿಸುವುದು (ಜವಾಬ್ದಾರಿ ಇಲ್ಲ, ಆದರೆ ಸಾಮರ್ಥ್ಯಗಳು ಮಾತ್ರ) ಸಾಫ್ಟ್‌ವೇರ್ ಡೆಲಿವರಿ ಲೈಫ್ ಸೈಕಲ್‌ನಲ್ಲಿ ಎಡಕ್ಕೆ ಕಾರ್ಯಕ್ಷಮತೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ರಚಿಸುವುದು, ಲಾಗ್‌ಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸುವುದು ಇತ್ಯಾದಿಗಳಂತಹ ಸಿಸ್ಟಂ ಎಂಜಿನಿಯರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಳಜಿವಹಿಸುವ ಕೆಲಸಗಳನ್ನು ಮಾಡಲು.
ಫೋಟೋ ಲೇಖಕ ಮೇಲೆ
ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳು ಕಂಪನಿಯು ಅದರ ಎಲ್ಲಾ ರೂಪಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು, ಲಾಗಿಂಗ್, ಮಾನಿಟರಿಂಗ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕೈಗೊಳ್ಳಲು ಬಳಸುವ ಮೇಲ್ವಿಚಾರಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸಲು ಮತ್ತು ತಿಳಿದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅವರ ಉತ್ಪನ್ನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವೀಕ್ಷಿಸಿ. ಡೆವಲಪರ್‌ಗಳು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನೋಡುವವರೆಗೆ ಮತ್ತು ಅವರು ಹೇಗೆ ಕಾಣುತ್ತಾರೆ, ಉತ್ಪನ್ನದ ಮಾಲೀಕರು ಮುಂದಿನ ಬ್ರೀಫಿಂಗ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು CTO ಗೆ ಹೇಗೆ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತಾರೆ, ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವವರೆಗೆ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಪ್ರಯತ್ನ ಮತ್ತು ಸಮಯವನ್ನು ಹೂಡಿಕೆ ಮಾಡಲು ನೀವು ಅವರನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ
- ನಿಮ್ಮ ಕುದುರೆಯನ್ನು ನೀರಿಗೆ ಕರೆದೊಯ್ಯಿರಿ. ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅವರು ತಮಗಾಗಿ ಎಷ್ಟು ತೊಂದರೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸಿ, ಅವರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸರಿಯಾದ KPI ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಅವರಿಗೆ ಸಹಾಯ ಮಾಡಿ ಇದರಿಂದ CTO ನಿಂದ ಕಿರುಚುತ್ತಿರುವ ಉತ್ಪನ್ನ ಮಾಲೀಕರಿಂದ ಕಡಿಮೆ ಕೂಗು ಇರುತ್ತದೆ. ನಿಧಾನವಾಗಿ ಮತ್ತು ಶಾಂತವಾಗಿ ಅವರನ್ನು ಬೆಳಕಿಗೆ ತನ್ನಿ. ಅದು ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ಲಂಚ ನೀಡಿ, ಬೆದರಿಕೆ ಹಾಕಿ ಮತ್ತು ಆದಷ್ಟು ಬೇಗ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆಯುವುದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅವರಿಗೆ ಅಥವಾ ಉತ್ಪನ್ನ ಮಾಲೀಕರಿಗೆ ಲಂಚ ನೀಡಿ, ತದನಂತರ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಎಳೆಯಿರಿ. ಇದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಇದನ್ನು ಆದ್ಯತೆಯಾಗಿ ನೋಡಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಉತ್ಪನ್ನದ ಮಾರ್ಗಸೂಚಿಯು ಅನೇಕ ಆದಾಯವನ್ನು ಉತ್ಪಾದಿಸುವ ಯೋಜನೆಗಳನ್ನು ಬಾಕಿಯಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಉತ್ಪನ್ನದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಖರ್ಚು ಮಾಡಿದ ಸಮಯ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಸಮರ್ಥಿಸಲು ನಿಮಗೆ ವ್ಯಾಪಾರ ಪ್ರಕರಣದ ಅಗತ್ಯವಿದೆ.
- ಸಿಸ್ಟಂ ಇಂಜಿನಿಯರ್‌ಗಳು ಉತ್ತಮ ನಿದ್ರೆ ಪಡೆಯಲು ಸಹಾಯ ಮಾಡಿ. ಯಾವುದೇ ಉತ್ಪನ್ನವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು "ಬಿಡುಗಡೆ ಮಾಡೋಣ" ಪರಿಶೀಲನಾಪಟ್ಟಿಯನ್ನು ಬಳಸುವುದು ಒಳ್ಳೆಯದು ಎಂದು ಅವರಿಗೆ ತೋರಿಸಿ. ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಮುಚ್ಚಲ್ಪಟ್ಟಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಏನು ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಿ ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಮೂಲಕ ರಾತ್ರಿಯಲ್ಲಿ ಉತ್ತಮ ನಿದ್ರೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಯಾವುದೇ ಡೆವಲಪರ್, ಉತ್ಪನ್ನ ಮಾಲೀಕರು ಅಥವಾ CTO ಅವರನ್ನು ಕೆರಳಿಸಲು ಮತ್ತು ನಿರಾಶೆಗೊಳಿಸಲು ಸರಿಯಾದ ಮಾರ್ಗವೆಂದರೆ ನಿರಂತರ ಮತ್ತು ವಿರೋಧಿಸುವುದು. ಈ ನಡವಳಿಕೆಯು ಯಾವುದೇ ಉತ್ಪನ್ನದ ಬಿಡುಗಡೆಯ ದಿನಾಂಕದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ನೀವು ಮತ್ತೆ ಕೊನೆಯ ನಿಮಿಷದವರೆಗೆ ಕಾಯುತ್ತಿದ್ದರೆ, ಮತ್ತೆ ಎಡಕ್ಕೆ ವರ್ಗಾಯಿಸಿ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಯೋಜನೆಯಲ್ಲಿ ಪಡೆಯಿರಿ. ಅಗತ್ಯವಿದ್ದರೆ, ಉತ್ಪನ್ನ ಸಭೆಗಳಿಗೆ ನಿಮ್ಮ ದಾರಿ ಮಾಡಿಕೊಳ್ಳಿ. ನಕಲಿ ಮೀಸೆ ಮತ್ತು ಭಾವನೆ ಅಥವಾ ಏನನ್ನಾದರೂ ಧರಿಸಿ, ಅದು ಎಂದಿಗೂ ವಿಫಲವಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕಾಳಜಿಗಳನ್ನು ಸಂವಹಿಸಿ, ಸ್ಪಷ್ಟ ಪ್ರಯೋಜನಗಳನ್ನು ಪ್ರದರ್ಶಿಸಿ ಮತ್ತು ಸುವಾರ್ತೆ ಮಾಡಿ.
- ಅಭಿವೃದ್ಧಿ (dev) ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳು (ops) ಎರಡೂ ಉತ್ಪನ್ನದ ಮೆಟ್ರಿಕ್‌ಗಳು ಕೆಂಪು ವಲಯಕ್ಕೆ ಚಲಿಸುವ ಅರ್ಥ ಮತ್ತು ಪರಿಣಾಮಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಉತ್ಪನ್ನದ ಆರೋಗ್ಯದ ಏಕೈಕ ರಕ್ಷಕನಾಗಿ Ops ಅನ್ನು ಬಿಡಬೇಡಿ, ಡೆವಲಪರ್‌ಗಳು ಸಹ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (#productsquads).
- ಲಾಗ್‌ಗಳು ಉತ್ತಮವಾದ ವಿಷಯ, ಆದರೆ ಮೆಟ್ರಿಕ್‌ಗಳೂ ಸಹ. ಅವುಗಳನ್ನು ಒಗ್ಗೂಡಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಲಾಗ್‌ಗಳು ನಿಷ್ಪ್ರಯೋಜಕತೆಯ ದೊಡ್ಡ ಉರಿಯುತ್ತಿರುವ ಚೆಂಡಿನಲ್ಲಿ ಕಸವಾಗಲು ಬಿಡಬೇಡಿ. ಅವರ ಲಾಗ್‌ಗಳನ್ನು ಬೇರೆ ಯಾರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸಿ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ತೋರಿಸಿ, ಬೆಳಿಗ್ಗೆ 3:15 ಕ್ಕೆ ಅನುಪಯುಕ್ತ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಹೇಗೆ ಎಂದು ಅವರಿಗೆ ತೋರಿಸಿ.
ಫೋಟೋ ಲೇಖಕ ಮೇಲೆ
ಅಷ್ಟೇ. ಮುಂದಿನ ವಾರ ಹೊಸ ವಸ್ತು ಬಿಡುಗಡೆಯಾಗಲಿದೆ. ನೀವು ಕೋರ್ಸ್ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನಾವು ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇವೆ , ಸೋಮವಾರ ನಡೆಯಲಿದೆ. ಮತ್ತು ಈಗ ನಾವು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ನಿಮ್ಮ ಕಾಮೆಂಟ್‌ಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ.
ಮೂಲ: www.habr.com