GH GambleHub

हादसा मैट्रिक्स

1) घटनाओं को क्यों मापते हैं

हादसा मैट्रिक्स अराजक घटनाओं को एक प्रबंधनीय प्रक्रिया में बदल देता है: प्रतिक्रिया और वसूली के समय को कम करने में मदद करता है, कारण पुनरावृत्ति को कम करता है, एसएलओ/अनुबंध पूर्ति साबित करता है, और स्वचालन बिंदु खोजता है। मेट्रिक्स का एक अच्छा सेट पूरे चक्र को कवर करता है: पता लगाना → वर्गीकरण → वृद्धि → क्रियाओं को कम करना → रिकवरी → CAPA →।


2) बुनियादी परिभाषाएं और सूत्र

घटना अंतराल

MTTD (माध्य समय का पता लगाने के लिए) = पहले सिग्नल/पता लगाने के लिए T0 (प्रभाव की वास्तविक शुरुआत) से मतलब समय।

MTTA (माध्य समय स्वीकार करने के लिए) = पहले सिग्नल से ack-call तक औसत समय।

MTTM (मीन टाइम टू मिटिगेट) = एसएलओ थ्रेशोल्ड (अक्सर यूएक्स वर्कअराउंड/क्षरण का समय) के नीचे कमी को प्रभावित करने का समय है।

MTTR (ठीक होने का औसत समय) = लक्ष्य SLIs की वसूली पूरी करने के लिए औसत समय।

MTBF (असफलताओं के बीच औसत समय) = प्रासंगिक घटनाओं के बीच औसत अंतराल।

ऑपरेटिंग समय

घोषणा करने का समय - टी 0 से एसईवी/घटना स्तर की आधिकारिक घोषणा तक।

Comms का समय - घोषणा से लेकर पहले सार्वजनिक/आंतरिक SLA अद्यतन तक।

प्रत्येक चरण में राज्य - अवधि में समय (ट्राइएज/डायग/फिक्स/सत्यापन)।

आवृत्ति और भिन्नात्मक

हादसा गणना - प्रति अवधि घटनाओं की संख्या।

हादसा दर - 1k/10k/100k सफल लेनदेन या अनुरोध (सामान्यीकरण) पर।

एसईवी मिक्स - गंभीरता से वितरण (SEV-0..। SEV-3)।

एसएलए ब्रीच काउंट/रेट - बाहरी एसएलए के उल्लंघन की संख्या/शेयर।

परिवर्तन की विफलता दर - परिवर्तन के कारण होने वाली घटनाओं का% (रिलीज/कॉन्फ़िग/माइग्रेशन)।

संकेतों और प्रक्रियाओं की गुणवत्ता

% एक्शन करने योग्य पृष्ठ - पृष्ठों का अनुपात जिसके कारण सार्थक प्लेबुक क्रिया हुई।

झूठी सकारात्मक दर (पृष्ठ) - झूठी सकारात्मकता का अनुपात।

पता लगाना कवरेज - स्वचालन द्वारा पाई गई घटनाओं का अनुपात (ग्राहक/समर्थन नहीं)।

फिर से खोलना दर - एक ही मूल कारण के साथ बार-बार होने वाली घटनाओं का अनुपात ≤90 दिनों।

CAPA पूर्णता - सुधारात्मक/निवारक क्रियाओं का% समय पर बंद।

Coms SLA पालन - आवश्यक आवृत्ति द्वारा प्रकाशित अद्यतन का अनुपात।


3) हादसा चरण द्वारा मेट्रिक्स मैप

स्टेजकुंजी मेट्रिक्सप्रश्न
पता लगानाएमटीटीडी, डिटेक्शन कवरेज, स्रोत मिक्स (निगरानी बनाम उपयोगकर्ता)कितनी जल्दी और कौन समस्या की पहचान करता है?
प्रतिक्रियाMTTA, डिक्लेयर करने का समय, पेज-टू-एक%, एस्केलेशन लेटेंसीटीम कितनी जल्दी जुटाती है और एसईवी असाइन करती है?
शमनएमटीटीएम, वर्कअराउंड सक्सेस%, चेंज फ्रीज लेटेंसीकितनी जल्दी प्रभाव सुरक्षित स्तर तक कम हो जाता है?
बहालीएमटीटीआर, एसएलओ बर्न स्टॉप टाइम, अवशिष्ट जोखिम विंडोसेवा पूरी तरह से कब सामान्य हो गई?
Commsकम्स का समय, SLA पालन, भावना/शिकायतेंहम कितनी अच्छी तरह और समय पर संवाद कर रहे हैं?
प्रशिक्षणपोस्टमॉर्टम लीड टाइम, CAPA पूरा/ओवरड्यू, रीओपेन रेटक्या हम सुधारों के पाश को सीख रहे हैं और बंद कर रहे हैं?

