حوادث و کتاب های SRE

1) حادثه چیست و چگونه به SLO مربوط می شود

حادثه رویدادی است که عملکرد SLO/service را نقض می کند یا خطر نقض را ایجاد می کند (بودجه اشتباه به سرعت غیرقابل قبول سوزانده می شود).
معیارهای کلاسیک: MTTD، MTTA، MTTR، MTBF.
خطای بودجه و نرخ سوختن پنجره های اولویت و تشدید را تعیین می کند.

2) سطح شدت (SEVs) و معیارها

محرک های SEV: بیش از 5xx٪، آستانه p95>، سنبله کاهش پرداخت، Kafka-lag> آستانه، NodeNotReady> X min، TLS منقضی می شود <7 روز، سیگنال های DDoS/نشت.

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

فرمانده حادثه (IC) - تنها تصمیم گیری، مدیریت جریان کار، تغییر وضعیت SEV.
Ops Lead (Tech Lead) - استراتژی فنی، فرضیه ها، هماهنگی رفع.
ارتباطات سرب (Comms) - به روز رسانی وضعیت (داخلی/خارجی), StatusPage/chat/mail.
Scribe (Chronicler) - جدول زمانی، راه حل ها، مصنوعات، لینک ها به نمودار/سیاهههای مربوط.
On-call Engineers/SMEs - اجرای اقدامات playbook.
امنیت/حریم خصوصی - برای حوادث امنیتی یا PII فعال شده است.
FinOps/پرداخت - هنگامی که تحت تاثیر صدور صورت حساب/PSP/هزینه.

4) چرخه عمر حادثه

1. تشخیص (هشدار/گزارش/مصنوعی) → ایجاد خودکار یک کارت حادثه.
2. Triage (IC اختصاص داده شده، SEV اختصاص داده شده، حداقل مجموعه زمینه).
3. تثبیت کننده (کاهش: خاموش کردن ویژگی/rollback/rate-limit/failover).
4. تحقیق (فرضیه RCA، جمع آوری حقایق).
5. بازیابی خدمات (اعتبار SLO، مشاهده).
6. ارتباطات (در داخل/خارج، گزارش نهایی).
7. Postmortem (بدون هزینه، طرح CAPA، صاحبان، مهلت).
8. پیشگیری (تست/هشدار/playbooks/پرچم، آموزش های اضافی از تیم).

5) ارتباطات و «اتاق جنگ»

Unified Incident Channel («# inc-sev1-YYYYMMDD-hhmm»)، فقط حقایق و اقدامات.

دستورهای سبک پروتکل رادیویی: "IC: I assign rollback version 1. 24 → ETA 10 دقیقه"

به روز رسانی وضعیت: SEV-1 هر 15 دقیقه، SEV-2 هر 30-60 دقیقه.
صفحه وضعیت/ارتباط خارجی - از طریق Comms سرب توسط قالب.
ممنوعه: اتاق های موازی «آرام»، فرضیه های آزمایش نشده در یک کانال مشترک.

6) هشدار و سوزاندن SLO (قوانین مثال)

کانال سریع (1-5 دقیقه) و کانال آهسته (1-2 ساعت) نرخ سوختن.
چند سیگنال: خطای بودجه، 5xx٪، p95، Kafka-lag، نرخ کاهش پرداخت، مصنوعی.
جستجو برای علت اصلی - تنها پس از تثبیت علائم.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) کتاب های بازی در مقابل ranbooks

Playbook - سناریوی اقدامات بر اساس نوع حادثه (انشعاب، شرایط، خطرات).
Runbook - یک «نقشه» خاص از مراحل/دستورات (چک، رفع، تأیید).
قانون: playbook به چندین runbooks اشاره دارد (rollbacks، feature-flags، failover، scaling، blocking traffic و غیره).

8) قالب کارت حادثه

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) الگوی کتابچه راهنمای SRE (نشانه گذاری)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) کتاب های معمولی

10. 1 API اسپایک 5xx

تثبیت کننده: ficheflag مشکل ساز را خاموش کنید. تقویت API کپی فعال کردن ذخیره سازی نورد به عقب انتشار.
تشخیص: انتشار diff، خطا در سیاهههای مربوط (بالا استثنا)، رشد p95، فشار DB/کش.
خطرات: آبشار در پرداخت/backends.

10. 2 БД: تکرار تاخیر/طوفان قفل

تثبیت: تعلیق مشاغل سنگین/گزارش ؛ تغییر مسیر به wal_buffers/replika-sloty افزایش جادوگر خوانده می شود.
تشخیص: معاملات طولانی، مسدود کردن درخواست ها، تغییرات برنامه.
تثبیت: شاخص ها/نکات، توسعه مجدد شغل، نمایش داده شد تقسیم شده است.

10. 3 تاخیر مصرف کننده کافکا

تثبیت: مصرف کنندگان به طور موقت مقیاس ؛ کاهش تولید از خدمات غیر بحرانی ؛ افزایش احزاب/سهمیه.
تشخیص: توازن، deserializations آهسته، مکث GC.
تأیید: تاخیر → به مقدار هدف، بدون قطره.

10. 4 K8s NodeNotReady/طوفان منابع

