Как организовать ротацию on-call дежурств

Организация on-call — это не только расписание: это набор правил, ролей, инструментов и культуры, которые вместе минимизируют простой сервиса и защищают людей от выгорания.

Принципы

• Чёткое разделение ролей (primary, secondary, eskalation).

• Предсказуемость и справедливость в расписании.

• Автоматизация и runbook-ориентированность (каждый алерт — с runbook).

• Поддержка и компенсация для дежурных (TOIL/оплата/время для восстановления).

• Blameless-культура и регулярные постмортемы.

Модели ротации (часто используемые)

• Еженедельная ротация (1 week) — удобна для команд: 7×24 покрытие, меньше переключений.

• Дневная ротация (24-часа) — для очень больших команд/отделов с короткими сменами.

• Follow-the-sun — глобальное покрытие с региональными сменами (минимизирует ночные вызовы для каждого региона).

• Primary/Secondary: primary отвечает за все страницы; secondary — резерв и помощь в сложных инцидентах.

Рекомендация: для небольших команд (5–10 человек) — weekly primary + backup secondary; максимум 1–2 подряд недели одному человеку.

Роли и политика эскалации

• Primary — принимает и обрабатывает алерты, запускает инцидент.

• Secondary — поддерживает primary/замещает при escalations.

• Incident Commander (IC) — назначается при крупном инциденте.

• Эскалация: P1 — если primary не ACK в 5–10 мин → уведомление secondary → если нет реакции → старший инженер/lead → менеджмент.

Подберите таймауты под свою дисциплину и SLO (пример: ACK P1 — 5 мин, P2 — 30 мин).

Handover (передача смены) — обязательный чек-лист

• Активные инциденты и статус (ID, owner, next steps).

• Открытые тикеты / задачи, которые влияют на прод.

• Планируемые изменения/деплои в ближайшие 24–48 часов.

• Изменения в конфигурации, контакт-лист, доступы.

• Краткий отчёт о pager-нагрузке за смену.

Передача должна быть письменно задокументирована (чат/вики).

Инструменты и автоматизация

• Планирование/эскалация: PagerDuty, Opsgenie, VictorOps.

• Расписания и swap-функции (самостоятельный swap, администрирование отпусков).

• Alerts → runbook links, dedupe, suppression, rate-limits.

• Statuspage и шаблоны коммуникаций для внешней и внутренней связи.

• Метрики on-call: time to ack, pages per shift, false positives.

Снижение нагрузки и защита on-call

• Минимизировать шум: threshold + debouncing, suppression windows, grouping.

• Обязательные runbooks и автоматические mitigations (self-healing).

• Ограничение подрядных дежурств: максимум 1–2 подряд недели.

• Компенсация: оплата / день восстановления / компенсационные выходные (TOIL).

Обучение и сопровождение

• Shadow shifts для новых on-call (наблюдение за опытным инженером).

• Регулярные walkthroughs runbooks и fire-drills.

• Доступность документации/скриптов в один клик из алерта.

Метрики эффективности и непрерывное улучшение

• MTTA (time to acknowledge), MTTR, pages per shift, % alerts with runbook.

• После каждого P1 — postmortem и action items (обновление алертов, runbooks, автоматизация).

Пример минимальной политики

• Ротация: 1 неделя primary, 1 неделя отдых/backup; максимум 2 недели подряд.

• Swap: возможен через UI с уведомлением тим-лида.

• ACK SLA: P1 — 5 мин, P2 — 30 мин.

• После P1: IC назначается и создаётся инцидент-ticket; postmortem в течение 72 часов.

Организация on-call — это баланс технических мер и заботы о людях: хорошие правила, инструменты и культура снижают количество страниц и повышают качество реагирования.