अवसंरचना केपीआई और अपटाइम

आपको इसकी आवश्यकता क्यों है?

बुनियादी ढांचा केपीआई स्थिरता के बारे में "भावनाओं" को औसत दर्जे के लक्ष्यों में बदल देता है, जोखिम का प्रबंधन करता है और काम का ध्यान केंद्रित करता है। सही मैट्रिक्स तकनीकी एसएलआई को व्यावसायिक परिणामों (रूपांतरण, टाइम-टू-वॉलेट, एलटीवी) से जोड़ ता है और आपको नवाचार बनाम विश्वसनीयता के विकास, भार और साझा की योजना बनाने की अनुमति देता है।

बुनियादी अवधारणाएँ: SLI, SLO, SLA और त्रुटि बजट

SLI (सेवा स्तर संकेतक) - मापा गुणवत्ता संकेतक: सफल अनुरोधों का अनुपात, p95 विलंबता, प्रति अंतराल अपटाइम।

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

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

त्रुटि बजट = '1 − SLO'। यह प्रति माप विंडो अधिकतम स्वीकार्य विफलता दर है। जोखिम भरे रिलीज और प्रयोगों के बारे में निर्णय लेने के लिए उपयोग किया जा

• उपलब्धता एसएलओ 99। 30 दिनों में 95% - त्रुटि बजट 0। 05% ≈ 21. एक कैलेंडर महीने में "विफलता" के 6 मिनट।

चार सोने के संकेत और अतिरिक्त

1. लेटेंसी (p50/p90/p95/p99, पूंछ औसत से अधिक महत्वपूर्ण है)।

2. त्रुटियाँ (5xx/timeout/business त्रुटियाँ)।

3. ट्रैफिक/थ्रूपुट (आरपीएस/क्यूपीएस, एमबीपी)।

4. संतृप्ति (सीपीयू/रैम/आईओ/एफडी/कनेक्शन/जीसी/कोटा)।

अतिरिक्त: ठंडी शुरुआत, कतारें/बैकलॉग, तैनात समय, एसएलओ अनुपालन।

विभिन्न प्रकार की सेवाओं के लिए SLI मॉडल

HTTP/API

उपलब्धता: '(सफल 2xx/3xx − तार्किक त्रुटियां )/( सभी निवेदन)'

विलंबता: सफल प्रश्नों के लिए 'p95'; गर्म मार्गों पर लक्ष्य।

गुणवत्ता: 'दर्शक/स्कोप' सही (authZ त्रुटियों के बिना) के साथ अनुरोधों का अनुपात।

कतार/अतुल्यकालिक

संदेश प्रक्रमण समय: p95 अंत से अंत ≤ N सेकंड

बैकलॉग: मध्य <X, पूंछ p99 <Y.

वितरण त्रुटि: ≤ Z पीपीएम।

डीबी/कैश

ऑपरेशन विलंबता: p95 गेट/पुट/कमिट।

संतृप्ति: कनेक्शन पूल उपयोग, कैश हिट-अनुपात।

त्रुटियां: टाइमआउट, गतिरोध, निष्कासन तूफान।

सीडीएन/स्थिर

हिट अनुपात: लक्ष्य स्तर ≥; गिरावट - मूल पर विकास लोड करें।

POP उपलब्धता: Anycast, विफलताओं की भरपाई पड़ोसियों द्वारा की जाती है।

भुगतान (व्यापार SLI)

टाइम-टू-वॉलेट पी 95, डिपॉजिट/आउटपुट सफलता%, पीएसपी विफलता दर।

उपलब्धता और समय की गणना

सेवा उपलब्धता = 'सफल अनुरोध/सभी अनुरोध' (अधिमानतः 'अपटाइम मिनट' नहीं)।

बुनियादी ढांचे के नोड्स के लिए एक विकल्प 'ग्रीन टाइम/विंडो टाइम' है।

कैलेंडर विंडो: 28-31 दिन, स्लाइडिंग विंडो: पिछले 30/90 दिन।

काम के घंटे/महत्वपूर्ण खिड़कियां: बैकऑफ़िस के लिए शेड्यूल के अनुसार अपटाइम माना जा सकता है (उदाहरण के लिए, 08: 00-22: 00 स्थानीय समय)।

• 'उपलब्धता (ए) ≈ एवी (बी) × एवी (सी) × एवी (ए' बी, सी) '- सीमाओं पर एसएलओ बिछाना महत्वपूर्ण है।

उदाहरण SLO किट (नमूना)

गेटवे एपीआई: ≥ 99 उपलब्ध है। 95 %/30d; p95 विलंबता ≤ 120 एमएस; त्रुटि ≤ 0। 2%.
चेकआउट/भुगतान: जमा सफलता ≥ 98। 5 %/30d; टाइम-टू-वॉलेट p95 ≤ 90 с; PSP-timeouts ≤ 0। 3%.

डेटाबेस: p95 पढ़ें ≤ 10 एमएस; p95 लिखें ≤ 25ms; प्रतिकृति अंतराल p95 ≤ 150 мс।

कैश: हिट अनुपात ≥ 85%; निष्कासन तूफान = 0/30д।

