SLA 99,9%: सुंदर आँकड़े के भीतर कौन-सी गड़बड़ी छिप सकती है

कुल इंडिकेटर हरा है, लेकिन एक पेमेंट मेथड किसी के लिए भी काम नहीं कर रहा। SLA उपलब्धता सही तरीके से गिनी गई हो, तब भी ऐसा हो सकता है: कम इस्तेमाल होने वाला मेथड औसत पर लगभग असर नहीं डालता। उपयोगी SLA इन सवालों से शुरू होता है कि प्रतिशत किसकी समस्या माप रहा है, उसमें कौन-से इवेंट शामिल हैं और महीना खत्म होने से पहले टीम क्या करती है।

देखें कि हर किसे छिपा रहा है

मान लीजिए एक विंडो में 100 000 योग्य रिक्वेस्ट आईं। मुख्य मेथड से 99 900 सफल तकनीकी नतीजे मिले। दूसरे मेथड पर 100 रिक्वेस्ट आईं और सभी तकनीकी एरर पर खत्म हुईं। कुल उपलब्धता 99,9% है, दूसरे मेथड की उपलब्धता 0%। यह एक अलग काल्पनिक उदाहरण है, किसी असली सर्विस का डेटा नहीं।

ऐसी रिपोर्ट कुल फ़ॉर्मूले का सही पालन करते हुए भी बिज़नेस के लिए नाकाफ़ी हो सकती है। ज़रूरी सेगमेंट पहले से तय करें: मेथड, देश, करेंसी या कोई खास रूट। छोटे सैंपल के लिए प्रभावित ट्रांज़ैक्शन की संख्या और एरर का क्रम दिखाएँ; कई दशमलव अंकों वाला प्रतिशत ऐसी सटीकता का भ्रम देता है जो असल में नहीं है।

बिना ओनर के सैकड़ों कट न जोड़ें। सिर्फ़ वही चुनें जिन पर टीम सच में अलग फ़ैसला लेगी: किसी खास इंटीग्रेशन की जाँच करेगी, सपोर्ट को पहले से बताएगी या तय सीमाओं के भीतर ग्राहक को दिखाया जाने वाला फ़्लो कुछ समय के लिए बदलेगी। हर मेट्रिक का एक साफ़ पाने वाला होना चाहिए।

पहले तीन अवधारणाओं को अलग करें

SLI मापा जाने वाला इंडिकेटर है, SLO उसका लक्ष्य मान तय करता है, और SLA समझौते और उसके उल्लंघन के नतीजों को दर्ज करता है। Google SRE लेटेंसी के डिस्ट्रिब्यूशन पर भी ध्यान दिलाता है: औसत मान बहुत धीमे जवाबों के छोटे हिस्से को छिपा सकता है। स्रोत: Google SRE, Service Level Objectives।

पेमेंट इंटीग्रेशन के लिए तीन अंतरालों का अलग-अलग विवरण बनाएँ: रिक्वेस्ट भेजने से API के जवाब तक, ट्रांज़ैक्शन बनने से चुने गए अंतिम स्टेटस तक, और इवेंट होने से आपके सिस्टम तक नोटिफ़िकेशन पहुँचने तक। हर अंतराल में देरी के अपने कारण होते हैं। बैंक ऐप में कन्फ़र्म करने में यूज़र जो समय लगाता है, उसे इन्फ़्रास्ट्रक्चर के प्रोसेसिंग समय से अलग दिखाना चाहिए।

उपलब्धता को भी हर चाहिए

समय पर आधारित परिभाषा में, अगर पूरी अवधि बिना किसी अपवाद के गिनी जाए, तो काल्पनिक 30 दिनों में 99,9% का मतलब 43,2 मिनट की अनुपलब्धता है। रिक्वेस्ट पर आधारित परिभाषा में वही प्रतिशत कुछ और बताता है: 100 000 योग्य रिक्वेस्ट में से असफल रिक्वेस्ट का बजट 100 है। लोड के डेटा के बिना एक तरीके को दूसरे में बदला नहीं जा सकता। पीक घंटों में दस मिनट का डाउनटाइम रात के एक घंटे से ज़्यादा ट्रांज़ैक्शन पर असर डाल सकता है।

Google SRE Workbook सुझाव देता है कि कई इंडिकेटर को योग्य सफल इवेंट और गिने गए सभी इवेंट के अनुपात के रूप में बनाया जाए। इस तरीके का व्यावहारिक फ़ायदा अंश, हर और थ्रेशोल्ड की साफ़ परिभाषा में है। स्रोत: Google SRE Workbook, Implementing SLOs।

तकनीकी उपलब्धता के लिए बैंक का सही ढंग से प्रोसेस किया गया डिक्लाइन भी सर्विस का सफल जवाब माना जा सकता है। पेमेंट कन्वर्ज़न के लिए वह सफलता नहीं होगी। रिपोर्टिंग में इन इंडिकेटर को पहले से अलग रखें। यह भी तय करें कि टाइमआउट कैसे गिने जाएँगे: अगर धीमी रिक्वेस्ट अवधि दर्ज होने से पहले ही सैंपल से गायब हो जाती हैं, तो लेटेंसी का ग्राफ़ ठीक गड़बड़ी के दौरान बेहतर दिख सकता है।

सिर्फ़ औसत समय क्यों काफ़ी नहीं

