ವೆಬ್ನಾರ್ ಕಳಪೆ ಆಡಿಯೊವನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಲಿಪ್ಯಂತರಗೊಳಿಸಿದ್ದೇವೆ.
ನನ್ನ ಹೆಸರು ಮೆಡ್ವೆಡೆವ್ ಎಡ್ವರ್ಡ್. ಇಂದು ನಾನು SRE ಎಂದರೇನು, SRE ಹೇಗೆ ಕಾಣಿಸಿಕೊಂಡಿತು, SRE ಎಂಜಿನಿಯರ್‌ಗಳು ಯಾವ ಕೆಲಸದ ಮಾನದಂಡಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ, ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮಾನದಂಡಗಳ ಬಗ್ಗೆ ಸ್ವಲ್ಪ, ಅದರ ಮೇಲ್ವಿಚಾರಣೆಯ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮಾತನಾಡುತ್ತೇನೆ. ನಾವು ಮೇಲ್ಭಾಗದಲ್ಲಿ ನಡೆಯುತ್ತೇವೆ, ಏಕೆಂದರೆ ನೀವು ಒಂದು ಗಂಟೆಯಲ್ಲಿ ಹೆಚ್ಚು ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚುವರಿ ವಿಮರ್ಶೆಗಾಗಿ ನಾನು ವಸ್ತುಗಳನ್ನು ನೀಡುತ್ತೇನೆ ಮತ್ತು ನಾವೆಲ್ಲರೂ ನಿಮಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ . ಜನವರಿ ಕೊನೆಯಲ್ಲಿ ಮಾಸ್ಕೋದಲ್ಲಿ.
ಮೊದಲಿಗೆ, SRE ಎಂದರೇನು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ - ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್. ಮತ್ತು ಅದು ಹೇಗೆ ಪ್ರತ್ಯೇಕ ಸ್ಥಾನವಾಗಿ, ಪ್ರತ್ಯೇಕ ದಿಕ್ಕಿನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಸಾಂಪ್ರದಾಯಿಕ ಅಭಿವೃದ್ಧಿ ವಲಯಗಳಲ್ಲಿ, ದೇವ್ ಮತ್ತು ಓಪ್ಸ್ ಎರಡು ವಿಭಿನ್ನ ತಂಡಗಳಾಗಿವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ವಿಭಿನ್ನ ಗುರಿಗಳೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಯಿತು. ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊರತರುವುದು ಮತ್ತು ವ್ಯಾಪಾರದ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದು ಅಭಿವೃದ್ಧಿ ತಂಡದ ಗುರಿಯಾಗಿದೆ. Ops ತಂಡದ ಗುರಿಯು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನೂ ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು. ನಿಸ್ಸಂಶಯವಾಗಿ, ಈ ಗುರಿಗಳು ಪರಸ್ಪರ ನೇರವಾಗಿ ವಿರೋಧಿಸುತ್ತವೆ: ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಏನೂ ಮುರಿಯಲು, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಮಾಡಿ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಈಗ DevOps ಎಂದು ಕರೆಯಲ್ಪಡುವ ವಿಧಾನವು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಅನೇಕ ಆಂತರಿಕ ಸಂಘರ್ಷಗಳಿವೆ.
ಸಮಸ್ಯೆಯೆಂದರೆ ನಾವು DevOps ನ ಸ್ಪಷ್ಟವಾದ ವ್ಯಾಖ್ಯಾನವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು DevOps ನ ಸ್ಪಷ್ಟ ಅನುಷ್ಠಾನವನ್ನು ಹೊಂದಿಲ್ಲ. ನಾನು 2 ವರ್ಷಗಳ ಹಿಂದೆ ಯೆಕಟೆರಿನ್‌ಬರ್ಗ್‌ನಲ್ಲಿ ನಡೆದ ಸಮ್ಮೇಳನದಲ್ಲಿ ಮಾತನಾಡಿದ್ದೇನೆ ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ DevOps ವಿಭಾಗವು "DevOps ಎಂದರೇನು" ಎಂಬ ವರದಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು. 2017 ರಲ್ಲಿ, ಡೆವೊಪ್ಸ್ ಸುಮಾರು 10 ವರ್ಷ ವಯಸ್ಸಾಗಿದೆ, ಆದರೆ ಅದು ಏನು ಎಂದು ನಾವು ಇನ್ನೂ ವಾದಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಇದು ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ ಗೂಗಲ್ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸಿದ ಬಹಳ ವಿಚಿತ್ರವಾದ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ.
2016 ರಲ್ಲಿ, ಗೂಗಲ್ ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್ ಎಂಬ ಪುಸ್ತಕವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿತು. ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ಈ ಪುಸ್ತಕದೊಂದಿಗೆ SRE ಚಳುವಳಿ ಪ್ರಾರಂಭವಾಯಿತು. SRE ಎನ್ನುವುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಂಪನಿಯಲ್ಲಿ DevOps ಮಾದರಿಯ ನಿರ್ದಿಷ್ಟ ಅನುಷ್ಠಾನವಾಗಿದೆ. ವ್ಯವಸ್ಥೆಗಳು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು SRE ಎಂಜಿನಿಯರ್‌ಗಳು ಬದ್ಧರಾಗಿದ್ದಾರೆ. ಅವರು ಹೆಚ್ಚಾಗಿ ಡೆವಲಪರ್‌ಗಳಿಂದ ಬರುತ್ತಾರೆ, ಕೆಲವೊಮ್ಮೆ ಬಲವಾದ ಅಭಿವೃದ್ಧಿ ಹಿನ್ನೆಲೆ ಹೊಂದಿರುವ ನಿರ್ವಾಹಕರು. ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೋ ಅದನ್ನು ಅವರು ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಕೋಡ್‌ನ ವಿಷಯದಲ್ಲಿ ಸಿಸ್ಟಮ್ನ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಜ್ಞಾನದಲ್ಲಿನ ಬಲವಾದ ಹಿನ್ನೆಲೆಯು ಈ ಜನರು ದಿನನಿತ್ಯದ ಆಡಳಿತಾತ್ಮಕ ಕೆಲಸಕ್ಕೆ ಒಲವು ತೋರುವುದಿಲ್ಲ, ಆದರೆ ಯಾಂತ್ರೀಕರಣಕ್ಕೆ ಒಲವು ತೋರುತ್ತಾರೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ರಚನಾತ್ಮಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ SRE ಇಂಜಿನಿಯರ್‌ಗಳು ಇದ್ದಾರೆ ಎಂಬ ಅಂಶದಿಂದ SRE ತಂಡಗಳಲ್ಲಿನ DevOps ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ದೇವ್ ಮತ್ತು ಆಪ್ಸ್ ನಡುವೆ 8 ವರ್ಷಗಳಿಂದ ಜನರು ಮಾತನಾಡುತ್ತಿರುವ ಅದೇ ಸಂಪರ್ಕ ಇಲ್ಲಿದೆ. SRE ಯ ಪಾತ್ರವು ವಾಸ್ತುಶಿಲ್ಪಿಯಂತೆಯೇ ಇರುತ್ತದೆ, ಇದರಲ್ಲಿ ಹೊಸಬರು SRE ಗಳಾಗುವುದಿಲ್ಲ. ತಮ್ಮ ವೃತ್ತಿಜೀವನದ ಆರಂಭದಲ್ಲಿ ಜನರು ಇನ್ನೂ ಯಾವುದೇ ಅನುಭವವನ್ನು ಹೊಂದಿಲ್ಲ, ಜ್ಞಾನದ ಅಗತ್ಯ ವಿಸ್ತಾರವನ್ನು ಹೊಂದಿಲ್ಲ. ಏಕೆಂದರೆ SRE ಗೆ ನಿಖರವಾಗಿ ಏನು ಮತ್ತು ಯಾವಾಗ ತಪ್ಪಾಗಬಹುದು ಎಂಬುದರ ಸೂಕ್ಷ್ಮ ಜ್ಞಾನದ ಅಗತ್ಯವಿದೆ. ಆದ್ದರಿಂದ, ಇಲ್ಲಿ ಕೆಲವು ಅನುಭವದ ಅಗತ್ಯವಿದೆ, ನಿಯಮದಂತೆ, ಕಂಪನಿಯ ಒಳಗೆ ಮತ್ತು ಹೊರಗೆ.
SRE ಮತ್ತು devops ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸಲಾಗುತ್ತದೆಯೇ ಎಂದು ಅವರು ಕೇಳುತ್ತಾರೆ. ಅವಳನ್ನು ಈಗಷ್ಟೇ ವಿವರಿಸಲಾಗಿದೆ. ಸಂಸ್ಥೆಯಲ್ಲಿ SRE ಸ್ಥಾನದ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡಬಹುದು. ಈ ಕ್ಲಾಸಿಕ್ DevOps ವಿಧಾನಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿ, Ops ಇನ್ನೂ ಪ್ರತ್ಯೇಕ ವಿಭಾಗವಾಗಿದೆ, SRE ಅಭಿವೃದ್ಧಿ ತಂಡದ ಭಾಗವಾಗಿದೆ. ಅವರು ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ. SRE ಪಾತ್ರವು ಒಬ್ಬ ಡೆವಲಪರ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಹಾದುಹೋಗುವ ಒಂದು ವಿಧಾನವೂ ಇದೆ. ಅವರು ಕೋಡ್ ವಿಮರ್ಶೆಗಳಲ್ಲಿ ಅದೇ ರೀತಿಯಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, UX ವಿನ್ಯಾಸಕರು, ಡೆವಲಪರ್ಗಳು, ಕೆಲವೊಮ್ಮೆ ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು. SRE ಗಳು ಒಂದೇ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಾವು ಅವುಗಳನ್ನು ಅನುಮೋದಿಸಬೇಕಾಗಿದೆ, ನಾವು ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ನಿಯೋಜನೆಗೆ SRE ಹೀಗೆ ಹೇಳುತ್ತದೆ: “ಸರಿ, ಈ ನಿಯೋಜನೆ, ಈ ಉತ್ಪನ್ನವು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಮತ್ತು ಅದು ಮಾಡಿದರೆ, ಕೆಲವು ಸ್ವೀಕಾರಾರ್ಹ ಮಿತಿಗಳಲ್ಲಿ. ಈ ಬಗ್ಗೆಯೂ ಮಾತನಾಡುತ್ತೇವೆ.
ಅಂತೆಯೇ, ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಲು SRE ವೀಟೋವನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, SRE ಅನ್ನು ತಪ್ಪಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ ಇದು ಕೆಲವು ರೀತಿಯ ಸಣ್ಣ ಸಂಘರ್ಷಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಇಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆ ಅದೇ ಪುಸ್ತಕದಲ್ಲಿ, ಹಲವು ಭಾಗಗಳು, ಒಂದಲ್ಲ, ಈ ಸಂಘರ್ಷಗಳನ್ನು ತಪ್ಪಿಸುವುದು ಹೇಗೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಮಾಹಿತಿ ಭದ್ರತೆಗೆ SRE ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ಅವರು ಕೇಳುತ್ತಾರೆ. ಮಾಹಿತಿ ಭದ್ರತೆಯಲ್ಲಿ SRE ನೇರವಾಗಿ ಭಾಗಿಯಾಗಿಲ್ಲ. ಮೂಲಭೂತವಾಗಿ, ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ, ಇದನ್ನು ವ್ಯಕ್ತಿಗಳು, ಪರೀಕ್ಷಕರು, ವಿಶ್ಲೇಷಕರು ಮಾಡುತ್ತಾರೆ. ಆದರೆ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳು, ಕೆಲವು ಬದ್ಧತೆಗಳು, ಭದ್ರತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಕೆಲವು ನಿಯೋಜನೆಗಳು ಉತ್ಪನ್ನದ ಲಭ್ಯತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು ಎಂಬ ಅರ್ಥದಲ್ಲಿ SRE ಅವರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಆದ್ದರಿಂದ, SRE ಒಟ್ಟಾರೆಯಾಗಿ ವಿಶ್ಲೇಷಕರು ಸೇರಿದಂತೆ ಭದ್ರತಾ ತಂಡಗಳು ಸೇರಿದಂತೆ ಯಾವುದೇ ತಂಡಗಳೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಹೊಂದಿದೆ. ಆದ್ದರಿಂದ, ಅವರು DevOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ SRE ಗಳು ಮುಖ್ಯವಾಗಿ ಅಗತ್ಯವಿದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೆವಲಪರ್‌ಗಳ ಮೇಲಿನ ಹೊರೆ ತುಂಬಾ ದೊಡ್ಡದಾಗುತ್ತದೆ. ಅಂದರೆ, ಈಗ ಅವರು ಓಪ್‌ಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರಬೇಕು ಎಂಬ ಅಂಶವನ್ನು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಇನ್ನು ಮುಂದೆ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಪ್ರತ್ಯೇಕ ಪಾತ್ರವಿದೆ. ಈ ಪಾತ್ರವನ್ನು ಬಜೆಟ್‌ನಲ್ಲಿ ಯೋಜಿಸಲಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಈ ಪಾತ್ರವನ್ನು ತಂಡದ ಗಾತ್ರದಲ್ಲಿ ಹಾಕಲಾಗುತ್ತದೆ, ಪ್ರತ್ಯೇಕ ವ್ಯಕ್ತಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಾನೆ, ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್ಗಳಲ್ಲಿ ಒಬ್ಬರು ಆಗುತ್ತಾರೆ. ತಂಡದಲ್ಲಿ ಮೊದಲ SRE ಕಾಣಿಸಿಕೊಳ್ಳುವುದು ಹೀಗೆ.
SRE ಯಿಂದ ಪ್ರಭಾವಿತವಾಗಿರುವ ವ್ಯವಸ್ಥೆಯ ಸಂಕೀರ್ಣತೆ, ಕಾರ್ಯಾಚರಣೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಸಂಕೀರ್ಣತೆ ಅಗತ್ಯ ಮತ್ತು ಆಕಸ್ಮಿಕವಾಗಿದೆ. ಹೊಸ ಉತ್ಪನ್ನದ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದ ಅಗತ್ಯವಿರುವ ಮಟ್ಟಿಗೆ ಉತ್ಪನ್ನದ ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚಿದಾಗ ಅಗತ್ಯ ಸಂಕೀರ್ಣತೆ. ವ್ಯವಸ್ಥೆಯ ಸಂಕೀರ್ಣತೆಯು ಹೆಚ್ಚಾದಾಗ ಯಾದೃಚ್ಛಿಕ ಸಂಕೀರ್ಣತೆಯಾಗಿದೆ, ಆದರೆ ಉತ್ಪನ್ನದ ವೈಶಿಷ್ಟ್ಯ ಮತ್ತು ವ್ಯಾಪಾರದ ಅವಶ್ಯಕತೆಗಳು ಇದನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಡೆವಲಪರ್ ಎಲ್ಲೋ ತಪ್ಪು ಮಾಡಿದ್ದಾರೆ, ಅಥವಾ ಅಲ್ಗಾರಿದಮ್ ಸೂಕ್ತವಲ್ಲ, ಅಥವಾ ವಿಶೇಷ ಅಗತ್ಯವಿಲ್ಲದೆ ಉತ್ಪನ್ನದ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಆಸಕ್ತಿಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಉತ್ತಮ SRE ಯಾವಾಗಲೂ ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಕಡಿತಗೊಳಿಸಬೇಕು. ಅಂದರೆ, ಯಾವುದೇ ಬದ್ಧತೆ, ಯಾವುದೇ ನಿಯೋಜನೆ, ಯಾವುದೇ ಪುಲ್ ವಿನಂತಿ, ಯಾದೃಚ್ಛಿಕ ಸೇರ್ಪಡೆಯಿಂದಾಗಿ ತೊಂದರೆ ಹೆಚ್ಚಾದರೆ, ನಿರ್ಬಂಧಿಸಬೇಕು.
ತಂಡಕ್ಕೆ ಕೇವಲ ಇಂಜಿನಿಯರ್, ಹೆಚ್ಚಿನ ಜ್ಞಾನವಿರುವ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಅನ್ನು ಏಕೆ ನೇಮಿಸಬಾರದು ಎಂಬುದು ಪ್ರಶ್ನೆ. ಎಂಜಿನಿಯರ್ ಪಾತ್ರದಲ್ಲಿ ಡೆವಲಪರ್, ನಮಗೆ ಹೇಳಲಾಗುತ್ತದೆ, ಉತ್ತಮ ಸಿಬ್ಬಂದಿ ಪರಿಹಾರವಲ್ಲ. ಎಂಜಿನಿಯರ್ ಪಾತ್ರದಲ್ಲಿ ಡೆವಲಪರ್ ಯಾವಾಗಲೂ ಉತ್ತಮ ಸಿಬ್ಬಂದಿ ಪರಿಹಾರವಲ್ಲ, ಆದರೆ ಇಲ್ಲಿ ವಿಷಯವೆಂದರೆ ಆಪ್ಸ್‌ನಲ್ಲಿ ತೊಡಗಿರುವ ಡೆವಲಪರ್ ಯಾಂತ್ರೀಕೃತಗೊಳ್ಳಲು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಆಸೆಯನ್ನು ಹೊಂದಿರುತ್ತಾನೆ, ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಜ್ಞಾನ ಮತ್ತು ಕೌಶಲ್ಯವನ್ನು ಹೊಂದಿದ್ದಾನೆ. ಈ ಯಾಂತ್ರೀಕೃತಗೊಂಡ. ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ನಾವು ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯವನ್ನು ಮಾತ್ರ ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ, ದಿನಚರಿಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ, MTTR (ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸರಾಸರಿ ಸಮಯ, ಚೇತರಿಕೆಯ ಸಮಯ) ನಂತಹ ಪ್ರಮುಖ ವ್ಯಾಪಾರ ನಿಯತಾಂಕಗಳನ್ನು ಸಹ ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ. ಹೀಗಾಗಿ, ಮತ್ತು ನಾವು ಈ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ, ನಾವು ಸಂಸ್ಥೆಗೆ ಹಣವನ್ನು ಉಳಿಸುತ್ತೇವೆ.
ಈಗ SRE ಕಾರ್ಯಾಚರಣೆಯ ಮಾನದಂಡಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ಮತ್ತು ಮೊದಲನೆಯದಾಗಿ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಬಗ್ಗೆ. ಸಣ್ಣ ಕಂಪನಿಗಳಲ್ಲಿ, ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಲ್ಲಿ, ಸೇವೆಯನ್ನು ಚೆನ್ನಾಗಿ ಬರೆದರೆ, ಉತ್ಪನ್ನವನ್ನು ಚೆನ್ನಾಗಿ ಮತ್ತು ಸರಿಯಾಗಿ ಬರೆದರೆ, ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅದು ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಜನರು ಭಾವಿಸುತ್ತಾರೆ. ಅಷ್ಟೆ, ನಾವು ಒಳ್ಳೆಯ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೇವೆ, ಆದ್ದರಿಂದ ಮುರಿಯಲು ಏನೂ ಇಲ್ಲ. ಕೋಡ್ ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಮುರಿಯಲು ಏನೂ ಇಲ್ಲ. ನಮಗೆ ಪರೀಕ್ಷೆಗಳು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಹೇಳುವ ಅದೇ ಜನರ ಬಗ್ಗೆ, ಏಕೆಂದರೆ, ನೋಡಿ, ಇವು ಮೂರು ವಿಪಿಐ ವಿಧಾನಗಳು, ಇಲ್ಲಿ ಏಕೆ ಮುರಿಯಬೇಕು.
ಇದೆಲ್ಲವೂ ತಪ್ಪಾಗಿದೆ, ಖಂಡಿತ. ಮತ್ತು ಈ ಜನರು ಆಚರಣೆಯಲ್ಲಿ ಅಂತಹ ಕೋಡ್ನಿಂದ ಆಗಾಗ್ಗೆ ಕಚ್ಚುತ್ತಾರೆ, ಏಕೆಂದರೆ ವಿಷಯಗಳು ಮುರಿಯುತ್ತವೆ. ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಕೆಲವೊಮ್ಮೆ ವಿಷಯಗಳು ಮುರಿಯುತ್ತವೆ. ಕೆಲವೊಮ್ಮೆ ಜನರು ಇಲ್ಲ ಎಂದು ಹೇಳುತ್ತಾರೆ, ಅದು ಎಂದಿಗೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಸಾರ್ವಕಾಲಿಕ ನಡೆಯುತ್ತದೆ. ಇದು ಸಾಕಷ್ಟು ಬಾರಿ ಸಂಭವಿಸುತ್ತದೆ. ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಯಾರೂ 100% ಲಭ್ಯತೆಗಾಗಿ ಶ್ರಮಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ 100% ಲಭ್ಯತೆ ಎಂದಿಗೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಇದು ರೂಢಿಯಾಗಿದೆ. ಮತ್ತು ಆದ್ದರಿಂದ, ನಾವು ಸೇವೆಯ ಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ನಾವು ಯಾವಾಗಲೂ ಒಂಬತ್ತುಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. 2 ನೈನ್, 3 ನೈನ್, 4 ನೈನ್, 5 ನೈನ್. ನಾವು ಇದನ್ನು ಡೌನ್‌ಟೈಮ್‌ಗೆ ಅನುವಾದಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, 5 ನೈನ್‌ಗಳು, ನಂತರ ಇದು ವರ್ಷಕ್ಕೆ 5 ನಿಮಿಷಗಳ ಅಲಭ್ಯತೆಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು, 2 ನೈನ್‌ಗಳು 3,5 ದಿನಗಳ ಅಲಭ್ಯತೆ.
ಆದರೆ ಕೆಲವು ಹಂತದಲ್ಲಿ POI, ಹೂಡಿಕೆಯ ಮೇಲಿನ ಆದಾಯದಲ್ಲಿ ಇಳಿಕೆ ಕಂಡುಬರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಎರಡು ನೈನ್‌ಗಳಿಂದ ಮೂರು ನೈನ್‌ಗಳಿಗೆ ಹೋಗುವುದು ಎಂದರೆ 3 ದಿನಗಳಿಗಿಂತ ಕಡಿಮೆ ಅಲಭ್ಯತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ನಾಲ್ಕು ಒಂಬತ್ತುಗಳಿಂದ ಐದಕ್ಕೆ ಹೋಗುವುದರಿಂದ ವರ್ಷಕ್ಕೆ 47 ನಿಮಿಷಗಳ ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಮತ್ತು ವ್ಯವಹಾರಕ್ಕೆ ಇದು ನಿರ್ಣಾಯಕವಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅಗತ್ಯವಿರುವ ವಿಶ್ವಾಸಾರ್ಹತೆಯು ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಯಲ್ಲ, ಮೊದಲನೆಯದಾಗಿ, ಇದು ವ್ಯಾಪಾರ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಇದು ಉತ್ಪನ್ನದ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಉತ್ಪನ್ನದ ಬಳಕೆದಾರರಿಗೆ ಯಾವ ಮಟ್ಟದ ಅಲಭ್ಯತೆಯು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ, ಅವರು ಏನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ, ಅವರು ಎಷ್ಟು ಪಾವತಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, ಅವರು ಎಷ್ಟು ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ, ಎಷ್ಟು ಹಣವನ್ನು ಸಿಸ್ಟಮ್ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
ಉಳಿದ ಘಟಕಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆ ಏನು ಎಂಬುದು ಇಲ್ಲಿ ಪ್ರಮುಖ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಏಕೆಂದರೆ 4 ನೈನ್‌ಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆ ಹೊಂದಿರುವ ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ನಲ್ಲಿ 5 ಮತ್ತು 2 ನೈನ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಗೋಚರಿಸುವುದಿಲ್ಲ. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಿಮ್ಮ ಸೇವೆಯಲ್ಲಿರುವ ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ನಲ್ಲಿ ವರ್ಷಕ್ಕೆ 10 ಬಾರಿ ಏನಾದರೂ ಮುರಿದರೆ, ಓಎಸ್ ಬದಿಯಲ್ಲಿ 8 ಬಾರಿ ಸ್ಥಗಿತ ಸಂಭವಿಸಬಹುದು. ಬಳಕೆದಾರರು ಇದನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ವರ್ಷಕ್ಕೆ ಒಂದು ಬಾರಿ ಗಮನ ಹರಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚುತ್ತಿರುವ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಲಾಭವನ್ನು ಹೆಚ್ಚಿಸುವ ಬೆಲೆಯನ್ನು ಪರಸ್ಪರ ಸಂಬಂಧಿಸುವುದು ಅವಶ್ಯಕ.
ಎಸ್‌ಆರ್‌ಇ ಪುಸ್ತಕದಲ್ಲಿ 4 ಒಂಬತ್ತುಗಳಿಂದ 3 ಒಂಬತ್ತುಗಳಿಗೆ ಹೆಚ್ಚಿಸುವ ಉತ್ತಮ ಉದಾಹರಣೆ ಇದೆ. ಲಭ್ಯತೆಯ ಹೆಚ್ಚಳವು 0,1% ಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಸೇವೆಯ ಆದಾಯವು ವರ್ಷಕ್ಕೆ $ 1 ಮಿಲಿಯನ್ ಆಗಿದ್ದರೆ, ಆದಾಯದ ಹೆಚ್ಚಳವು $ 900 ಆಗಿದೆ. ಒಂಬತ್ತರಿಂದ ಕೈಗೆಟುಕುವಿಕೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಮಗೆ ವರ್ಷಕ್ಕೆ $900 ಗಿಂತ ಕಡಿಮೆ ವೆಚ್ಚವಾಗಿದ್ದರೆ, ಹೆಚ್ಚಳವು ಆರ್ಥಿಕ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ವರ್ಷಕ್ಕೆ 900 ಡಾಲರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗಿದ್ದರೆ, ಅದು ಇನ್ನು ಮುಂದೆ ಅರ್ಥವಿಲ್ಲ, ಏಕೆಂದರೆ ಆದಾಯದ ಹೆಚ್ಚಳವು ಕಾರ್ಮಿಕ ವೆಚ್ಚಗಳು, ಸಂಪನ್ಮೂಲ ವೆಚ್ಚಗಳಿಗೆ ಸರಿದೂಗಿಸುವುದಿಲ್ಲ. ಮತ್ತು ನಮಗೆ 3 ಒಂಬತ್ತುಗಳು ಸಾಕು.
ಇದು ಸಹಜವಾಗಿ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಸಮಾನವಾಗಿರುವ ಸರಳೀಕೃತ ಉದಾಹರಣೆಯಾಗಿದೆ. ಮತ್ತು 3 ನೈನ್‌ಗಳಿಂದ 4 ನೈನ್‌ಗಳಿಗೆ ಹೋಗುವುದು ಸಾಕಷ್ಟು ಸುಲಭ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, 2 ನೈನ್‌ಗಳಿಂದ 3 ಕ್ಕೆ ಹೋಗುವುದು, ಇದು ಈಗಾಗಲೇ 9 ಸಾವಿರ ಡಾಲರ್‌ಗಳ ಉಳಿತಾಯವಾಗಿದೆ, ಇದು ಆರ್ಥಿಕ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ವಾಸ್ತವದಲ್ಲಿ, ನೋಂದಣಿ ವಿನಂತಿಯ ವೈಫಲ್ಯವು ಪುಟವನ್ನು ಪ್ರದರ್ಶಿಸುವಲ್ಲಿ ವಿಫಲತೆಗಿಂತ ಕೆಟ್ಟದಾಗಿದೆ, ವಿನಂತಿಗಳು ವಿಭಿನ್ನ ತೂಕವನ್ನು ಹೊಂದಿವೆ. ಅವರು ವ್ಯವಹಾರದ ದೃಷ್ಟಿಕೋನದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಮಾನದಂಡವನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಹೇಗಾದರೂ, ನಿಯಮದಂತೆ, ನಾವು ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡದಿದ್ದರೆ, ಇದು ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ ಅಂದಾಜು.
ಸೇವೆಗಾಗಿ ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ SRE ಸಂಯೋಜಕರಲ್ಲಿ ಒಬ್ಬರೇ ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ನಾವು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಏಕೀಕರಣದ ವಿಷಯದಲ್ಲಿ ಹೇಳೋಣ, ಆದ್ದರಿಂದ ಅದರ ಸ್ಥಿರತೆಗೆ ಯಾವುದೇ ನಷ್ಟವಿಲ್ಲ. ಹೌದು, SRE ಗಳು, ಅದೇ ರೀತಿಯಲ್ಲಿ ಪುಲ್ ವಿನಂತಿಗಳು, ಬದ್ಧತೆಗಳು, ಬಿಡುಗಡೆಗಳು ವಾಸ್ತುಶಿಲ್ಪ, ಹೊಸ ಸೇವೆಗಳ ಪರಿಚಯ, ಮೈಕ್ರೋ ಸರ್ವೀಸ್, ಹೊಸ ಪರಿಹಾರಗಳ ಅನುಷ್ಠಾನದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಅನುಭವ ಬೇಕು, ಅರ್ಹತೆ ಬೇಕು ಎಂದು ಮೊದಲೇ ಯಾಕೆ ಹೇಳಿದ್ದೆ. ವಾಸ್ತವವಾಗಿ, ಯಾವುದೇ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಹಾರದಲ್ಲಿ SRE ನಿರ್ಬಂಧಿಸುವ ಧ್ವನಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಅಂತೆಯೇ, ಒಬ್ಬ ಇಂಜಿನಿಯರ್ ಆಗಿ SRE, ಮೊದಲನೆಯದಾಗಿ, ಕೆಲವು ನಿರ್ದಿಷ್ಟ ನಿರ್ಧಾರಗಳು ವಿಶ್ವಾಸಾರ್ಹತೆ, ಸ್ಥಿರತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಇದು ವ್ಯವಹಾರದ ಅಗತ್ಯಗಳಿಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಯಾವ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಸ್ವೀಕಾರಾರ್ಹ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ.
ಆದ್ದರಿಂದ, ಈಗ ನಾವು ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮಾನದಂಡಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಬಹುದು, ಇದನ್ನು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ SRE ನಲ್ಲಿ SLA (ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದ) ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಹೆಚ್ಚಾಗಿ ಪರಿಚಿತ ಪದ. SLI (ಸೇವಾ ಮಟ್ಟದ ಸೂಚಕ). SLO (ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶ). ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದವು ಬಹುಶಃ ಸಾಂಕೇತಿಕ ಪದವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ನೀವು ನೆಟ್‌ವರ್ಕ್‌ಗಳೊಂದಿಗೆ, ಪೂರೈಕೆದಾರರೊಂದಿಗೆ, ಹೋಸ್ಟಿಂಗ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದರೆ. ಇದು ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸೇವೆಯ ಕಾರ್ಯಕ್ಷಮತೆ, ದಂಡಗಳು, ದೋಷಗಳಿಗೆ ಕೆಲವು ದಂಡಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು, ಮಾನದಂಡಗಳನ್ನು ವಿವರಿಸುವ ಸಾಮಾನ್ಯ ಒಪ್ಪಂದವಾಗಿದೆ. ಮತ್ತು SLI ಲಭ್ಯತೆಯ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ. ಅಂದರೆ, SLI ಏನಾಗಬಹುದು: ಸೇವೆಯಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ, ಶೇಕಡಾವಾರು ದೋಷಗಳ ಸಂಖ್ಯೆ. ಇದು ಕೆಲವು ರೀತಿಯ ಫೈಲ್ ಹೋಸ್ಟಿಂಗ್ ಆಗಿದ್ದರೆ ಅದು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಆಗಿರಬಹುದು. ಗುರುತಿಸುವಿಕೆ ಅಲ್ಗಾರಿದಮ್‌ಗಳಿಗೆ ಬಂದಾಗ, ಸೂಚಕವು ಉತ್ತರದ ಸರಿಯಾದತೆಯೂ ಆಗಿರಬಹುದು. SLO (ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶ) ಕ್ರಮವಾಗಿ, SLI ಸೂಚಕ, ಅದರ ಮೌಲ್ಯ ಮತ್ತು ಅವಧಿಯ ಸಂಯೋಜನೆಯಾಗಿದೆ.
SLA ಹೀಗಿರಬಹುದು ಎಂದು ಹೇಳೋಣ. ಸೇವೆಯು ವರ್ಷವಿಡೀ 99,95% ಸಮಯ ಲಭ್ಯವಿದೆ. ಅಥವಾ ಪ್ರತಿ ತ್ರೈಮಾಸಿಕಕ್ಕೆ 99 ಗಂಟೆಗಳ ಒಳಗೆ 3 ನಿರ್ಣಾಯಕ ಬೆಂಬಲ ಟಿಕೆಟ್‌ಗಳನ್ನು ಮುಚ್ಚಲಾಗುತ್ತದೆ. ಅಥವಾ 85% ಪ್ರಶ್ನೆಗಳು ಪ್ರತಿ ತಿಂಗಳು 1,5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಪಡೆಯುತ್ತವೆ. ಅಂದರೆ, ದೋಷಗಳು ಮತ್ತು ವೈಫಲ್ಯಗಳು ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯವೆಂದು ನಾವು ಕ್ರಮೇಣ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಇದು ಸ್ವೀಕಾರಾರ್ಹ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ, ನಾವು ಅದನ್ನು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ, ನಾವು ಅದನ್ನು ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ಎಣಿಸುತ್ತಿದ್ದೇವೆ. ಅಂದರೆ, SRE ತಪ್ಪುಗಳನ್ನು ಮಾಡಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಅದು ದೋಷಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು, ಅದು ಅವುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಮತ್ತು ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ, ಬಳಕೆದಾರರು ಅವುಗಳನ್ನು ಗಮನಿಸದ ಅಥವಾ ಗಮನಿಸದ ರೀತಿಯಲ್ಲಿ ದೋಷಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು, ಆದರೆ ಕೆಲವು ರೀತಿಯ ಪರಿಹಾರವಿದೆ, ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಕುಸಿಯುವುದಿಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ನೀವು YouTube ಗೆ ವೀಡಿಯೊವನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದರೆ ಮತ್ತು YouTube ಅದನ್ನು ತಕ್ಷಣವೇ ಪರಿವರ್ತಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ವೀಡಿಯೊ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಸ್ವರೂಪವು ಸೂಕ್ತವಾಗಿಲ್ಲದಿದ್ದರೆ, ನಂತರ ವಿನಂತಿಯು ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಮಯ ಮೀರಿದಾಗ ವಿಫಲವಾಗುವುದಿಲ್ಲ, YouTube 502 ದೋಷವನ್ನು ನೀಡುವುದಿಲ್ಲ , YouTube ಹೀಗೆ ಹೇಳುತ್ತದೆ: “ನಾವು ಎಲ್ಲವನ್ನೂ ರಚಿಸಿದ್ದೇವೆ, ನಿಮ್ಮ ವೀಡಿಯೊವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ಇದು ಸುಮಾರು 10 ನಿಮಿಷಗಳಲ್ಲಿ ಸಿದ್ಧವಾಗಲಿದೆ. ” ಇದು ಆಕರ್ಷಕವಾದ ಅವನತಿಯ ತತ್ವವಾಗಿದೆ, ಇದು ಪರಿಚಿತವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಮುಂಭಾಗದ ಅಭಿವೃದ್ಧಿಯಿಂದ, ನೀವು ಎಂದಾದರೂ ಇದನ್ನು ಮಾಡಿದ್ದರೆ.
ನಾವು ಮಾತನಾಡುವ ಮುಂದಿನ ಪದಗಳು, ವಿಶ್ವಾಸಾರ್ಹತೆಯೊಂದಿಗೆ, ದೋಷಗಳೊಂದಿಗೆ, ನಿರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಹಳ ಮುಖ್ಯವಾದವುಗಳು MTBF ಮತ್ತು MTTR. MTBF ವೈಫಲ್ಯಗಳ ನಡುವಿನ ಸರಾಸರಿ ಸಮಯ. MTTR ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸರಾಸರಿ ಸಮಯ, ಚೇತರಿಕೆಯ ಸರಾಸರಿ ಸಮಯ. ಅಂದರೆ, ದೋಷ ಪತ್ತೆಯಾದ ಕ್ಷಣದಿಂದ ಎಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ, ದೋಷ ಕಾಣಿಸಿಕೊಂಡ ಕ್ಷಣದಿಂದ ಸೇವೆಯನ್ನು ಪೂರ್ಣ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಗೆ ಮರುಸ್ಥಾಪಿಸುವ ಕ್ಷಣಕ್ಕೆ. MTBF ಅನ್ನು ಮುಖ್ಯವಾಗಿ ಕೋಡ್ ಗುಣಮಟ್ಟದ ಕೆಲಸದಿಂದ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಅಂದರೆ, SRE ಗಳು "ಇಲ್ಲ" ಎಂದು ಹೇಳಬಹುದು. ಮತ್ತು SRE "ಇಲ್ಲ" ಎಂದು ಹೇಳಿದಾಗ, ಅವನು ಅದನ್ನು ಹೇಳುವುದು ಹಾನಿಕಾರಕ ಎಂಬ ಕಾರಣದಿಂದಲ್ಲ, ಅವನು ಕೆಟ್ಟವನಾಗಿರುವುದರಿಂದ ಅಲ್ಲ, ಆದರೆ ಇಲ್ಲದಿದ್ದರೆ ಎಲ್ಲರೂ ಬಳಲುತ್ತಿದ್ದಾರೆ ಎಂದು ನಿಮಗೆ ಇಡೀ ತಂಡದ ತಿಳುವಳಿಕೆ ಬೇಕು.
ಮತ್ತೆ, ನಾನು ಆಗಾಗ್ಗೆ ಉಲ್ಲೇಖಿಸುವ ಪುಸ್ತಕದಲ್ಲಿ ಬಹಳಷ್ಟು ಲೇಖನಗಳು, ಬಹಳಷ್ಟು ವಿಧಾನಗಳು, ಬಹಳಷ್ಟು ಮಾರ್ಗಗಳಿವೆ, ಇತರ ಡೆವಲಪರ್ಗಳು SRE ಅನ್ನು ದ್ವೇಷಿಸಲು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ. MTTR, ಮತ್ತೊಂದೆಡೆ, ನಿಮ್ಮ SLO ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು (ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶ). ಮತ್ತು ಇದು ಹೆಚ್ಚಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ. ಏಕೆಂದರೆ, ಉದಾಹರಣೆಗೆ, ನಮ್ಮ SLO ಪ್ರತಿ ತ್ರೈಮಾಸಿಕಕ್ಕೆ 4 ನೈನ್‌ಗಳ ಅಪ್‌ಟೈಮ್ ಆಗಿದೆ. ಇದರರ್ಥ 3 ತಿಂಗಳಲ್ಲಿ ನಾವು 13 ನಿಮಿಷಗಳ ಅಲಭ್ಯತೆಯನ್ನು ಅನುಮತಿಸಬಹುದು. ಮತ್ತು MTTR 13 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಇರುವಂತಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ನಾವು 13 ನಿಮಿಷಗಳಲ್ಲಿ ಕನಿಷ್ಠ 1 ಅಲಭ್ಯತೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಇದರರ್ಥ ನಾವು ಈಗಾಗಲೇ ತ್ರೈಮಾಸಿಕಕ್ಕೆ ಸಂಪೂರ್ಣ ಬಜೆಟ್ ಅನ್ನು ಖಾಲಿ ಮಾಡಿದ್ದೇವೆ. ನಾವು SLO ಅನ್ನು ಮುರಿಯುತ್ತಿದ್ದೇವೆ. ಕ್ರ್ಯಾಶ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು 13 ನಿಮಿಷಗಳು ಯಂತ್ರಕ್ಕೆ ಬಹಳಷ್ಟು, ಆದರೆ ಮನುಷ್ಯನಿಗೆ ಬಹಳ ಕಡಿಮೆ. ಏಕೆಂದರೆ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ, ಅವನು ಪ್ರತಿಕ್ರಿಯಿಸುವವರೆಗೆ, ಅವನು ದೋಷವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವವರೆಗೆ, ಇದು ಈಗಾಗಲೇ ಹಲವಾರು ನಿಮಿಷಗಳು. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಬೇಕು, ನಿಖರವಾಗಿ ಏನು ಸರಿಪಡಿಸಬೇಕು, ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವವರೆಗೆ, ಇದು ಇನ್ನೂ ಕೆಲವು ನಿಮಿಷಗಳು. ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ನೀವು ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದ್ದರೂ ಸಹ, ಅದು ಬದಲಾದಂತೆ, ಅಥವಾ ಹೊಸ ನೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿ, ನಂತರ ಹಸ್ತಚಾಲಿತವಾಗಿ MTTR ಈಗಾಗಲೇ ಸುಮಾರು 7-8 ನಿಮಿಷಗಳು. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಾಗ, MTTR ಆಗಾಗ್ಗೆ ಎರಡನೇ, ಕೆಲವೊಮ್ಮೆ ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ತಲುಪುತ್ತದೆ. ಗೂಗಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, ಎಲ್ಲವೂ ಅಷ್ಟು ಉತ್ತಮವಾಗಿಲ್ಲ.
ತಾತ್ತ್ವಿಕವಾಗಿ, SRE ತನ್ನ ಕೆಲಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು, ಏಕೆಂದರೆ ಇದು MTTR, ಅದರ ಮೆಟ್ರಿಕ್‌ಗಳು, ಸಂಪೂರ್ಣ ಸೇವೆಯ SLO ಮತ್ತು ಅದರ ಪ್ರಕಾರ ವ್ಯಾಪಾರ ಲಾಭದ ಮೇಲೆ ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಸಮಯ ಮೀರಿದರೆ, SRE ದೋಷವಿದೆಯೇ ಎಂದು ನಮ್ಮನ್ನು ಕೇಳಲಾಗುತ್ತದೆ. ಅದೃಷ್ಟವಶಾತ್, ಯಾರೂ ದೂರುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಬಾಲ್ಮ್ಲೆಸ್ ಪೋಸ್ಟ್ಮಾರ್ಟಮ್ ಎಂಬ ಪ್ರತ್ಯೇಕ ಸಂಸ್ಕೃತಿಯಾಗಿದೆ, ಇದನ್ನು ನಾವು ಇಂದು ಮಾತನಾಡುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಅದನ್ನು ಸ್ಲರ್ಮ್ನಲ್ಲಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ಇದು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದ್ದು, ಸಾಕಷ್ಟು ಮಾತನಾಡಬಹುದು. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪ್ರತಿ ತ್ರೈಮಾಸಿಕಕ್ಕೆ ನಿಗದಿಪಡಿಸಿದ ಸಮಯ ಮೀರಿದರೆ, ಸ್ವಲ್ಪ ಎಲ್ಲರನ್ನೂ ದೂಷಿಸಬೇಕಾಗುತ್ತದೆ, ಅಂದರೆ ಎಲ್ಲರನ್ನೂ ದೂಷಿಸುವುದು ಉತ್ಪಾದಕವಲ್ಲ, ಬದಲಿಗೆ ಯಾರನ್ನೂ ದೂಷಿಸಬೇಡಿ, ಆದರೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ನಮ್ಮೊಂದಿಗೆ ಕೆಲಸ ಮಾಡೋಣ. ನನ್ನ ಅನುಭವದಲ್ಲಿ, ಈ ವಿಧಾನವು ಹೆಚ್ಚಿನ ತಂಡಗಳಿಗೆ ಸ್ವಲ್ಪ ಅನ್ಯವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ರಷ್ಯಾದಲ್ಲಿ, ಆದರೆ ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಈ ವಿಷಯದ ಬಗ್ಗೆ ನೀವು ಓದಬಹುದಾದ ಲೇಖನ ಮತ್ತು ಸಾಹಿತ್ಯದ ಕೊನೆಯಲ್ಲಿ ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಅಥವಾ ಸ್ಲರ್ಮ್ SRE ಗೆ ಬನ್ನಿ.
ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ಪ್ರತಿ ತ್ರೈಮಾಸಿಕಕ್ಕೆ SLO ಸಮಯ ಮೀರಿದರೆ, ಅಲಭ್ಯತೆಯು 13 ನಿಮಿಷಗಳು ಅಲ್ಲ, ಆದರೆ 15 ಆಗಿದ್ದರೆ, ಇದಕ್ಕೆ ಯಾರು ಹೊಣೆಯಾಗಬಹುದು? ಸಹಜವಾಗಿ, SRE ದೂಷಿಸಬಹುದು, ಏಕೆಂದರೆ ಅವರು ಕೆಲವು ರೀತಿಯ ಕೆಟ್ಟ ಬದ್ಧತೆ ಅಥವಾ ನಿಯೋಜನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮಾಡಿದ್ದಾರೆ. ಡೇಟಾ ಸೆಂಟರ್‌ನ ನಿರ್ವಾಹಕರು ಇದಕ್ಕೆ ಕಾರಣವಾಗಿರಬಹುದು, ಏಕೆಂದರೆ ಅವರು ಕೆಲವು ರೀತಿಯ ಅನಿಯಂತ್ರಿತ ನಿರ್ವಹಣೆಯನ್ನು ನಡೆಸಿರಬಹುದು. ಡೇಟಾ ಸೆಂಟರ್‌ನ ನಿರ್ವಾಹಕರು ಇದಕ್ಕೆ ಕಾರಣರಾಗಿದ್ದರೆ, ಓಪ್ಸ್‌ನ ವ್ಯಕ್ತಿ ಇದಕ್ಕೆ ಹೊಣೆಯಾಗುತ್ತಾರೆ, ಅವರು SLO ಅನ್ನು ಸಂಘಟಿಸಿದಾಗ ನಿರ್ವಹಣೆಯನ್ನು ಲೆಕ್ಕ ಹಾಕಲಿಲ್ಲ. ಮ್ಯಾನೇಜರ್, ಟೆಕ್ನಿಕಲ್ ಡೈರೆಕ್ಟರ್ ಅಥವಾ ಡೇಟಾ ಸೆಂಟರ್ ಒಪ್ಪಂದಕ್ಕೆ ಸಹಿ ಹಾಕಿದ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್‌ನ SLA ಅನ್ನು ಅಗತ್ಯವಿರುವ ಅಲಭ್ಯತೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ಗಮನ ಕೊಡದ ಯಾರಾದರೂ ಇದಕ್ಕೆ ಕಾರಣರಾಗಿದ್ದಾರೆ. ಅಂತೆಯೇ, ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಎಲ್ಲರೂ ದೂರುತ್ತಾರೆ. ಮತ್ತು ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಯಾರ ಮೇಲೂ ಆರೋಪ ಹೊರಿಸುವುದರಲ್ಲಿ ಅರ್ಥವಿಲ್ಲ. ಆದರೆ ಸಹಜವಾಗಿ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ. ಅದಕ್ಕಾಗಿಯೇ ಮರಣೋತ್ತರ ಪರೀಕ್ಷೆಗಳಿವೆ. ಮತ್ತು ನೀವು ಓದಿದರೆ, ಉದಾಹರಣೆಗೆ, ಗಿಟ್‌ಹಬ್ ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್‌ಗಳು, ಮತ್ತು ಇದು ಯಾವಾಗಲೂ ಪ್ರತಿ ಪ್ರಕರಣದಲ್ಲಿ ಬಹಳ ಆಸಕ್ತಿದಾಯಕ, ಸಣ್ಣ ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಕಥೆಯಾಗಿದ್ದರೆ, ಈ ನಿರ್ದಿಷ್ಟ ವ್ಯಕ್ತಿಯನ್ನು ದೂಷಿಸಬೇಕೆಂದು ಯಾರೂ ಹೇಳುವುದಿಲ್ಲ ಎಂದು ನೀವು ಬದಲಾಯಿಸಬಹುದು. ಆಪಾದನೆಯನ್ನು ಯಾವಾಗಲೂ ನಿರ್ದಿಷ್ಟ ಅಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಗಳ ಮೇಲೆ ಇರಿಸಲಾಗುತ್ತದೆ.
ಮುಂದಿನ ಪ್ರಶ್ನೆಗೆ ಹೋಗೋಣ. ಆಟೋಮೇಷನ್. ನಾನು ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ನೀವು ನಿಜವಾಗಿ ಉಳಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳದೆಯೇ ಕೆಲಸವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನೀವು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು ಎಂದು ಹೇಳುವ ಟೇಬಲ್ ಅನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ಉಲ್ಲೇಖಿಸುತ್ತೇನೆ. ಒಂದು ಸ್ನ್ಯಾಗ್ ಇದೆ. ಕ್ಯಾಚ್ ಏನೆಂದರೆ, SRE ಗಳು ಕಾರ್ಯವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದಾಗ, ಅವರು ಸಮಯವನ್ನು ಉಳಿಸುವುದಿಲ್ಲ, ಅವರು ಹಣವನ್ನು ಉಳಿಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ಸ್ವಯಂಚಾಲಿತತೆಯು MTTR ಮೇಲೆ ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಅವರು ಮಾತನಾಡಲು, ಉದ್ಯೋಗಿಗಳು ಮತ್ತು ಅಭಿವರ್ಧಕರ ನೈತಿಕತೆಯನ್ನು ಉಳಿಸುತ್ತಾರೆ, ಇದು ಖಾಲಿಯಾದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಅವರು ದಿನಚರಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತಾರೆ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಕೆಲಸದ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ವ್ಯವಹಾರದ ಮೇಲೆ, ಸಮಯದ ವೆಚ್ಚದ ವಿಷಯದಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಅರ್ಥವಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆಯಾದರೂ.
ವಾಸ್ತವವಾಗಿ, ಇದು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಹೊಂದಿದೆ, ಮತ್ತು SRE ಪಾತ್ರದಲ್ಲಿ ಏನನ್ನಾದರೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಾರದು ಎಂಬ ಕೆಲವೇ ಕೆಲವು ಪ್ರಕರಣಗಳಿವೆ. ಮುಂದೆ ನಾವು ದೋಷ ಬಜೆಟ್, ದೋಷಗಳಿಗಾಗಿ ಬಜೆಟ್ ಎಂದು ಕರೆಯುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ವಾಸ್ತವವಾಗಿ, ನೀವು ನಿಮಗಾಗಿ ಹೊಂದಿಸಿರುವ SLO ಗಿಂತ ಎಲ್ಲವೂ ನಿಮಗೆ ಉತ್ತಮವಾಗಿದ್ದರೆ, ಇದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಇದು ಕೆಟ್ಟದಾಗಿದೆ, ಏಕೆಂದರೆ SLO ಕಡಿಮೆಯಾಗಿ ಮಾತ್ರವಲ್ಲದೆ ಅಂದಾಜು ಮೇಲಿನ ಬೌಂಡ್ ಆಗಿಯೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು 99% ಲಭ್ಯತೆಯ SLO ಅನ್ನು ಹೊಂದಿಸಿದಾಗ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ನೀವು 99,99% ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ವ್ಯವಹಾರಕ್ಕೆ ಯಾವುದೇ ಹಾನಿಯಾಗದ ಪ್ರಯೋಗಗಳಿಗೆ ನೀವು ಸ್ವಲ್ಪ ಜಾಗವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವೇ ಇದನ್ನು ಒಟ್ಟಾಗಿ ನಿರ್ಧರಿಸಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಈ ಜಾಗವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ತಪ್ಪುಗಳಿಗಾಗಿ ನೀವು ಬಜೆಟ್ ಹೊಂದಿದ್ದೀರಿ, ಅದು ನಿಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ನಾವು ಅದನ್ನು ಏನು ಮಾಡುತ್ತೇವೆ. ನಾವು ಅದನ್ನು ಅಕ್ಷರಶಃ ಎಲ್ಲದಕ್ಕೂ ಬಳಸುತ್ತೇವೆ. ಉತ್ಪಾದನಾ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಪರೀಕ್ಷೆಗಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದಾದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊರತರಲು, ಬಿಡುಗಡೆಗಳಿಗಾಗಿ, ನಿರ್ವಹಣೆಗಾಗಿ, ಯೋಜಿತ ಅಲಭ್ಯತೆಗಳಿಗಾಗಿ. ರಿವರ್ಸ್ ನಿಯಮವು ಸಹ ಅನ್ವಯಿಸುತ್ತದೆ: ಬಜೆಟ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ನಾವು ಹೊಸದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ನಾವು SLO ಅನ್ನು ಮೀರುತ್ತೇವೆ. ಬಜೆಟ್ ಈಗಾಗಲೇ ಖಾಲಿಯಾಗಿದೆ, ಅದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರಿದರೆ ನಾವು ಏನನ್ನಾದರೂ ಬಿಡುಗಡೆ ಮಾಡಿದ್ದೇವೆ, ಅಂದರೆ, ಇದು ನೇರವಾಗಿ SLO ಅನ್ನು ಹೆಚ್ಚಿಸುವ ಕೆಲವು ರೀತಿಯ ಫಿಕ್ಸ್ ಅಲ್ಲದಿದ್ದರೆ, ನಾವು ಬಜೆಟ್ ಅನ್ನು ಮೀರಿ ಹೋಗುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಇದು ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ , ಅದನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಅಗತ್ಯವಿದೆ , ಮರಣೋತ್ತರ ಪರೀಕ್ಷೆ, ಮತ್ತು ಪ್ರಾಯಶಃ ಕೆಲವು ಪ್ರಕ್ರಿಯೆ ಪರಿಹಾರಗಳು.
ಅಂದರೆ, ಸೇವೆಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ ಮತ್ತು SLO ಖರ್ಚು ಮಾಡಿದರೆ ಮತ್ತು ಬಜೆಟ್ ಅನ್ನು ಪ್ರಯೋಗಗಳಿಗಾಗಿ ಖರ್ಚು ಮಾಡದಿದ್ದರೆ, ಕೆಲವು ಬಿಡುಗಡೆಗಳ ಮೇಲೆ ಅಲ್ಲ, ಆದರೆ ಸ್ವತಃ, ನಂತರ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಪರಿಹಾರಗಳ ಬದಲಿಗೆ, ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳ ಬದಲಿಗೆ, ಬದಲಿಗೆ ಆಸಕ್ತಿದಾಯಕ ಬಿಡುಗಡೆಗಳು. ಯಾವುದೇ ಸೃಜನಾತ್ಮಕ ಕೆಲಸದ ಬದಲಿಗೆ, ಬಜೆಟ್ ಅನ್ನು ಕ್ರಮವಾಗಿ ಮರಳಿ ಪಡೆಯಲು ಅಥವಾ SLO ಅನ್ನು ಸಂಪಾದಿಸಲು ನೀವು ಮೂರ್ಖ ಪರಿಹಾರಗಳನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.
ಆದ್ದರಿಂದ, ದೋಷಗಳಿಗಾಗಿ ನಾವು ಹೆಚ್ಚು ಬಜೆಟ್ ಹೊಂದಿರುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರೂ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ: SRE ಮತ್ತು ಡೆವಲಪರ್ಗಳು. ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ, ದೋಷಗಳಿಗಾಗಿ ದೊಡ್ಡ ಬಜೆಟ್ ಎಂದರೆ ನೀವು ಬಿಡುಗಡೆಗಳು, ಪರೀಕ್ಷೆಗಳು, ಪ್ರಯೋಗಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸಬಹುದು. SRE ಗಳಿಗೆ, ದೋಷಗಳಿಗಾಗಿ ಬಜೆಟ್ ಮತ್ತು ಆ ಬಜೆಟ್ ಅನ್ನು ನಮೂದಿಸುವುದು ಎಂದರೆ ಅವರು ನೇರವಾಗಿ ತಮ್ಮ ಕೆಲಸವನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದರ್ಥ. ಮತ್ತು ಇದು ಕೆಲವು ರೀತಿಯ ಜಂಟಿ ಕೆಲಸದ ಪ್ರೇರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳಾಗಿ ನಿಮ್ಮ SRE ಗಳನ್ನು ನೀವು ಆಲಿಸಿದರೆ, ಉತ್ತಮ ಕೆಲಸಕ್ಕಾಗಿ ನೀವು ಹೆಚ್ಚು ಸ್ಥಳಾವಕಾಶವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ ಮತ್ತು ಕಡಿಮೆ ದಿನಚರಿಯನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.
ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಪ್ರಯೋಗಗಳು ದೊಡ್ಡ ತಂಡಗಳಲ್ಲಿ SRE ಯ ಒಂದು ಪ್ರಮುಖ ಮತ್ತು ಬಹುತೇಕ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಇದು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿನ ತಂಡದಿಂದ ಬಂದಿದೆ, ಅದು ಚೋಸ್ ಮಂಕಿ ಎಂಬ ಉಪಯುಕ್ತತೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ.
ಚೋಸ್ ಮಂಕಿ CI/CD ಪೈಪ್‌ಲೈನ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸರ್ವರ್ ಅನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಕ್ರ್ಯಾಶ್ ಮಾಡುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, SRE ರಚನೆಯಲ್ಲಿ, ಕೆಳಗೆ ಬಿದ್ದ ಸರ್ವರ್ ಸ್ವತಃ ಕೆಟ್ಟದ್ದಲ್ಲ ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಅದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ಮತ್ತು ಇದು ಬಜೆಟ್ನೊಳಗೆ ಇದ್ದರೆ, ಅದು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ ಮತ್ತು ವ್ಯವಹಾರಕ್ಕೆ ಹಾನಿಯಾಗುವುದಿಲ್ಲ. ಸಹಜವಾಗಿ, ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಅನಗತ್ಯ ಸರ್ವರ್‌ಗಳು, ಸಾಕಷ್ಟು ಪುನರಾವರ್ತನೆ ಇದೆ, ಇದರಿಂದ ಇವೆಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಬಳಕೆದಾರರು ಗಮನಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಯಾರೂ ಯಾವುದೇ ಬಜೆಟ್‌ಗಾಗಿ ಒಂದು ಸರ್ವರ್ ಅನ್ನು ಬಿಡುವುದಿಲ್ಲ.
ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಅಂತಹ ಉಪಯುಕ್ತತೆಗಳ ಸಂಪೂರ್ಣ ಸೂಟ್ ಅನ್ನು ಹೊಂದಿತ್ತು, ಅದರಲ್ಲಿ ಒಂದು, ಚೋಸ್ ಗೊರಿಲ್ಲಾ, Amazon ನ ಲಭ್ಯತೆಯ ವಲಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚುತ್ತದೆ. ಮತ್ತು ಅಂತಹ ವಿಷಯಗಳು ಬಹಿರಂಗಪಡಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಮೊದಲನೆಯದಾಗಿ, ಮರೆಮಾಡಿದ ಅವಲಂಬನೆಗಳು, ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಯಾವುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಎಂಬುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಮತ್ತು ಇದು, ನೀವು ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಸಾಕಷ್ಟು ಪರಿಪೂರ್ಣವಾಗಿಲ್ಲದಿದ್ದರೆ, ಇದು ನಿಮಗೆ ಪರಿಚಿತವಾಗಿರಬಹುದು. ಮತ್ತೊಮ್ಮೆ, ನೀವು ಸ್ಟೇಜಿಂಗ್‌ನಲ್ಲಿ ಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗದ ಕೋಡ್‌ನಲ್ಲಿ ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ಇದು ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾವುದೇ ಸ್ಟೇಜಿಂಗ್ ನಿಖರವಾಗಿ ನಿಖರವಾದ ಸಿಮ್ಯುಲೇಶನ್ ಅಲ್ಲ, ಲೋಡ್ ಸ್ಕೇಲ್ ವಿಭಿನ್ನವಾಗಿದೆ, ಲೋಡ್ ಪ್ಯಾಟರ್ನ್ ವಿಭಿನ್ನವಾಗಿದೆ, ಉಪಕರಣಗಳು ಸಹ, ಹೆಚ್ಚಾಗಿ, ಇತರ. ಗರಿಷ್ಠ ಹೊರೆಗಳು ಅನಿರೀಕ್ಷಿತ ಮತ್ತು ಅನಿರೀಕ್ಷಿತವಾಗಿರಬಹುದು. ಮತ್ತು ಅಂತಹ ಪರೀಕ್ಷೆಯು ಮತ್ತೊಮ್ಮೆ ಬಜೆಟ್ ಅನ್ನು ಮೀರಿ ಹೋಗುವುದಿಲ್ಲ, ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ಚೆನ್ನಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅದು ಸ್ಟೇಜಿಂಗ್, ಆಟೋಟೆಸ್ಟ್ಗಳು, CI / CD ಪೈಪ್ಲೈನ್ ಅನ್ನು ಎಂದಿಗೂ ಹಿಡಿಯುವುದಿಲ್ಲ. ಮತ್ತು ನಿಮ್ಮ ಬಜೆಟ್‌ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಸೇರಿಸುವವರೆಗೆ, ನಿಮ್ಮ ಸೇವೆಯು ಅಲ್ಲಿಗೆ ಹೋಗಿದ್ದರೂ ಪರವಾಗಿಲ್ಲ, ಇದು ತುಂಬಾ ಭಯಾನಕವೆಂದು ತೋರುತ್ತದೆಯಾದರೂ, ಸರ್ವರ್ ಡೌನ್ ಆಯಿತು, ಎಂತಹ ದುಃಸ್ವಪ್ನ. ಇಲ್ಲ, ಅದು ಸಾಮಾನ್ಯವಾಗಿದೆ, ಅದು ಒಳ್ಳೆಯದು, ಅದು ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನೀವು ಬಜೆಟ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಖರ್ಚು ಮಾಡಬಹುದು.
ಪ್ರಶ್ನೆ: ನಾನು ಯಾವ ಸಾಹಿತ್ಯವನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು? ಕೊನೆಯಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಿ. ಬಹಳಷ್ಟು ಸಾಹಿತ್ಯವಿದೆ, ನಾನು ಕೆಲವು ವರದಿಗಳಿಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು SRE ತನ್ನದೇ ಆದ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನವಿಲ್ಲದೆ ಅಥವಾ ಕನಿಷ್ಠ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ ಕಂಪನಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಮುಖ್ಯ ಚಟುವಟಿಕೆಯು ಸಾಫ್ಟ್‌ವೇರ್ ಅಲ್ಲದ ಉದ್ಯಮದಲ್ಲಿ. ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ, ಮುಖ್ಯ ಚಟುವಟಿಕೆಯು ಸಾಫ್ಟ್‌ವೇರ್ ಅಲ್ಲದಿರುವಲ್ಲಿ, SRE ಎಲ್ಲೆಡೆಯಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ ನೀವು ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸದಿದ್ದರೂ ಸಹ ಬಳಸಬೇಕಾಗುತ್ತದೆ, ನೀವು ನವೀಕರಣಗಳನ್ನು ಹೊರತರಬೇಕಾಗುತ್ತದೆ, ನೀವು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ ಮೂಲಸೌಕರ್ಯ, ನೀವು ಬೆಳೆಯಬೇಕು, ನೀವು ಅಳೆಯಬೇಕು. ಮತ್ತು SRE ಗಳು ಈ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಊಹಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಬೆಳವಣಿಗೆ ಪ್ರಾರಂಭವಾದ ನಂತರ ಮತ್ತು ವ್ಯಾಪಾರದ ಅಗತ್ಯಗಳು ಬದಲಾದ ನಂತರ ಅವುಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಏಕೆಂದರೆ ನೀವು ಕನಿಷ್ಟ ಕೆಲವು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೀವು ಕನಿಷ್ಟ ಕೆಲವು ಬೆಳವಣಿಗೆಯನ್ನು ಹೊಂದುವ ನಿರೀಕ್ಷೆಯಿದ್ದರೆ SRE ಅನ್ನು ಹೊಂದಲು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಅನಿವಾರ್ಯವಲ್ಲ.
ಸಣ್ಣ ಯೋಜನೆಗಳು, ಸಣ್ಣ ಸಂಸ್ಥೆಗಳಿಗೆ ಅದೇ ಹೋಗುತ್ತದೆ, ಏಕೆಂದರೆ ದೊಡ್ಡ ಕಂಪನಿಗಳಿಗೆ ಬಜೆಟ್ ಮತ್ತು ಪ್ರಯೋಗಕ್ಕೆ ಸ್ಥಳವಿದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಪ್ರಯೋಗಗಳ ಈ ಎಲ್ಲಾ ಹಣ್ಣುಗಳನ್ನು ಎಲ್ಲಿ ಬೇಕಾದರೂ ಬಳಸಬಹುದು, ಅಂದರೆ, SRE, ಸಹಜವಾಗಿ, ಗೂಗಲ್‌ನಲ್ಲಿ, ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿ, ಡ್ರಾಪ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಣ್ಣ ಕಂಪನಿಗಳು ಮತ್ತು ಪ್ರಾರಂಭಗಳು ಈಗಾಗಲೇ ಮಂದಗೊಳಿಸಿದ ವಸ್ತುಗಳನ್ನು ಓದಬಹುದು, ಪುಸ್ತಕಗಳನ್ನು ಓದಬಹುದು, ವರದಿಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು. ಅವರು ಅದರ ಬಗ್ಗೆ ಹೆಚ್ಚಾಗಿ ಕೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ, ಅವರು ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡುತ್ತಾರೆ, ಅದು ಸರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಇದು ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತವಾಗಬಹುದು, ನಮಗೂ ಇದು ಬೇಕು, ಇದು ಅದ್ಭುತವಾಗಿದೆ.
ಅಂದರೆ, ಈ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವ ಎಲ್ಲಾ ಮುಖ್ಯ ಕೆಲಸಗಳನ್ನು ಈಗಾಗಲೇ ನಿಮಗಾಗಿ ಮಾಡಲಾಗಿದೆ. ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಎಸ್‌ಆರ್‌ಇ ಪಾತ್ರವನ್ನು ನಿರ್ಧರಿಸಲು ಮತ್ತು ಈ ಎಲ್ಲಾ ಅಭ್ಯಾಸಗಳನ್ನು ವಾಸ್ತವವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಲು ಇದು ಉಳಿದಿದೆ, ಅದನ್ನು ಮತ್ತೆ ಈಗಾಗಲೇ ವಿವರಿಸಲಾಗಿದೆ. ಅಂದರೆ, ಸಣ್ಣ ಕಂಪನಿಗಳಿಗೆ ಉಪಯುಕ್ತ ತತ್ವಗಳಿಂದ, ಇದು ಯಾವಾಗಲೂ SLA, SLI, SLO ನ ವ್ಯಾಖ್ಯಾನವಾಗಿದೆ. ನೀವು ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲದಿದ್ದರೆ, ಇವುಗಳು ಆಂತರಿಕ SLA ಗಳು ಮತ್ತು ಆಂತರಿಕ SLO ಗಳು, ದೋಷಗಳಿಗಾಗಿ ಆಂತರಿಕ ಬಜೆಟ್ ಆಗಿರುತ್ತದೆ. ಇದು ಯಾವಾಗಲೂ ತಂಡದೊಳಗೆ ಮತ್ತು ವ್ಯವಹಾರದೊಳಗೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಚರ್ಚೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವು ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ, ಕೆಲವು ರೀತಿಯ ಆದರ್ಶ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಘಟನೆಯಲ್ಲಿ ಖರ್ಚು ಮಾಡುತ್ತೀರಿ ಎಂದು ತಿರುಗಬಹುದು, ಆದರ್ಶ ಪೈಪ್ಲೈನ್ ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು. ಮತ್ತು ನೀವು ಐಟಿ ವಿಭಾಗದಲ್ಲಿ ಹೊಂದಿರುವ ಈ 4 ನೈನ್‌ಗಳು ಈಗ ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿಲ್ಲ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ಸಮಯವನ್ನು ಕಳೆಯಬಹುದು, ಬೇರೆಯದರಲ್ಲಿ ತಪ್ಪುಗಳಿಗಾಗಿ ಬಜೆಟ್ ಅನ್ನು ಕಳೆಯಬಹುದು.
ಅಂತೆಯೇ, ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯ ಸಂಘಟನೆಯು ಯಾವುದೇ ಗಾತ್ರದ ಕಂಪನಿಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ. ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಈ ರೀತಿಯ ಆಲೋಚನಾ ವಿಧಾನ, ಅಲ್ಲಿ ತಪ್ಪುಗಳು ಸ್ವೀಕಾರಾರ್ಹವಾದವುಗಳಾಗಿವೆ, ಅಲ್ಲಿ ಬಜೆಟ್ ಇದೆ, ಅಲ್ಲಿ ಉದ್ದೇಶಗಳಿವೆ, ಇದು 3 ಜನರಿಗೆ ಪ್ರಾರಂಭದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಯಾವುದೇ ಗಾತ್ರದ ಕಂಪನಿಗೆ ಮತ್ತೆ ಉಪಯುಕ್ತವಾಗಿದೆ.
ಮಾತನಾಡಲು ತಾಂತ್ರಿಕ ಸೂಕ್ಷ್ಮಗಳಲ್ಲಿ ಕೊನೆಯದು ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿದೆ. ಏಕೆಂದರೆ ನಾವು SLA, SLI, SLO ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ನಾವು ಬಜೆಟ್‌ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತೇವೆಯೇ, ನಾವು ನಮ್ಮ ಉದ್ದೇಶಗಳನ್ನು ಅನುಸರಿಸುತ್ತೇವೆಯೇ ಮತ್ತು ಅಂತಿಮ SLA ಅನ್ನು ಹೇಗೆ ಪ್ರಭಾವಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡದೆ ನಮಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮೇಲ್ವಿಚಾರಣೆಯು ಈ ರೀತಿ ನಡೆಯುತ್ತದೆ ಎಂದು ನಾನು ಹಲವಾರು ಬಾರಿ ನೋಡಿದ್ದೇನೆ: ಕೆಲವು ಮೌಲ್ಯವಿದೆ, ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯ ಸಮಯ, ಸರಾಸರಿ ಸಮಯ ಅಥವಾ ಡೇಟಾಬೇಸ್‌ಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ. ಅವರು ಎಂಜಿನಿಯರ್ ನಿರ್ಧರಿಸಿದ ಮಾನದಂಡವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಮೆಟ್ರಿಕ್ ರೂಢಿಯಿಂದ ವಿಚಲನಗೊಂಡರೆ, ನಂತರ ಇಮೇಲ್ ಬರುತ್ತದೆ. ನಿಯಮದಂತೆ, ಇದೆಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಅಂತಹ ಎಚ್ಚರಿಕೆಗಳ ಗ್ಲಾಟ್ಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ಸಂದೇಶಗಳ ಗ್ಲಾಟ್, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು, ಮೊದಲನೆಯದಾಗಿ, ಅವುಗಳನ್ನು ಪ್ರತಿ ಬಾರಿ ಅರ್ಥೈಸಿಕೊಳ್ಳಬೇಕು, ಅಂದರೆ, ಮೆಟ್ರಿಕ್ ಎಂದರೆ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಬೇಕು. ಕೆಲವು ಕ್ರಮಗಳ ಅಗತ್ಯತೆ. ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಮೂಲತಃ ಅವನಿಂದ ಯಾವುದೇ ಕ್ರಮ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಅವನು ಈ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಗಮನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾನೆ. ಅದು ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ನಿಯಮವಾಗಿದೆ ಮತ್ತು SRE ಅನ್ನು ಜಾರಿಗೊಳಿಸಿದಾಗ ಮೊಟ್ಟಮೊದಲ ನಿಯಮವೆಂದರೆ ಕ್ರಮ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಅಧಿಸೂಚನೆ ಬರಬೇಕು.
ಪ್ರಮಾಣಿತ ಸಂದರ್ಭದಲ್ಲಿ, 3 ಹಂತದ ಘಟನೆಗಳಿವೆ. ಎಚ್ಚರಿಕೆಗಳಿವೆ, ಟಿಕೆಟ್‌ಗಳಿವೆ, ಲಾಗ್‌ಗಳಿವೆ. ನೀವು ತಕ್ಷಣದ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಅಗತ್ಯವಿರುವ ಯಾವುದಾದರೂ ಎಚ್ಚರಿಕೆಗಳು. ಅಂದರೆ, ಎಲ್ಲವೂ ಮುರಿದುಹೋಗಿವೆ, ನೀವು ಇದೀಗ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ. ಟಿಕೆಟ್‌ಗಳು ವಿಳಂಬವಾದ ಕ್ರಮದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೌದು, ನೀವು ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ, ನೀವು ಹಸ್ತಚಾಲಿತವಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ, ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ವಿಫಲವಾಗಿದೆ, ಆದರೆ ಮುಂದಿನ ಕೆಲವು ನಿಮಿಷಗಳವರೆಗೆ ನೀವು ಅದನ್ನು ಮಾಡಬೇಕಾಗಿಲ್ಲ. ಲಾಗ್‌ಗಳು ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿಲ್ಲದ ಯಾವುದಾದರೂ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ವಿಷಯಗಳು ಸರಿಯಾಗಿ ನಡೆದರೆ, ಯಾರೂ ಅವುಗಳನ್ನು ಓದುವುದಿಲ್ಲ. ಸಿಂಹಾವಲೋಕನದಲ್ಲಿ, ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಏನಾದರೂ ಮುರಿದುಹೋಗಿದೆ, ಅದರ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದಾಗ ಮಾತ್ರ ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಓದಬೇಕಾಗುತ್ತದೆ. ಅಥವಾ ನೀವು ಸ್ವಲ್ಪ ಸಂಶೋಧನೆ ಮಾಡಬೇಕೇ? ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವುದೇ ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿಲ್ಲದ ಎಲ್ಲವೂ ಲಾಗ್‌ಗಳಿಗೆ ಹೋಗುತ್ತದೆ.
ಈ ಎಲ್ಲದರ ಅಡ್ಡ ಪರಿಣಾಮವಾಗಿ, ಯಾವ ಘಟನೆಗಳಿಗೆ ಕ್ರಿಯೆಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಾವು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದರೆ ಮತ್ತು ಈ ಕ್ರಿಯೆಗಳು ಏನಾಗಿರಬೇಕು ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ವಿವರಿಸಿದರೆ, ಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು ಎಂದರ್ಥ. ಅಂದರೆ, ಏನಾಗುತ್ತದೆ. ನಾವು ಎಚ್ಚರಿಕೆಯಿಂದ ಹೋಗುತ್ತೇವೆ. ಕ್ರಮಕ್ಕೆ ಹೋಗೋಣ. ನಾವು ಈ ಕ್ರಿಯೆಯ ವಿವರಣೆಗೆ ಹೋಗುತ್ತೇವೆ. ತದನಂತರ ನಾವು ಯಾಂತ್ರೀಕರಣಕ್ಕೆ ಹೋಗುತ್ತೇವೆ. ಅಂದರೆ, ಯಾವುದೇ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಘಟನೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ, ನಾವು ವೀಕ್ಷಣೆ ಎಂಬ ಪದಕ್ಕೆ ಹೋಗುತ್ತೇವೆ. ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ಈ ಪದದ ಸುತ್ತ ಸ್ವಲ್ಪ ಪ್ರಚಾರವೂ ಇದೆ. ಮತ್ತು ಕೆಲವು ಜನರು ಇದರ ಅರ್ಥವನ್ನು ಸಂದರ್ಭದಿಂದ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಆದರೆ ಮುಖ್ಯ ಅಂಶವೆಂದರೆ ವೀಕ್ಷಣೆಯು ವ್ಯವಸ್ಥೆಯ ಪಾರದರ್ಶಕತೆಗೆ ಒಂದು ಮೆಟ್ರಿಕ್ ಆಗಿದೆ. ಏನಾದರೂ ತಪ್ಪಾಗಿದ್ದರೆ, ನಿಖರವಾಗಿ ಏನು ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಸಿಸ್ಟಮ್ನ ಸ್ಥಿತಿ ಏನೆಂದು ನೀವು ಎಷ್ಟು ಬೇಗನೆ ನಿರ್ಧರಿಸಬಹುದು. ಕೋಡ್ ವಿಷಯದಲ್ಲಿ: ಯಾವ ಕಾರ್ಯ ವಿಫಲವಾಗಿದೆ, ಯಾವ ಸೇವೆ ವಿಫಲವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಆಂತರಿಕ ಅಸ್ಥಿರಗಳು, ಸಂರಚನೆಯ ಸ್ಥಿತಿ ಏನು. ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಲಭ್ಯತೆಯ ವಲಯದಲ್ಲಿ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ ಮತ್ತು ನೀವು ಯಾವುದೇ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಯಾವ ಪಾಡ್‌ನಲ್ಲಿ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ, ಪಾಡ್‌ನ ಸ್ಥಿತಿ ಏನು. ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ವೀಕ್ಷಣೆಯು MTTR ನೊಂದಿಗೆ ನೇರ ಸಂಬಂಧವನ್ನು ಹೊಂದಿದೆ. ಸೇವೆಯ ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆ, ದೋಷವನ್ನು ಗುರುತಿಸುವುದು ಸುಲಭ, ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದು ಸುಲಭ, ದೋಷವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಸುಲಭ, MTTR ಕಡಿಮೆ.
ಮತ್ತೆ ಸಣ್ಣ ಕಂಪನಿಗಳಿಗೆ ಹೋಗುವಾಗ, ಈಗಲೂ ಸಹ, ತಂಡದ ಗಾತ್ರವನ್ನು ಹೇಗೆ ಎದುರಿಸುವುದು ಮತ್ತು ಸಣ್ಣ ತಂಡವು ಪ್ರತ್ಯೇಕ SRE ಅನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಬೇಕೇ ಎಂದು ಕೇಳುವುದು ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ. ಈ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮುಂಚೆಯೇ ಮಾತನಾಡಿದೆ. ಪ್ರಾರಂಭದ ಅಭಿವೃದ್ಧಿಯ ಮೊದಲ ಹಂತಗಳಲ್ಲಿ ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಒಂದು ತಂಡ, ಇದು ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ SRE ಅನ್ನು ಪರಿವರ್ತನೆಯ ಪಾತ್ರವನ್ನಾಗಿ ಮಾಡಬಹುದು. ಮತ್ತು ಇದು ತಂಡವನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಪುನರುಜ್ಜೀವನಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಕನಿಷ್ಠ ಕೆಲವು ವೈವಿಧ್ಯತೆಗಳಿವೆ. ಮತ್ತು ಜೊತೆಗೆ ಇದು ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ, ಸಾಮಾನ್ಯವಾಗಿ, SRE ಯ ಜವಾಬ್ದಾರಿಗಳು ಬಹಳ ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗುತ್ತವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಜನರನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ನೀವು ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ನೇಮಿಸಿಕೊಂಡರೆ, ಸಹಜವಾಗಿ, ಅವನಿಗೆ ಕೆಲವು ನಿರೀಕ್ಷೆಗಳಿವೆ. ಮತ್ತು ಈ ನಿರೀಕ್ಷೆಗಳು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಅವಶ್ಯಕತೆಗಳು ತುಂಬಾ ಬದಲಾಗುತ್ತವೆ. ಆದ್ದರಿಂದ, SRE ಅನ್ನು ಹೇಗೆ ನೇಮಿಸಿಕೊಳ್ಳುವುದು ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಕಷ್ಟ. ನಿಮ್ಮ ಸ್ವಂತವಾಗಿ ಬೆಳೆಯುವುದು ತುಂಬಾ ಸುಲಭ. ಆದರೆ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಅತ್ಯಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ಮತ್ತು ಉತ್ತಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಬೆಳವಣಿಗೆಯ ಅವಶ್ಯಕತೆಗಳು ಇದ್ದಾಗ ಮಾತ್ರ ವಿನಾಯಿತಿ, ಬಹುಶಃ. ಅಂದರೆ, ಪ್ರಾರಂಭದ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಹೂಡಿಕೆದಾರರಿಂದ ಕೆಲವು ರೀತಿಯ ಒತ್ತಡವಾಗಿರಬಹುದು, ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಬಾರಿ ಬೆಳವಣಿಗೆಗೆ ಕೆಲವು ರೀತಿಯ ಮುನ್ಸೂಚನೆ. ನಂತರ SRE ಅನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವುದು ಮೂಲಭೂತವಾಗಿ ಸಮರ್ಥನೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಅದನ್ನು ಸಮರ್ಥಿಸಬಹುದು. ನಮಗೆ ಬೆಳವಣಿಗೆಗೆ ಅವಶ್ಯಕತೆಗಳಿವೆ, ಅಂತಹ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ ಏನೂ ಮುರಿಯುವುದಿಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ವ್ಯಕ್ತಿಯ ಅಗತ್ಯವಿದೆ.
ಮತ್ತೊಂದು ಪ್ರಶ್ನೆ. ಹಲವಾರು ಬಾರಿ ಡೆವಲಪರ್ಗಳು ಪರೀಕ್ಷೆಗಳನ್ನು ಹಾದುಹೋಗುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕತ್ತರಿಸಿದಾಗ ಏನು ಮಾಡಬೇಕು, ಆದರೆ ಉತ್ಪಾದನೆಯನ್ನು ಮುರಿಯುತ್ತದೆ, ಬೇಸ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಇತರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮುರಿಯುತ್ತದೆ, ಯಾವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು. ಅಂತೆಯೇ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ದೋಷಗಳಿಗಾಗಿ ಬಜೆಟ್ ಅನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ. ಮತ್ತು ಕೆಲವು ಸೇವೆಗಳು, ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ. ಇದು ಕ್ಯಾನರಿ ಆಗಿರಬಹುದು, ಕೇವಲ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರು, ಆದರೆ ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿ, ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ಆದರೆ ಈಗಾಗಲೇ ಏನಾದರೂ ಮುರಿದರೆ, ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಬಳಕೆದಾರರಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಪ್ರತಿಶತದಷ್ಟು ಜನರಿಗೆ ಅದು ಇನ್ನೂ ಪೂರೈಸುತ್ತದೆ ಎಂಬ ನಿರೀಕ್ಷೆಯೊಂದಿಗೆ ದೋಷಗಳಿಗಾಗಿ ಬಜೆಟ್. ಅಂತೆಯೇ, ಹೌದು, ದೋಷವಿರುತ್ತದೆ, ಕೆಲವು ಬಳಕೆದಾರರಿಗೆ ಎಲ್ಲವೂ ಮುರಿಯುತ್ತದೆ, ಆದರೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ ಎಂದು ನಾವು ಈಗಾಗಲೇ ಹೇಳಿದ್ದೇವೆ.
SRE ಪರಿಕರಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಯಿತ್ತು. ಅಂದರೆ, ಎಸ್‌ಆರ್‌ಇಗಳು ಎಲ್ಲರೂ ಬಳಸದೇ ಇರುವ ನಿರ್ದಿಷ್ಟವಾಗಿ ಏನಾದರೂ ಇದೆಯೇ. ವಾಸ್ತವವಾಗಿ, ಕೆಲವು ಹೆಚ್ಚು ವಿಶೇಷವಾದ ಉಪಯುಕ್ತತೆಗಳಿವೆ, ಕೆಲವು ರೀತಿಯ ಸಾಫ್ಟ್‌ವೇರ್ ಇದೆ, ಉದಾಹರಣೆಗೆ, ಲೋಡ್‌ಗಳನ್ನು ಅನುಕರಿಸುತ್ತದೆ ಅಥವಾ ಕ್ಯಾನರಿ ಎ / ಬಿ ಪರೀಕ್ಷೆಯಲ್ಲಿ ತೊಡಗಿದೆ. ಆದರೆ ಮೂಲಭೂತವಾಗಿ SRE ಟೂಲ್ಕಿಟ್ ಅನ್ನು ನಿಮ್ಮ ಡೆವಲಪರ್ಗಳು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿದ್ದಾರೆ. ಏಕೆಂದರೆ SRE ನೇರವಾಗಿ ಅಭಿವೃದ್ಧಿ ತಂಡದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಮತ್ತು ನೀವು ವಿಭಿನ್ನ ಪರಿಕರಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ವಿಶೇಷವಾಗಿ ಎಸ್‌ಆರ್‌ಇಗಳು ದೊಡ್ಡ ತಂಡಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರೆ, ಹಲವಾರು ತಂಡಗಳು ಇರಬಹುದಾದ ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ, ಇದು ಕಂಪನಿಯಾದ್ಯಂತದ ಪ್ರಮಾಣೀಕರಣವು ಇಲ್ಲಿ ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ 50 ತಂಡಗಳಲ್ಲಿ 50 ವಿಭಿನ್ನ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಬಳಸಿದರೆ, ಇದರರ್ಥ ಎಸ್‌ಆರ್‌ಇ ಅವುಗಳನ್ನು ತಿಳಿದಿರಬೇಕು. ಎಲ್ಲಾ. ಮತ್ತು ಸಹಜವಾಗಿ ಇದು ಎಂದಿಗೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಕೆಲಸದ ಗುಣಮಟ್ಟ, ಕನಿಷ್ಠ ಕೆಲವು ತಂಡಗಳ ನಿಯಂತ್ರಣದ ಗುಣಮಟ್ಟ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ನಮ್ಮ ವೆಬ್ನಾರ್ ಕೊನೆಗೊಳ್ಳುತ್ತಿದೆ. ನಾನು ಕೆಲವು ಮೂಲಭೂತ ವಿಷಯಗಳನ್ನು ಹೇಳಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೆ. ಸಹಜವಾಗಿ, SRE ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಒಂದು ಗಂಟೆಯಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ ನಾನು ಈ ರೀತಿಯ ಆಲೋಚನಾ ವಿಧಾನವನ್ನು, ಮುಖ್ಯ ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ತಿಳಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ತದನಂತರ ಅದು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಆಸಕ್ತಿ ಇದ್ದರೆ, ವಿಷಯವನ್ನು ಪರಿಶೀಲಿಸಲು, ನಿಮ್ಮದೇ ಆದ ಮೇಲೆ ಕಲಿಯಲು, ಇತರ ಜನರು, ಇತರ ಕಂಪನಿಗಳಲ್ಲಿ ಅದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಫೆಬ್ರವರಿ ಆರಂಭದಲ್ಲಿ, ಸ್ಲರ್ಮ್ SRE ನಲ್ಲಿ ನಮ್ಮ ಬಳಿಗೆ ಬನ್ನಿ.
ಸ್ಲರ್ಮ್ ಎಸ್‌ಆರ್‌ಇ ಮೂರು ದಿನಗಳ ತೀವ್ರ ಕೋರ್ಸ್ ಆಗಿದ್ದು ಅದು ನಾನು ಈಗ ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇನೆ, ಆದರೆ ಹೆಚ್ಚು ಆಳದೊಂದಿಗೆ, ನೈಜ ಪ್ರಕರಣಗಳೊಂದಿಗೆ, ಅಭ್ಯಾಸದೊಂದಿಗೆ, ಸಂಪೂರ್ಣ ತೀವ್ರತೆಯು ಪ್ರಾಯೋಗಿಕ ಕೆಲಸವನ್ನು ಗುರಿಯಾಗಿರಿಸಿಕೊಂಡಿದೆ. ಜನರನ್ನು ತಂಡಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗುವುದು. ನೀವೆಲ್ಲರೂ ನೈಜ ಪ್ರಕರಣಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೀರಿ. ಅದರಂತೆ, ನಾವು Booking.com ಬೋಧಕರಾದ ಇವಾನ್ ಕ್ರುಗ್ಲೋವ್ ಮತ್ತು ಬೆನ್ ಟೈಲರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಸ್ಯಾನ್ ಫ್ರಾನ್ಸಿಸ್ಕೋದಿಂದ Google ನಿಂದ ಅದ್ಭುತವಾದ ಯುಜೀನ್ ಬರಬ್ಬಾಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾನು ನಿಮಗೆ ಏನಾದರೂ ಹೇಳುತ್ತೇನೆ. ಆದ್ದರಿಂದ ನಮ್ಮನ್ನು ಭೇಟಿ ಮಾಡಲು ಮರೆಯದಿರಿ.
ಆದ್ದರಿಂದ, ಗ್ರಂಥಸೂಚಿ. SRE ನಲ್ಲಿ ಉಲ್ಲೇಖಗಳಿವೆ. ಅದೇ ಪುಸ್ತಕದಲ್ಲಿ, ಅಥವಾ Google ನಿಂದ ಬರೆದ SRE ಕುರಿತು 2 ಪುಸ್ತಕಗಳಲ್ಲಿ. ಮತ್ತೊಂದು , ಅಲ್ಲಿ ನಿಯಮಗಳು ಮತ್ತು ಅವುಗಳ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವಿವರವಾಗಿದೆ. ಮುಂದಿನ 3 ವಿವಿಧ ಕಂಪನಿಗಳಲ್ಲಿ SRE ಕುರಿತು ವರದಿಗಳು. ಪ್ರಥಮ - , ಇದು ಗೂಗಲ್‌ನ ಬೆನ್ ಟ್ರೈನರ್‌ನ ಪ್ರಮುಖ ಟಿಪ್ಪಣಿಯಾಗಿದೆ. ಎರಡನೇ - . ಮೂರನೆಯದು ಮತ್ತೆ . ನಿಂದ ನಾಲ್ಕನೇ ವರದಿ , ಇದು 5 ದೇಶಗಳಲ್ಲಿ ಕೇವಲ 190 ಪ್ರಮುಖ SRE ಉದ್ಯೋಗಿಗಳನ್ನು ಹೊಂದಿದೆ. ಇದೆಲ್ಲವನ್ನೂ ನೋಡುವುದು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಏಕೆಂದರೆ DevOps ವಿಭಿನ್ನ ಕಂಪನಿಗಳಿಗೆ ಮತ್ತು ವಿಭಿನ್ನ ತಂಡಗಳಿಗೆ ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ಅರ್ಥೈಸುತ್ತದೆ, SRE ಒಂದೇ ರೀತಿಯ ಗಾತ್ರದ ಕಂಪನಿಗಳಲ್ಲಿಯೂ ಸಹ ವಿಭಿನ್ನ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹೊಂದಿದೆ.
ಚೋಸ್ ಇಂಜಿನಿಯರಿಂಗ್ ತತ್ವಗಳ ಮೇಲೆ ಇನ್ನೂ 2 ಲಿಂಕ್‌ಗಳು: , . ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಸರಣಿಯ ಅದ್ಭುತ ಪಟ್ಟಿಗಳಿಂದ 3 ಪಟ್ಟಿಗಳಿವೆ , ಬಗ್ಗೆ ಮತ್ತು ಬಗ್ಗೆ . SRE ಯಲ್ಲಿನ ಪಟ್ಟಿಯು ನಂಬಲಾಗದಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ, ಇದು ಎಲ್ಲವನ್ನೂ ಹಾದುಹೋಗುವ ಅಗತ್ಯವಿಲ್ಲ, ಸುಮಾರು 200 ಲೇಖನಗಳಿವೆ. ಸಾಮರ್ಥ್ಯ ಯೋಜನೆ ಮತ್ತು ದೋಷರಹಿತ ಪೋಸ್ಟ್ಮಾರ್ಟಮ್ ಕುರಿತು ನಾನು ಅಲ್ಲಿಂದ ಲೇಖನಗಳನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಕುತೂಹಲಕಾರಿ ಲೇಖನ:
ಈ ಸಮಯದಲ್ಲಿ ನನ್ನ ಮಾತನ್ನು ಆಲಿಸಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ನೀವು ಏನನ್ನಾದರೂ ಕಲಿತಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. ಇನ್ನೂ ಹೆಚ್ಚಿನದನ್ನು ಕಲಿಯಲು ನೀವು ಸಾಕಷ್ಟು ವಸ್ತುಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. ಮತ್ತು ನಿಮ್ಮನ್ನು ನೋಡಿ. ಆಶಾದಾಯಕವಾಗಿ ಫೆಬ್ರವರಿಯಲ್ಲಿ.
ವೆಬ್ನಾರ್ ಅನ್ನು ಎಡ್ವರ್ಡ್ ಮೆಡ್ವೆಡೆವ್ ಆಯೋಜಿಸಿದ್ದರು.
PS: ಓದಲು ಇಷ್ಟಪಡುವವರಿಗೆ, ಎಡ್ವರ್ಡ್ ಉಲ್ಲೇಖಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡಿದರು. ಆಚರಣೆಯಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಆದ್ಯತೆ ನೀಡುವವರಿಗೆ ಸ್ವಾಗತ .
ಮೂಲ: www.habr.com