एसएलए, एसएलओ और विश्वसनीयता केपीआई

1) शर्तें और अंतर

SLI (सेवा स्तर संकेतक) - गुणवत्ता का एक औसत दर्जे का संकेतक (उदाहरण के लिए, सफल अनुरोधों का अनुपात, p95 विलंबता)।

एसएलओ (सेवा स्तर उद्देश्य) - प्रति समय विंडो पर एसएलआई मूल्य लक्षित करें (उदाहरण के लिए, "सफलता ≥ 99। 28 दिनों में 9%")।

त्रुटि बजट - अनुमत SLO विफलता दर '1 − SLO' है।

एसएलए (सेवा स्तर का समझौता) - जुर्माना/क्रेडिट (बाहरी) के साथ संविदात्मक दायित्व।

विश्वसनीयता केपीआई - परिचालन प्रक्रिया मैट्रिक्स (एमटीटीडी/एमटीटीआर/एमटीबीएफ,% स्वचालित शमन, चेतावनी कवरेज, आदि)।

💡 नियम: SLA ≤ SLO; बाहरी अनुबंध सेवा के आंतरिक उद्देश्य से सख्त नहीं होना चाहिए।

2) SLI कैसे चुनें (गोल्डन सिग्नल पर आधारित)

1. कुंजी समापन बिंदुओं के लिए लेटेंसी - p95/p99।

2. ट्रैफिक - आरपीएस/आरपीएम/संदेश प्रवाह।

3. त्रुटियां - 5xx/व्यापार त्रुटियों का हिस्सा (उदाहरण के लिए, भुगतान को बाहर करना "PSP गलती के कारण गिरावट)।

4. संतृप्ति - संसाधन संतृप्ति (सीपीयू/रैम/आईओ/लैग)।

अच्छा SLI मानदंड:

उपयोगकर्ता-कथित अनुभव के साथ सहसंबंध।
तकनीकी रूप से उपलब्ध और माप में स्थिर।
हम नियंत्रण करते हैं (सुधार के लिए कार्रवाई संभव है)।
कम संग्रह लागत।

3) सूत्र और उदाहरण

3. 1 उपलब्धता


Availability = Successful Requests/All Requests
Error Budget = 1 − SLO

उदाहरण: SLO 99। 30 दिनों में 9% - त्रुटि बजट = 0। 1%, जो अनुपलब्धता के 43 मिनट 12 सेकंड के बराबर है।

3. 2 विलंबता

विलंबता से एसएलओ को अनुरोधों के अनुपात के रूप में तैयार किया जाता है जो सीमा में फिट होते हैं:


Latency SLI = percentage of requests with duration ≤ T
SLO example: 99% requests ≤ 300ms (rolling 28d)

3. 3 भुगतान (व्यवसाय स्तर)


Payment Success SLI =/all attempts

💡 सेवा विफलताओं से "ग्राहक कार्ड द्वारा गिरावट" को बाहर करना; केवल मंच अपराध शामिल करें।

4) त्रुटिपूर्ण बजट और बर्न-रेट

बजट त्रुटि - नवाचार के लिए आपका "ईंधन टैंक" (रिलीज, प्रयोग)।

बर्न-रेट - बजट खपत की गति:

तेज चैनल (~ 1 h में पता लगाना),
धीमा चैनल (~ 6-12 एच/24 एच पर प्रवृत्ति)।

सीमा विचार:

यदि बर्न-रेट> 14. 4 में 1 घंटा - SEV-1 (हम ~ 100 मिनट में दैनिक बजट खाएंगे)।
यदि बर्न-रेट> 6 में 6 घंटे - SEV-2 (तेजी से गिरावट)।

5) एसएलओ (मल्टी-विंडो, मल्टी-बर्न) द्वारा सचेत करना

त्रुटि सूचक: 5xx या विलंबता उल्लंघन का अनुपात।

PromQL के उदाहरण (सामान्यीकृत):

promql
5 minute error rate sum (rate (http_requests_total{status=~"5"..}[5m]))
/
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

Slow burn (30m window)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

विलंबता से SLO के लिए, प्रतिशत हिस्टोग्राम का उपयोग करें:

promql p95 latency histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) डोमेन द्वारा SLI/SLO उदाहरण

6. 1 एपीआई गेटवे/एज

SLI-त्रुटि: 5xx प्रतिक्रिया दर <0। 1% (28 डी)।

SLI-Latency: p95 ≤ 250 ms (दिन)।

एसएलओ: उपलब्धता ≥ 99। 95% (तिमाही)।

6. 2 भुगतान