4) सामान्यीकरण और विभाजन

वॉल्यूम (यातायात, सफलता, सक्रिय उपयोगकर्ता) के लिए काउंटरों को सामान्य करें।

खंड द्वारा: क्षेत्र/किरायेदार, प्रदाता (पीएसपी/केवाईसी/सीडीएन), परिवर्तन का प्रकार (कोड/कॉन्फिग/इंफ्रा), दिन का समय (दिन/रात), पहचान स्रोत (सिंथेटिक/आरयूएम/इन्फ्रा/सपोर)।

व्यापार एसएलआई (भुगतान की सफलता, पंजीकरण, पुनः पूर्ति) व्यवसाय के लिए महत्वपूर्ण हैं - उनके क्षरण के लिए लिंक घटना मैट्रिक्स।


5) थ्रेशोल्ड लक्ष्य (स्थल, डोमेन के अनुकूल)

MTTD: ≤ के लिए Tier-0 5 मिनट, Tier-1 के लिए ≤ 10-15 मिनट।

MTTA: ≤ 5 मिनट (24/7), ≤ 10 मिनट (फॉलो-द-सन)।

MTTM: ≤ 15 मिनट (टियर -0), ≤ 30-60 मिनट (टियर -1)।

MTTR: ≤ 60 मिनट (टियर -0), ≤ 4 एच (टियर -1)।

पहचान कवरेज: ≥ 85% स्वचालन।

% क्रियाशील पृष्ठ: ≥ 80-90%; FP पृष्ठ: ≤ 5%।

रीपेन रेट (90д): ≤ 5-10%।

CAPA पूर्णता (समय पर): ≥ 85%।


6) कारणों और परिवर्तनों के प्रभाव का कारण

प्रत्येक घटना के लिए एक प्राथमिक कारण (कोड/कॉन्फिग/इन्फ्रा/प्रदाता/सुरक्षा/डेटा/क्षमता) और ट्रिगर (रिलीज आईडी, कॉन्फिग परिवर्तन, माइग्रेशन, बाहरी कारक) आबंटित करें।

परिवर्तन से जुड़े MTTR/गणना रखें - कितना रिलीज और कॉन्फ़िग योगदान करते हैं (गेट/कैनरी नीतियों के लिए आधार)।

मार्गों और अनुबंधों को प्रबंधित करने के लिए प्रदाता-कारण की घटनाओं (पीएसपी/केवाईसी/सीडीएन/क्लाउड) पर अलग से विचार करें।


7) संचार और ग्राहक प्रभाव

प्रथम सार्वजनिक अद्यतन और अद्यतन ताल का समय (उदाहरण के लिए, हर 15/30 मिनट में)।

शिकायत दर - टिकट/शिकायतें 1 घटना, प्रवृत्ति के बारे में।

स्थिति सटीकता - बिना पीछे हटने के सार्वजनिक अपडेट का हिस्सा।

पोस्ट-इंसीडेंट एनपीएस (प्रमुख ग्राहक द्वारा) - SEV-1/0 के बाद एक संक्षिप्त बढ़ावा।


8) घटनाओं के आसपास गुणवत्ता मैट्रिक्स को सचेत करना

पेज स्टॉर्म इंडेक्स - एक घटना के दौरान पृष्ठों/घंटे प्रति कॉल की संख्या (मध्य/p95)।

Dedup दक्षता - दबाए गए डुप्लिकेट का अनुपात।

कोरम पुष्टिकरण दर - उन घटनाओं का अनुपात जहां जांच का कोरम (≥2 स्वतंत्र स्रोत) ट्रिगर किया गया था।

Shadow→Canary→Prod नए नियमों का रूपांतरण (अलर्ट-ए-कोड)।


9) डैशबोर्ड (न्यूनतम सेट)

1. कार्यकारी (28 दिन): घटनाओं की संख्या, एसईवी वितरण, एमटीटीआर/एमटीटीएम, एसएलए ब्रेक, रीओपेन, सीएपीए।

2. SRE ऑपरेशन: MTTD/MTTA по часам/сменам, पेज स्टॉर्म, एक्शनेबल%, डिटेक्शन कवरेज, डिक्लेयर/कॉम्स का समय।

3. परिवर्तन प्रभाव: रिलीज/कॉन्फिग घटनाओं का हिस्सा, परिवर्तन की घटनाओं के लिए एमटीटीआर, रखरखाव खिड़कियां बनाम घटनाएं।

4. प्रदाता: प्रदाता द्वारा घटनाएं, गिरावट का समय, मार्ग स्विच, संविदात्मक एसएलए।

