एसएलओ/एसएलए और मेट्रिक्स

SLO/SLA और मैट्रिक्स

1) शर्तें और पदानुक्रम

SLI (सेवा स्तर संकेतक) - एक औसत दर्जे का संकेतक "जैसा कि उपयोगकर्ता हमें देखता है": सफल अनुरोधों का हिस्सा, p95 विलंबता, डेटा की ताजगी, सफलतापूर्वक संसाधित बैचों का हिस्सा, आदि।

एसएलओ (सेवा स्तर उद्देश्य) - अवलोकन अंतराल (28/30/90 दिन) पर एसएलआई मूल्य लक्षित करें। उदाहरण: "99। 9% अनुरोध/भुगतान अंत ≤ 400 एमएस।"

त्रुटि बजट - 1 − SLO। एसएलओ 99 पर। 9% त्रुटि बजट = 0। 1% समय/अनुरोध।

एसएलए (समझौता) - कानूनी रूप से महत्वपूर्ण सेवा स्तर: एसएलओ, माप, अपवाद, मुआवजे/जुर्माना शामिल हैं।

2) डिजाइन सिद्धांत

लक्षण> आंतरिक मैट्रिक्स। एसएलआई को वास्तविक उपयोगकर्ता अनुभव को प्रतिबिंबित करना चा

प्रमुख एसएलआई की कम संख्या। सेवा के लिए - 2-5 मुख्य: सफलता, विलंबता, थ्रूपुट/ताजगी, शुद्धता।

महत्वपूर्ण रास्तों का कवरेज। प्रत्येक व्यवसाय परिदृश्य (चेकआउट, लॉगिन, वेबहुक, ईटीएल डाउनलोड) का अपना एसएलआई/एसएलओ है।

सख्त "सफलता" शब्दार्थ। "कोड 200" नहीं, लेकिन "उपयोगकर्ता को समय पर प्रतिक्रिया मिली और परिणाम वैध है।"

बाहरी और आंतरिक एसएलओ का पृथक्करण। आंतरिक - सख्त; बाहरी SLA ≤ 1-2 नाइन कम।

3) एसएलआई कैटलॉग (संदर्भ)

3. 1 एपीआई/ऑनलाइन सेवाएं

सफलता: 'SLI _ सफलता = 1 − (5xx + टाइमआउट + business_error )/ all_requests'

लेटेंसी: p95/p99 'http _ server _ deration _ secons' मार्ग/विधि/किरायेदार द्वारा

बैंडविड्थ: 'आरपीएस '/लिमिट/कोटा

शुद्धता: वैध प्रतिक्रियाओं का अनुपात (हस्ताक्षर, स्कीमा, अपरिवर्तनीय)

3. 2 वेबहूक/अतुल्यकालिक प्रसव

डिलीवरी: टी सेकंड और ≤ N रिट्रेज़में पुष्टि की गई घटनाओं का अनुपात

ग्राहक: लंबे समय तक देरी के बिना ग्राहकों का प्रतिशत (प्रति किरायेदार)

3. 3 डेटा/ईटीएल/डीडब्ल्यूएच

ताजगी: 'अब

पूर्णता: 'ingested _ rows/ expected_rows'

शुद्धता: गुणवत्ता जांच पारित करने वाले अभिलेखों का अनुपात

पाइपलाइन: समय सीमा से पहले पूरी की गई नौकरियों का हिस

3. 4 मोबाइल/क्लाइंट एसडीके

क्लाइंट सफलता: घातक त्रुटियों के बिना सत्रों का अनुपात

राउंड-ट्रिप लेटेंसी: अनुरोध से रेंडर तक p95

कैश हिट: कैश से परोसा गया प्रतिशत (प्रदर्शन के लक्षण के रूप में)

4) सूत्र और लक्ष्यों के उदाहरण

• 'SLI _ req _ avail = 1 − (failed_requests/ total_requests)'
• 'SLO _ req _ avail = 99। 30 दिनों के लिए 95% '- त्रुटि बजट = 0। 05% अनुरोध।

• 'अपटाइम = (obs_window − डाउनटाइम )/ obs_window'

• 7-दिवसीय स्लाइस पर 'SLO _ latency = p95 (रूट = "/पे ") ≤ 400 ms', कैश वार्म-अप (1%) को छोड़ कर

• 'SLO _ ताजगी (डेटासेट = "ऑर्डर") ≤ 24 घंटे में 10 मिनट' p99।

