एरर बजट और बर्न-रेट अलर्ट: सही कारणों से जगाना

उपयोगकर्ता के अनुभव से शुरू करें

ज़्यादातर शोर वाले अलर्ट कारणों — CPU, मेमोरी, रीस्टार्ट हुआ पॉड — पर अलर्ट करने से आते हैं, न कि इस पर कि उपयोगकर्ता क्या महसूस करते हैं। सर्विस-लेवल इंडिकेटर (SLI) सीधे इसे मापता है: वैध अनुरोधों में से कितने अच्छे रहे। अच्छा का मतलब हो सकता है बिना सर्वर एरर का जवाब, किसी सीमा से तेज़ जवाब, या दोनों।

सर्विस-लेवल ऑब्जेक्टिव (SLO) एक अवधि में इस अनुपात का लक्ष्य तय करता है, जैसे 30 दिनों में 99.9% अनुरोध सफल। 100% तक का अंतर एरर बजट है: यहाँ 0.1% अनुरोध, यानी महीने में लगभग 43 मिनट का पूर्ण आउटेज।

थ्रेशोल्ड अलर्ट क्यों विफल होते हैं

“5 मिनट तक एरर दर 1% से ऊपर” जैसा अलर्ट एक साथ बहुत संवेदनशील और बहुत धीमा होता है। यह उस छोटे उछाल पर जगा देता है जिसने बजट का ज़रा सा हिस्सा खर्च किया, और 0.5% की उस एरर दर पर कभी नहीं बजता जो चुपचाप एक हफ़्ते में पूरा बजट खत्म कर देती है।

बर्न रेट इसे ठीक करता है। यह SLO के सापेक्ष बजट खर्च होने की गति है: बर्न रेट 1 पूरी अवधि में ठीक-ठीक बजट खर्च करता है; बर्न रेट 14.4 तीस दिन का बजट दो दिन से थोड़े ज़्यादा में खत्म कर देता है।

मल्टी-विंडो, मल्टी-बर्न-रेट अलर्ट

Google की SRE Workbook में बताया गया तरीका हर बर्न-रेट थ्रेशोल्ड को एक लंबी विंडो के साथ जोड़ता है, जो साबित करती है कि समस्या गंभीर है, और एक छोटी विंडो के साथ, जो साबित करती है कि यह अभी भी जारी है। 30 दिनों में 99.9% SLO के लिए एक आम शुरुआती बिंदु है:

• जगाएँ: 1 घंटे और 5 मिनट दोनों में बर्न रेट 14.4 से ऊपर — एक घंटे में बजट का 2% खर्च।
• जगाएँ: 6 घंटे और 30 मिनट दोनों में बर्न रेट 6 से ऊपर — बजट का 5% खर्च।
• टिकट: 3 दिन और 6 घंटे दोनों में बर्न रेट 1 से ऊपर — बजट का 10% खर्च।

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

छोटी विंडो उतनी ही ज़रूरी है जितनी लंबी: जैसे ही फ़िक्स लागू होता है, 5 मिनट का अनुपात गिरता है और अलर्ट बाकी घंटे बजते रहने के बजाय बंद हो जाता है।

वे बारीकियाँ जो तय करती हैं कि यह काम करेगा या नहीं

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

बजट किस लिए है

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