گزارش های پس از حادثه

1) چرا تجزیه پس از حادثه مورد نیاز است

گزارشگیری پس از حادثه (post-mortem/AAR) یک فرآیند ساختاری برای آموزش یک سازمان پس از یک شکست است. هدف یافتن مقصر نیست، بلکه شناسایی علل ریشه ای و کمک کننده و تحکیم اقدامات قابل اندازه گیری (CAPA) است که خطر عود و هزینه حوادث را کاهش می دهد، بهبود SLO، MTTR و اعتماد مشتری/نظارتی.

2) اصول (فرهنگ عادلانه)

بدون اتهام: ما سیستم ها، تصمیمات و زمینه ها را تجزیه و تحلیل می کنیم، نه شخصیت ها.
حقایق مهمتر از نظرات هستند: جدول زمانی، سیاههها، معیارها، مسیرها، مصنوعات تغییرات.
نمای E2E: از علائم روی مشتری گرفته تا وابستگی های داخلی و ارائه دهندگان خارجی.
قابلیت اطمینان: هر فرضیه توسط آزمایش/داده پشتیبانی می شود.
بستن حلقه: تجزیۀ CAPA → بازرسیها → بازرسیها.

3) چه زمانی تجزیه را اجرا کنیم و چه فرمت هایی هستند

مورد نیاز: SEV-0/1 ؛ نقض الزامات SLA/قانونی ؛ نشت اطلاعات ؛ ریسک مهم روابط عمومی

شتاب (نور): SEV-2 با تأثیر قابل توجه یا علائم تکراری.
AAR ارتباطات: اگر شکست بر صفحه وضعیت/پشتیبانی تاثیر می گذارد، ما SLA ها را به روز رسانی ها و کیفیت پیام ها بررسی می کنیم.

شرایط: پیش نویس برای 48-72 ساعت، نسخه نهایی - تا 5 روز کاری (مگر اینکه در غیر این صورت توافق).

4) نقش ها و مسئولیت ها

RCA Lead: فرآیند را سازماندهی می کند، جلسه را هدایت می کند، مسئول کیفیت گزارش و CAPA است.
فرمانده حادثه (IC): حقایق و راه حل های حادثه را ارائه می دهد.
Tech Leads (by Systems): تجزیه و تحلیل علت که مصنوعات را تایید می کند.
Comms/Support/Legal: ارزیابی ارتباطات و الزامات انطباق.
Scribe: پروتکل، جمع آوری شواهد، انطباق با ساختار.

ذینفعان محصول/کسب و کار - تاثیر مشتری/گردش مالی، اولویت بندی CAPA

5) آماده سازی: چه چیزی را قبل از جلسه جمع آوری کنید

خط زمان (UTC): تشخیص T0 → بازیابی Tn ؛ releases/feature flags/configs, وضعیت ارائه دهندگان.
داده های قابل مشاهده: نمودارهای SLI/SLO، نرخ خطا، درصد، سیاهههای مربوط، ردیابی، تصاویر.
زمینه تغییرات: پیوندها به PR/deploy، مهاجرت DB، پرچم های ویژگی، برنامه های کاری.
تاثیر: گروه های تحت تاثیر/مناطق/ارائه دهندگان، دقیقه خرابی، اعتبارات SLA.
ارتباطات: پیش نویس/پست در صفحه وضعیت، پاسخ پشتیبانی، اطلاعیه های داخلی.
سیاستمداران/playbooks: چه باید در روند رخ داده است که در آن انحرافات وجود دارد.

6) روش های تحلیلی (ترکیب را انتخاب کنید)

5 چرا: کالبد شکافی سریع زنجیره علت (خطر - ساده سازی بیش از حد).
نمودار Fishbone: افراد/فرآیند/پلت فرم/سیاست/شریک/محصول.
تجزیه و تحلیل درخت خطا (FTA) - کسر از رویداد به علل متعدد (AND/OR).
تجزیه و تحلیل تغییر: چه چیزی در طول حادثه در مقابل وضعیت پایدار تغییر کرده است.
نمودار علّی: نمودار علّی برای میکروسرویسهای پیچیده و وابستگیهای خارجی.

بررسی عوامل انسانی: خستگی، سر و صدای اطلاعات، کتاب های بی ربط و

7) ساختار گزارش (قالب)

1. خلاصه اجرایی - چه زمانی، چه کسی تحت تاثیر قرار گرفت، وضعیت نهایی.
2. تاثیر: SLI/SLO، کاربران، مناطق/ارائه دهندگان، خرابی حداقل، اثرات مالی/نظارتی.
3. Timeline (UTC): رویدادهای کلیدی، انتشار، راه حل های IC، ارتباطات.
4. مشاهدات و داده ها: نمودار ها، سیاهههای مربوط، آثار، انتشار پیکربندی/طرح.
5. فرضیه ها و آزمون: پذیرفته/رد, اشاره به آزمایش/شبیه سازی.
6. علل ریشه: سیستم/فرآیند/فنی (جمله بندی روشن).
7. عوامل موثر: چرا قبلا متوجه نشده اید/متوقف شده اید.
8. چه چیزی کار کرد/چه چیزی کار نکرد: فرآیندها، ابزارها، افراد.
9. CAPA: اقدامات اصلاحی و پیشگیرانه با صاحبان/مهلت/معیارهای موفقیت.
10. طرح تأیید: D + 14/D + 30 نقاط کنترل، معیارهای بسته شدن.
11. نسخه های خارجی: مشتری/نظارتی (بدون اطلاعات حساس).
12. برنامه های کاربردی: مصنوعات، لینک به بلیط/PR، تصاویر داشبورد.