भुगतान: p95 प्रसंस्करण ≤ 5 मिनट; धोखाधड़ी-फॉल-पॉजिटिव ≤ 0। 3%.

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

यदि विंडो के मध्य से पहले त्रुटि बजट 50% + समाप्त हो जाता है, तो सुविधाओं/रिलीज़का "फ्रीज" पेश किया जाता है, फोकस स्थिरीकरण पर है।

यदि बजट धीरे-धीरे खर्च किया जाता है, तो आप प्रयोगों/कैनरी को गति दे सकते हैं।

बजट की खपत को 'release _ id' के माध्यम से विशिष्ट रिलीज/घटनाओं से जोड़ें।

चेतावनी: व्यर्थ में "रात में कॉल" कैसे न करें

केवल एसएलओ गिरावट और महत्वपूर्ण लक्षणों के लिए अलर्ट, प्रत्येक मीट्रिक के लिए नहीं।

मल्टी-विंडो, मल्टी-बर्न रेट: शॉर्ट विंडो (5-15 मिनट) + लॉन्ग विंडो (1-6 एच)।

उदाहरण: "बर्न रेट 14 × 5 मिनट में और 6 × 1 घंटे में" - ऑन-कॉल पेज।

non-P1 संकेतों के लिए शांत घंटे; स्वामित्व मार्ग।

डैशबोर्ड और विज़ुअलाइज़ेशन प्रथाएँ

एसएलओ पैनल: सेवा अनुपालन, शेष बजट, निर्भरता मानचित्र।

लेटेंसी पैनल: p50/p90/p95/p99, मार्गों/किरायेदारों/देशों/एएसएन द्वारा अपघटन।

त्रुटि पैनल: कोड/कारण, रिलीज/फीचर फ्लैग के साथ सहसंबंध।

क्षमता-पैनल: सीपीयू/रैम/आईओ/नेटवर्क/एफडी/कनेक्शन, रुझान और पूर्वानुमान।

व्यापार पैनल: रूपांतरण, समय-से-बटुआ, जमा/निकासी, सुरक्षा का प्रभाव (WAF/एंटी-बॉट्स)।

घटनाएं, एमटीटीआर और पोस्टमार्टम

• MTTD (पहचान), MTTA (स्वीकार), MTTR/MTTC (वसूली/रोकथाम), समय पर RCA के बिना% घटनाएं।
• प्लेबुक: कौन आगे बढ़ ता है, कैसे फ़ीचर फ्लैग/ब्लॉक चालू करें, कैसे रिलीज़ को वापस रोल करें, व्यवसाय के साथ संचार करें।
• पोस्टमॉर्टम (दोषरहित): तथ्य, समय रेखा, मूल कारण (उन/प्रक्रियाओं), क्रियाएं: तत्काल/दीर्घकालिक, प्रतिगमन परीक्षण, एसएलओ पर प्रभाव।

प्रदर्शन, संतृप्ति और गिरावट

हेडरूम: लक्ष्य संसाधन हेडरूम (जैसे। CPU <70% p95, RAM <75% p95)।

गर्म रास्ते: महत्वपूर्ण मार्गों की रूपरेखा; 'p99' औसत से अधिक महत्वपूर्ण है।

गिरावट मोड: कैश-ओनली, रीड-ओनली, महत्वहीन अनुरोधों की ड्रॉप-ग्राइंडिंग, "रेट लिमिट "/कोटा।

सूत्र और गणना के उदाहरण

1) ऑन-डिमांड उपलब्धता

availability = (total_requests - error_requests) / total_requests

जहां 'error _ requests' = 5xx + टाइमआउट + बिजनेस एरर्स (configurable)।

2) त्रुटि बजट (मिनट)

error_budget_minutes = window_minutes (1 - SLO)

उदाहरण: 30 दिन (43,200 मिनट), एसएलओ 99। 95% → 21. 6 मिनट।

3) बर्न रेट

burn_rate = observed_error_ratio / (1 - SLO)

यदि SLO 99। 9% (बजट 0। 1%) और त्रुटि 1% = 10 ×।

4) यौगिक उपलब्धता

A_total ≈ A_gw × A_auth × A_db × A_psp

छोटे फॉल्स ने समग्र ए को हिट किया।

मापन और अपवाद नीतियाँ

अनिर्धारित विंडो (घटनाओं) - को ध्यान में रखा गया।

नियोजित रखरखाव खिड़कियां - केवल तभी ध्यान में रखा जाता है जब एसएलए इतना निर्धारित है; एसएलओ के लिए अक्सर घटाया नहीं जाता है (या अलग से 'नियोजित _ डाउनटाइम' के रूप में चिह्नित किया जाता है)।

सिंथेटिक्स बनाम वास्तविक उपयोगकर्ता: दोनों चैनलों (RUM + सिंथेटिक चेक) के लिए उपयोगी है।

कलाकृतियों के उदाहरण

