Wzorce polityk eskalacji: 5 szablonów dla typowych incydentów

Zacznę od podsumowania, do którego dochodzimy zwykle pod koniec konsultacji z nowymi klientami. Pięć szablonów polityk eskalacji, każdy w formie YAML, gotowe do skopiowania. Bez wprowadzenia, bez kontekstu. Jeśli wiecie, co robicie, kopiujcie i dostosowujcie. Wyjaśnienie każdego — niżej.

# 1. Ostrzeżenie po wdrożeniu
trigger: deploy_warning
chain:
  - target: deployer
    channels: [telegram, slack]
    delay: 0m
  - target: primary_oncall
    channels: [telegram, sms]
    delay: 15m
quiet_hours:
  respect: true

# 2. Awaria widoczna dla klientów
trigger: p1_outage
chain:
  - target: primary_oncall
    channels: [telegram_voip, sms, pstn]
    delay: 0m
  - target: primary_oncall          # powtórzenie tego samego głównego
    channels: [telegram_voip, sms, pstn]
    delay: 2m
  - target: secondary_oncall
    channels: [telegram_voip, sms, pstn]
    delay: 5m
  - target: engineering_manager
    channels: [pstn, sms]
    delay: 10m
quiet_hours:
  ignore: true

# 3. Alarm bezpieczeństwa
trigger: security_alert
chain:
  - target: security_oncall
    channels: [telegram_voip, sms]
    delay: 0m
    require_ack_from: security_oncall
  - target: security_team_channel    # równolegle, bez ack
    channels: [slack]
    delay: 0m
    parallel: true
  - target: ciso
    channels: [sms, telegram]
    delay: 5m
    parallel: true
quiet_hours:
  ignore: true

# 4. Awaria nocnego zadania wsadowego
trigger: batch_job_failure
chain:
  - target: data_team_channel
    channels: [slack, email]
    delay: 0m
  - target: data_engineering_lead
    channels: [telegram, sms]
    delay: 4h
business_hours:
  defer: true
  window: "08:00-18:00 Europe/Warsaw"

# 5. Miękki sygnał (głębokość kolejki, dysk itd.)
trigger: soft_warning
chain:
  - target: ops_channel
    channels: [slack]
    delay: 0m
  - target: primary_oncall
    channels: [telegram]
    delay: 30m
business_hours:
  defer: true
  window: "09:00-18:00 Europe/Warsaw"
  days: [mon, tue, wed, thu, fri]

Dalej — wyjaśnienie każdego, w kolejności od najbardziej kontrowersyjnego.

Drugie wezwanie głównego dyżurnego — i statystyka, która ratuje zapasowego

Drugi szablon, ten dla awarii produkcji, ma w sobie krok, na który zazwyczaj nikt nie wpada bez własnej awarii. Dwie minuty po pierwszej próbie wezwania głównego dyżurnego — drugie wezwanie, do tej samej osoby. Dopiero potem, na piątej minucie, do zapasowego.

Statystyka, którą zmierzyliśmy na własnym łańcuchu za półtora roku: główny dyżurny odpowiada na drugie wezwanie w 41% przypadków, gdy przegapił pierwsze. Czyli prawie połowa «pominiętych» pierwszych prób kończy się sukcesem dwie minuty później. Człowiek pod prysznicem, telefon w kuchni, dwie minuty wystarczy. Sześć minut to już sporo na incydent, ale wciąż mniej, niż zwykła obróbka «budź zapasowego, on przybiegnie».

Przejście od razu do zapasowego byłoby tańsze obliczeniowo — jeden link w łańcuchu zamiast dwóch — ale kosztowniejsze ludzko. Zapasowy ma życie. Jego małżonek śpi obok. Każde niepotrzebne wybudzenie zapasowego dyżurnego deformuje jego stosunek do roli — a zapasowy demoralizuje się szybciej niż główny, bo «teoretycznie nie miałem chodzić w nocy».

Autor wdrożenia jako pierwsza linia obrony po ostrzeżeniu

Konkretny przypadek z tej kategorii: piątek, 23:40. Ktoś wepchnął zmianę w integrację z bramką płatniczą. Częstość błędów od razu wzrosła dwukrotnie. Sergiusz, aktualny dyżurny, budzi się, otwiera dziennik zmian, widzi tuzin zmian z ostatnich sześciu godzin. Czterdzieści minut próbuje zrozumieć, co dokładnie się zmieniło. W końcu dzwoni do Ilyi, autora wdrożenia, ten w osiem minut wycofuje zmianę. Sergiusz nie spał do rana. Ilya mógłby zrobić to samo, gdyby pierwszy sygnał przyszedł do niego.

Stąd pierwszy szablon kieruje powiadomienie do autora wdrożenia, nie do dyżurnego. Logika: ten, kto napisał kod, wie, co zmienił. Dyżurny zaczyna od zera. Piętnaście minut to taryfa, w której autor zwykle może otworzyć swój kod, porównać z ostatnimi zmianami i podać rekomendację — wycofać, przeczekać, eskalować.