8) CAPAs: چگونه می توان اقدامات را انجام داد

هر اقدام یک مالک، یک مهلت و یک KPI اثر دارد (به عنوان مثال، کاهش نرخ تغییر شکست X٪، تکرار صفر 90 روز، کاهش میزان سوزاندن در سنبله ها).

اقدامات اصلاحی و پیشگیرانه جداگانه

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

9) بررسی اثر و بسته شدن

نقاط بازرسی: D + 7 (متوسط)، D + 14/D + 30 (اصلی)، D + 90 (کل).
تأیید: تست/شبیه سازی (روز بازی)، ترافیک سایه، قابلیت مشاهده (SLI پایدار در منطقه سبز)، بدون عود.
بستن فقط با CAPA های تکمیل شده و معیارهای معتبر امکان پذیر است.

10) ارتباطات و انطباق

داخلی: وضعیت روشن برای محصول/پشتیبانی/مدیریت، به روز رسانی SLA ملاقات کرد.
خارجی: صفحه وضعیت، ارسال نامه به مشتریان/شرکا ؛ زبان بدون سرزنش، یک برنامه پیشگیری واضح.
مقررات: مهلت اطلاع رسانی، شخصی سازی نمونه ها، ذخیره سازی غیر قابل تغییر گزارش ها و مصنوعات.

11) معیارهای بلوغ فرآیند

گزارش زمان انتشار: واقعی در مقابل SLA (به عنوان مثال ≤5 روز کاری).
نرخ تکمیل CAPA: درصد فعالیت های بسته شده در تاریخ مقرر.
نرخ بازگشایی: نسبت حوادث تکراری در 90 روز.

نسبت علل سیستمیک در مقابل «خطای انسانی»

بهداشت هشدار: کاهش صفحات دروغین، رشد هشدارهای تحت پوشش runbooks.
تغییر معیارهای DORA: MTTR, change-failure-rate before/after.

12) چک لیست

قبل از تجزیه

• مالک RCA و عضویت تعریف شده است.
• جدول زمانی جمع آوری شده و مصنوعات (سیاهههای مربوط/نمودار/انتشار/پرچم).
• تاثیر ارزیابی شده توسط کوهورت/منطقه/ارائه دهنده.
• پیش نویس بخش های تاثیر و جدول زمانی آماده شده است.
• سیاست های مربوطه/playbooks به اقدامات واقعی نقشه برداری.

در طول

• فرضیه ها و دلایل پذیرفته شده/رد شده ثبت شد.
• علل ریشه ای و مشارکت شناسایی شده است.
• یک طرح CAPA با KPI ها و مهلت ها ایجاد شده است.
• نسخه گزارش برای احزاب خارجی توافق (در صورت لزوم).

پس از

• گزارش منتشر شده در زمان، دسترسی به نقش.
• CAPA ها وارد سیستم می شوند، صاحبان تایید می شوند.
• نقاط تست و مینی شبیه سازی برای تأیید اختصاص داده شده است.
• به روز شده runbook/SOP/هشدار/اسناد و مدارک.

13) ضد الگوهای

«گناهکار مرد X» - تکرار → بدون دلایل سیستمیک.
گزارش بدون CAPA یا بدون صاحبان/مهلت - مقاله برای کاغذ.
بدون حقایق/مصنوعات - نتیجه گیری در مورد احساسات.
زبان بیش از حد رایج («اضافه بار پایگاه داده») بدون تغییر خاص.
نادیده گرفتن ارتباطات و انطباق، خطرات اعتبار است.
بسته شدن بدون اثر تست - عود پس از هفته.

14) قالب های کوچک

هدر گزارش

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

فرمول علت ریشه (مثال)

CAPA (قطعه)

مسیریابی قناری را به PSP-A فعال کنید (1٪ → 5٪ → 25٪)، مالک: @ payments-tl، تا: 2025-11-07، KPI: حوادث صفر P1 وقتی ارائه دهندگان 30 روز را آزاد می کنند.
تنظیم timeouts/retrays با زمان SLA ≤ کل 800 میلی ثانیه، صاحب: @ پلت فرم-sre، تا: 2025-11-05، KPI: p99 <600 میلی ثانیه تحت بار N.
SLI کسب و کار را توسط BIN Cohort اضافه کنید، مالک: data-lead، به: 2025-11-10، KPI: تشخیص تخریب <5 دقیقه.

15) جاسازی در عمل روزانه

بررسی هفتگی RCA: وضعیت CAPA، درس های جدید، به روز رسانی فرآیند.
دایرکتوری پس از مرگ در ویکی با برچسب ها (سرویس، SEV، دلایل) و جستجو.
شبیه سازی بر اساس حادثه در 2-4 هفته به منظور بررسی اقدامات.
از جمله درس در on-call onboarding و به روز رسانی سناریوهای آموزش.

16) خط پایین

تجزیه پس از حادثه یک مکانیسم برای بهبود سیستمیک است. هنگامی که حقایق جمع آوری می شوند، علیت ثابت می شود، اقدامات قابل اندازه گیری و تأیید می شوند، سازمان سرمایه عملیاتی قابل اطمینان را جمع آوری می کند: MTTR و تکرار حوادث سقوط، پیش بینی پذیری انتشار و افزایش اعتماد مشتری.