Налаштування 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 дня