معیارهای حادثه

1) چرا حوادث را اندازه گیری می کنیم

معیارهای حادثه رویدادهای هرج و مرج را به یک فرایند قابل کنترل تبدیل می کنند: کمک به کاهش زمان پاسخ و بهبود، کاهش علت عود، اثبات SLO/قرارداد تحقق، و پیدا کردن نقاط اتوماسیون. مجموعه خوبی از معیارها کل چرخه را پوشش می دهد: تشخیص → طبقه بندی → تشدید → اقدامات کاهش → بازیابی → تجزیه و تحلیل CAPA →

2) تعاریف و فرمول های اساسی

فواصل رویداد

MTTD (میانگین زمان تشخیص) = میانگین زمان از T0 (شروع واقعی نفوذ) تا اولین سیگنال/تشخیص.
MTTA (میانگین زمان تایید) = میانگین زمان از اولین سیگنال به ACK در تماس.
MTTM (میانگین زمان برای کاهش) = میانگین زمان برای کاهش اثر زیر آستانه SLO (اغلب = زمان به UX راه حل/تخریب).
MTTR (میانگین زمان برای بازیابی) = متوسط زمان برای بازیابی SLI های هدف.
MTBF (میانگین زمان بین خرابی ها) = میانگین فاصله بین حوادث مربوطه.

زمان کار

زمان اعلام - از T0 به اعلام رسمی سطح SEV/حادثه.
زمان به Comms - از اعلام به اولین عمومی/داخلی به روز رسانی SLA.
زمان در حالت - مدت زمان در هر مرحله (triage/diag/fix/verify).

فرکانس و کسری

تعداد حوادث - تعداد حوادث در هر دوره.
نرخ حادثه - در معاملات یا درخواست های موفق 1k/10k/100k (عادی سازی).

SEV Mix - توزیع بر اساس شدت (SEV-0... SEV-3)

SLA تعداد نقض/نرخ - تعداد/سهم از نقض SLA های خارجی.
نرخ شکست تغییر -٪ از حوادث ناشی از تغییرات (releases/configs/migrations).

کیفیت سیگنال ها و فرآیندها

٪ صفحات قابل اجرا - نسبت صفحات که منجر به اقدامات playbook معنی دار است.
نرخ مثبت کاذب (صفحات) - نسبت مثبت کاذب.
پوشش تشخیص - نسبت حوادث شناسایی شده توسط اتوماسیون (نه مشتریان/پشتیبانی).
نرخ بازگشایی - نسبت حوادث تکراری با همان علت ریشه ای ≤90 روزها.
تکمیل CAPA -٪ از اقدامات اصلاحی/پیشگیرانه به موقع بسته شده است.
Comms SLA Adjustment - نسبت به روز رسانی های منتشر شده توسط فرکانس مورد نیاز.

3) نقشه متریک توسط مرحله حادثه

4) عادی سازی و تقسیم بندی

عادی شمارنده به حجم (ترافیک، موفقیت، کاربران فعال).
بخش بر اساس: منطقه/مستاجر، ارائه دهنده (PSP/KYC/CDN)، نوع تغییر (کد/پیکربندی/مادون قرمز)، زمان روز (روز/شب)، منبع تشخیص (مصنوعی/RUM/مادون قرمز/پشتیبانی).
SLI های تجاری (موفقیت پرداخت ها، ثبت نام ها، دوباره پر کردن) برای کسب و کار مهم هستند - معیارهای حادثه را به تخریب آنها پیوند می دهند.

5) اهداف آستانه (نشانه ها، انطباق با دامنه)

MTTD: ≤ 5 دقیقه برای Tier-0، ≤ 10-15 دقیقه برای Tier-1.
MTTA: ≤ 5 دقیقه (24/7)، ≤ 10 دقیقه (بعد از خورشید).
MTTM: ≤ 15 دقیقه (Tier-0)، ≤ 30-60 دقیقه (Tier-1).
MTTR: ≤ 60 دقیقه (Tier-0)، ≤ 4 ساعت (Tier-1).
پوشش تشخیص: ≥ 85٪ اتوماسیون.

٪ صفحات قابل اجرا: ≥ 80-90٪ ؛ صفحات FP: ≤ 5٪

نرخ بازگشایی (90д): ≤ 5-10٪.
تکمیل CAPA (در زمان): ≥ 85٪.

6) تخصیص علل و تاثیر تغییرات

یک علت اصلی (کد/پیکربندی/Infra/ارائه دهنده/امنیت/داده/ظرفیت) و ماشه (شناسه انتشار، تغییر پیکربندی، مهاجرت، عامل خارجی) را به هر حادثه اختصاص دهید.
نگه داشتن MTTR/Count مرتبط با تغییر - چقدر انتشار و پیکربندی کمک می کند (پایه برای سیاست های دروازه/canary).
به طور جداگانه، حوادث ناشی از ارائه دهنده (PSP/KYC/CDN/Cloud) را برای مدیریت مسیرها و قراردادها در نظر بگیرید.

7) ارتباطات و تاثیر مشتری

