अपटाइम रिपोर्ट और एसएलए लेखा परीक्षा

1) हमें औपचारिक अपटाइम रिपोर्टिंग प्रक्रिया की आवश्यकता क्यों है

ग्राहक विश्वास और अनुबंध पारदर्शिता - एक एकल माप तकनीक, दोहराने योग्य गणना।

एसएलओ और त्रुटि बजट प्रबंधन - रिलीज और घटनाओं के साथ उपलब्धता के तथ्य को जोड़ ना।

सही एसएलए ऋण उद्देश्य सूत्र, पूर्वानुमानित भुगतान/ऑफसेट हैं।

कानूनी स्थिरता - साक्ष्य आधार, स्वतंत्र ऑडिट, कानूनी पकड़।

2) शर्तें और सीमाएँ

एसएलआई उपलब्धता - प्रति अवधि में सफल सत्यापन/लेनदेन का प्रतिशत।

एसएलओ - आंतरिक लक्ष्य (जैसे। 99. 28 दिनों में 95%)।

एसएलए - बाहरी प्रतिबद्धता (जैसे) 99. 9 %/महीने + सेवा ऋण)।

मापन विंडो - पंचांग माह (एसएलए) तथा रोलिंग विंडो (एसएलओ)।

स्कोप - कौन से घटक गणना (किनारे, एपीआई, भुगतान) में शामिल हैं और जो (व्यवस्थापक पोर्टल, गैर-प्रोड) नहीं हैं।

💡 नियम: SLA ≤ SLO और क्लाइंट-सत्यापित SLIs पर आधारित है।

3) सत्य के स्रोत (और कब प्रभारी हैं)

1. सिंथेटिक्स (ब्लैकबॉक्स/हेडलेस) "उपयोगकर्ता-आंख पहुंच" के लिए प्राथमिक एसएलआई है।

2. लॉग/मैट्रिक्स - विफलता के पैमाने और प्रकृति की पुष्टि करते हैं।

3. व्यावसायिक कार्यक्रम "लेनदेन सफलता" हैं (उदाहरण के लिए, भुगतान अधिकृत)

4. स्थिति पृष्ठ - सार्वजनिक संचार तथ्यों नंबर 1-3 के खिलाफ जाँच की जाती है।

विसंगतियों के मामले में: क्षेत्रों से सही कोरम के साथ सिंथेटिक्स को प्राथमिकता दी जाती है।

4) उपलब्धता गणना पद्धति

4. 1 मूल सूत्र


Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 बहु-क्षेत्रीय कोरम

एक घटना की गिनती की जाती है यदि ≥N स्वतंत्र क्षेत्र/एएसएन एक साथ विफलता दर्ज करते हैं।

अनुशंसित: N = 3 का 2 (EU/NA/APAC)।

4. 3 एसएलआई प्रकार

HTTP SLI: код 2xx/3xx, विलंबता ≤ T।

DNS/TLS SLI: NXDOMAIN/SERVFAIL/समाप्ति।

SLI व्यवसाय: सफल लेनदेन/सभी प्रयास (ग्राहक विफलताओं को छोड़ कर)।

4. 4 अपवाद (प्रलेखित)

अनुसूचित रखरखाव विंडो अग्रिम N घंटे में घोषित और मनाया।

SLA (उदाहरण के लिए, IX आपदा प्रदाता) से बल का उपयोग - केवल अगर सबूत और सार्वजनिक नोटिस है।

क्लाइंट त्रुटियां/प्रतिबंध (कोटा से अधिक, 4xx)।

5) विंडो रखरखाव नीति

अनुबंध में समय स्लॉट सहमत हुए (उदा। सन 02: 00-04: 00 UTC + 0)।

'रखरखाव = अलर्ट/पैनल में सही' मार्कर - SLI से बहिष्करण।

अधिसूचना सीमा: कम से कम 5 कार्य दिवस (या अनुबंध में)।

विंडो से बाहर - एसएलए प्रभाव पर विचार किया जाता है।

6) किनारे के मामले और गोल नियम

ब्राउनआउट (आंशिक गिरावट): विफलताओं के प्रतिशत (भारित डाउनटाइम) की गिनती करें, न कि "0/1"।

फड़फड़ाना: खाते की न्यूनतम इकाई - नमूना अंतराल (उदाहरण के लिए, 30-60 सेकंड) + हिस्टेरिसिस (के लिए: 2-5 मिनट)।

घड़ी बहाव: UTC और ISO-8601 में हर समय; एनटीपी तुल्यकालन।

7) PromQL के उदाहरण (सिंथेटिक्स → uptime)

HTTP स्कैन सफलता:

promql probe_success{job="blackbox-http"} == 1

p95 विलंबता:

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

SLA अपटाइम प्रति माह (सेकंड):

promql sum_over_time((probe_success==1)[30d]) / (30246060)

विफलताओं का कोरम (3 मिनट का क्षेत्र):

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) SQL के उदाहरण (रिपोर्ट एकत्रीकरण)