5. सेवा/क्षेत्र द्वारा हीटमैप: घटनाएं और एमटीटीआर प्रति 1k लेनदेन।

एसएलआई/एसएलओ ग्राफिक्स को रिलीज एनोटेशन और एसईवी मार्क्स के साथ मिलाएं।


10) हादसा डेटा आरेख (अनुशंसित)

न्यूनतम कार्ड/तालिका क्षेत्र:

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11) गणना उदाहरण (SQL विचार)

समय के साथ MTTR (मंझला):
sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');
पहचान कवरेज:
sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';
असफलता दर बदलें (28 दिनों में):
sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12) एसएलओ और त्रुटि बजट के लिए लिंक

रिकॉर्ड एसएलओ प्रति घटना मिनट जलता है - यह घटना का मुख्य "वजन" है।

घटना की गिनती के बजाय कुल बर्न और एसईवी वजन द्वारा सीएपीए को प्राथमिकता दें।

वित्तीय प्रभाव के साथ एक साथ सिलाई (उदाहरण: $/मिनट डाउनटाइम या $/खोए हुए लेनदेन)।


13) कार्यक्रम-स्तरीय मैट्रिक्स

पोस्टमॉर्टम लीड टाइम: मेडियन को घटना के बंद होने से लेकर रिपोर्ट के प्रकाशन तक।

साक्ष्य पूर्णता: समयरेखा, एसएलआई चार्ट, लॉग, पीआर/कॉम्स के लिंक के साथ रिपोर्टों का हिस्सा।

अलर्ट हाइजीन स्कोर: कार्रवाई योग्य/एफपी/डेडअप/कोरम द्वारा समग्र सूचकांक।

हैंडओवर दोष: पारियों का अनुपात जहां सक्रिय घटनाओं का संदर्भ खो जाता है।

प्रशिक्षण कवरेज: तिमाही में% ऑन-कॉल का अनुकरण किया गया।


14) मेट्रिक्स कार्यान्वयन चेकलिस्ट

  • यूनिफ़ॉर्म टाइमस्टैम्प (यूटीसी) और घटना घटना अनुबंध को परिभाषित किया गया है।
  • SEV, मूल कारण वर्गीकरण और पहचान स्रोतों को अपनाया।
  • मेट्रिक्स को वॉल्यूम (यातायात/सफलता) के लिए सामान्यीकृत किया
  • रेडी 3 डैशबोर्ड: कार्यकारी, संचालन, परिवर्तन प्रभाव।
  • अलर्ट-ए-कोड: प्रत्येक पृष्ठ नियम में एक प्लेबुक और एक मालिक है।
  • एसएलए पोस्टमार्टम (जैसे) ड्राफ्ट ≤72ch, अंतिम ≤5 दास। दिन)।
  • CAPA को KPI और D + 14/D 30 तारीखों के साथ ट्रैक किया जाता है।
  • साप्ताहिक हादसा समीक्षा: रुझान, शीर्ष कारण, CAPA स्थिति।

15) एंटी-पैटर्न

MTTD/MTTA/MTTM के बिना केवल MTTR पर विचार करें - शुरुआती चरणों की नियंत्रणीयता का नुकसान।

वॉल्यूम में सामान्य नहीं करने के लिए - बड़ी सेवाएं "बदतर" लगती हैं।

Unsystematic SEV → असमान घटनाओं।

साक्ष्य की कमी - सुधार के बजाय विवाद।

जलने/एसएलओ प्रभाव के बजाय घटनाओं की संख्या पर ध्यान केंद्रित करें।

Reopen और CAPA → अनन्त रिलेप्स को अनदेखा करें।

टेलीमेट्री/आईटीएसएम से स्वचालित अपलोड किए बिना एक्सेल में मेट्रिक्स।


16) मिनी टेम्पलेट्स

हादसा कार्ड (abbr।)


INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

कार्यकारी रिपोर्ट (28 दिन, प्रमुख लाइ


Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17) रोडमैप (4-6 सप्ताह)

1. नेड। 1-Timestamp/field मानक, एसईवी/कारण शब्दकोश मूल घटना शोकेस।

2. नेड। 2: MTTD/MTTA/MTTM/MTTR गणना, सामान्यीकरण और SEV-डैशबोर्ड।

3. नेड। 3: रिलीज/कॉन्फ़िग, डिटेक्शन कवरेज और अलर्ट हाइजीन के साथ बंडल।

4. नेड। 4: कार्यकारी रिपोर्ट, एसएलए पोस्टमार्टम, सीएपीए ट्रैकर।

5. नेड। 5-6: प्रदाता रिपोर्ट, burn→$ वित्तीय मॉडल, त्रैमासिक लक्ष्य और त्रैमासिक घटना समीक्षा।


18) नीचे की रेखा

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

Contact

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

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।