Сообщить об ошибкеКороткий ответ
Нужна многоуровневая политика эскалации с таймаутами подтверждения на каждом уровне (первичный дежурный → резервный дежурный → руководитель команды/следующая команда), автоматическим переходом на следующий уровень при отсутствии подтверждения, и регулярным тестированием самой системы оповещения, а не только документированием схемы.
Как это работает подробнее
escalation policy определяет цепочку получателей алерта и таймаут на подтверждение (acknowledge) для каждого уровня; если дежурный не подтвердил получение за заданное время (например, 10-15 минут для критичных алертов), система автоматически уведомляет следующий уровень, не дожидаясь, пока кто-то вручную заметит проблему.
Пример / кейс
Ожидаемое поведение: если первичный дежурный не подтвердил критичный алерт за 10 минут, система автоматически звонит резервному; если и резервный не ответил ещё за 10 минут — эскалирует руководителю с дублирующим каналом связи, гарантируя, что инцидент не останется без внимания дольше 20 минут.
Пример кода
Escalation policy для алертов severity=critical:
Уровень 1: Первичный дежурный, таймаут подтверждения 10 мин
Уровень 2: Резервный дежурный, таймаут подтверждения 10 мин
Уровень 3: Руководитель команды + второй канал (SMS и звонок одновременно)Что использовать на практике
- Практический подход. Критичные (высокий severity) алерты должны иметь короче таймауты эскалации, чем менее критичные; важно периодически тестировать саму цепочку (например, через тестовые "учебные" срабатывания), а не только полагаться на то, что конфигурация верна; нужно учитывать часовые пояса и реальную доступность людей (отпуска, больничные) в графике, а не только формальную ротацию.
Подводные камни
- Частые ошибки. Настраивать эскалацию только на одного дежурного без резервного уровня, что превращает любую его недоступность (разрядился телефон, плохая связь) в risk для всего инцидента; делать таймаут эскалации слишком большим для критичных алертов (например, 1 час), что фактически увеличивает время реагирования на критичный инцидент; не проверять, что номера телефонов/контакты в системе оповещения актуальны.