5) त्रुटि बजट और परिवर्तन प्रबंधन

बजट (बी): 'बी = 1 − SLO'।

बर्न - स्वीकार्य त्रुटियों के लिए वास्तविक त्रुटियों का अनुपात।

• ओवरस्पेंड (बर्न> 1) → सुविधा फ्रीज, विश्वसनीयता पर ध्यान केंद्रित करें।
• बर्न दर> X छोटी विंडो घटना और टोपी में। उपाय।
• योजना: विश्वसनीयता का स्प्रिंट का हिस्सा पिछली अवधि में जलने से संबंधित है।

6) अलर्टिंग: बर्न रेट और मल्टी-विंडो नियम

विचार: हम तेजी से लीक और धीमे बहाव को पकड़ ते हैं।

• महत्वपूर्ण: "1 घंटे में 2% बजट" (तेज आग)।
• चेतावनी: "6 घंटे में बजट का 5%" (रेंगना गिरावट)।

• त्वरित घटनाओं के लिए लघु खिड़की (मिनट-घंटा)।
• रुझानों के लिए लंबी खिड़की (6-24 घंटे)।
• विलंबता: p99> दहलीज ≥5 मिनट द्वारा सतर्क, ट्रेस उदाहरणों के साथ फड़फड़ाने और संचार के दमन के साथ।

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) बहु-किरायेदार और विभाजन

SLI/SLO को किरायेदारों/योजनाओं/क्षेत्रों के अनुसार गिना जाता है, अन्यथा मंझला विफलताओं को "कवर" करेगा।

सांख्यिकीय महत्व (गार्ड-रेल) के लिए घटनाओं की न्यूनतम संख्या।

एसएलए टैरिफ में भिन्न हो सकता है (उदाहरण के लिए, "प्रो 99। 9%, नि: शुल्क 99। 5%»).

8) अवलोकन और निशान के साथ संघ

SLI मैट्रिक्स - हिस्टोग्राम/काउंटर से उदाहरण के साथ - "खराब" ट्रेल्स में संक्रमण।

लॉग कारणों का स्रोत हैं: टाइमआउट, बिजनेस त्रुटि कोड, सीमाएं।

डेटा के लिए - वंश के साथ एक लिंक: "कौन सी नौकरी ने ताजगी मीट्रिक में देरी की।"

9) अनुबंध और एसएलए

• SLI/माप विधि/विंडो परिभाषाएँ।
• अपवाद (नियोजित कार्य, बल राजसी)।
• हादसा और संचार प्रक्रिया (स्थिति पृष्ठ, RFO/RCA)।
• सेवा क्रेडिट और अनुरोध आदेश।
• क्षेत्राधिकार, वैधता की अवधि, संशोधन की शर्तें।

• कभी भी सार्वजनिक रूप से एसएलओ को वास्तुकला और परिचालन प्रथाओं की तुलना में सख्त वादा नहीं
• अलग आंतरिक एसएलओ और बाहरी एसएलए।

10) लागत और प्राथमिकता

नाइन की कीमत रैखिक रूप से नहीं बढ़ रही है। «99. 9% → 99. 99%" = अलग आर्किटेक्चर क्लास (एन + 1, मल्टी-ज़ोन, एसेट-टू-एसेट)।

सबसे मूल्यवान उपयोगकर्ता क्रियाओं पर SLO डालें।

टेलीमेट्री की लागत को नियंत्रित करें - वर्ग द्वारा डाउनसैम्पलिंग, कोटा, प्रतिकृति और भंडारण।

11) प्रक्रियाएं और रिपोर्टिंग

साप्ताहिक रिपोर्ट: सेवा/किरायेदार, बजट व्यय, शीर्ष कारणों, सुधार योजनाओं द्वारा एसएलओ निष्पादन।

पोस्ट-घटना आरसीए: हम बजट के टुकड़ों के साथ जुड़ ते हैं; हम मूल कारणों को समाप्त करने के लिए कार्य निर्धारित करते हैं।

फिचफ्रीज़: समावेश/वापसी मानदंड।

12) टेम्पलेट्स (एक त्वरित शुरुआत के लिए)

12. 1 एसएलओ कार्ड (उदाहरण)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 एसएलओ परिपक्वता तालिका

13) नियमों के उदाहरण (टुकड़े)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) डेटा और एमएल के लिए एसएलओ (सुविधाएँ)

