Incydenty i playbooks SRE

1) Co to jest incydent i jak odnosi się do SLO

Incydent jest zdarzeniem, które narusza funkcję SLO/usługi lub stwarza ryzyko naruszenia (błędny budżet jest spalany niedopuszczalnie szybko).
Klasyczne wskaźniki: MTTD, MTTA, MTTR, MTBF.
Błąd budżetowy i szybkość spalania określają priorytetowe i eskalacyjne okna.

2) Poziomy dotkliwości (SEV) i kryteria

Wyzwalacze SEV: powyżej 5xx%, p95> próg, skok spadku płatności, Kafka-lag> próg, NodeNotReady> X min, TLS wygasa <7 dni, sygnały DDoS/wyciek.

3) Role i obowiązki (RACI)

Komunikacja Lead (Comms) - Aktualizacje stanu (wewnętrzny/zewnętrzny),

Dowódca incydentu (IC) - wyłączne podejmowanie decyzji, zarządzanie przepływem zadań, zmiana statusu SEV.
Ops Lead (Tech Lead) - strategia techniczna, hipotezy, koordynacja poprawek.
Scribe (Chronicler) - linia czasu, rozwiązania, artefakty, linki do wykresów/dzienników.
Dyżurni inżynierowie/MŚP - realizacja działań w ramach playbook.
Bezpieczeństwo/Prywatność - Włączone dla bezpieczeństwa lub incydentów PII.
FinOps/Payments - przy wpływaniu na rozliczenie/PSP/koszt.

4) Cykl życia incydentu

1. Wykrywanie (alert/report/synthetic) → automatyczne tworzenie karty incydentu.
2. Triage (przypisany IC, przypisany SEV, minimalny zbiór kontekstu).
3. Stabilizacja (łagodzenie: wyłączyć funkcję/rollback/rate-limit/failover).
4. Dochodzenie (hipotezy RCA, zbiór faktów).
5. Odzyskiwanie usług (potwierdzenie SLO, obserwacja).
6. Komunikat (wewnętrzny/zewnętrzny, sprawozdanie końcowe).
7. Postmortem (bez opłat, plan CAPA, właściciele, terminy).
8. Zapobieganie (testy/wpisy/playbooks/flagi, dodatkowe szkolenie zespołu).

5) Komunikacja i „pokój wojenny”

Jednolity kanał incydentu ('# inc-sev1-YYYYMMDD-hhmm'), tylko fakty i działania.

Styl protokołu radiowego poleca: "IC: Przypisuję wersję rollback 1. 24 → ETA 10 min"

Aktualizacje stanu: SEV-1 co 15 minut, SEV-2 co 30-60 minut.
Status Strona/komunikacja zewnętrzna - za pośrednictwem komunikatora Prowadź według szablonu.
Zabronione: równoległe „ciche” pokoje, niewyjaśnione hipotezy do wspólnego kanału.

6) Ostrzeganie i spalanie SLO (przykładowe zasady)

Szybki kanał (1-5 min) i wolny kanał (1-2 h) szybkość spalania.
Wiele sygnałów: błąd budżetowy, 5xx%, p95, Kafka-lag, wskaźnik spadku płatności, syntetyka.
Szukaj przyczyny korzenia - tylko po ustabilizowaniu objawów.

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) Playbooks vs ranbooks

Playbook - scenariusz działań według rodzaju incydentu (rozgałęzienie, warunki, ryzyko).
Runbook - konkretna „mapa” kroków/poleceń (czeki, poprawki, weryfikacja).
Zasada: odtwarzanie odnosi się do kilku książek startowych (rollbacks, feature-flags, failover, skalowanie, blokowanie ruchu itp.).

8) Szablon karty incydentu

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) Szablon odtwarzania SRE (Markdown)

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

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

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

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

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

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

10) Typowe playbooks

10. 1 API 5xx Spike

Stabilizacja: wyłączyć problematyczne ficheflag; Zwiększ repliki API Włącz buforowanie walcowanie z powrotem wydania.
Diagnostyka: diff release, błędy w dziennikach (top-wyjątki), wzrost p95, ciśnienie DB/cache.
Ryzyko: kaskada w płatnościach/backendach.

10. 2 СИ: replikacja lag/lock storm

Stabilizacja: zawieszenie ciężkich miejsc pracy/sprawozdań; przekierowanie odczytuje do kreatora zwiększenie wal_buffers/replika-sloty.
Diagnostyka: długie transakcje, blokowanie żądań, planowanie zmian.
Utrwalenie: indeksy/wskazówki, przebudowa zadań, podzielone zapytania.

10. 3 Kafka opóźnienie konsumenckie

Stabilizacja: konsumenci czasowo skalowani; ograniczenie produkcji z usług innych niż krytyczne; zwiększenie partii/kwot.
Diagnostyka: przywrócenia równowagi, powolne deserializacje, pauzy GC.
Weryfikacja: lag → do wartości docelowej, bez spadków.

10. 4 K8s NodeNotReady/burza zasobów

Stabilizacja: kordon + drenaż; obciążenia redystrybucji; Sprawdź CNI/nakładka wyłączyć hałaśliwe DaemonSets.
Diagnostyka: ciśnienie dysku, OOM, dławienie, krople do sieci.
Zapobieganie: budżety zakłóceń, limity zasobów/żądania.

10. 5 TLS/certyfikaty wygasają

