Шаблони політик ескалації: 5 зразків для типових інцидентів

Чотириста тисяч гривень. Стільки втратила одна команда, з якою я працював минулого року, через сорок хвилин затримки в ескалаційному ланцюжку під час недільної аварії платіжного шлюзу. Не через помилку інженера. Через те, що політика ескалації в їхньому інструменті була одна на всі випадки життя — той самий ланцюжок для аварії, для попередження після релізу, для нічної помилки пакетної обробки даних.

Цей текст — про те, чому в проді ми тримаємо пʼять окремих ланцюжків замість одного, і чому кожен із них розвʼязує власну задачу. Нижче — пʼять випадків, у яких універсальний «розмір — на всіх» ланцюжок завдав би більше шкоди, ніж користі.

Виклик до автора релізу, а не до чергового

Сценарій: пʼятниця, 23:40. Хтось вкотив зміну в інтеграцію з платіжним сервісом. Частота помилок одразу зросла вдвічі. Сергій, нинішній черговий, прокидається, відкриває журнал змін, бачить десяток коммітів за останні шість годин. Сорок хвилин намагається зрозуміти, що саме змінилось. Урешті дзвонить Іллі, автору релізу, той за вісім хвилин відкочує зміну.

Сергій спав не до ранку.

Те саме повторилося в інший спосіб через тиждень — Сергій уже відмовлявся приймати нічні виклики. Ілля міг би зробити те саме, якби йому одразу прийшло сповіщення. Він знав, що змінив.

Рішення. Перший крок ескалації йде до автора релізу, не до чергового. Якщо автор не реагує за 15 хвилин — переходить до чергового. У трьох наших клієнтів за рік цей ланцюжок жодного разу не дійшов до чергового. Автор реагує сам.

trigger: deploy_warning
chain:
  - target: deployer
    channels: [telegram, slack]
    delay: 0m
  - target: primary_oncall
    channels: [telegram, sms]
    delay: 15m
quiet_hours:
  respect: true

Повторний виклик того самого чергового через дві хвилини

Це перше, що ставлять під сумнів нові керівники інженерії, які бачать наш ланцюжок для аварій. Чому б одразу не йти до резервного, навіщо турбувати ту саму людину двічі? Логіка не очевидна, поки не побачиш статистику.

На власному ланцюжку за вісімнадцять місяців основний черговий відповідає на повторний виклик у сорока одному відсотку випадків, коли проґавив перший. Майже половина. Причини банальні — телефон у ванні, людина в кінотеатрі, дзвінок перейшов у голосову пошту, особисті обставини.

Якби ми переходили одразу до резервного, у сорока одному відсотку випадків будили б двох людей замість одного. У резервного теж сімʼя, теж робочий тиждень. Кожне зайве пробудження резервного руйнує його ставлення до цієї ролі — а резервні деморалізуються швидше за основних, бо «теоретично не мав чергувати вночі».

trigger: p1_outage
chain:
  - target: primary_oncall
    channels: [telegram_voip, sms, pstn]
    delay: 0m
  - target: primary_oncall          # повтор того самого
    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

Безпековий тригер: один підтверджує, троє бачать у режимі контексту

Якщо ви хоч раз бачили, як шість інженерів одночасно намагаються розібратися в одному й тому ж журналі аудиту, ви знаєте, чому так робити не варто. Це не координація, це безлад: троє паралельно лізуть у дані, двоє висувають конкуруючі гіпотези, ніхто не приймає рішення.

Зворотна крайність гірша. Будити одного безпекового чергового, а решту команди тримати в темряві до понеділка — означає, що директор з ІБ почне тиждень з відновлення таймлайну замість прийняття рішення.

Робочий компроміс — гібрид. Безпековий черговий отримує виклик з вимогою підтвердження. Решта команди безпеки і директор з ІБ отримують паралельне сповіщення без вимоги підтвердження — для контексту, не для будіння. У понеділок розбір не починається з нуля: повний слід дій чергового лежить у каналі команди.

trigger: security_alert
chain:
  - target: security_oncall
    channels: [telegram_voip, sms]
    delay: 0m
    require_ack_from: security_oncall
  - target: security_team_channel
    channels: [slack]
    delay: 0m
    parallel: true
  - target: ciso
    channels: [sms, telegram]
    delay: 5m
    parallel: true
quiet_hours:
  ignore: true

Чому пакетне завдання чекає до ранку

Коротка причина: бо нічний ремонт, зроблений напівпритомним інженером, у девʼяноста відсотках випадків виявляється помилковим, і його доводиться переробляти зранку.

Я бачив це багато разів. Інженер прокидається о 03:14, перезапускає задачу, засипає о 04:30. О 11:00 виявляє, що перезапуск стартував із того самого стану, що й помилкова попередня спроба — фікс був помилковий. Робить правильно об 11:30. Підсумок — одна безсонна ніч і шість годин шумного руху замість одного спокійного рішення на свіжу голову.

Ефективна конфігурація: сповіщення в канал команди й на пошту відразу. Реальний виклик до чергового — тільки на початок робочого дня. Один параметр у конфігурації — defer: true — перетворює викликану з ліжка людину в спокійний ранковий комунікат при каві.

Якщо ситуація реально термінова, хтось із команди підвищить її пріоритет вручну — і тоді спрацює другий шаблон, що нікого не питає про години тиші.

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/Kyiv"

Мʼякі сигнали в Slack, не в нічний дзвінок

Якщо щоночі будити чергового про диск на 70%, за два місяці він перестане реагувати взагалі. Це не теорія — у 2024 році ми деякий час підіймали диск, чергу, повільні запити прямо через основний ланцюжок ескалації. Через шість тижнів черговий пропустив справжню аварію, бо телефон дзвонив утретє за ніч, і він поставив усю систему на тишу. Ми втратили девʼять годин простою через довіру, зруйновану мʼякими сигналами.

Робоча конфігурація: м’які сигнали йдуть тільки в Slack. Виклик до чергового — тільки після 30 хвилин відсутності реакції і тільки в робочий час. Решта — буде розв’язано до обіду командою на робочому місці.

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/Kyiv"
  days: [mon, tue, wed, thu, fri]

Зведена таблиця

Усі п’ять шаблонів в одному погляді:

Сценарій	Перший виклик до	Години тиші	Підтвердження	Резервний канал
Попередження після релізу	Автор релізу	Поважати	Лише від автора	Основний черговий через 15 хв
Аварія для клієнтів	Основний черговий	Ігнорувати	Від чергового	Повтор основного, потім резервний
Безпековий тригер	Безпековий черговий + канал команди	Ігнорувати	Лише від безпекового	Директор з ІБ через 5 хв
Нічні пакетні задачі	Канал команди + email	Відкласти до ранку	Не вимагається	Керівник через 4 год у робочий час
М’які сигнали	Slack каналу	Відкласти	Не вимагається	Черговий через 30 хв у робочий час

П’ять шаблонів, п’ять різних відповідей на одне питання — як зробити так, щоб правильна людина дізналась про правильну річ у правильний момент. Жоден з них не виник з теорії. Кожен має за собою конкретний випадок, після якого ми переписали правила.