एंड-टू-एंड डेटा SLO: p99 ताजगी, p99 पूर्णता, पोस्ट-क्रैश "पुनर्प्रसंस्करण" समय।

डेटा अनुबंध: अपेक्षित योजनाएं, मात्रा, समय सीमा; डेटा उल्लंघन → घटना।

एमएल: अनुमान विलंबता के लिए एसएलओ, सुविधा स्टॉर उपलब्धता के लिए एसएलए, बहाव निगरानी (मॉडल गुणवत्ता एक अलग विषय है, एसएलए के बाहर)।

15) सुरक्षा और गोपनीयता के साथ एकीकरण

SLI PII/रहस्यों के बिना लॉग; टोकन/मास्किंग।

लेखा परीक्षा SLO/SLA में बदलती है और अपरिवर्तनीय लॉग में प्रकाशनों की रिपोर्ट करती है।

नियामक मार्गों (भुगतान/पीआईआई) के लिए - अलग, अधिक कठोर एसएलओ।

16) चेकलिस्ट

सेवा/सुविधाएँ प्रारंभ करने से पहले

• सफलता/लेटेंसी/थ्रूपुट/फ्रेशनेस एसएलआई परिभाषित।
• एसएलओ और विंडो परिभाषित; एक त्रुटि बजट की गणना की जाती है।
• बर्न-रेट अलर्ट सेट करें (छोटा + लंबा)।
• डैशबोर्ड RED + उदाहरण - मार्ग; घटना runibooks।
• मल्टी-लीज सेक्शन और महत्व थ्रेसहोल्ड।
• Fichfreeze और रिपोर्टिंग प्रक्रिया।

ऑपरेशन

• SLO/बर्न साप्ताहिक रिपोर्ट, सख्त योजनाएं।
• वास्तुकला/लोड बदलने पर एसएलओ का पुनर्मूल्यांकन करें।
• आवधिक "ड्रिल घटनाएं" और रनिबुक अपडेट।
• टेलीमेट्री लागत और SLI गणना मॉनिटर करें।

17) Runbook'и

रनबुक: रैपिड ग्रोथ p99/पे

1. अलर्ट p99> सीमा - एक डैशबोर्ड खोलें ट्रेस करने के लिए अनुकरणीय के माध्यम से जाएं।

2. एक संकीर्ण क्लाइंट/सर्वर अवधि ढूंढें, क्षेत्रों/संस्करणों की तुलना करें।

3. डिग्रेडेशन (कैश/लिमिट/फॉलबैक) सक्षम करें, निर्भरता कमांड को सूचित करें।

4. स्थिरीकरण के बाद - आरसीए, अनुकूलन कार्य, एसएलओ माप को अद्यतन करना।

रनबुक: सप्ताह के लिए बजट व्यय> 50%

1. फ्रीज सुविधाएँ, विश्वसनीयता प्राथमिकता बढ़ा

2. त्रुटियों का समूह: मार्गों/किरायेदारों/निर्भरताओं द्वारा।

3. रोल आउट सुधार - प्रवृत्ति वसूली की पुष्टि।

4. पूर्वव्यापी और सतर्क/दहलीज समायोजन।

18) एफएक्यू

प्रश्न: आपको कितने एसएलओ की आवश्यकता है?

A: महत्वपूर्ण उपयोगकर्ता परिदृश्यों पर न्यूनतम: सफलता + विलंबता। बाकी सब कुछ आवश्यकता से बाहर है।

प्रश्नः समय या अनुरोध द्वारा कौन सी बेहतर उपलब्धता है?

A: मांग पर - अधिक उपयोगकर्ता मीट्रिक। नेटवर्क घटकों/इंफ्रा के लिए समय सुविधाजनक है।

प्रश्न: p95 क्यों, औसत नहीं?

A: मध्य पूंछ को छिपाता है; उपयोगकर्ता p95/p99 महसूस करता है।

प्रश्न: कैसे "शिकंजा कसना" बहुत अधिक नहीं है?

A: यथार्थवादी लक्ष्यों (ऐतिहासिक डेटा) के साथ शुरू करें, फिर परिपक्व होने पर कड़ा करें।

• "अवलोकन: लॉग, मैट्रिक्स, निशान"
• "वितरित निशान"
• "ऑडिट और अपरिवर्तनीय लॉग"
• "वेबहुक डिलीवरी गारंटी"
• "ट्रांजिट/एट रेस्ट एन्क्रिप्शन" में
• "डेटा ओरिजिन (वंश)"