Zarządzanie incydentami

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Zarządzanie incydentami jest powtarzalnym procesem umożliwiającym szybkie przywrócenie wartości użytkownika i zminimalizowanie szkód biznesowych. Wsparcie - wyraźne role (Incident Manager, Tech Lead, Comms), bramy SLO, eskalacje, procesy ChatOps, przygotowane runabooks i „nieszkodliwe” po incydencie parsing z wymiernych elementów działania.

1) Cele i zasady

Szybkość i bezpieczeństwo: szybka diagnoza → bezpieczna stabilizacja → trwałe odzyskiwanie.
Wyłączny właściciel - wyznaczony menedżer incydentów (IM) podejmuje decyzje procesowe.
Komunikacja jako produkt: przewidywalne aktualizacje dla zainteresowanych stron i użytkowników.
Dane> opinie: SLO/metrics/trails/logs są źródłem prawdy.
Bez winy: analiza przyczyn bez osobistych oskarżeń; skupić się na ulepszeniach systemu.

2) Klasyfikacja incydentów (dotkliwość/wpływ/pilność)

• SEV1 (krytyczne): poważne szkody w dochodach/TTW/płatnościach,> 20% użytkowników lub całych regionów; Zagrożenie SLA/PII.
• SEV2 (wysoki): częściowa degradacja przepływów kluczowych (depozyt/zakład/uruchomienie gier), wpływ 5-20%.
• SEV3 (medium): zauważalna degradacja usług wtórnych, istnieje obwodnica.
• SEV4 (niski): niewielki, ograniczony efekt, brak wpływu na SLO/SLA.

Wpływ: kto jest dotknięty (all/region/najemca/kanał). Pilność: wskaźnik degradacji (szybkie spalanie/powolne spalanie w budżecie na błędy).

3) Cykl życia incydentu

1. Wykrywanie - sygnał z wpisów/SLO/syntetyki/raportów.
2. Potwierdzenie - dyżur potwierdza odbiór, przypisuje IM.
3. Triage - wynik SEV/Impact, kolekcja hipotez, odkrycie pokoju wojennego.
4. Złagodzenie - stabilizacja (wałek/przełączanie trasy/ficheflagi/skalowanie).
5. Komunikacja - regularne aktualizacje stanu (wewnątrz/na zewnątrz).
6. Odzyskaj - Full SLO/business metrics recovery.
7. Close - nagrywanie chronologii, kolekcja artefaktów, PIR (RCA + pozycje akcji).

4) Role i obowiązki (RACI)

Menedżer incydentu (IM) - właściciel procesu, przypisuje role, monitoruje czas, podejmuje decyzje procesowe (R).
Ołów techniczny (TL) - prowadzi diagnostykę/hipotezy/poprawki, inżynierów współrzędnych (A/R).
Komunikacja (Komunikaty) - aktualizacje stanu, połączenie z obsługą/biznesem/PR, strona stanu (R).
Skryba - protokół (linia czasowa, podejmowane decyzje, linki, artefakty) (R).
Zainteresowane strony - Produkty/Płatności/Dostawcy gier/Bezpieczeństwo (C/I).

Minimum na SEV1: IM + TL + Comms + Scribe. Dopuszcza się łączenie ról na SEV2.

5) Pokój wojenny - ChatOps

Poszczególne kanały: '# incident-warroom- <id>' (działa), '# incident-status' (tylko aktualizacje).
Polecenia szablonu: '/incydent start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot wyciąga kontekst: ostatnie wydania, deski rozdzielcze, powiązane wpisy, przykłady śladów, systemy zależności.
Zasady komunikacji: krótko, na fakty, jeden głośnik (TL), IM umiarkowanych.

6) Spusty i bramy

Bramki SLO: szybkie/powolne oparzenie, spadek konwersji płatności, TTW p95> próg, p99 API, kolejki płatności są w ogniu.
Akcje automatyczne: stop canary, rollback, włączając tryb degradacji (funkcje ograniczające), umożliwiając syntetykę wysokiej częstotliwości.
Zamrożenie: wszystkie zwolnienia/migracje stopy przed stabilizacją i PIR.

7) Typowe scenariusze (wzory runabook)

A) Płatności: zwiększenie terminów/niepowodzeń w PSP

1. Zatrzymaj promocję i zamrażaj wersje pętli płatności.
2. Przełącz trasę PSP na tryb czuwania, podnieś harmonogram/przekwalifikowanie według zasad.
3. Uzgodnienie niekompletnych transakcji, powtarzanie z kluczem idempotentnym.
4. Komunikacja komunikacyjna → wsparcie: czy pracujesz w rezerwie? ETA.

B) API p99 i 5xx po zwolnieniu

1. Rollback (niebiesko-zielony/kanaryjski → stabilny).
2. Sprawdź hit pamięci podręcznej, głębokość kolejki, bazę danych/hotspoty dostawcy gier.
3. Tymczasowe skalowanie, ograniczanie ciężkich funkcji poprzez flagi funkcji.

C) Dostawca gier niedostępny

1. Przełącz ruch na dostępne studia/gry, pokaż baner stanu.
2. Włączać syntetyczne kontrole co 30-60 s.
3. Uzgodnij rekompensatę/premie (według zasad) - dodaj do PIR.

D) Wyciek/podejrzenie PII

1. Izolacja komponentów, odwołanie klucza/tokena, zbieranie dzienników (WORM).
2. Komunikacja prawna/dostosowanie przepisów.
3. Działania powypadkowe: tajny obrót, maskowanie, dostęp.