SLI-सक्सेस: सफल (ग्राहक विफलताओं को छोड़ कर) ≥ 99 के लिए भुगतान। 8% (28 डी)।

SLI-Latency: प्राधिकरण ≤ 99% (दिन) के लिए 2 सेकंड।

SLO: टाइम-टू-वॉलेट p95 ≤ 3 мин (24h)।

6. 3 डेटाबेस (PostgreSQL)

SLI-Lag: प्रतिकृति अंतराल p95 ≤ 1 सेकंड (दिन)।

SLI-त्रुटि: क्वेरी त्रुटि दर ≤ 0। 05% (28 डी)।

एसएलओ क्लस्टर उपलब्धता ≥ 99। 95%.

6. 4 कतारें/स्ट्रीमिंग (काफ्का)

SLI-Lag: उपभोक्ता अंतराल p95 ≤ N संदेश (घंटा)।

SLI-स्थायित्व - ≥ 99 प्रविष्टि की पुष्टि करें। 99% (28 डी)।

SLO: दलालों की उपलब्धता ≥ 99। 9%.

7) विश्वसनीयता प्रक्रिया केपीआई

MTTD (पता लगाने के लिए औसत समय)

MTTA (... स्वीकार करने के लिए)

MTTR (... बहाल करने के लिए)

एमटीबीएफ (...) विफलताओं के बीच)

स्वचालित शमन के साथ घटनाओं का%

एसएलओ/शीर्ष यातायात पथ का अलर्ट कवरेज (लक्ष्य ≥ 95%)

कैनरी चरण के साथ रिलीज का हिस्सा

टीमों/विशेषताओं द्वारा गलत बजट का उपभोग

8) एसएलओ यथार्थवादी कैसे रखें

1. वर्तमान आधारभूत विश्वसनीयता (3-4 सप्ताह) को मापते हैं।

2. "संवेदनशील" उपयोक्ता पथ परिभाषित करें (लॉगिन, जमा, खेल).

3. प्रत्येक विचलन (समय, धन, प्रतिष्ठा) की लागत पर विचार करें।

4. एक महत्वाकांक्षी लेकिन प्राप्त करने योग्य लक्ष्य (बेसलाइन पर 10-30% सुधार) चुनें।

5. तिमाही की समीक्षा करें।

एंटी-पैटर्न:

बिना औचित्य के तुरंत "पांच नाइन"।
उपयोगकर्ता को दिखाई नहीं देने वाले मैट्रिक्स द्वारा एसएलओ (उदाहरण के लिए, यूएक्स के साथ संचार के बिना सीपीयू)।
बहुत अधिक SLO → फोकस स्प्रे।

9) एसएलओ और बजट रिपोर्टिंग

मानक रिपोर्ट (साप्ताहिक/मासिक):

प्रति एसएलओ पूरा करना: वास्तविक बनाम लक्ष्य, रुझान, आत्मविश्वास।
त्रुटि खपत का सारांश: कितना बजट "जला" है जिसकी तुलना में (रिलीज/घटना)।
गिरावट के शीर्ष पांच कारण, CAPA योजना और कार्य की स्थिति।
व्यावसायिक प्रभाव: रूपांतरण, एनडी, प्रतिधारण, एलटीवी।

10) रिलीज नीति के साथ संचार

त्रुटि बजट <50% → मुफ्त रिलीज।

50-80% → "सतर्क मोड": केवल कम जोखिम/कैनरी गणना।

💡 80% → रिलीज फ्रीज, स्थिरीकरण और ऋण पर ध्यान केंद्रित करता है।

11) एसएलए (संविदात्मक) - आइटम टेम्पलेट

उपलब्धता दायित्व: उदाहरण के लिए, 99। 9 %/महीना।

फोर्स मेजर: डीडीओएस उचित नियंत्रण से परे, तीसरे पक्ष के प्रदाता।

मापन खिड़की और जिम्मेदारी का क्षेत्र: मैट्रिक्स के स्रोत, गणना विधि।

क्रेडिट/दंड: स्तरों की एक तालिका (उदाहरण के लिए, 60-120 मिनट की अनुपलब्धता एक्स%)।

वृद्धि और अधिसूचना प्रक्रियाएं: समय सीमा, चैनल।

डेटा और गोपनीयता: मास्किंग, भंडारण, कानूनी पकड़।

उल्लंघन के मामले में पुनरावृत्ति निवारण योजना (सीएपीए)।

💡 बाहरी एसएलए को विशिष्ट, सत्यापन योग्य एसएलआई और गणना पद्धति का उल्लेख करना चाहिए।

12) माप उपकरण

निष्क्रिय मैट्रिक्स: प्रोमेथियस/मिमिर/थानोस, निर्यातक।

