त्रुटि बजट और एसएलओ प्रबंधन

1) एसएलओ और त्रुटि बजट क्यों

एसएलओ (सेवा स्तर उद्देश्य) - उपयोगकर्ता द्वारा कथित लक्ष्य गुणवत्ता स्तर; SLI - मापा मीट्रिक; प्रति विंडो विचलन के लिए त्रुटि बजट - सहिष्णुता (आमतौर पर 30/90 दिन)।

त्रुटि बजट एक "अमूर्तता" से विश्वसनीयता को एक प्रबंधित संसाधन में बदल देता है: जब बजट जल्दी से जलता है, तो हम सुविधाओं और चिनम को फ्रीज करते हैं; जब बजट स्वस्थ होता है - तो आप रिलीज को गति दे सकते हैं।

2) एसएलआई पिक: "अच्छा" के रूप में क्या मायने रखता है

मानदंड: "उपयोगकर्ता के दृष्टिकोण से सफल।"

2. 1 क्लासिक एसएलआई

उपलब्धता सफल अनुरोधों का प्रतिशत है (ग्राहक द्वारा रद्द किए गए लोगों को छोड़ कर)।

'success = http_status ∈ {2xx, 3xx, 404} और नो टाइमआउट' (404 को पढ़ा हुआ एपीआई सफलता माना जा सकता है यदि यह शब्दार्थ की अपेक्षा है)।

विलंबता: अनुरोधों का अनुपात सीमा से अधिक तेज है (उदाहरण के लिए, p95 ≤ 300 एमएस)।

'good _ latency = duration_ms ≤ 300'।

ताजगी/स्थिरता: "डेटा एक्स मिनट से पुराना नहीं है" (कैश, निर्देशिका, गुणांक)।

गुणवत्ता: परिणाम की शुद्धता (पासिंग बिजनेस वेलिडेटर्स/बैकेंड इनवेरिएंट्स)।

2. 2 सीमाएँ और खंड

SLI को महत्वपूर्ण स्लाइस द्वारा गिना जाना चाहिए: 'मार्ग', 'किरायेदार/ब्रांड', 'क्षेत्र/क्षेत्राधिकार', 'भुगतान _ प्रदाता'। इसलिए आप पूरे सिस्टम में एक महत्वपूर्ण हैंडल की विफलता को "धब्बा" नहीं देंगे।

3) सूत्र और बजट

3. 1 अनुरोध-आधारित (एपीआई के लिए पसंदीदा)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 समय-आधारित (पृष्ठभूमि सेवाओं/स्ट्रीमिंग के

SLO_uptime = good_minutes / total_minutes

3. 3 लक्ष्यों का उदाहरण

एपीआई जनरल: 99। 30 दिनों में 9% उपलब्धता - बजट = 0। 1%.
महत्वपूर्ण भुगतान कलम: 99। 95%; कैटलॉग/खोज: 99। 5%.

लेटेंसी: '/v1/भुगतान 'पर p95 ≤ 300 ms, p99 ≤ 800 ms।

4) एसएलआई इंस्ट्रूमेंटेशन

4. 1 सिद्धांत

लॉग/ट्रेल्स → RED (दर/त्रुटियां/अवधि) स्पष्ट बाल्टी के साथ मैट्रिक्स।

'किरायेदार', 'क्षेत्र', 'रूट _ क्लास' (पीआईआई के बिना) लगाना सुनिश्चित करें।

दो मैट्रिक्स की गणना करें: "सफलता" और "कुल", और विलंबता के लिए, "तेज" और "कुल"।

4. 2 प्रोमेथियस उदाहरण (दर प्रति 5 मी)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) बर्न रेट (मल्टी-विंडो, मल्टी-बर्न) द्वारा अलर्ट

5. 1 आइडिया

हम देखते हैं कि लक्ष्य के सापेक्ष बजट कितनी तेजी से जलता है। यदि गति एक छोटी और लंबी खिड़की पर उच्च है, तो हम संकेत देते हैं।

5. 2 थ्रेशोल्ड प्रोफाइल (SLO 99 के लिए। 9%)

पेजिंग: बर्न रेट ≥ 14। 4 × (1 घंटे के लिए बजट का 10% और 6 घंटे के लिए 5%)।

टिकट: बर्न रेट ≥ 6 × (6 घंटे में 2% और 24 घंटे में 1%)।

5. 3 उदाहरण नियम (प्रोमेथियस, छद्म)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

इसी तरह टिकट के लिए 6h/24h के लिए।

6) बजट का कार्यालय: प्रक्रियाएं

6. 1 रिलीज़ गेट्स

यदि बजट का संतुलन <25% है और प्रवृत्ति नकारात्मक है - सुविधाओं पर "कोड-फ्रीज", प्राथमिकता एसआरई/स्थिरता है।

कैनरी रिलीज़ में एक अलग SLO स्लाइस ('तैनाती) होना चाहिए। पर्यावरण =" कैनरी")।

6. 2 बैकलॉग को प्राथमिकता देना

दहन दर और राजस्व प्रभाव के अनुपात में कमांड क्षमता वितरित करें।

मैट्रिक्स के साथ तकनीकी ऋण को सही ठहराएं: "फिक्स एक्स वाई% द्वारा जलन दर को कम करेगा।"

6. 3 पोस्ट-घटना

प्रत्येक घटना - आरसीए और "फिक्स जिसे वापस रोल नहीं किया जा सकता है" (कार्रवाई योग्य), नियंत्रण "एसएलओ में वापस आ गया है।"

7) कोड के रूप में SLO