Stabilizacja: wymuszona aktualizacja tajemnicy/ingress; tymczasowe przekroczenie.
Diagnostyka: łańcuch zaufania, zegar-skew.
Zapobieganie: alerty T-30/T-7/T-1, auto-rental.

10. 6 DDoS/nieprawidłowy ruch

Stabilizacja: zasady WAF/bot, tempo-limit/geo-filtry, obciążenie przed strumieniem.
Diagnostyka: profile ataku (L3/4/7), źródła, parasole.
Zapobieganie: anycast, autoskalowanie, buforowanie, zabawa-miło z dostawcami.

10. 7 Płatność PSP-przerwa

Stabilizacja: inteligentna droga do alternatywnych metod/PSP; podnieść retry z jitter; „miękka” degradacja UI.
Diagnostyka: awarie kolca według kodów, statusy API/strony stanu PSP.
Komunikacja: przejrzyste aktualizacje dla biznesu i wsparcia, poprawne statystyki ND/konwersji.

10. 8 Incydent bezpieczeństwa/wyciek PII

Stabilizacja: izolacja węzłów/tajna rotacja, blokowanie eksfiltracji, blokada prawna.
Diagnostyka: terminy dostępu, dotknięte tematy/pola.
Ogłoszenia: Regulatorzy/Partnerzy/Użytkownicy według wymagań jurysdykcyjnych.
Zapobieganie: wzmocnienie DLP/segmentacji, „najmniejszy przywilej”.

11) Automatyzacja odtwarzaczy

Polecenia ChatOps: '/ic set sev 1 ', '/deploy rollback api 1. 23. 4 ', '/funkcja off X'.
Runbook-bots: półautomatyczne kroki (węzeł spustowy, ruch zwrotny, pamięć podręczna oczyszczania).
Samouzdrawiające haczyki: detektor → standardowe łagodzenie (ograniczenie szybkości, ponowne uruchomienie, skala).
Automatyczne tworzenie kart/linii czasowych z wpisów i poleceń.

12) Jakość Playbook: lista kontrolna

• Wyraźne objawy i detektory (mierniki/kłody/ślady).
• Szybkie etapy stabilizacji wraz z oceną ryzyka.
• Polecenia/skrypty są aktualne, sprawdzane w stacji.
• Weryfikacja odzysku SLO.
• Szablony komunikacyjne i zewnętrzne kryteria aktualizacji.
• Odniesienie pośmiertne i CAPA po zamknięciu.

13) Postmortem (nienaganny) i CAPA

Cel: nauczyć się, a nie znaleźć winowajcę.
Treść: co się stało, co okazało się dobre/złe, wkład czynników (te + procesy), działania zapobiegające.
Termin: SEV-1 - w ciągu 48 godzin; SEV-2 - 3 dni robocze.
CAPA: konkretni właściciele, terminy, wymierne efekty (zmniejszenie MTTR/zwiększenie MTTD).

14) Aspekty prawne i podstawa dowodowa

Blokada prawna: zamrażanie kłód/utworów/wpisów, zapisywanie raz przechowywania.
Łańcuch przechowywania artefaktów: dostęp według roli, kontrola integralności.
Ogłoszenia regulacyjne: harmonogramy/szablony dla jurysdykcji (szczególnie w przypadku płatności dotkniętych problemem/PII).
Prywatność: minimalizacja PII i maskowanie podczas parsowania.

15) Incydent Process Performance Metrics

MTTD/MTTA/MTTR według kwartałów i domeny.
Dokładność SEV (niedoszacowanie/przereklamowanie).
Udział zdarzeń łagodzących auto.
Pokrycie Playbook najlepszych scenariuszy N (> 90%).
Wykonać CAPA na czas.

16) Realizacja w podziale na etapy

1. Tydzień 1: matryca SEV, role dyżuru, szablon karty ogólnej, regulamin pokoju wojennego.
2. Tydzień 2: Playbooks dla 5 najlepszych objawów (5xx, DB lag, Kafka-lag, NodeNotReady, TLS).
3. Tydzień 3: ChatOps/boty, automatyczne tworzenie kart, szablony komunikacyjne/Page.

4. Tydzień 4 +: Playbooks bezpieczeństwa, Przerwa PSP, Prawna blokada, Regularne wiertła/Gry chaosu

17) Przykłady „szybkich” ranbooków (fragmenty)

Rollback 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

Węzeł drenarski

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

Funkcja-flag OFF (przykład)

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

18) Mini-FAQ

Kiedy podnieść SEV-1?
Gdy klucz SLO/funkcja biznesowa (płatności, login, gra) cierpi, a tempo spalania „zjada” budżet na godziny przed.

Co jest ważniejsze - RCA lub odzysku?
Zawsze stabilizacja, potem RCA. Czas do stabilizacji jest głównym wskaźnikiem.

Czy muszę wszystko zautomatyzować?
Automatyzuj częste i bezpieczne kroki; rzadkie/ryzykowne - poprzez potwierdzenie półautomatyczne i IC.

Wynik

Solidny proces incydentu opiera się na trzech filarach: jasnych ról i zasad SEV, wysokiej jakości playbooks/ranbooks z automatyzacją, i kultury pośmiertnej bez winy. Przechwytywanie wzorów, dyżur pociągu, pomiar MTTR/błędny budżet, i stale poprawiać detektory i playbooks - to bezpośrednio zmniejsza ryzyko i koszt przestojów.