8) Komunikacja (wewnętrzna/zewnętrzna)

Częstotliwość aktualizacji: SEV1 - co 15-30 minut, SEV2 - 30-60 minut.

• Co jest złamane: „Depozyty za pośrednictwem PSP-X: Wzrost czasu”.
• Dotyczy: „TR/BR, ~ 18% użytkowników strumienia”.
• Kiedy to się zaczęło: „12:07 EET, SEV1.”
• Co robimy: „Zmiana trasy na PSP-Y, retrayes/rate cap enabled”.
• Następna aktualizacja: „za 20 minut”.
• Kontakt: „IM @ duty-im, TL @ oncall-pay”.

Status publiczny (strony/sieci społecznościowe) - skrót, bez PII i niepotrzebnych szczegółów, z ETA i link do dalszych aktualizacji.

9) Zbieranie i audyt artefaktów

Linia czasu zdarzeń (dokładność minuty), wersje serwisowe, flagi funkcji, zmiany konfiguracyjne.
Zdjęcia desek rozdzielczych, przybliżone trasy (trace_id), dzienniki „przed/podczas/po”.
Linki do biletów, PR, wydania, runabooks.
Raport komunikacyjny (kiedy/do/co).
Wszystko pasuje do karty incydentu.

10) Zamknięcie i PIR (przegląd po incydencie)

• Podsumowanie: co się stało, skala, czas trwania, SEV.
• Wpływ: użytkownicy/regiony, SLO/SLA, efekt Fin.
• Linia czasu: szczegółowo, za minutę.
• Przyczyna korzenia: techniczna + organizacyjna (dlaczego nie wykryto wcześniej).
• Wykrywanie i obrona: co pomogło/nie powiodło się (alerty, syntetyka, ficheflagi).
• Pozycje działania: konkretne zadania, właściciele, terminy (i jak sprawdzić efekt).
• Wyciągnięte wnioski: Co zmieniamy w procesie/architekturze/obserwowalności.

Zasady: bez opłat, maksymalne fakty, obowiązkowe działania następcze po 2-4 tygodniach sprawdzania wypełnionych przedmiotów.

11) Metryki niezawodności procesu

MTTD - średni czas do wykrycia

MTTA (... Potwierdzenie) - przed potwierdzeniem dyżuru.
MTTR (... Przywracanie) - do czasu przywrócenia SLO.
Zmiana współczynnika awarii -% zwolnień powodujących incydenty.
Wskaźnik incydentów według SEV, dystrybucja według domeny (Płatności/Gry/Infra).
Jakość alertu: Proporcja hałasu/fałszywego, czas do działania po wpisie.
Comm-SLA: zgodność z częstotliwością aktualizacji stanu.

12) Integracja z SLO i wydania

Bramki w CD: promocja kanaryjska tylko z zielonymi proxami SLO (dostępność, p95, conv, TTW).
Zamrażanie procedur: po fast-burn/SEV1 - zatrzymanie zwolnień przed PIR.
Automatyczne adnotacje na wykresach: wydania/flagi/migracje są widoczne na deskach rozdzielczych.

13) Regulacja i zgodność

PII: maskowanie/aliasing w logach/torach, sklepach audytu WORM, kontrola dostępu.
Regionalność: Nie bierz danych użytkowników poza dozwolone jurysdykcje.
Raportowanie: sformalizowane listy/powiadomienia dla regulatorów - szablony i proces eskalacji.

14) Nauka i gotowość (dzień gry)

Ćwiczenia kwartalne: „PSP drop”, „dostawca gier niedostępny”, „p99 surge”, „key leak”.
Zegary na MTTA/MTTR, retro na ćwiczenia.
Aktualizacja runabooks i kontaktów, sprawdzanie poleceń ChatOps.

15) Lista kontrolna gotowości (przed incydentem)

1. Uzgodniono zasady SEV i matrycę eskalacji.
2. Przypisane rotacje dyżurów, IM/TL/Comms/Scribe.
3. Runabooks dla kluczowych scenariuszy (płatności, gry, bazy danych, bufory, kolejki).
4. Karta SLO i nagrywane wpisy, strona stanu.
5. Bot ChatOps: polecenia, auto-kontekst, szablony stanu.
6. Szablony PIR i karty incydentów.
7. Regularne zmiany w dzień gry i kontakt/prawa.
8. Zamrażanie zasad i „czerwony przycisk” (rollback/kill-switch).

16) Antypattery

Nie ma pojedynczego IM, „tłum prowadzi” → chaos i opóźnienia.
Brak bram SLO → późne wykrywanie, hałaśliwe wpisy.
Zwolnienie podczas incydentu bez zamrażania → wypadki kaskadowe.
Kłody i szlaki nie wystarczy, nie ma artefaktów → słaby PIR.
Kultura oskarżycielska → ukryte błędy, strach przed eskalacją.
Inspirująca komunikacja → utrata zaufania biznesu/użytkownika.

17) Szablony (kopia do wiki)

A) Karta incydentu (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Aktualizacja stanu (wewnętrzna)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (cap)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Podsumowanie

Silne zarządzanie incydentami to struktura + dyscyplina: wstępnie uzgodnione role, bramy SLO, pracowite runabooks, przejrzysta komunikacja i „nieszkodliwe” PIR. Ta pętla zmniejsza MTTA/MTTR, obniża koszty przestojów, buduje zaufanie użytkowników i pozwala na odważniejsze - ale bezpieczne.