Настройка On-Call ротации для команды поддержки сайта
On-call ротация — это система, при которой ответственность за реакцию на инциденты вне рабочего времени распределяется между членами команды по очереди. Без ротации — один дежурный выгорает за месяц. С правильно настроенной ротацией — нагрузка равномерна, а реакция предсказуема.
Структура on-call схемы
Primary on-call: Первый уровень, получает все алерты. Обязан ответить в течение 5-15 минут.
Secondary on-call (backup): Если primary не ответил за 10-15 минут — эскалация на secondary. Страховка от недоступности.
Escalation path: Primary → Secondary → Engineering Manager → CTO. Каждый уровень — +10-15 минут.
Rotation period: Обычно 1 неделя. Можно 2 недели для зрелых команд с низким alert noise. Меньше недели — слишком частая смена контекста.
Требования к on-call инженеру
Быть on-call значит:
- Доступность за 15 минут (не полчаса до душа)
- Ноутбук и VPN-доступ всегда под рукой
- Трезвость и способность к техническому мышлению
- Знание runbooks для типовых инцидентов
On-call не значит «работать 24/7». Если ночных алертов нет — инженер спит. Цель — быть готовым, а не постоянно работать.
Настройка в PagerDuty
Service → Escalation Policy:
Level 1: On-Call schedule (primary)
- Notify after: immediately
- Escalate after: 15 minutes
Level 2: On-Call schedule (secondary)
- Notify after: escalation
- Escalate after: 15 minutes
Level 3: Engineering Manager
- Notify after: escalation
Schedule (Primary):
Rotation type: Weekly
Handoff time: Monday 10:00 local time
Restrictions: None (24/7 coverage)
Layer 1: [Engineer A, Engineer B, Engineer C, Engineer D]
Handoff в рабочее время (не в 00:00) — инженер принимает смену в спокойной обстановке, изучает открытые инциденты.
Компенсация за on-call дежурство
On-call — это дополнительная нагрузка, которая должна компенсироваться:
- Денежная надбавка за дежурную неделю
- Отгул после тяжёлой недели с ночными инцидентами
- Компенсация за каждый ночной вызов (если их было много)
Команда без компенсации — команда, которая саботирует дежурство или уходит.
Снижение alert fatigue
On-call работает только если алерты значимы. Если за дежурную неделю приходит 50 алертов, из которых 45 — шум, через месяц команда перестаёт реагировать.
Инструменты борьбы с noise:
- Alert grouping: несколько связанных алертов → один инцидент
- Smart notifications: разные каналы для дня (Slack) и ночи (звонок)
- Alert review: еженедельный просмотр сработавших алертов, отключение ложных
- SLO-based alerting: алерты на burn rate, а не на пороговые значения
Handoff процедура
Каждую смену — передача контекста:
- Список открытых/недавних инцидентов
- Что из инфраструктуры нестабильно прямо сейчас
- Запланированные изменения на этой неделе (деплои, миграции)
- «Горячие» места, требующие внимания
Шаблон handoff-заметки в Slack/Confluence, заполняемой уходящим дежурным.
Метрики on-call здоровья
- Incidents per week per engineer — если > 5, нужно снижать alarm noise
- After-hours incidents % — сколько инцидентов происходит ночью/в выходные
- MTTA (Mean Time to Acknowledge) — если > 15 минут, escalation policy слабая
- Fatigue score — субъективная оценка нагрузки от каждого дежурного
Сроки настройки
- PagerDuty/OpsGenie + schedules + escalation policy — 1-2 дня
- Интеграция с Prometheus/Datadog алертами — 1-2 дня
- Настройка каналов нотификации (Slack, звонок, SMS) — 1 день
- Документация процесса + обучение команды — 1-2 дня