Jeśli autor nie odpowie w 15 minut, sygnał idzie do głównego dyżurnego, ale do tego momentu zwykle nie dochodzi. W przypadku trzech klientów, u których stosujemy ten szablon od roku, dyżurny otrzymał ostrzeżenie z tego łańcucha trzy razy. Trzy razy w roku, nie dziennie. Dyżurnym zostaje czas na poważne sprawy.

Godziny ciszy są respektowane. Ostrzeżenie to nie awaria — jeśli sytuacja eskaluje, włączy się drugi szablon, i ten nie pyta o porę dnia.

Bezpieczeństwo: jeden potwierdza, reszta zespołu widzi w czasie rzeczywistym

Trzeci szablon ma w sobie nietypowy element — kanał zespołu bezpieczeństwa otrzymuje powiadomienie równolegle z dyżurnym, bez wymogu potwierdzenia. Większość zespołów konfiguruje to inaczej: wszyscy budzeni, wszyscy potwierdzają. Wynik — chaos, dwie osoby grzebią w tym samym dzienniku audytu.

Druga skrajność, równie częsta: wzywany tylko dyżurny. Reszta zespołu dowiaduje się rano. Dyrektor bezpieczeństwa wchodzi w poniedziałek do biura, widzi otwarty incydent z sześciogodzinną luką w kontekście, i zaczyna swój tydzień nie od decyzji, lecz od odtwarzania, co się stało.

Powiadomienie równoległe bez wymogu potwierdzenia rozwiązuje obie sytuacje. Dyżurny musi reagować, ma na sobie odpowiedzialność. Reszta zespołu dostaje pełen kontekst w czasie rzeczywistym, ale bez presji odpowiedzi. Analiza po incydencie w poniedziałek przestaje być archeologią — jest pełen ślad w kanale.

Nocne zadania wsadowe i ekonomia napiętego ranka

Czwarty szablon to pierwsza rzecz, którą wprowadzam u każdego nowego klienta. Powiadomienie o awarii nocnej obróbki danych idzie w kanał zespołu i na e-mail, ale faktyczne wezwanie do człowieka — dopiero po starcie dnia.

Powód jest prosty i statystyczny. Inżynierowi wybudzonemu o 03:14 grozi jedna z dwóch rzeczy. Albo zrobi nocną naprawę, która rano okaże się błędna, i będzie ją powtarzał — wtedy ma sześć godzin szumu i jedną bezsenną noc na sumieniu. Albo zrobi nocną naprawę, która zadziała, ale kolejne dwa tygodnie pamięta, że firma uznała wadliwy graf w Airflowie za sprawę godną wybudzenia. Po pół roku takich nocy odchodzi.

Jedyną rzeczą, której nie chcemy w tej konfiguracji, jest brak ścieżki podniesienia priorytetu, gdy sprawa jest naprawdę pilna. Stąd kanał zespołu jako pierwszy krok — ktoś z innej strefy czasowej, ktoś, kto jeszcze nie zasnął, ktoś dyżurny w innym narzędziu — może promować incydent do drugiego szablonu, i wtedy obowiązują inne reguły.

Miękkie sygnały — Slack, godziny pracy, żadnego telefonu nocą

Piąty szablon obsługuje kategorię, która w wielu zespołach jest największym źródłem niezasłużonego budzenia. Głębokość kolejki rośnie, dziennik powolnych zapytań się zapełnia, dysk na 70%. Nic nie pada, nikt nie cierpi, ale sygnał powinien gdzieś się pojawić.

Klasyczna konfiguracja podsyła te alarmy normalną ścieżką eskalacji, w wyniku czego dyżurny budzi się o 03:00 dla dysku na 70%, sprawdza w panelu, mówi «dobra, jutro», i wraca do łóżka. Po piątym takim wezwaniu przestaje ufać całemu narzędziu powiadomień. Wszystko, co przychodzi przez Telegrama o 03:00, dla niego jest «pewnie znowu szum».

Slack jako pierwszy krok, eskalacja telefoniczna tylko po 30 minutach braku reakcji, ograniczenie do godzin pracy. Konfiguracja, która zmienia kategorię z «budź mnie dla szumu» w «spokojny sygnał, który dostaje uwagę w trakcie pracy».

Pierwsza rzecz, którą sprawdzam u nowych klientów: ile mają polityk eskalacji w obecnym narzędziu. Jeśli odpowiedź to «jedna», migracja zaczyna się od rozdzielenia na pięć. Jeśli odpowiedź to «szesnaście», migracja zaczyna się od scalenia w pięć. Liczba między tymi dwoma rzadko zdarza się przypadkowo — zwykle oznacza, że ktoś już raz przeszedł przez to ćwiczenie i wie, gdzie jest sens.