On-call и эскалации

Задача on-call

On-call назначает ответственного за первую реакцию на критичные сигналы вне обычного рабочего процесса. Дежурный не обязан лично устранять любую причину: он подтверждает получение, оценивает влияние, начинает runbook и привлекает нужных людей.

Устойчивая система включает расписание, понятную эскалацию, защищённое время отдыха и регулярную проверку качества оповещений.

Ротации и overrides

Расписание содержит основного и резервного ответственного, часовой пояс и правила перехода смены. Override — временная замена на конкретный интервал, например отпуск или несколько часов недоступности. Изменение должно быть видно всей команде и учтено в календаре.

Не проектируйте постоянное дежурство одного человека. Это создаёт bus factor, усталость и стимул игнорировать сигналы.

Acknowledgement и эскалация

Acknowledgement (ack) подтверждает, что ответственный принял сигнал и начал реакцию. Он не означает решение проблемы.

Пример escalation policy:

1. Critical alert отправляется основному дежурному.
2. Если ack не получен за заданное время — сигнал уходит резервному.
3. При подтверждённом значимом влиянии объявляется инцидент и назначается IC.
4. Для нужной компетенции привлекается владелец сервиса или смежная команда.
5. При передаче смены новый ответственный явно подтверждает принятие.

Таймауты выбирают по severity и обязательствам сервиса. Эскалация должна запускаться при отсутствии реакции, а не просто повторять звонок тому же человеку бесконечно.

Runbooks

Runbook содержит минимальный проверенный сценарий:

• как подтвердить влияние и охват;
• ссылки на dashboard, логи, traces и status page;
• безопасные первые действия;
• когда остановиться и эскалировать;
• как откатить действие;
• что записать в документ инцидента.

Runbook не заменяет инженерное мышление и не должен содержать разрушительную команду без условий применения и проверки результата.

MTTA и MTTR

• MTTA — Mean Time To Acknowledge — среднее время от сигнала до подтверждения реакции. Помогает увидеть проблемы маршрутизации и доступности дежурного.
• MTTR — Mean Time To Recovery/Restore — среднее время восстановления. Нужно единое определение начала и конца интервала.

Метрики сравнивают по типу и severity, а не как единый рейтинг людей. Ускорение acknowledgement не должно поощрять формальный ack без реальной реакции.

Alert fatigue

Усталость возникает, когда сигналов много, а действий по ним мало. Полезно регулярно удалять или перенастраивать неactionable правила, объединять связанные события и разводить critical с рабочими уведомлениями. Подробнее — в alerting.

Для проверки системы проводят учебные сценарии: кто получил сигнал, был ли доступен runbook, хватило ли прав, как прошёл handoff. Тренировка безопаснее первого реального ночного инцидента.

Связанные инструменты

• PagerDuty — расписания, escalation policies и мобильные уведомления.
• Better Stack — on-call, incidents и телеметрия.
• Grafana — alerting rules и notification policies.

Связанные материалы

• Управление инцидентами — роли и жизненный цикл.
• Postmortem — улучшение процесса после восстановления.
• SRE — снижение операционного toil.

Материалы и источники

• Google SRE: Being On-Call — дежурства, нагрузка и практика реакции.
• Google SRE: Managing Incidents — роли и явная передача смены.
• Better Stack: Incident management — rotations, overrides и escalation workflows.
• PagerDuty: Support — настройка дежурств, уведомлений и эскалаций.