KQL/PromQL (विचार)

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

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

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (भुगतान व्यवसाय SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

निर्भरता और कैस्केड प्रबंधित करें

टीमों के बीच एसएलओ अनुबंध: gateway↔auth↔wallet↔PSP।

गिरावट की नीतियां: जब निर्भरता गिरती है, तो सेवा "सरलीकृत मोड" में जाती है।

सुविधा झंडे: गैर-महत्वपूर्ण कार्यों को अक्षम करना, विलंबता पूंछ को कम करने के लिए "ग्रे रिलीज़"।

क्षमता योजना और पूर्वानुमान

Schomes। RPS/MBps रुझानों और घटनाओं (टूर्नामेंट, मैच, प्रचार) द्वारा पूर्वानुमान।

"गोल्डन पथ" द्वारा लोड परीक्षण, पीएसपी/भुगतान के लिए अलग परीक्षण।

शिखर पर स्टॉक: लक्ष्य कारक 1। 3 × -2। अपेक्षित भार का 0 ×।

SLO/KPI कार्यान्वयन जांच सूची

1. महत्वपूर्ण उपयोगकर्ता पथ की पहचान करें और एसएलआई को "ग्राहक के दृष्टिकोण से" पर बातचीत करें।

2. एसएलओ लक्ष्य और विंडो चुनें (30/90 दिन); त्रुटि बजट की गणना करें।

3. प्रवेश द्वार/सेवाओं में मीट्रिक संग्रह का निर्माण करें, कोड/कारणों को सामान्य

4. बर्न-रेट अलर्ट (शॉर्ट + लॉन्ग विंडो), रूटिंग और ऑन-कॉल कॉन्फ़िगर करें।

5. एसएलओ अनुपालन की कल्पना करें, रिलीज/फीचर फ्लैग के साथ सहयोगी।

6. परिवर्तन नीति और फ्रीज प्रक्रिया के खिलाफ एक बजट बनाएँ।

7. प्रत्येक अतिरिक्त, प्रतिगमन परीक्षण पर पूर्वव्यापी और आरसीए।

8. वास्तविक बजट उपयोग और व्यावसायिक उद्देश्यों के लिए त्रैमासिक एसएलओ की समीक्षा करें।

सामान्य गलतियाँ

एप्लिकेशन त्रुटियों की अनदेखी करते हुए "पिंग द्वारा अपटाइम" मापते हैं।

एसएलओ "रिजर्व में" सेट किए गए हैं (99। 999%), लेकिन अप्राप्य और कुछ भी हल नहीं।

उपयोगकर्ता लक्षणों के बजाय निम्न-स्तरीय मैट्रिक्स पर अलर्ट।

कोई निर्भरता मानचित्र नहीं है - यह स्पष्ट नहीं है कि यह कहां जल रहा है।

एसएलओ और रिलीज़ के बीच कोई संबंध नहीं है - यह स्पष्ट नहीं है कि बजट किसने "खाया"।

p99 पूंछ को अनदेखा करें - अच्छा औसत लेकिन खराब UX VIP उपयोगकर्ता।

iGaming/fintech विशिष्ट

अनुसूचित चोटियों: मैच/इवेंट/प्रमोशन - अग्रिम में क्षमता में वृद्धि, वार्म अप कैश/सीडीएन, विशेष सीमा प्रोफाइल शामिल हैं।

व्यापार SLI: समय-से-बटुआ, जमा/निकासी सफलता, "भुगतान गति" p95; डैशबोर्ड की जड़ में।

PSP/partners: प्रदाता द्वारा व्यक्तिगत SLO/डैशबोर्ड, स्वचालित मार्ग स्विचिंग।

एंटीबॉट/एंटी-फ्रॉड: त्रुटियों के लिए कोई बजट नहीं होना चाहिए - "तकनीकी त्रुटियों" से अलग "वैध ब्लॉक"।

नियामक: लॉग भंडारण, एसएलओ/एसएलए गणना की प्रजनन क्षमता, घटना रिपोर्ट।

FAQ

क्या मुझे एसएलओ से नियोजित कार्य को घटाने की आवश्यकता है?
आमतौर पर नहीं: SLO उपयोगकर्ता द्वारा अनुभव किए गए अनुभव को दर्शाता है। आप SLAs के लिए अपवाद निर्दिष्ट कर सकते हैं.

p95 क्यों, औसत नहीं?

मध्य एक पूंछ का मुखौटा; UX पूंछ परिभाषित करें (p95/p99)।

क्या मेरे पास पूरे उत्पाद के लिए एक एसएलओ हो सकता है?

आपको एक एसएलओ पेड़ की आवश्यकता है: महत्वपूर्ण रास्तों/घटकों द्वारा उत्पाद और बच्चों द्वारा कुल।

कुल

एक मजबूत बुनियादी ढांचा केपीआई प्रणाली कस्टम एसएलआई, यथार्थवादी एसएलओ, एक परिवर्तन नियंत्रण लीवर, स्मार्ट अलर्ट और घटना अनुशासन और आरसीए के रूप में त्रुटि बजट है। तकनीकी संकेतकों को व्यवसाय मैट्रिक्स, स्वचालित संग्रह और दृश्य के साथ जोड़ें - और बुनियादी ढांचा अनुमानित हो जाएगा, और शिखर परिदृश्यों में भी अपटाइम को नियंत्रित किया जाएगा।