شبیه سازی حادثه

1) چرا شبیه سازی

• MTTD/MTTA/MTTR پایین، افزایش اعتماد به نفس در ضربات و fylovers ؛
• شناسایی شکاف فرآیند (تشدید، ارتباطات) و نقاط ضعف معماری ؛
• خدمت به عنوان یک ورودی به RCA → CAPA و بهبود اسناد و مدارک (runbook/SOP) ؛
• آمادگی برای الزامات SLA/نظارتی/حسابرسی را تأیید کنید.

2) فرمت های شبیه سازی

Tabletop (tabletop) - اسکریپت مکالمه در هیئت مدیره/چت: ارزان، سریع، عالی برای تمرین نقش ها و ارتباطات.
روز بازی (تمرینات در مرحله/فروش با محدودیت) - گام های عملی برای playbooks ؛ در فروش - فقط اقدامات ایمن و برگشت پذیر با دروازه های روشن.
Chaos Engineering - خرابی های کنترل شده (قطع وابستگی ها/شبکه ها/گره ها) برای بررسی ثبات و دروازه های SLO.
تمرینات DR (Disaster Recovery) - شکست AZ/منطقه، بازیابی از پشتیبان گیری، ارائه دهندگان سوئیچینگ.
Comms-drill - صرفا ارتباطات: صفحه وضعیت، قالب پیام، PR/Legal.

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

فرمانده حادثه (IC) - تصمیم می گیرد، یک برنامه را هدایت می کند، تنش زدایی می کند.
سرب فنی (TL) - تشخیص، فنی «تزریق» و فرضیه.
Comms Lead (CL) - به روز رسانی داخلی/خارجی، صفحه وضعیت.
Scribe - پروتکل (جدول زمانی، اقدامات، تصمیمات، مصنوعات).
ناظران/ارزیابان - معیارهای ضبط و انطباق با روش ها.
تیم قرمز (اختیاری) - «تزریق» غیر منتظره را معرفی می کند.

4) معیارهای موفقیت شبیه سازی

MTTD/MTTA/MTTR توسط حادثه مصنوعی.
Comm SLA: به موقع بودن و کیفیت به روز رسانی.
SLO-guardrails: واکنش صحیح به میزان سوختگی، حد نصاب نمونه های خارجی.
وفاداری Runbook:٪ از مراحل تکمیل شده در هر سند، بدون بداهه.
Escalation latency - سرعت اتصال نقش/ارائه دهنده مورد نظر.
چک لیست نرخ عبور: انطباق با «آماده/پذیرفته/بسته».
سر و صدا و خستگی: هشدار اضافی، بیش از حد در تماس.
تکمیل CAPA: درصد اقدامات تکمیل شده پس از شبیه سازی.

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

هدف و فرضیه ها: آنچه ما بررسی می کنیم (فرآیندها، معماری، مردم)

سناریو و «تزریق»: دنباله ای از علائم/حوادث با زمان بندی.
محدودیت های امنیتی: ممنوعیت تغییرات غیر قابل برگشت ؛ نقاط را باز کنید.
داده ها و غرفه ها: ترافیک مصنوعی، پرچم ویژگی های تخریب، کلید های امن.
اسناد: پیوندهایی به runbook/SOP، تشدید، لیست تماس ارائه دهندگان.
قابلیت مشاهده: داشبورد/هشدار از پیش مشخص شده، قناری های تست.
تدارکات: زمان/مدت زمان، شرکت کنندگان، کانال جنگ اتاق، ضبط.

6) اجرای شبیه سازی: مراحل

1. مختصر (5-10 دقیقه): IC شبیه اهداف، نقش ها، قوانین ایمنی، معیارهای تکمیل است.
2. T0 - تزریق علائم: هشدار (ها)، افت SLI کسب و کار، وضعیت خارجی ارائه دهنده.
3. تریاژ و تشدید: اختصاص SEV، انتشار یخ، اتصال نقش های لازم.
4. تشخیص: فرضیه ها، DNS/TLS/CDN/DB/cache/bus check، حاشیه نویسی انتشار.
5. اقدامات کاهش دهنده: otkat/kanareyka↓، پرچم های تخریب، ارائه دهنده شکست، محدودیت ها/retras.
6. ارتباطات: به روز رسانی به طور منظم (فرمت: Impakt → Diagnostika → Deystviya → سورتمه. به روز رسانی).
7. بازیابی و تأیید: مصنوعی خارجی + SLI در فواصل سبز منطقه N.
8. Debrief (AAR): 15-30 دقیقه - حقایق، نتیجه گیری، CAPA.

7) سناریوهای مثال (کاتالوگ)

موفقیت در حال سقوط پرداخت: ارائه دهنده A در یک کشور تنزل می یابد ؛ اقدامات مورد انتظار - توزیع مجدد ترافیک، فعال کردن UX ساده، ارتباطات.
خرابی DNS: خطای write/TTL، برخی از کاربران دامنه را حل نمی کنند. مراحل مورد انتظار - رفع/folback، پاکسازی CDN، به روز رسانی وضعیت.
گواهی TLS منقضی شده: دست دادن برای مشتریان قدیمی ؛ گسترش اضطراری و چک زنجیره ای در انتظار.
تاخیر کافکا: افزایش تاخیر در رویدادهای KYC/AML ؛ انتظارات - مصرف کنندگان در مقیاس، محدود کردن تولید کنندگان.
پایگاه داده p99 ↑ و رشد 5xx: شاخص های باریک، حد اتصال ؛ انتظارات - پرچم های ویژگی، محدودیت ها، hotfix/rollback.
شکست منطقه ای: خاموش شدن AZ/PoP ؛ waiting - سوئیچینگ GSLB/Anycast، تأیید داده ها و SLO.
تمرین ارتباطات: همه چیز «سبز» است، اما ما الگوهای، فواصل و هماهنگی با Legal/PR را بررسی می کنیم.

