SRE (ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್) ವೆಬ್ ಯೋಜನೆಗಳ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಒಂದು ವಿಧಾನವಾಗಿದೆ. ಇದನ್ನು DevOps ಗೆ ಚೌಕಟ್ಟು ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು DevOps ಅಭ್ಯಾಸಗಳನ್ನು ಅನ್ವಯಿಸುವಲ್ಲಿ ಯಶಸ್ಸನ್ನು ಹೇಗೆ ಸಾಧಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ ಅನುವಾದ ಪುಸ್ತಕಗಳು Google ನಿಂದ. ನಾನು ಈ ಅನುವಾದವನ್ನು ನಾನೇ ಸಿದ್ಧಪಡಿಸಿದ್ದೇನೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ನನ್ನ ಸ್ವಂತ ಅನುಭವವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಟೆಲಿಗ್ರಾಂ ಚಾನೆಲ್‌ನಲ್ಲಿ и ನಾನು ಸೇವಾ ಮಟ್ಟದ ಗುರಿಗಳ ಬಗ್ಗೆ ಅದೇ ಪುಸ್ತಕದ ಅಧ್ಯಾಯ 6 ರ ಅನುವಾದವನ್ನೂ ಪ್ರಕಟಿಸಿದೆ.
ಬೆಕ್ಕಿನ ಅನುವಾದ. ಓದಿ ಆನಂದಿಸಿ!
ಯಾವ ಸೂಚಕಗಳು ನಿಜವಾಗಿ ಮುಖ್ಯವಾಗಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಅಳೆಯುವುದು ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಎಂಬುದರ ಬಗ್ಗೆ ಯಾವುದೇ ತಿಳುವಳಿಕೆ ಇಲ್ಲದಿದ್ದರೆ ಸೇವೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಅಸಾಧ್ಯ. ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ನಮ್ಮ ಬಳಕೆದಾರರು ನಮ್ಮ ಆಂತರಿಕ API ಗಳಲ್ಲಿ ಒಂದನ್ನು ಅಥವಾ ಸಾರ್ವಜನಿಕ ಉತ್ಪನ್ನವನ್ನು ಬಳಸುತ್ತಾರೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ನಾವು ನಿರ್ದಿಷ್ಟ ಮಟ್ಟದ ಸೇವೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ ಮತ್ತು ಒದಗಿಸುತ್ತೇವೆ.
ಸೇವಾ ಮಟ್ಟದ ಸೂಚಕಗಳು (ಎಸ್‌ಎಲ್‌ಐಗಳು), ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶಗಳು (ಎಸ್‌ಎಲ್‌ಒಗಳು) ಮತ್ತು ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದಗಳನ್ನು (ಎಸ್‌ಎಲ್‌ಎ) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಳಕೆದಾರರ ಬಯಕೆಯ ನಮ್ಮ ಅಂತಃಪ್ರಜ್ಞೆ, ಅನುಭವ ಮತ್ತು ತಿಳುವಳಿಕೆಯನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ. ಈ ಆಯಾಮಗಳು ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಯಸುವ ಮುಖ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ನಾವು ನಿರೀಕ್ಷಿತ ಗುಣಮಟ್ಟದ ಸೇವೆಯನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ನಾವು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತೇವೆ. ಅಂತಿಮವಾಗಿ, ಸರಿಯಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ ಸರಿಯಾದ ಕ್ರಮಗಳಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುತ್ತದೆ ಮತ್ತು ಸೇವೆಯ ಆರೋಗ್ಯದಲ್ಲಿ SRE ತಂಡಕ್ಕೆ ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ.
ಮೆಟ್ರಿಕ್ ಮಾಡೆಲಿಂಗ್, ಮೆಟ್ರಿಕ್ ಆಯ್ಕೆ ಮತ್ತು ಮೆಟ್ರಿಕ್ ವಿಶ್ಲೇಷಣೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ನಾವು ಬಳಸುವ ವಿಧಾನವನ್ನು ಈ ಅಧ್ಯಾಯವು ವಿವರಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ವಿವರಣೆಯು ಉದಾಹರಣೆಗಳಿಲ್ಲದೆ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಖ್ಯ ಅಂಶಗಳನ್ನು ವಿವರಿಸಲು ನಾವು ಅದರ ಅನುಷ್ಠಾನದ ಉದಾಹರಣೆಯಲ್ಲಿ ವಿವರಿಸಿದ ಷೇಕ್ಸ್‌ಪಿಯರ್ ಸೇವೆಯನ್ನು ಬಳಸುತ್ತೇವೆ (ಷೇಕ್ಸ್‌ಪಿಯರ್‌ನ ಕೃತಿಗಳಿಗಾಗಿ ಹುಡುಕಿ).
ಸೇವಾ ಮಟ್ಟದ ಪರಿಭಾಷೆ
ಅನೇಕ ಓದುಗರು SLA ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿರಬಹುದು, ಆದರೆ SLI ಮತ್ತು SLO ಪದಗಳು ಎಚ್ಚರಿಕೆಯ ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಅರ್ಹವಾಗಿವೆ ಏಕೆಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ SLA ಪದವು ಓವರ್‌ಲೋಡ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಸಂದರ್ಭಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಹಲವಾರು ಅರ್ಥಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸ್ಪಷ್ಟತೆಗಾಗಿ, ನಾವು ಈ ಮೌಲ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಬಯಸುತ್ತೇವೆ.
ಇಂಡಿಕೇಟರ್ಸ್
SLI ಎನ್ನುವುದು ಸೇವಾ ಮಟ್ಟದ ಸೂಚಕವಾಗಿದೆ-ಒದಗಿಸಿದ ಸೇವೆಯ ಮಟ್ಟದ ಒಂದು ಅಂಶದ ಎಚ್ಚರಿಕೆಯಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಪರಿಮಾಣಾತ್ಮಕ ಅಳತೆಯಾಗಿದೆ.
ಹೆಚ್ಚಿನ ಸೇವೆಗಳಿಗೆ, ಕೀ SLI ಅನ್ನು ವಿನಂತಿಯ ಸುಪ್ತತೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ - ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇತರ ಸಾಮಾನ್ಯ SLIಗಳು ದೋಷ ದರವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವೀಕರಿಸಿದ ಎಲ್ಲಾ ವಿನಂತಿಗಳ ಒಂದು ಭಾಗವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ. ಮಾಪನಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ: ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಮೊದಲು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಬದಲಾವಣೆ, ಸರಾಸರಿ ಅಥವಾ ಶೇಕಡಾವಾರು ದರವಾಗಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ.
ತಾತ್ತ್ವಿಕವಾಗಿ, SLI ನೇರವಾಗಿ ಆಸಕ್ತಿಯ ಸೇವಾ ಮಟ್ಟವನ್ನು ಅಳೆಯುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಸಂಬಂಧಿತ ಮೆಟ್ರಿಕ್ ಮಾತ್ರ ಮಾಪನಕ್ಕೆ ಲಭ್ಯವಿದೆ ಏಕೆಂದರೆ ಮೂಲವನ್ನು ಪಡೆಯಲು ಅಥವಾ ಅರ್ಥೈಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್-ಸೈಡ್ ಲೇಟೆನ್ಸಿ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ, ಆದರೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಸುಪ್ತತೆಯನ್ನು ಅಳೆಯಬಹುದಾದ ಸಂದರ್ಭಗಳಿವೆ.
SRE ಗಳಿಗೆ ಮುಖ್ಯವಾದ ಮತ್ತೊಂದು ರೀತಿಯ SLI ಲಭ್ಯತೆ ಅಥವಾ ಸೇವೆಯನ್ನು ಬಳಸಬಹುದಾದ ಸಮಯದ ಭಾಗವಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಯಶಸ್ವಿ ವಿನಂತಿಗಳ ದರ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ, ಕೆಲವೊಮ್ಮೆ ಇಳುವರಿ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. (ಜೀವಮಾನ-ವಿಸ್ತೃತ ಅವಧಿಯವರೆಗೆ ಡೇಟಾವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಸಾಧ್ಯತೆ-ದತ್ತಾಂಶ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸಹ ಮುಖ್ಯವಾಗಿದೆ.) 100% ಲಭ್ಯತೆ ಸಾಧ್ಯವಾಗದಿದ್ದರೂ, 100% ರಷ್ಟು ಲಭ್ಯತೆ ಸಾಮಾನ್ಯವಾಗಿ ಸಾಧಿಸಬಹುದು; ಲಭ್ಯತೆಯ ಮೌಲ್ಯಗಳನ್ನು ಹೀಗೆ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ "ಒಂಬತ್ತು" ಸಂಖ್ಯೆ » ಲಭ್ಯತೆಯ ಶೇಕಡಾವಾರು. ಉದಾಹರಣೆಗೆ, 99% ಮತ್ತು 99,999% ಲಭ್ಯತೆಯನ್ನು "2 ನೈನ್ಸ್" ಮತ್ತು "5 ನೈನ್ಸ್" ಎಂದು ಲೇಬಲ್ ಮಾಡಬಹುದು. Google ಕಂಪ್ಯೂಟ್ ಎಂಜಿನ್‌ನ ಪ್ರಸ್ತುತ ಹೇಳಲಾದ ಲಭ್ಯತೆಯ ಗುರಿಯು "ಮೂರು ಮತ್ತು ಅರ್ಧ ನೈನ್" ಅಥವಾ 99,95% ಆಗಿದೆ.
ಉದ್ದೇಶಗಳು
SLO ಒಂದು ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶವಾಗಿದೆ: SLI ಯಿಂದ ಅಳೆಯುವ ಸೇವಾ ಮಟ್ಟಕ್ಕೆ ಗುರಿ ಮೌಲ್ಯ ಅಥವಾ ಮೌಲ್ಯಗಳ ಶ್ರೇಣಿ. SLO ಗಾಗಿ ಸಾಮಾನ್ಯ ಮೌಲ್ಯವೆಂದರೆ "SLI ≤ ಗುರಿ" ಅಥವಾ "ಕಡಿಮೆ ಮಿತಿ ≤ SLI ≤ ಮೇಲಿನ ಮಿತಿ". ಉದಾಹರಣೆಗೆ, SLO ಅನ್ನು 100 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆಯ ಸರಾಸರಿ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಯ ಸುಪ್ತತೆಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ ನಾವು ಶೇಕ್ಸ್‌ಪಿಯರ್ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳನ್ನು "ವೇಗವಾಗಿ" ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಬಹುದು.
ಸರಿಯಾದ SLO ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಒಂದು ಸಂಕೀರ್ಣ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಯಾವಾಗಲೂ ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಸೇವೆಗೆ ಬಾಹ್ಯ ಒಳಬರುವ HTTP ವಿನಂತಿಗಳಿಗಾಗಿ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಪ್ರಶ್ನೆ (QPS) ಮೆಟ್ರಿಕ್ ಅನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ನಿಮ್ಮ ಸೇವೆಗೆ ಭೇಟಿ ನೀಡುವ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಬಯಕೆಯಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕಾಗಿ ನೀವು SLO ಅನ್ನು ಹೊಂದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಮತ್ತೊಂದೆಡೆ, ಪ್ರತಿ ವಿನಂತಿಯ ಸರಾಸರಿ ಲೇಟೆನ್ಸಿಯು 100 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆಯಿರಬೇಕೆಂದು ನೀವು ಹೇಳಬಹುದು. ಅಂತಹ ಗುರಿಯನ್ನು ಹೊಂದಿಸುವುದರಿಂದ ನಿಮ್ಮ ಮುಂಭಾಗವನ್ನು ಕಡಿಮೆ ಸುಪ್ತತೆಯೊಂದಿಗೆ ಬರೆಯಲು ಅಥವಾ ಅಂತಹ ಸುಪ್ತತೆಯನ್ನು ಒದಗಿಸುವ ಸಾಧನಗಳನ್ನು ಖರೀದಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸಬಹುದು. (100 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು ನಿಸ್ಸಂಶಯವಾಗಿ ಅನಿಯಂತ್ರಿತ ಸಂಖ್ಯೆಯಾಗಿದೆ, ಆದರೆ ಕಡಿಮೆ ಸುಪ್ತ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿರುವುದು ಉತ್ತಮವಾಗಿದೆ. ವೇಗದ ವೇಗವು ನಿಧಾನಗತಿಯ ವೇಗಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಸೂಚಿಸಲು ಪುರಾವೆಗಳಿವೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಲ್ಲಿನ ಸುಪ್ತತೆಯು ವಾಸ್ತವವಾಗಿ ಜನರು ದೂರವಿರಲು ಒತ್ತಾಯಿಸುತ್ತದೆ ನಿಮ್ಮ ಸೇವೆಯಿಂದ.)
ಮತ್ತೊಮ್ಮೆ, ಇದು ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಸ್ಪಷ್ಟವಾಗಿದೆ: ನೀವು QPS ಅನ್ನು ಲೆಕ್ಕಾಚಾರದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಹೊರಗಿಡಬಾರದು. ಸತ್ಯವೆಂದರೆ QPS ಮತ್ತು ಲೇಟೆನ್ಸಿ ಪರಸ್ಪರ ಬಲವಾಗಿ ಸಂಬಂಧಿಸಿವೆ: ಹೆಚ್ಚಿನ QPS ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಮತ್ತು ಸೇವೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಲೋಡ್ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ತೀಕ್ಷ್ಣವಾದ ಇಳಿಕೆಯನ್ನು ಅನುಭವಿಸುತ್ತವೆ.
SLO ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮತ್ತು ಪ್ರಕಟಿಸುವುದು ಸೇವೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಈ ಕಾರ್ಯತಂತ್ರವು ನಿಧಾನಗತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯಂತಹ ಸೇವಾ ಮಾಲೀಕರ ವಿರುದ್ಧ ಆಧಾರರಹಿತ ದೂರುಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಸ್ಪಷ್ಟವಾದ SLO ಇಲ್ಲದೆ, ಬಳಕೆದಾರರು ಸಾಮಾನ್ಯವಾಗಿ ಅಪೇಕ್ಷಿತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ತಮ್ಮದೇ ಆದ ನಿರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ, ಇದು ಸೇವೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಜನರ ಅಭಿಪ್ರಾಯಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಈ ಪರಿಸ್ಥಿತಿಯು ಸೇವೆಯಿಂದ ಉಬ್ಬಿಕೊಂಡಿರುವ ನಿರೀಕ್ಷೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು, ಸೇವೆಯು ನಿಜವಾಗಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರವೇಶಿಸಬಹುದು ಎಂದು ಬಳಕೆದಾರರು ತಪ್ಪಾಗಿ ನಂಬಿದಾಗ ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿಜವಾಗಿರುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಎಂದು ಬಳಕೆದಾರರು ನಂಬಿದಾಗ ಅಪನಂಬಿಕೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು.
ಒಪ್ಪಂದಗಳು
ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದವು ನಿಮ್ಮ ಬಳಕೆದಾರರೊಂದಿಗೆ ಸ್ಪಷ್ಟವಾದ ಅಥವಾ ಸೂಚ್ಯವಾದ ಒಪ್ಪಂದವಾಗಿದ್ದು, ಅವರು ಹೊಂದಿರುವ SLO ಗಳನ್ನು ಭೇಟಿ ಮಾಡುವುದರ (ಅಥವಾ ಭೇಟಿಯಾಗದಿರುವ) ಪರಿಣಾಮಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆರ್ಥಿಕ-ರಿಯಾಯತಿ ಅಥವಾ ದಂಡ-ಆದರೆ ಅವು ಇತರ ರೂಪಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. SLO ಗಳು ಮತ್ತು SLA ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ "SLO ಗಳನ್ನು ಪೂರೈಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?" ಯಾವುದೇ ಸ್ಪಷ್ಟ ಪರಿಣಾಮಗಳಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಬಹುತೇಕ SLO ಅನ್ನು ನೋಡುತ್ತಿರುವಿರಿ.
ಎಸ್‌ಆರ್‌ಇ ಸಾಮಾನ್ಯವಾಗಿ ಎಸ್‌ಎಲ್‌ಎಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲ ಏಕೆಂದರೆ ಎಸ್‌ಎಲ್‌ಎಗಳು ವ್ಯಾಪಾರ ಮತ್ತು ಉತ್ಪನ್ನ ನಿರ್ಧಾರಗಳಿಗೆ ನಿಕಟ ಸಂಬಂಧ ಹೊಂದಿವೆ. ಆದಾಗ್ಯೂ, SRE ವಿಫಲವಾದ SLO ಗಳ ಪರಿಣಾಮಗಳನ್ನು ತಗ್ಗಿಸಲು ಸಹಾಯ ಮಾಡುವಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ. ಅವರು SLI ಅನ್ನು ನಿರ್ಧರಿಸಲು ಸಹ ಸಹಾಯ ಮಾಡಬಹುದು: ನಿಸ್ಸಂಶಯವಾಗಿ, ಒಪ್ಪಂದದಲ್ಲಿ SLO ಅನ್ನು ಅಳೆಯಲು ವಸ್ತುನಿಷ್ಠ ಮಾರ್ಗವಿರಬೇಕು ಅಥವಾ ಭಿನ್ನಾಭಿಪ್ರಾಯವಿರುತ್ತದೆ.
Google ಹುಡುಕಾಟವು ಸಾರ್ವಜನಿಕ SLA ಅನ್ನು ಹೊಂದಿರದ ಪ್ರಮುಖ ಸೇವೆಯ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ: ಪ್ರತಿಯೊಬ್ಬರೂ ಹುಡುಕಾಟವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ, ಆದರೆ ನಾವು ಪ್ರಪಂಚದೊಂದಿಗೆ ಒಪ್ಪಂದಕ್ಕೆ ಸಹಿ ಹಾಕಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಹುಡುಕಾಟವು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಇನ್ನೂ ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ - ಅಲಭ್ಯತೆಯು ನಮ್ಮ ಖ್ಯಾತಿಯ ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಜಾಹೀರಾತು ಆದಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. Google for Work ನಂತಹ ಇತರ ಹಲವು Google ಸೇವೆಗಳು ಬಳಕೆದಾರರೊಂದಿಗೆ ಸ್ಪಷ್ಟ ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದಗಳನ್ನು ಹೊಂದಿವೆ. ನಿರ್ದಿಷ್ಟ ಸೇವೆಯು SLA ಅನ್ನು ಹೊಂದಿದೆಯೇ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, SLI ಮತ್ತು SLO ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಮತ್ತು ಸೇವೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಅವುಗಳನ್ನು ಬಳಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ತುಂಬಾ ಸಿದ್ಧಾಂತ - ಈಗ ಅನುಭವಿಸಲು.
ಆಚರಣೆಯಲ್ಲಿ ಸೂಚಕಗಳು
ಸೇವೆಯ ಮಟ್ಟವನ್ನು ಅಳೆಯಲು ಸೂಕ್ತವಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮುಖ್ಯ ಎಂದು ನಾವು ತೀರ್ಮಾನಿಸಿದ್ದೇವೆ, ಸೇವೆ ಅಥವಾ ಸಿಸ್ಟಮ್‌ಗೆ ಯಾವ ಮೆಟ್ರಿಕ್‌ಗಳು ಮುಖ್ಯವೆಂದು ಈಗ ನಿಮಗೆ ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ?
ನೀವು ಮತ್ತು ನಿಮ್ಮ ಬಳಕೆದಾರರು ಏನು ಕಾಳಜಿ ವಹಿಸುತ್ತೀರಿ?
ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದಾದ SLI ನಂತೆ ನೀವು ಪ್ರತಿ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಬಳಸಬೇಕಾಗಿಲ್ಲ; ಸಿಸ್ಟಮ್‌ನಿಂದ ಬಳಕೆದಾರರು ಏನನ್ನು ಬಯಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನಿಮಗೆ ಹಲವಾರು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹಲವಾರು ಸೂಚಕಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ಪ್ರಮುಖ ಸೂಚಕಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ, ಆದರೆ ಸಣ್ಣ ಸಂಖ್ಯೆಯನ್ನು ಆರಿಸುವುದರಿಂದ ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ನ ದೊಡ್ಡ ಭಾಗಗಳನ್ನು ಗಮನಿಸದೆ ಬಿಡಬಹುದು. ಸಿಸ್ಟಂನ ಆರೋಗ್ಯವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಹಲವಾರು ಪ್ರಮುಖ ಸೂಚಕಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.
ಸೇವೆಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಎಸ್‌ಎಲ್‌ಐ ಪರಿಭಾಷೆಯಲ್ಲಿ ಹಲವಾರು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು, ಅದು ಅವರಿಗೆ ಸಂಬಂಧಿಸಿದೆ:
- ನಮ್ಮ ಉದಾಹರಣೆಯಿಂದ ಶೇಕ್ಸ್‌ಪಿಯರ್ ಸೇವೆಗಾಗಿ ಹುಡುಕಾಟ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಂತಹ ಕಸ್ಟಮ್ ಫ್ರಂಟ್-ಎಂಡ್ ಸಿಸ್ಟಮ್‌ಗಳು. ಅವು ಲಭ್ಯವಿರಬೇಕು, ಯಾವುದೇ ವಿಳಂಬಗಳಿಲ್ಲ ಮತ್ತು ಸಾಕಷ್ಟು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಹೊಂದಿರಬೇಕು. ಅಂತೆಯೇ, ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು: ನಾವು ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದೇ? ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು? ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು?
- ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳು. ಅವರು ಕಡಿಮೆ ಪ್ರತಿಕ್ರಿಯೆ ಸುಪ್ತತೆ, ಲಭ್ಯತೆ ಮತ್ತು ಬಾಳಿಕೆಗಳನ್ನು ಗೌರವಿಸುತ್ತಾರೆ. ಸಂಬಂಧಿತ ಪ್ರಶ್ನೆಗಳು: ಡೇಟಾವನ್ನು ಓದಲು ಅಥವಾ ಬರೆಯಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? ವಿನಂತಿಯ ಮೇರೆಗೆ ನಾವು ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಬಹುದೇ? ನಮಗೆ ಅಗತ್ಯವಿರುವಾಗ ಡೇಟಾ ಲಭ್ಯವಿದೆಯೇ? ಅಧ್ಯಾಯ 26 ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನು ನೋಡಿ: ಈ ಸಮಸ್ಯೆಗಳ ವಿವರವಾದ ಚರ್ಚೆಗಾಗಿ ನೀವು ಏನು ಓದುತ್ತೀರಿ ಎಂಬುದನ್ನು ನೀವು ಓದುತ್ತೀರಿ.
- ಡೇಟಾ ಸಂಸ್ಕರಣಾ ಪೈಪ್‌ಲೈನ್‌ಗಳಂತಹ ದೊಡ್ಡ ಡೇಟಾ ಸಿಸ್ಟಮ್‌ಗಳು ಥ್ರೋಪುಟ್ ಮತ್ತು ಕ್ವೆರಿ ಪ್ರೊಸೆಸಿಂಗ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಅವಲಂಬಿಸಿವೆ. ಸಂಬಂಧಿತ ಪ್ರಶ್ನೆಗಳು: ಎಷ್ಟು ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ? ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವುದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವವರೆಗೆ ಡೇಟಾ ಪ್ರಯಾಣಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? (ಸಿಸ್ಟಮ್‌ನ ಕೆಲವು ಭಾಗಗಳು ಕೆಲವು ಹಂತಗಳಲ್ಲಿ ವಿಳಂಬವನ್ನು ಹೊಂದಿರಬಹುದು.)
ಸೂಚಕಗಳ ಸಂಗ್ರಹ
ಬೋರ್ಗ್‌ಮನ್‌ನಂತಹ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅನೇಕ ಸೇವಾ ಮಟ್ಟದ ಸೂಚಕಗಳನ್ನು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ಕೆಳಗೆ ನೋಡಿ). ) ಅಥವಾ ಪ್ರಮೀಥಿಯಸ್, ಅಥವಾ ನಿಯತಕಾಲಿಕವಾಗಿ ಲಾಗ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು, ಸ್ಥಿತಿ 500 ನೊಂದಿಗೆ HTTP ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಗುರುತಿಸುವುದು. ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್-ಸೈಡ್ ಮಾನಿಟರಿಂಗ್ ಕೊರತೆಯು ಪರಿಣಾಮ ಬೀರುವ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಕಾರಣವಾಗುವುದರಿಂದ ಕೆಲವು ಸಿಸ್ಟಮ್‌ಗಳು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿರಬೇಕು. ಬಳಕೆದಾರರು, ಆದರೆ ಸರ್ವರ್-ಸೈಡ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಷೇಕ್ಸ್‌ಪಿಯರ್ ಹುಡುಕಾಟ ಪರೀಕ್ಷಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬ್ಯಾಕೆಂಡ್ ಪ್ರತಿಕ್ರಿಯೆಯ ಲೇಟೆನ್ಸಿಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು JavaScript ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಬಳಕೆದಾರರ ಬದಿಯಲ್ಲಿ ಲೇಟೆನ್ಸಿಗೆ ಕಾರಣವಾಗಬಹುದು: ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪುಟವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬ್ರೌಸರ್ ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅಳೆಯುವುದು ಉತ್ತಮ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ.
ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ
ಸರಳತೆ ಮತ್ತು ಬಳಕೆಯ ಸುಲಭತೆಗಾಗಿ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಕಚ್ಚಾ ಅಳತೆಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ. ಇದನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಮಾಡಬೇಕು.
ಕೆಲವು ಮೆಟ್ರಿಕ್‌ಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳಂತೆ ಸರಳವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಇದು ಸ್ಪಷ್ಟವಾಗಿ ನೇರವಾದ ಮಾಪನವು ಕಾಲಾನಂತರದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸೂಚ್ಯವಾಗಿ ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ. ಮಾಪನವನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಅಳತೆಯನ್ನು ಸರಾಸರಿ ಮಾಡಲಾಗಿದೆಯೇ? ನಂತರದ ಆಯ್ಕೆಯು ಕೆಲವೇ ಸೆಕೆಂಡುಗಳ ಕಾಲ ಉಳಿಯುವ ಹೆಚ್ಚಿನ ತ್ವರಿತ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ಮರೆಮಾಡಬಹುದು. ಸಮ ಸಂಖ್ಯೆಗಳೊಂದಿಗೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 200 ವಿನಂತಿಗಳನ್ನು ಮತ್ತು ಉಳಿದ ಸಮಯದಲ್ಲಿ 0 ಅನ್ನು ಪೂರೈಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಗಣಿಸಿ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳ ಸರಾಸರಿ ಮೌಲ್ಯದ ರೂಪದಲ್ಲಿ ಸ್ಥಿರ ಮತ್ತು ಎರಡು ಬಾರಿ ತತ್ಕ್ಷಣದ ಲೋಡ್ ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಸರಾಸರಿ ಪ್ರಶ್ನೆ ಲೇಟೆನ್ಸಿಗಳು ಆಕರ್ಷಕವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಇದು ಒಂದು ಪ್ರಮುಖ ವಿವರವನ್ನು ಮರೆಮಾಡುತ್ತದೆ: ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳು ವೇಗವಾಗಿರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಆದರೆ ನಿಧಾನವಾದ ಅನೇಕ ಪ್ರಶ್ನೆಗಳು ಇರುತ್ತವೆ.
ಹೆಚ್ಚಿನ ಸೂಚಕಗಳನ್ನು ಸರಾಸರಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ವಿತರಣೆಗಳಾಗಿ ಉತ್ತಮವಾಗಿ ವೀಕ್ಷಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, SLI ಲೇಟೆನ್ಸಿಗಾಗಿ, ಕೆಲವು ವಿನಂತಿಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಕೆಲವು ಯಾವಾಗಲೂ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸರಳ ಸರಾಸರಿಯು ಈ ದೀರ್ಘ ವಿಳಂಬಗಳನ್ನು ಮರೆಮಾಡಬಹುದು. ಚಿತ್ರವು ಒಂದು ಉದಾಹರಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ: ಸಾಮಾನ್ಯ ವಿನಂತಿಯು ಸರಿಸುಮಾರು 50 ms ಅನ್ನು ಪೂರೈಸಲು ತೆಗೆದುಕೊಂಡರೂ, 5% ವಿನಂತಿಗಳು 20 ಪಟ್ಟು ನಿಧಾನವಾಗಿರುತ್ತವೆ! ಸರಾಸರಿ ಸುಪ್ತತೆಯ ಆಧಾರದ ಮೇಲೆ ಮಾತ್ರ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಎಚ್ಚರಿಕೆ ನೀಡುವಿಕೆಯು ದಿನವಿಡೀ ನಡವಳಿಕೆಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ, ವಾಸ್ತವವಾಗಿ ಕೆಲವು ವಿನಂತಿಗಳ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ (ಮೇಲಿನ ಸಾಲು) ಗಮನಾರ್ಹ ಬದಲಾವಣೆಗಳಿವೆ.
50, 85, 95, ಮತ್ತು 99 ಶೇಕಡಾ ಸಿಸ್ಟಮ್ ಲೇಟೆನ್ಸಿ. Y ಅಕ್ಷವು ಲಾಗರಿಥಮಿಕ್ ಸ್ವರೂಪದಲ್ಲಿದೆ.
ಸೂಚಕಗಳಿಗಾಗಿ ಶೇಕಡಾವಾರುಗಳನ್ನು ಬಳಸುವುದರಿಂದ ವಿತರಣೆಯ ಆಕಾರ ಮತ್ತು ಅದರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನೋಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ: 99 ಅಥವಾ 99,9 ನಂತಹ ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಮಟ್ಟವು ಕೆಟ್ಟ ಮೌಲ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ 50 ಶೇಕಡಾವಾರು (ಮಧ್ಯಸ್ಥ ಎಂದೂ ಕರೆಯುತ್ತಾರೆ) ಆಗಾಗ್ಗೆ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ ಮೆಟ್ರಿಕ್. ಹೆಚ್ಚಿನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದ ಪ್ರಸರಣ, ಹೆಚ್ಚು ದೀರ್ಘಾವಧಿಯ ವಿನಂತಿಗಳು ಬಳಕೆದಾರರ ಅನುಭವದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಹೆಚ್ಚಿನ ಹೊರೆ ಮತ್ತು ಸಾಲುಗಳ ಉಪಸ್ಥಿತಿಯಲ್ಲಿ ಪರಿಣಾಮವನ್ನು ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದ ವ್ಯತ್ಯಾಸದೊಂದಿಗೆ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ನಿಧಾನವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಯಸುತ್ತಾರೆ ಎಂದು ಬಳಕೆದಾರರ ಅನುಭವ ಸಂಶೋಧನೆಯು ತೋರಿಸಿದೆ, ಆದ್ದರಿಂದ ಕೆಲವು SRE ತಂಡಗಳು ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಅಂಕಗಳ ಮೇಲೆ ಮಾತ್ರ ಗಮನಹರಿಸುತ್ತವೆ, 99,9 ಶೇಕಡಾದಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ನ ನಡವಳಿಕೆಯು ಉತ್ತಮವಾಗಿದ್ದರೆ, ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರು ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ. .
ಅಂಕಿಅಂಶಗಳ ದೋಷಗಳನ್ನು ಗಮನಿಸಿ
ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಮೌಲ್ಯಗಳ ಗುಂಪಿನ ಸರಾಸರಿ (ಅಂಕಗಣಿತದ ಸರಾಸರಿ) ಗಿಂತ ಶೇಕಡಾವಾರುಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ಇದು ಹೆಚ್ಚು ಚದುರಿದ ಮೌಲ್ಯಗಳನ್ನು ಪರಿಗಣಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸರಾಸರಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ವಿಭಿನ್ನ (ಮತ್ತು ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ) ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಕಂಪ್ಯೂಟಿಂಗ್ ಸಿಸ್ಟಂಗಳ ಕೃತಕ ಸ್ವಭಾವದಿಂದಾಗಿ, ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯಗಳು ಹೆಚ್ಚಾಗಿ ಓರೆಯಾಗಿರುತ್ತವೆ, ಉದಾಹರಣೆಗೆ, ಯಾವುದೇ ವಿನಂತಿಯು 0 ms ಗಿಂತ ಕಡಿಮೆಯಿರುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು 1000 ms ಸಮಯ ಮೀರಿದರೆ ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಯಶಸ್ವಿ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಇರುವಂತಿಲ್ಲ. ಸಮಯ ಮೀರುವುದಕ್ಕಿಂತ. ಪರಿಣಾಮವಾಗಿ, ಸರಾಸರಿ ಮತ್ತು ಸರಾಸರಿ ಒಂದೇ ಆಗಿರಬಹುದು ಅಥವಾ ಪರಸ್ಪರ ಹತ್ತಿರವಾಗಿರಬಹುದು ಎಂದು ನಾವು ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ!
ಪೂರ್ವ ಪರೀಕ್ಷೆಯಿಲ್ಲದೆ, ಮತ್ತು ಕೆಲವು ಪ್ರಮಾಣಿತ ಊಹೆಗಳು ಮತ್ತು ಅಂದಾಜುಗಳು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳದ ಹೊರತು, ನಮ್ಮ ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ ಎಂದು ತೀರ್ಮಾನಿಸದಂತೆ ನಾವು ಎಚ್ಚರಿಕೆಯಿಂದಿರುತ್ತೇವೆ. ವಿತರಣೆಯು ನಿರೀಕ್ಷೆಯಂತೆ ಇಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪ್ರಕ್ರಿಯೆಯು (ಉದಾಹರಣೆಗೆ, ಅದು ಹೊರಗಿನವರನ್ನು ನೋಡಿದಾಗ, ಹೆಚ್ಚಿನ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಲೇಟೆನ್ಸಿಗಳೊಂದಿಗೆ ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ) ಇದನ್ನು ಆಗಾಗ್ಗೆ ಮಾಡುತ್ತಿರಬಹುದು ಅಥವಾ ಆಗಾಗ್ಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ (ಎರಡೂ ಅಲ್ಲ ತುಂಬಾ ಒಳ್ಳೆಯದು).
ಸೂಚಕಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿ
SLI ಗಾಗಿ ಸಾಮಾನ್ಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಇದರಿಂದ ನೀವು ಪ್ರತಿ ಬಾರಿಯೂ ಅವುಗಳ ಬಗ್ಗೆ ಊಹಿಸಬೇಕಾಗಿಲ್ಲ. ಪ್ರಮಾಣಿತ ಮಾದರಿಗಳನ್ನು ಪೂರೈಸುವ ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪ್ರತ್ಯೇಕ SLI ಯ ನಿರ್ದಿಷ್ಟತೆಯಿಂದ ಹೊರಗಿಡಬಹುದು, ಉದಾಹರಣೆಗೆ:
- ಒಟ್ಟುಗೂಡಿಸುವ ಮಧ್ಯಂತರಗಳು: "ಸರಾಸರಿ 1 ನಿಮಿಷಕ್ಕಿಂತ ಹೆಚ್ಚು"
- ಒಟ್ಟುಗೂಡಿಸುವ ಪ್ರದೇಶಗಳು: "ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು"
- ಎಷ್ಟು ಬಾರಿ ಅಳತೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ: "ಪ್ರತಿ 10 ಸೆಕೆಂಡುಗಳು"
- ಯಾವ ವಿನಂತಿಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ: "ಬ್ಲಾಕ್ ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಉದ್ಯೋಗಗಳಿಂದ HTTP ಪಡೆಯಿರಿ"
- ಡೇಟಾವನ್ನು ಹೇಗೆ ಪಡೆಯಲಾಗುತ್ತದೆ: "ಸರ್ವರ್‌ನಲ್ಲಿ ಅಳೆಯಲಾದ ನಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಗೆ ಧನ್ಯವಾದಗಳು"
- ಡೇಟಾ ಪ್ರವೇಶ ಸುಪ್ತತೆ: "ಕೊನೆಯ ಬೈಟ್‌ಗೆ ಸಮಯ"
ಪ್ರಯತ್ನವನ್ನು ಉಳಿಸಲು, ಪ್ರತಿ ಸಾಮಾನ್ಯ ಮೆಟ್ರಿಕ್‌ಗೆ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ SLI ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಗುಂಪನ್ನು ರಚಿಸಿ; ನಿರ್ದಿಷ್ಟ ಎಸ್‌ಎಲ್‌ಐ ಎಂದರೆ ಏನೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಎಲ್ಲರಿಗೂ ಸುಲಭವಾಗುತ್ತದೆ.
ಆಚರಣೆಯಲ್ಲಿ ಗುರಿಗಳು
ನಿಮ್ಮ ಬಳಕೆದಾರರು ಯಾವುದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತೀರಿ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸುವ ಮೂಲಕ (ಅಥವಾ ಕಂಡುಹಿಡಿಯುವ ಮೂಲಕ!) ಪ್ರಾರಂಭಿಸಿ, ನೀವು ಏನನ್ನು ಅಳೆಯಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಬಳಕೆದಾರರು ಏನು ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅಳೆಯಲು ಕಷ್ಟ ಅಥವಾ ಅಸಾಧ್ಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಅವರ ಅಗತ್ಯಗಳಿಗೆ ಹತ್ತಿರವಾಗುತ್ತೀರಿ. ಆದಾಗ್ಯೂ, ನೀವು ಅಳೆಯಲು ಸುಲಭವಾದುದನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ನೀವು ಕಡಿಮೆ ಉಪಯುಕ್ತ SLOಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವಿರಿ. ಪರಿಣಾಮವಾಗಿ, ಆರಂಭದಲ್ಲಿ ಅಪೇಕ್ಷಿತ ಗುರಿಗಳನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಸೂಚಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಸೂಚಕಗಳನ್ನು ಆರಿಸುವುದಕ್ಕಿಂತ ಮತ್ತು ನಂತರ ಗುರಿಗಳನ್ನು ಸಾಧಿಸುವುದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ಕೆಲವೊಮ್ಮೆ ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.
ನಿಮ್ಮ ಗುರಿಗಳನ್ನು ವಿವರಿಸಿ
ಗರಿಷ್ಠ ಸ್ಪಷ್ಟತೆಗಾಗಿ, SLO ಗಳನ್ನು ಹೇಗೆ ಅಳೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅವು ಮಾನ್ಯವಾಗಿರುವ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಹೇಗೆ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೇಳಬಹುದು (ಎರಡನೆಯ ಸಾಲು ಮೊದಲಿನಂತೆಯೇ ಇರುತ್ತದೆ, ಆದರೆ SLI ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ):
- ಗೆಟ್ RPC ಕರೆಗಳ 99% (ಸರಾಸರಿ 1 ನಿಮಿಷ) 100ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ (ಎಲ್ಲಾ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ).
- 99% ಗೆಟ್ RPC ಕರೆಗಳು 100ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತವೆ.
ಕಾರ್ಯಕ್ಷಮತೆಯ ವಕ್ರಾಕೃತಿಗಳ ಆಕಾರವು ಮುಖ್ಯವಾಗಿದ್ದರೆ, ನೀವು ಬಹು SLO ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು:
- 90% ರಷ್ಟು RPC ಕರೆಗಳನ್ನು 1 ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ.
- 99% ರಷ್ಟು RPC ಕರೆಗಳನ್ನು 10 ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ.
- 99.9% ರಷ್ಟು RPC ಕರೆಗಳನ್ನು 100 ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ.
ನಿಮ್ಮ ಬಳಕೆದಾರರು ವೈವಿಧ್ಯಮಯ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಸೃಷ್ಟಿಸಿದರೆ: ಬೃಹತ್ ಪ್ರಕ್ರಿಯೆ (ಇದಕ್ಕಾಗಿ ಥ್ರೋಪುಟ್ ಮುಖ್ಯ) ಮತ್ತು ಸಂವಾದಾತ್ಮಕ ಸಂಸ್ಕರಣೆ (ಇದಕ್ಕಾಗಿ ಲೇಟೆನ್ಸಿ ಮುಖ್ಯವಾಗಿದೆ), ಪ್ರತಿ ಲೋಡ್ ವರ್ಗಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಗುರಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಇದು ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ:
- 95% ಗ್ರಾಹಕರ ವಿನಂತಿಗಳಿಗೆ ಥ್ರೋಪುಟ್ ಅಗತ್ಯವಿರುತ್ತದೆ. <1 ಸೆ. ಕಾರ್ಯಗತಗೊಳಿಸಿದ RPC ಕರೆಗಳ ಎಣಿಕೆಯನ್ನು ಹೊಂದಿಸಿ.
- 99% ಗ್ರಾಹಕರು ಲೇಟೆನ್ಸಿ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ. ಟ್ರಾಫಿಕ್ <1 KB ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ <10 ms ನೊಂದಿಗೆ RPC ಕರೆಗಳ ಎಣಿಕೆಯನ್ನು ಹೊಂದಿಸಿ.
SLO ಗಳನ್ನು 100% ಸಮಯಕ್ಕೆ ಪೂರೈಸಲಾಗುವುದು ಎಂದು ಒತ್ತಾಯಿಸಲು ಇದು ಅವಾಸ್ತವಿಕ ಮತ್ತು ಅನಪೇಕ್ಷಿತವಾಗಿದೆ: ಇದು ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ಪರಿಚಯಿಸುವ ವೇಗವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ದುಬಾರಿ ಪರಿಹಾರಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಬದಲಾಗಿ, ದೋಷ ಬಜೆಟ್ ಅನ್ನು ಅನುಮತಿಸುವುದು ಉತ್ತಮ - ಸಿಸ್ಟಮ್ ಅಲಭ್ಯತೆಯ ಶೇಕಡಾವಾರು ಅನುಮತಿಸಲಾಗಿದೆ - ಮತ್ತು ಈ ಮೌಲ್ಯವನ್ನು ಪ್ರತಿದಿನ ಅಥವಾ ವಾರಕ್ಕೊಮ್ಮೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಹಿರಿಯ ನಿರ್ವಹಣೆಯು ಮಾಸಿಕ ಅಥವಾ ತ್ರೈಮಾಸಿಕ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ಬಯಸಬಹುದು. (ದೋಷದ ಬಜೆಟ್ ಮತ್ತೊಂದು SLO ನೊಂದಿಗೆ ಹೋಲಿಸಲು ಕೇವಲ SLO ಆಗಿದೆ.)
SLO ಉಲ್ಲಂಘನೆಗಳ ಶೇಕಡಾವಾರು ದೋಷದ ಬಜೆಟ್‌ಗೆ ಹೋಲಿಸಬಹುದು (ಅಧ್ಯಾಯ 3 ಮತ್ತು ವಿಭಾಗವನ್ನು ನೋಡಿ ), ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ಯಾವಾಗ ನಿಯೋಜಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ಇನ್‌ಪುಟ್ ಆಗಿ ಬಳಸಲಾಗುವ ವ್ಯತ್ಯಾಸದ ಮೌಲ್ಯದೊಂದಿಗೆ.
ಗುರಿ ಮೌಲ್ಯಗಳ ಆಯ್ಕೆ
ಆಯ್ದ SLI ಗಳು, SLO ಗಳು (ಮತ್ತು ಬಹುಶಃ SLA ಗಳು) ಪ್ರತಿಬಿಂಬಿಸಬೇಕಾದ ಉತ್ಪನ್ನ ಮತ್ತು ವ್ಯಾಪಾರ ಆಸಕ್ತಿಗಳ ಕಾರಣದಿಂದಾಗಿ ಯೋಜನೆ ಮೌಲ್ಯಗಳನ್ನು (SLO ಗಳು) ಆಯ್ಕೆ ಮಾಡುವುದು ಸಂಪೂರ್ಣವಾಗಿ ತಾಂತ್ರಿಕ ಚಟುವಟಿಕೆಯಲ್ಲ. ಅಂತೆಯೇ, ಸಿಬ್ಬಂದಿ, ಮಾರುಕಟ್ಟೆಗೆ ಸಮಯ, ಸಲಕರಣೆಗಳ ಲಭ್ಯತೆ ಮತ್ತು ಹಣಕಾಸುಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಮಾಹಿತಿಯನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಬಹುದು. SRE ಈ ಸಂಭಾಷಣೆಯ ಭಾಗವಾಗಿರಬೇಕು ಮತ್ತು ವಿವಿಧ ಆಯ್ಕೆಗಳ ಅಪಾಯಗಳು ಮತ್ತು ಕಾರ್ಯಸಾಧ್ಯತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡಬೇಕು. ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಚರ್ಚೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುವ ಕೆಲವು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನಾವು ಬಂದಿದ್ದೇವೆ:
ಪ್ರಸ್ತುತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಆಧರಿಸಿ ಗುರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಡಿ.
ಸಿಸ್ಟಮ್‌ನ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಮಿತಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದ್ದರೂ, ತಾರ್ಕಿಕತೆಯಿಲ್ಲದೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ನಿಮ್ಮನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು: ಗಮನಾರ್ಹವಾದ ಮರುವಿನ್ಯಾಸವಿಲ್ಲದೆ ಸಾಧಿಸಲಾಗದ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ವೀರೋಚಿತ ಪ್ರಯತ್ನಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಸರಳವಾಗಿರಿಸಿ
ಸಂಕೀರ್ಣ SLI ಲೆಕ್ಕಾಚಾರಗಳು ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಮರೆಮಾಡಬಹುದು ಮತ್ತು ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಸಂಪೂರ್ಣಗಳನ್ನು ತಪ್ಪಿಸಿ
ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸದೆ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಲು ಇದು ಪ್ರಲೋಭನಕಾರಿಯಾಗಿದೆ, ಈ ಅವಶ್ಯಕತೆಯು ಅವಾಸ್ತವಿಕವಾಗಿದೆ. ಅಂತಹ ಆದರ್ಶಗಳನ್ನು ಸಮೀಪಿಸುವ ವ್ಯವಸ್ಥೆಯು ವಿನ್ಯಾಸ ಮತ್ತು ನಿರ್ಮಿಸಲು ಸಾಕಷ್ಟು ಸಮಯ ಬೇಕಾಗುತ್ತದೆ, ಕಾರ್ಯನಿರ್ವಹಿಸಲು ದುಬಾರಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಏನನ್ನೂ ಮಾಡುವ ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳಿಗೆ ತುಂಬಾ ಒಳ್ಳೆಯದು.
ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ SLO ಗಳನ್ನು ಬಳಸಿ
ಸಿಸ್ಟಮ್ ಗುಣಲಕ್ಷಣಗಳ ಉತ್ತಮ ವ್ಯಾಪ್ತಿಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ SLOಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ. ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ SLO ಗಳನ್ನು ರಕ್ಷಿಸಿ: ನಿರ್ದಿಷ್ಟ SLO ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ ಆದ್ಯತೆಗಳ ಕುರಿತು ನೀವು ಎಂದಿಗೂ ವಾದವನ್ನು ಗೆಲ್ಲಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅದು SLO ಅನ್ನು ಪರಿಗಣಿಸಲು ಯೋಗ್ಯವಾಗಿರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಗುಣಲಕ್ಷಣಗಳು SLO ಗಳಿಗೆ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ: SLO ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬಳಕೆದಾರರ ಸಂತೋಷದ ಮಟ್ಟವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಕಷ್ಟ.
ಪರಿಪೂರ್ಣತೆಯನ್ನು ಬೆನ್ನಟ್ಟಬೇಡಿ
ಲೋಡ್‌ನಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನ ನಡವಳಿಕೆಯ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳುವುದರಿಂದ ನೀವು ಯಾವಾಗಲೂ SLO ಗಳ ವ್ಯಾಖ್ಯಾನಗಳು ಮತ್ತು ಗುರಿಗಳನ್ನು ಪರಿಷ್ಕರಿಸಬಹುದು. ನೀವು ಸಾಧಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಕಂಡುಕೊಂಡಾಗ ವಿಶ್ರಾಂತಿ ಪಡೆಯಬೇಕಾದ ಅತಿಯಾದ ಕಟ್ಟುನಿಟ್ಟಾದ ಗುರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಕ್ಕಿಂತ ಕಾಲಾನಂತರದಲ್ಲಿ ನೀವು ಪರಿಷ್ಕರಿಸುವ ತೇಲುವ ಗುರಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಉತ್ತಮ.
SLO ಗಳು SRE ಗಳು ಮತ್ತು ಉತ್ಪನ್ನ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುವ ಕೆಲಸಕ್ಕೆ ಪ್ರಮುಖ ಚಾಲಕರಾಗಬಹುದು ಮತ್ತು ಏಕೆಂದರೆ ಅವುಗಳು ಬಳಕೆದಾರರ ಕಾಳಜಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ. ಉತ್ತಮ SLO ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ಉಪಯುಕ್ತ ಜಾರಿ ಸಾಧನವಾಗಿದೆ. ಆದರೆ ತಂಡವು ಅತಿಯಾದ ಆಕ್ರಮಣಕಾರಿ SLO ಅನ್ನು ಸಾಧಿಸಲು ವೀರೋಚಿತ ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಿದರೆ ಅಥವಾ SLO ತುಂಬಾ ಕಡಿಮೆಯಿದ್ದರೆ ಕಳಪೆ ಉತ್ಪನ್ನವು ಕಳಪೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ SLO ವ್ಯರ್ಥವಾದ ಕೆಲಸಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. SLO ಶಕ್ತಿಯುತ ಲಿವರ್ ಆಗಿದೆ, ಅದನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಬಳಸಿ.
ನಿಮ್ಮ ಅಳತೆಗಳನ್ನು ನಿಯಂತ್ರಿಸಿ
SLI ಮತ್ತು SLO ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಳಸುವ ಪ್ರಮುಖ ಅಂಶಗಳಾಗಿವೆ:
- SLI ವ್ಯವಸ್ಥೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ಮತ್ತು ಅಳತೆ ಮಾಡಿ.
- SLI ಅನ್ನು SLO ಗೆ ಹೋಲಿಸಿ ಮತ್ತು ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ.
- ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ಏನಾಗಬೇಕು ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ.
- ಈ ಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ.
ಉದಾಹರಣೆಗೆ, ಹಂತ 2 ವಿನಂತಿಯು ಸಮಯ ಮೀರುತ್ತಿದೆ ಮತ್ತು ಏನನ್ನೂ ಮಾಡದಿದ್ದರೆ ಕೆಲವೇ ಗಂಟೆಗಳಲ್ಲಿ SLO ಅನ್ನು ಮುರಿಯುತ್ತದೆ ಎಂದು ತೋರಿಸಿದರೆ, ಹಂತ 3 ಸರ್ವರ್‌ಗಳು CPU ಬೌಂಡ್ ಆಗಿವೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ಲೋಡ್ ಅನ್ನು ವಿತರಿಸುತ್ತದೆ ಎಂಬ ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. SLO ಇಲ್ಲದೆ, ನಿಮಗೆ (ಅಥವಾ ಯಾವಾಗ) ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಬೇಕೆಂದು ತಿಳಿಯುವುದಿಲ್ಲ.
SLO ಅನ್ನು ಹೊಂದಿಸಿ - ನಂತರ ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತದೆ
SLO ಅನ್ನು ಪ್ರಕಟಿಸುವುದು ಸಿಸ್ಟಂ ನಡವಳಿಕೆಗಾಗಿ ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು (ಮತ್ತು ಸಂಭಾವ್ಯ ಬಳಕೆದಾರರು) ಸಾಮಾನ್ಯವಾಗಿ ಸೇವೆಯಿಂದ ಏನನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತಾರೆ, ಅದು ಬಳಕೆಗೆ ಸೂಕ್ತವಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ಉದಾಹರಣೆಗೆ, ಫೋಟೋ-ಹಂಚಿಕೆ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುವ ಜನರು ಸ್ವಲ್ಪ ಕಡಿಮೆ ಲಭ್ಯತೆಗೆ ಬದಲಾಗಿ ದೀರ್ಘಾಯುಷ್ಯ ಮತ್ತು ಕಡಿಮೆ ವೆಚ್ಚದ ಭರವಸೆ ನೀಡುವ ಸೇವೆಯನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಬಯಸಬಹುದು, ಅದೇ ಸೇವೆಯು ಆರ್ಕೈವ್ ದಾಖಲೆಗಳ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸೂಕ್ತವಾಗಿದೆ.
ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ವಾಸ್ತವಿಕ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸಲು, ಕೆಳಗಿನ ಒಂದು ಅಥವಾ ಎರಡನ್ನೂ ಬಳಸಿ:
- ಸುರಕ್ಷತೆಯ ಅಂಚು ನಿರ್ವಹಿಸಿ. ಬಳಕೆದಾರರಿಗೆ ಜಾಹೀರಾತು ನೀಡುವುದಕ್ಕಿಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ಆಂತರಿಕ SLO ಅನ್ನು ಬಳಸಿ. ಸಮಸ್ಯೆಗಳು ಬಾಹ್ಯವಾಗಿ ಗೋಚರಿಸುವ ಮೊದಲು ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಇದು ನಿಮಗೆ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ. SLO ಬಫರ್ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಬಿಡುಗಡೆಗಳನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಸುರಕ್ಷತಾ ಅಂಚು ಹೊಂದಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಅಲಭ್ಯತೆಯ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ನಿರಾಶೆಗೊಳಿಸದೆಯೇ ಸಿಸ್ಟಮ್ ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಮೀರಬೇಡಿ. ಬಳಕೆದಾರರು ನೀವು ನೀಡುವದನ್ನು ಆಧರಿಸಿರುತ್ತಾರೆ, ನೀವು ಏನು ಹೇಳುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅಲ್ಲ. ನಿಮ್ಮ ಸೇವೆಯ ನೈಜ ಕಾರ್ಯಕ್ಷಮತೆಯು ಹೇಳಲಾದ SLO ಗಿಂತ ಉತ್ತಮವಾಗಿದ್ದರೆ, ಬಳಕೆದಾರರು ಪ್ರಸ್ತುತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತಾರೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮುಚ್ಚುವ ಮೂಲಕ ಅಥವಾ ಬೆಳಕಿನ ಲೋಡ್ಗಳ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ನೀವು ಮಿತಿಮೀರಿದ ಅವಲಂಬನೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು.
ಸಿಸ್ಟಮ್ ನಿರೀಕ್ಷೆಗಳನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ವ್ಯವಸ್ಥೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ಮತ್ತು ಅದನ್ನು ಹೆಚ್ಚು ಸುಲಭವಾಗಿ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕವಾಗಿಸಲು ಹೂಡಿಕೆ ಮಾಡಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪರ್ಯಾಯವಾಗಿ, ಸೇವೆಯು ತುಂಬಾ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಕೆಲವು ಸಿಬ್ಬಂದಿ ಸಮಯವನ್ನು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಪಾವತಿಸುವುದು, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಹೊಸ ಉತ್ಪನ್ನಗಳನ್ನು ಪರಿಚಯಿಸುವಂತಹ ಇತರ ಆದ್ಯತೆಗಳಿಗೆ ಖರ್ಚು ಮಾಡಬೇಕು.
ಆಚರಣೆಯಲ್ಲಿ ಒಪ್ಪಂದಗಳು
SLA ಅನ್ನು ರಚಿಸಲು ವ್ಯಾಪಾರ ಮತ್ತು ಕಾನೂನು ತಂಡಗಳು ಅದನ್ನು ಉಲ್ಲಂಘಿಸಿದ್ದಕ್ಕಾಗಿ ಪರಿಣಾಮಗಳು ಮತ್ತು ದಂಡಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗುತ್ತದೆ. SLA ಯಲ್ಲಿ ಒಳಗೊಂಡಿರುವ SLO ಗಳನ್ನು ಪೂರೈಸುವಲ್ಲಿ ಸಂಭವನೀಯ ಸವಾಲುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅವರಿಗೆ ಸಹಾಯ ಮಾಡುವುದು SRE ಯ ಪಾತ್ರವಾಗಿದೆ. SLO ಗಳನ್ನು ರಚಿಸುವುದಕ್ಕಾಗಿ ಹೆಚ್ಚಿನ ಶಿಫಾರಸುಗಳು SLA ಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತವೆ. ನೀವು ಬಳಕೆದಾರರಿಗೆ ಭರವಸೆ ನೀಡುವಲ್ಲಿ ಸಂಪ್ರದಾಯವಾದಿಯಾಗಿರುವುದು ಬುದ್ಧಿವಂತವಾಗಿದೆ ಏಕೆಂದರೆ ನೀವು ಹೆಚ್ಚು ಹೊಂದಿದ್ದೀರಿ, ಅಸಮಂಜಸ ಅಥವಾ ಭೇಟಿಯಾಗಲು ಕಷ್ಟಕರವೆಂದು ತೋರುವ SLA ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಅಥವಾ ತೆಗೆದುಹಾಕುವುದು ಕಷ್ಟ.
ಅನುವಾದವನ್ನು ಕೊನೆಯವರೆಗೂ ಓದಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ಮೇಲ್ವಿಚಾರಣೆಯ ಕುರಿತು ನನ್ನ ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್‌ಗೆ ಚಂದಾದಾರರಾಗಿ и .
ಮೂಲ: www.habr.com