Reagowanie na incydenty

Eskalacja, która działa, aż ktoś potwierdzi

Użyj WardenPoint jako warstwy alertowania w Twoim procesie reagowania na incydenty. Potwierdzenie zamyka łańcuch; resolve hooki go anulują; dziennik audytu zasila Twój post-mortem. Ciche godziny i drzemka szanują czas dyżurnego bez blokowania P1 — krytyczny priorytet zawsze omija.

Zacznij za darmo Porozmawiaj z lead'em incydentów
Świadomy potwierdzeń Wielokanałowy łańcuch Oś czasu gotowa na audyt

Oś czasu incydentu

  1. 00:00
    Źródło
    Sentry critical error · ChargeFailedException spike
  2. 00:02
    WardenPoint
    Telegram + głos do dyżurującego dowódcy incydentu
  3. 00:07
    Commander
    Acks · uruchamia centrum operacyjne · zespół ds. płatności
  4. 00:18
    Źródło
    Resolve hook · WardenPoint anuluje chain · audit zamyka

Gdzie boli IR

Ból reagowania na incydenty — i co zmieniamy

Trzy zarzuty od lead'ów reagowania na incydenty o ich obecnej warstwie alertowania.

Zmęczenie alertami tępi sygnał

Krytyczne alerty mieszają się z głośnymi warningami. Dyżurni przestają im ufać; SLA cierpi.

Fix

Tylko severity=critical pali głos. Severity to kontrakt, nie sugestia.

Brak strukturalnej osi czasu

Autorzy post-mortem zszywają scrollbacki Slacka, eksporty PagerDuty i wątki mailowe.

Fix

Jeden dziennik audytu na UUID incydentu. Każda wysyłka, potwierdzenie i resolve to jedna linia obok.

Luki w hand-off

Gdy dyżurny przekazuje incydent specjaliście, alerty wciąż budzą złą osobę.

Fix

Ręczne potwierdzenie przerywa łańcuch; nowy łańcuch startuje do nowego odbiorcy. Żadnych zalegających retry.

Polityka eskalacji

Przepis: eskalacja dowódcy incydentu

Dla zespołów z rolą Dowódca incydentu. Łańcuch zaczyna głośno i robi się głośniejszy, ale zatrzymuje się gdy ktoś przejmuje ownership.

  1. 1
    W minucie
    0:00

    Primary IC przez głos + Telegram

    Którykolwiek IC jest na rotacji dostaje call i Telegram message jednocześnie.

    voice_calltelegram_voice
  2. 2
    W minucie
    0:03

    Backup IC przez głos

    Jeśli brak potwierdzenia, zapasowy IC dostaje wezwanie. E-mail ląduje na kanale war-room.

    voice_callemail
  3. 3
    W minucie
    0:08

    Wybudź managera

    Manager inżynierów dostaje call. W tej minucie sytuacja ma oczywiste implikacje obsadowe.

    voice_call
  4. 4
    W minucie
    0:15

    Wezwij dyżurnego dyrektora

    Ostatnia deska ratunku. Rzadko wyzwalane; testowane kwartalnie przez 'Wyślij test'.

    voice_calltelegram_voicesms

Źródła incydentów

Skąd przychodzą incydenty

Zespoły IR muszą przyjmować sygnały zewsząd — monitoring, error tracking, uptime, business metrics.

Grafana
Metryki + logi
Sentry
Błędy aplikacji
Prometheus
Alertmanager
Uptime Kuma
Uptime endpointów
Webhooks
Wykrywanie anomalii

Co się zmieni

Co zespoły IR raportują

Szybsze potwierdzenia

Wysyłanie wiadomości przede wszystkim na telefony do wąskiej grupy wyznaczonych odbiorców skraca czas między wysłaniem wiadomości „alert” a potwierdzeniem odbioru.

Auditowalna oś czasu

Post-mortemy ciągną strukturalny dziennik audytu bezpośrednio. Bez archeologii „kto i kiedy dostał wezwanie”.

Łańcuch zatrzymuje się czysto

Potwierdzenie jest kanoniczne. Bez dwóch dyżurnych przekonanych, że wciąż są na haku.

FAQ IR

Pytania incident-response

Każdy incydent ma swój UUID i swój łańcuch eskalacji. Potwierdzenie jednego nie wpływa na inne. Odbiorcy widzą odrębne alerty.
Plan darmowy

Wypróbuj łańcuch, który zatrzymuje się, gdy ktoś przejmie incydent

Podłącz przykładową politykę, odpal test z curl i obserwuj, jak oś czasu audytu renderuje się w czasie rzeczywistym.

Zacznij za darmo Porozmawiaj z lead'em incydentów
  • Potwierdzenie anuluje łańcuch
  • Auditowalna oś czasu
  • Czyste przekazania zmian