8) قالب «تزریق» (کارت)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) ایمنی و انطباق

شبیه سازی تولید - تنها برگشت پذیر: پرچم ویژگی، تغییر ترافیک در کسرهای کوچک، اظهارات برای خواندن، «ترافیک سایه».
کنترل دسترسی/حسابرسی: تمام اقدامات از طریق ChatOps/pipeline ؛ سیاهههای مربوط در ذخیره سازی غیر قابل تغییر.
PII/اسرار - در مصنوعات آموزشی استفاده نمی شود ؛ داده ها شخصی شده است.
تنظیم: اگر شبیه سازی ارتباطات مشتری را تحت تاثیر قرار دهد - علامت گذاری «آموزش» در کانال های خصوصی ؛ پست های عمومی تقلید نمی شوند.

10) ارزیابی و AAR → RCA → کاپا

AAR (After Action Review) - بلافاصله پس از تمرین: آنچه انتظار می رفت/دیده می شد، چه کار می کرد/نه.
RCA - برای شکست های قابل توجه (به عنوان مثال، تشدید کار نمی کند) با توجه به قالب RCA.
CAPA - لیستی از اقدامات با صاحبان/مهلت/معیارهای اثر (تغییر در playbooks، هشدار، معماری).
نقاط بازرسی - D + 14/D + 30: تأیید اعدام، تکرار مینی دریل در نقاط آسیب پذیر.

11) مستندات و مصنوعات

برنامه شبیه سازی: اهداف، سناریو، تزریق، شرکت کنندگان، پنجره ها، معیارهای موفقیت.
خط زمان (UTC): T0...Tn، راه حل های IC، مراحل فنی، به روز رسانی.
تصاویر داشبورد/سیاهههای مربوط، عصاره هشدار و وضعیت.

گزارش خلاصه - معیارها، اختلافات Playbook، CAPA ها

به روز رسانی مستندات: ویرایش runbook/SOP/contact، لینک به داشبورد جدید.

12) فرکانس و پوشش

Tabletop: 2-4 بار در ماه (توسط جریان های کلیدی و نقش ها).
روزهای بازی در مرحله: 1-2 بار در ماه.
موارد هرج و مرج (تولید نور): سه ماهه، به شدت توسط گیتس.
تمرینات DR: 1-2 بار در سال با تعویض واقعی.
Comms-drill: ماهانه برای آموزش قالب ها و به روز رسانی SLA.

13) چک لیست

قبل از شبیه سازی

• سناریو، «تزریق»، معیارهای موفقیت، پنجره های ایمنی.
• نقش ها، کانال ها، وضعیت قالب ها سازگار است.
• در دسترس بودن غرفه/پرچم/داشبورد بررسی می شود.
• طرح برداشت و برگشت پذیری مستند شده است.
• خطرات و تاثیر بر SLO/مشتریان ارزیابی شده است.

در طول

• SEV اختصاص داده شده، انتشار یخ (در صورت نیاز).
• ارتباط در یک برنامه، فرمت سازگار است.
• همه اقدامات از طریق ابزار حسابرسی.
• کاتب حفظ یک پروتکل، جمع آوری مصنوعات.
• ایمنی: ممنوعیت/محدودیت ها رعایت می شود.

پس از

• AAR ارسال شده، گزارش ذخیره شده است.
• RCA (در صورت شکست) آغاز شده است.
• CAPA ها با صاحبان/مهلت صادر شده است.
• به روز شده runbook/SOP/اطلاعات تماس.
• تست مجدد آسیب پذیری ها برنامه ریزی شده است.

14) ضد الگوهای

«بداهه به جای یک برنامه» - هیچ اسکریپت و معیارهای موفقیت وجود دارد.
خطرات بدون دروازه و برنامه لغو - تمرینات به یک حادثه تبدیل می شوند.
کار کردن فقط تجهیزات بدون ارتباطات و تشدید.
کمبود AAR/RCA - تیم در حال یادگیری نیست.
Prod-chaos بدون مشاهده و SLO-gardrails.
حقوق مات: کتابچه راهنمای کاربر مخفی ویرایش در انگیختن.

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

دستور کار روز بازی (60-90 دقیقه)

1. مختصر (5 دقیقه) → اهداف، نقش ها، امنیت.
2. سناریو T0 (5 دقیقه) → ارائه علائم.
3. تریاژ/تشدید (10 دقیقه).
4. تشخیص + اقدامات (30-45 دقیقه) - 1-2 «تزریق».
5. بازیابی و تأیید (10 دقیقه).
6. AAR (15 دقیقه) - نتیجه گیری، CAPA.

AAR الگو (کوتاه)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) خط پایین

شبیه سازی حادثه یک «شبیه ساز» برای افراد، فرایندها و معماری است. تمرینات منظم، ایمن و قابل اندازه گیری، بحران ها را به یک روال تبدیل می کند: تیم سریعتر واکنش نشان می دهد، playbooks واقعا کار می کند، معماری پایدار تر است، و تنظیم کننده و مشتریان بلوغ عملکرد عملیاتی را می بینند. نکته اصلی اهداف روشن، دروازه های امن، معیارهای خوب و AAR اجباری → RCA → CAPA است.