7. 1 एसएलओ मेनिफेस्ट उदाहरण (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 नियम पीढ़ी

नियम, डैशबोर्ड और रिपोर्ट बनाने के लिए जनरेटर (स्लो-जनरेटर, पाइरा, स्लॉथ) का उपयोग करें।

8) एसएलओ गिरावट और सुरक्षा

लोड शेडर: चरम पर "महंगी" निर्भरता के बिना त्वरित जवाब दें।

कैश और बासी: 'बासी-जबकि-पुनर्नवीनीकरण' для पढ़ें।

दर/संगोष्ठी सीमा: बैकेंड की रक्षा करता है; महत्वपूर्ण मार्ग - प्राथ

सर्किट/टाइमआउट: फास्ट टाइमआउट और "फॉलबैक" शाखाएं।

फ्लैग्स: एक बटन के साथ भारी सुविधाओं को अक्षम करना।

9) एसएलओ के लिए अवलोकन

डैशबोर्ड: एसएलओ वास्तविक बनाम लक्ष्य, बजट संतुलन, बर्न दर, मार्गों/प्रदाताओं द्वारा योगदान।

सहसंबंध: SLO के "छेद" से अनुकरणीय - एक विशिष्ट ट्रेस लॉग/प्रोफाइल।

रिपोर्ट: साप्ताहिक - रुझान, बजट की खपत, गिरावट के शीर्ष कारण।

10) एंटीपैटर्न

पूरे "मास्क समस्याओं के लिए एक" वैश्विक "एसएलओ। खंड।

«99. हर चीज पर 99%" लागत और वास्तविकता को छोड़ कर। उपयोगकर्ता अनुभव से लक्ष्य चुनें।

बर्न दर/एसएलओ के बजाय सीपीयू/ढेर अलर्ट।

UX को खराब करने वाले 4xx/long redirects को अनदेखा करना।

अपारदर्शी खिड़की (रोलिंग बनाम कैलेंडर) - "संतरे के साथ सेब" की तुलना।

11) आईगेमिंग/वित्त की विशिष्टताएं

मुद्रा पथ (जमा/निकासी): समग्र स्तर से ऊपर व्यक्तिगत एसएलओ (जैसे) 99. 95% उपलब्धता; p95 ≤ 250 ms)।

PSP/KYC प्रदाता: जलाने में उनके योगदान के लिए प्रत्येक प्रदाता + अलर्ट के लिए SLO; स्वचालित मार्ग स्विचिंग (स्मार्ट रूटिंग)

न्यायालय/किरायेदार: एसएलओ और बजट 'क्षेत्र/अधिकार क्षेत्र/ब्रांड' द्वारा ताकि एक स्थानीय समस्या वैश्विक मीट्रिक को "बाढ़" न हो।

जिम्मेदार खेल: सीमा/स्व-बहिष्करण (अनुपालन-सूत्र) के आवेदन की अवधि के लिए एसएलओ।

लेखा परीक्षा/नियामक: एसएलओ और घटना रिपोर्ट रखें; आंतरिक ऑडिट के लिए पारदर्शिता।

12) प्रोड रेडीनेस चेकलिस्ट

• एसएलआई (उपलब्धता/विलंबता/गुणवत्ता/ताजगी) और खंडों (मार्ग/किरायेदार/क्षेत्र) को परिभाषित किया गया है।
• लक्ष्य (एसएलओ) यथार्थवादी हैं, व्यापार के साथ संरेखित हैं; रोलिंग विंडो 30/90 दिन हैं।
• मल्टी-विंडो (पेजिंग/टिकट) के साथ बर्न रेट द्वारा अलर्ट।
• एसएलओ कोड के रूप में (नियम/डैशबोर्ड जनरेटर); बजट रिपोर्ट।
• रिलीज़ गेट बाकी बजट से बंधे हैं; कैनरी अनुभाग।
• क्षरण तंत्र (शेडर, कैश बासी, सर्किट, सीमा) को लागू और परीक्षण किया जाता है।
• मेट्रिक्स - ट्रेल्स सहसंबंध, स्पष्ट रनबुक।
• वित्तीय/क्षेत्राधिकार मार्ग - अलग एसएलओ/अलर्ट; PSP/KYC असंबद्ध हैं।
• नियमित घटना रेट्रो और बर्न-आधारित विश्वसनीयता निवेश।

13) टीएल; डीआर

उपयोगकर्ता मूल्य द्वारा SLIs को परिभाषित करें, यथार्थवादी SLO सेट करें, और त्रुटि बजट के माध्यम से प्रबंधन करें और मल्टी-विंडोज के साथ बर्न दर। योजना के अनुसार SLO-as-code, रिलीज़ गेट और क्षरण सक्षम करें। मार्ग/किरायेदार/क्षेत्र द्वारा खंड; पैसे के रास्ते के लिए तंग लक्ष्य और अलग अलर्ट रखते हैं।