काल्पनिक 1 000 रिक्वेस्ट लें: 980 रिक्वेस्ट 0,2 सेकंड में पूरी हुईं, बाकी 20 रिक्वेस्ट 10 सेकंड में। औसत 0,396 सेकंड है। यह आँकड़ा काफ़ी शांत दिखता है, जबकि बीस यूज़र को साफ़ तौर पर इंतज़ार करना पड़ा। नियरेस्ट-रैंक तरीके से गिनने पर यहाँ p95 0,2 सेकंड है और p99 10 सेकंड।

p99 पर्सेंटाइल चुने गए सैंपल में लगभग 99% ऑब्ज़र्वेशन की सीमा बताता है। यह अधिकतम समय तय नहीं करता और अगली रिक्वेस्ट के नतीजे की गारंटी नहीं देता। सैंपल का आकार और मापने की विंडो हमेशा दिखाएँ। कम इस्तेमाल होने वाले पेमेंट मेथड पर ट्रांज़ैक्शन कम होने से ऊँचे पर्सेंटाइल अस्थिर हो जाते हैं; उनके साथ धीमे मामलों की असली संख्या देखना ज़्यादा उपयोगी है।

अलग-अलग सर्वर या दिनों के p99 का औसत निकालकर कुल p99 न बनाएँ। Prometheus साफ़ चेतावनी देता है कि तैयार क्वांटाइल को इस तरह एग्रीगेट नहीं किया जा सकता; हिस्टोग्राम उनकी संरचना की शर्तें पूरी होने पर डिस्ट्रिब्यूशन को जोड़ने देते हैं। स्रोत: Prometheus, Histograms and summaries।

ऑन-कॉल इंजीनियर के लिए कॉन्ट्रैक्ट का महीना बहुत लंबा है

समझौते के पालन की रिपोर्ट और तुरंत जाँच के सिग्नल को अलग करें। मासिक आँकड़ा कॉन्ट्रैक्ट के आकलन के लिए है; ऑपरेटर के लिए हाल की एरर, पेंडिंग पेमेंट की संख्या और सबसे पुराने अनिश्चित ट्रांज़ैक्शन की उम्र मायने रखती है। अंदरूनी थ्रेशोल्ड अपने ऑब्ज़र्वेशन और स्वीकार्य नुकसान के हिसाब से तय करें, किसी गढ़े हुए सार्वभौमिक थ्रेशोल्ड को इंडस्ट्री स्टैंडर्ड बताकर पेश न करें।

प्रोवाइडर से संपर्क के लिए गुमनाम किए गए आइडेंटिफ़ायर, टाइम ज़ोन सहित सटीक विंडो, अपेक्षित नतीजा, असली कोड और प्रभावित फ़्लो का आकार सहेजें। बताएँ कि उदाहरण कैसे चुने गए। पाँच समस्या वाले पेमेंट डायग्नोसिस में काम आते हैं, लेकिन कुल संख्या के बिना पैमाने का अंदाज़ा नहीं लगता।

ऑब्ज़र्वेशन खो जाने पर क्या करना है, यह अलग से तय करें। अगर काउंटर अपडेट होना बंद हो गया है, तो 0% एरर रेट रिकवरी घोषित करने का आधार नहीं है। स्वतंत्र लॉग और काम की कतारों का मिलान करें। इंसिडेंट तब बंद करना समझदारी है जब ग्राहक का ज़रूरी कदम सच में बहाल होने की पुष्टि हो जाए और जमा हुए अज्ञात नतीजे सुलझा लिए जाएँ: API का उपलब्ध होना अभी यह नहीं बताता कि गड़बड़ी के दौरान रिक्वेस्ट के साथ क्या हुआ।

साइन करने से पहले क्या तय होना चाहिए

• ट्रांज़ैक्शन और माप की सीमाएँ: खास API, पेमेंट मेथड, क्षेत्र, नतीजे का स्टेटस।
• गणना की विंडो, टाइम ज़ोन, डेटा का स्रोत और ऑब्ज़र्वेशन की न्यूनतम संख्या।
• एरर, टाइमआउट, रिट्राई और बाहर रखे गए इवेंट को गिनने के नियम।
• असली प्रोसेस के साथ तय किए गए लेटेंसी और उपलब्धता के थ्रेशोल्ड।
• नोटिफ़िकेशन, एस्केलेशन, सबूत देने और उल्लंघन की समीक्षा की प्रक्रिया।

भले ही कॉन्ट्रैक्ट कुछ कारणों को बाहर रखता हो, यूज़र के नज़रिए से गड़बड़ियों का कुल इंडिकेटर भी बनाए रखें। किसी बाहरी पक्ष की समस्या होने पर भी ग्राहक को इंतज़ार करना ही पड़ता है। ज़िम्मेदारी का कानूनी बँटवारा और ग्राहक अनुभव का डायग्नोसिस अलग-अलग काम हैं और दोनों एक साथ दिखते रहने चाहिए।

अगली समीक्षा में सबसे ज़्यादा समस्या वाला मेथड लें और रिक्वेस्ट से ग्राहक के नतीजे तक उसका रास्ता दोबारा बनाएँ। इस रास्ते की तुलना उससे करें जो SLA असल में कवर करता है। दोनों के बीच का फ़र्क बताएगा कि कौन-सा ऑब्ज़र्वेशन या समझौते की कौन-सी शर्त सबसे पहले स्पष्ट करनी है।