लॉग: व्यावसायिक स्तर पर सफलताओं/त्रुटियों की गिनती के लिए लोकी/ईएलके।

सिंथेटिक्स: क्रोन द्वारा सक्रिय नमूने (लॉगिन/जमा/खेल)।

ट्रेसिंग: p99 बाधाओं के लिए टेम्पो/जैगर।

भुगतान/वित्त: भुगतान SLI के लिए जमीनी सत्य स्रोत।

13) क्वेरी उदाहरण (टेम्प्लेट्स)

सफल API निवेदन का प्रतिशत (क्लाइंट के रूप में 4xx को छोड़ कर):

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

एसएलओ कार्ड:

yaml slo:
name: "API Availability"
window: "28d"
target: 0. 999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14. 4}
slow_burn: {window: "6h", factor: 6}

भुगतान सफलता (लॉग/स्ट्रीम में व्यावसायिक घटनाओं के लिए):


success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

कुंजी> "ग्राहक द्वारा गिरावट" को बाहर करने के लिए फिल्टर रिफाइन करें।

14) फिनोप्स और विश्वसनीयता

प्रति 9 लागत: नौ जोड़ ने की लागत तेजी से बढ़ रही है।

लाभ वक्र: इष्टतम जहां राजस्व में वृद्धि/नुकसान में कमी - अतिरिक्त "9" की लागत।

एसएलओ पोर्टफोलियो: विभिन्न रास्तों के लिए विभिन्न स्तर (महत्वपूर्ण भुगतान "अधिक महंगे" हैं, रिपोर्टिंग "सस्ता" है)।

15) एसएलओ/अलर्ट क्वालिटी - चेकलिस्ट

SLI UX और व्यापार मेट्रिक्स के साथ सहसंबंध रखता है।
विंडो और एकत्रीकरण सुसंगत हैं (रोलिंग 28 डी/क्वार्टर)।
मल्टी-विंडो अलर्ट, कोई फड़फड़ाना, भूमिका-आधारित मार्ग।
प्रलेखन: मालिक, सूत्र, स्रोत, रनबुक।
गलत बजट और बर्न संकेतक के साथ SLO डेमो पैनल।
नियमित रूप से लक्ष्यों (त्रैमासिक) की समी
प्रमुख परिदृश्यों पर सिंथेटिक्स परीक्षण।

16) कार्यान्वयन योजना (4 पुनरावृत्ति)

1. सप्ताह 1: उपयोगकर्ता पथ, एसएलआई ड्राफ्ट, बुनियादी डैशबोर्ड की सूची।

2. सप्ताह 2: एसएलओ औपचारिकता, बजट, अलर्ट (तेज/धीमी गति से जलन)।

3. सप्ताह 3: घटना/रिलीज प्रक्रिया के साथ एकीकरण, फ्रीज नियम।

4. सप्ताह 4 +: संविदात्मक एसएलए, त्रैमासिक समीक्षा, "लागत प्रति 9" फिनॉप्स मॉडल

17) मिनी-एफएक्यू

क्या मुझे प्रति सेवा एक एसएलओ की आवश्यकता है?

दर्जनों माध्यमिक के बजाय बेहतर 2-3 कुंजी (सफलता + विलंबता)।

अगर बजट समाप्त हो जाए तो क्या होगा?

ठंड रिलीज, स्थिरीकरण और CAPA पर ध्यान केंद्रित करते हुए, प्रायोगिक सुविधाओं को हटाते हुए।

रिलीज की गति और विश्वसनीयता के बीच संघर्ष से कैसे बचें?

योजना "बजट पर" जारी करती है, कैनरी गणना और सुविधा-झंडे को लागू करती है।

कुल

विश्वसनीयता को असमान मैट्रिक्स के एक सेट द्वारा नियंत्रित नहीं किया जाता है, लेकिन सिस्टम द्वारा: SLI → SLO → बजट त्रुटि → अलर्ट → घटना प्रक्रिया → CAPA → SLA को जलाएं। परिभाषाओं, डेटा स्रोतों और रिपोर्टिंग, उपयोगकर्ता अनुभव और अर्थशास्त्र के लिंक लक्ष्यों को मानकीकृत करें, और वास्तविक दुनिया ROI के आधार पर नियमित रूप से नाइन की समीक्षा करें।

एसएलए, एसएलओ और विश्वसनीयता केपीआई

कुल

हमसे संपर्क करें

त्वरित संपर्क

वीडियो जल्द ही अपडेट किया जाएगा

हम इस समय परियोजनाओं में बहुत व्यस्त हैं