تثبیت کننده: بند ناف + تخلیه ؛ توزیع مجدد بارها ؛ بررسی CNI/پوشش خاموش DaemonSets پر سر و صدا.
تشخیص: فشار دیسک، OOM، کاهش، افت شبکه.
پیشگیری: بودجه اختلال غلاف، محدودیت منابع/درخواست.

10. 5 TLS/گواهینامه ها منقضی می شوند

تثبیت: به روز رسانی اجباری راز/ورود ؛ لغو موقت

تشخیص: زنجیره ای از اعتماد، ساعت پیچ و تاب.
پیشگیری: هشدار T-30/T-7/T-1، خودکار renual.

10. 6 DDoS/ترافیک غیر طبیعی

تثبیت: قوانین WAF/bot، rate-limit/geo-filters، بار بالادست بالادست.
تشخیص: پروفایل های حمله (L3/4/7)، منابع، چتر.
پیشگیری: anycast، autoscaling، ذخیره، بازی خوب با ارائه دهندگان.

10. 7 پرداخت PSP قطع

تثبیت: مسیریابی هوشمند به PSP/روش های جایگزین ؛ دوباره سعی کنید با jitter ؛ «نرم» تخریب UI.
تشخیص: خرابی سنبله توسط کدها، وضعیت API/صفحات وضعیت PSP.
ارتباطات: به روز رسانی شفاف برای کسب و کار و پشتیبانی، آمار ND/تبدیل درست است.

10. 8 حادثه ایمنی/نشت PII

تثبیت: انزوا گره/چرخش مخفی، مسدود کردن exfiltration، نگه داشتن قانونی.
تشخیص: جدول زمانی دسترسی، موضوعات/زمینه های آسیب دیده.
اطلاعیه: تنظیم کننده/همکاران/کاربران توسط صلاحیت مورد نیاز.
پیشگیری: افزایش DLP/تقسیم بندی، «حداقل امتیاز».

11) اتوماسیون از playbooks

دستورات ChatOps: '/ic set sev 1 ', '/deploy rollback api 1. 23. 4 '، '/ویژگی خاموش X'.
Runbook-رباتها: مراحل نیمه اتوماتیک (گره تخلیه, ترافیک تلنگر, کش پاکسازی).
قلاب خود شفا: آشکارساز → کاهش استاندارد (نرخ محدود، راه اندازی مجدد، مقیاس).
خودکار ایجاد کارت/جدول زمانی از هشدارها و دستورات.

12) کیفیت بازی: چک لیست

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

13) Postmortem (بی گناه) و CAPA

هدف: یادگیری، نه پیدا کردن مقصر.
محتوا: چه اتفاقی افتاد، چه چیزی خوب/بد بود، سهم عوامل (کسانی که + فرآیندها)، اقدامات برای جلوگیری از.
مدت: SEV-1 - ظرف 48 ساعت ؛ SEV-2 - 3 روز کاری.
CAPA: صاحبان خاص، زمان بندی، اثرات قابل اندازه گیری (کاهش MTTR/افزایش MTTD).

14) جنبه های حقوقی و پایه شواهد

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

15) معیارهای عملکرد فرآیند حادثه

MTTD/MTTA/MTTR توسط سه ماهه و دامنه.
دقت SEV (کم/بیش از حد).
سهم حوادث کاهش خودکار.
پوشش Playbook از سناریوهای بالا N (> 90٪).
CAPA را به موقع انجام دهید.

16) اجرای مرحله ای

1. هفته 1: ماتریس SEV، نقش های تماس، قالب کارت عمومی، مقررات اتاق جنگ.
2. هفته 2: کتاب های بازی برای علائم 5 بالا (5xx، تاخیر DB، Kafka-lag، NodeNotReady، TLS).
3. هفته 3: ChatOps/رباتها, کارت های خودکار ایجاد, قالب های ارتباطی/StatusPage.

4. هفته 4 +: ایمنی Playbooks، قطع PSP، حقوقی نگه دارید، به طور منظم دریل/بازی هرج و مرج

17) نمونه هایی از ranbooks «سریع» (قطعات)

برگشت API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

تخلیه گره

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

ویژگی پرچم خاموش (مثال)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) مینی سوالات متداول

چه زمانی SEV-1 را بالا ببریم ؟

هنگامی که عملکرد کلیدی SLO/کسب و کار (پرداخت، ورود، بازی) رنج می برد، و نرخ سوختن «خوردن» بودجه برای ساعت ها پیش رو.

چه چیزی مهمتر است ؟ RCA یا بهبودی ؟

همیشه ثبات، سپس RCA. زمان به ثبات شاخص اصلی است.

آیا باید همه چیز را اتوماتیک کنم ؟

مراحل مکرر و ایمن را خودکار کنید نادر/خطرناک - از طریق تایید نیمه اتوماتیک و IC.

نتیجه گیری

فرآیند حادثه قوی بر سه ستون استوار است: نقش های روشن و قوانین SEV، بازی های با کیفیت/ranbooks با اتوماسیون، و یک فرهنگ پس از مرگ بدون سرزنش. الگوهای ضبط، آموزش در تماس، اندازه گیری MTTR/بودجه اشتباه، و به طور مداوم بهبود آشکارسازها و playbooks - این به طور مستقیم خطر و هزینه خرابی را کاهش می دهد.