زمان اولین به روز رسانی عمومی و به روز رسانی کادنس (به عنوان مثال، هر 15/30 دقیقه).
نرخ شکایت - بلیط/شکایت در مورد 1 حادثه، روند.
دقت وضعیت - سهم به روز رسانی عمومی بدون retractions.
NPS پس از حادثه (توسط مشتری کلیدی) - افزایش کوتاه پس از SEV-1/0.

8) هشدار معیارهای کیفیت در اطراف حوادث

Page Storm Index - تعداد صفحات/ساعت در هر تماس در طول یک حادثه (میانه/p95).
Dedup بهره وری - نسبت تکراری سرکوب شده است.
Quorum Confirmation Rate - نسبت حوادثی که در آن حد نصاب پروب (≥2 منابع مستقل) باعث شد.
Shadow → Canary → Prod تبدیل قوانین جدید (هشدار به عنوان کد).

9) داشبورد (حداقل مجموعه)

1. اجرایی (28 روز): تعداد حوادث، توزیع SEV، MTTR/MTTM، شکاف SLA، بازگشایی، CAPA.
2. عملیات SRE: MTTD/MTTA по часам/сменам، طوفان صفحه،٪ قابل اجرا، پوشش تشخیص، زمان اعلام/Comms.
3. تأثیر تغییر: سهم حوادث انتشار/پیکربندی، MTTR برای حوادث تغییر، پنجره های تعمیر و نگهداری در مقابل حوادث.
4. ارائه دهندگان: حوادث توسط ارائه دهنده، زمان تخریب، سوئیچ مسیر، SLA های قراردادی.
5. نقشه حرارتی توسط سرویس/منطقه: حوادث و MTTR در هر 1K معاملات.

ترکیب گرافیک SLI/SLO با حاشیه نویسی انتشار و علائم SEV.

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)

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';

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) پیوند به SLO و بودجه خطا

ضبط دقیقه سوزاندن SLO در هر حادثه - این «وزن» اصلی این رویداد است.
اولویت بندی CAPA توسط کل سوختگی و وزن SEV به جای تعداد حادثه.
سوختگی را با تأثیر مالی همراه کنید (به عنوان مثال: $/دقیقه خرابی یا $/معامله از دست رفته).

13) معیارهای سطح برنامه

زمان سرب پس از مرگ: متوسط از بسته شدن حادثه تا انتشار گزارش.
شواهد کامل: سهم گزارش با جدول زمانی، نمودار SLI، سیاهههای مربوط، لینک به PR/comms.
امتیاز بهداشت هشدار: شاخص کامپوزیت توسط عملی/FP/dedup/حد نصاب.
نقص تحویل: نسبت شیفتهایی که زمینه حوادث فعال از دست رفته است.
پوشش آموزش:٪ در تماس شبیه سازی شده در سه ماهه.

14) چک لیست پیاده سازی معیارها

• زمان بندی یکنواخت (UTC) و قرارداد رویداد حادثه تعریف شده است.
• SEV، علت اصلی طبقه بندی و منابع تشخیص اتخاذ شده است.
• معیارها به حجم (ترافیک/موفقیت) نرمال می شوند.
• آماده 3 داشبورد: اجرایی، عملیات، تغییر تاثیر.
• هشدار به عنوان کد: هر قانون صفحه دارای یک playbook و یک مالک است.
• SLA پس از مرگ (به عنوان مثال پيش نويس ≤72ch، آخرين برده ≤5. روزها).
• CAPA ها با KPI های اثر و تاریخ D + 14/D + 30 ردیابی می شوند.
• بررسی حادثه هفتگی: روند، دلایل بالا، وضعیت CAPA.

15) ضد الگوهای

حوادث SEV غیر سیستماتیک

فقط MTTR را بدون MTTD/MTTA/MTTM → از دست دادن کنترل مراحل اولیه در نظر بگیرید.
نه برای عادی سازی در حجم → خدمات بزرگ «به نظر می رسد» بدتر است.
فقدان شواهد → بحث به جای بهبود.
تمرکز بر تعداد حوادث به جای سوختگی/تاثیر SLO.
نادیده گرفتن بازگشایی و CAPA → عود ابدی.
معیارهای موجود در اکسل بدون آپلود خودکار از Telemetry/ITSM.

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، SEV/فرهنگ لغت دلیل اساسی ویترین حادثه.
2. «ند». 2: MTTD/MTTA/MTTM/MTTR محاسبات، عادی سازی و SEV-داشبورد.
3. «ند». 3: بسته نرم افزاری با انتشار/پیکربندی، پوشش تشخیص و هشدار بهداشت.
4. «ند». 4: گزارش اجرایی، SLA پس از مرگ، ردیاب CAPA.
5. «ند». 5-6: گزارش های ارائه دهنده، سوزاندن → مدل مالی، اهداف سه ماهه و بررسی حوادث سه ماهه.

18) خط پایین

معیارهای حادثه فقط اعداد نیستند، بلکه یک داستان از قابلیت اطمینان عملیاتی هستند. هنگامی که کل جریان را اندازه گیری می کنید (از تشخیص به CAPA)، معیارها را عادی می کنید، آنها را با SLO ها و تغییرات مرتبط می کنید و به طور مرتب بررسی می کنید، سازمان به طور قابل پیش بینی زمان پاسخ، هزینه و فرکانس حادثه را کاهش می دهد و کاربران یک سرویس پایدار را می بینند.