मासिक अपटाइम और डाउनटाइम:

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

स्थिति पृष्ठ सुलह (घटनाएँ):

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) मासिक रिपोर्ट टेम्पलेट (ग्राहक के अनुकूल)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) एसएलए क्रेडिट: गणना और आवेदन

क्रेडिट की तालिका: उदाहरण के लिए, 99। 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10%, आदि।

ट्रू-अप: क्रेडिट अगले खाते में क्रेडिट नोट के रूप में लागू होता है।

स्वचालन: "यदि 'मापा _ उपलब्धता

क्लाइंट के लिए शोकेस: पोर्टल कार्ड "एसएलए क्रेडिट बैलेंस।"

11) ऑडिट, साक्ष्य और कानूनी पकड़

ऑडिट ट्रेल: कौन/क्या/जब गणना की जाती है, कार्यप्रणाली का संस्करण, चेकसम।

कच्चा डेटा अपरिवर्तनीय है (केवल एपेंड-केवल); समायोजन - अलग रिकॉर्ड द्वारा।

कानूनी पकड़: डेटा रेंज (नमूने, लॉग, घटना कार्ड, अलर्ट) को फ्रीज करना।

प्रतिकृति अभिलेखागार - WORM/S3 ऑब्जेक्ट लॉक।

12) सार्वजनिक स्थिति पृष्ठ के साथ सुलह

एक स्थिति पृष्ठ पर एक घटना में एक समयरेखा और घटक होना चाहिए।

समय/पैमाने का बेमेल - विसंगति-रिकॉर्ड द्वारा बनाया गया है और आरसीए द्वारा पोस्ट किया गया है।

रिपोर्ट के सारांश में सुलह नोट्स अनुभाग शामिल है।

13) घटनाएं और रिपोर्टिंग

प्रत्येक डाउनटाइम विंडो एक INC कार्ड (ID, SEV, मालिक, RCA, CAPA) से मेल खाती है।

रिपोर्ट में: INC से लिंक, लघु मूल कारण, CAPA स्थिति।

के लिए: पोस्टमोर विषय - बंद होने से 48 घंटे।

14) डेटा गुणवत्ता नियंत्रण

नमूनों की स्वच्छता: > एजेंटों के सफल स्क्रैप का 99%, अंतराल की अनुपस्थिति> 5 मिनट।

एंटी-शोर: कोरम + मल्टी-विंडो, डेब्यू।

ट्रेस/लॉग सैंपलिंग रिकॉर्ड और प्रलेखित है।

विधि परीक्षण: गणना की इकाई परीक्षण, ऐतिहासिक डेटा के आधार पर सुनहरी फाइलें।

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

निगलने के लिए TLS/mTLS, पैकेट हस्ताक्षर (HMAC)।

लॉग/रिपोर्ट में पीआईआई संस्करण; SLA रिपोर्ट को व्यक्तिगत डेटा का खुलासा नहीं करना चाहि

रिपोर्ट पर RBAC/ABAC; पहुंच निशान ऑडिट लॉग पर लिखे जाते हैं।

16) डैशबोर्ड और एसएलओ विजेट (क्या दिखाना है)

माह/तिमाही के लिए सेवा द्वारा समग्र उपलब्धता।

गंभीरता और पहचान चैनल के साथ डाउनटाइम विंडो।

त्रुटि बजट बर्न (तेज/धीमी) और रुझान।

गणना के ओवरले - एनोटेशन जारी करता है।

एसएलए क्रेडिट पूर्वानुमान - वर्तमान प्रवृत्ति पर।

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

1. मॉडल और डेटा (2 सप्ताह): SLI/SLO/SLA को ठीक करें, कोरम सिंथेटिक्स शामिल करें, DWH में "कच्चे माल" एकत्र करें।

2. गणना और रिपोर्ट (2-3 सप्ताह): सूत्र, SQL/PromQL, YAML/PDF टेम्पलेट, ग्राहक पोर्टल, ऑटो-क्रेडिट।

3. लेखा परीक्षा और स्वचालन (3-4 सप्ताह): कानूनी पकड़, स्थिति पृष्ठ के साथ सुलह, वेबहुक पर हस्ताक्षर, विवाद नियम।

18) गुणवत्ता चेकलिस्ट की रिपोर्ट क

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

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

सिंथेटिक्स मुख्य स्रोत क्यों है?

यह उपयोगकर्ता पथ के सबसे करीब है और इसमें एक परिधि (DNS/CDN/WAF) शामिल है। मेट्रिक्स/लॉग - कारण स्पष्ट करें।

आंशिक गिरावट की गणना कैसे करें?

भारित डाउनटाइम: विफलताओं का अनुपात × खिड़की की अवधि, न कि "सभी या कुछ भी नहीं।"

क्या मुझे "कच्चे" चेक स्टोर करने की आवश्यकता है?

हाँ मैंने किया। किसी विवाद में लेखापरीक्षा और पुनर्गणना के लिए आवश्यक है।

परिणाम

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