On-call — необходимость для любой команды, отвечающей за production. Но плохо организованный on-call превращается в источник выгорания: ночные алерты из-за ложных срабатываний, отсутствие runbooks, размытая escalation policy, и ощущение, что ты один на один с production.
Хорошо организованный on-call — предсказуемый, справедливый, и поддерживаемый инструментами. Ниже — практики, которые превращают on-call из кошмара в управляемый процесс.
Расписание: структура ротации
Базовая ротация
Primary on-call: первый responder. Получает все alerts. Обязан acknowledge в течение 5 минут.
Secondary on-call: backup. Получает alert, если primary не acknowledge за 10-15 минут. Также доступен для эскалации сложных инцидентов.
Длительность: 1 неделя (Monday 10:00 → Monday 10:00). Handoff в рабочее время, не в выходные.
Направление ротации: по кругу, предсказуемо. Расписание на 2-3 месяца вперёд. Возможность swap между участниками.
Follow-the-sun
Для распределённых команд (EU + US + Asia): on-call передаётся по часовым поясам. EU-инженер on-call с 08:00 до 16:00 CET, US-инженер с 08:00 до 16:00 EST, Asia — ночное окно. Никто не просыпается ночью.
Требование: минимум 2 человека в каждом timezone для backup.
Сложность: handoff между timezone требует чёткого процесса (status update, open incidents, context transfer).
Alert fatigue: главный враг on-call
Alert fatigue — состояние, когда on-call инженер перестаёт реагировать на алерты, потому что большинство из них — ложные или неактуальные. Исследования показывают: после 3-5 ложных срабатываний за ночь инженер начинает игнорировать alerts. Одно пропущенное реальное — и P1 инцидент без ответа.
Источники alert fatigue
False positives: мониторинг срабатывает из-за network glitch, а не реального outage. Решение: quorum confirmation в AtomPing — 2/3 агентов подтверждают проблему перед alert.
Non-actionable alerts: «disk usage 81%» в 3 ночи. Это может подождать до утра. Решение: severity-based routing — P1/P2 будят, P3/P4 идут в Slack channel.
Alert storms: cascading failure создаёт 20 alerts одновременно. Решение: grouping и deduplication. Один инцидент — один alert, даже если 10 monitors failed.
Flapping: monitor переключается UP↔DOWN каждые 2 минуты. Решение: hysteresis — требовать N consecutive failures перед alert и M consecutive successes перед recovery.
Метрика: alerts per on-call shift
Здоровый уровень: 0-2 pages за неделю (out-of-hours). 5-10 — терпимо. 10+ — проблема, которую нужно решать.
Отслеживание: после каждого on-call shift — краткий отчёт: сколько alerts, сколько actionable, сколько false positives. Трендируйте помесячно.
Escalation policies
Escalation policy определяет: кто получает alert, в каком порядке, и через сколько минут alert эскалируется на следующий уровень.
Уровень 1 (0 min): Primary on-call → Slack + push notification. Acknowledge timeout: 5 минут.
Уровень 2 (5 min): Secondary on-call → Slack + push + SMS. Acknowledge timeout: 10 минут.
Уровень 3 (15 min): Engineering manager → phone call. Acknowledge timeout: 10 минут.
Уровень 4 (25 min): CTO / VP Engineering → phone call. Это P1, и никто не ответил за 25 минут.
Severity определяет, с какого уровня начинается escalation. P1 (revenue impact) — с уровня 1, immediate. P4 (minor cosmetic issue) — в Slack channel, без пейджинга.
Severity-based routing
P1 — Critical: revenue loss, data loss, full outage. → Phone call + SMS + push. Wake up the engineer. Пример: checkout API 503, database unreachable.
P2 — High: significant degradation, partial outage. → Push notification + Slack DM. Пример: API latency 10x normal, одна region down.
P3 — Medium: minor degradation, workaround exists. → Slack channel only. Пример: email service slow, analytics delayed.
P4 — Low: cosmetic, informational. → Slack channel, review next business day. Пример: disk usage 80%, certificate expires in 20 days.
Runbooks: документируйте реакцию
Runbook — пошаговая инструкция для on-call инженера: что делать при конкретном alert. Без runbook инженер (особенно junior или из другой команды) тратит 20 минут на понимание контекста. С runbook — 2 минуты.
Структура runbook:
Alert name: «Checkout API 503»
What it means: Checkout endpoint возвращает 503. Пользователи не могут оплатить.
Severity: P1 — revenue impact
First check: 1) Открыть Grafana dashboard «Payment Service» 2) Проверить pod status: kubectl get pods -n payments
Common causes: Database connection exhaustion → restart pods. OOMKilled → check memory leak, rollback last deployment. Stripe API down → check status.stripe.com
Escalate if: Причина неясна после 15 минут → escalate to payment team lead
Правило: каждый alert, который будит человека ночью, должен иметь runbook. Если alert не имеет runbook — либо напишите его, либо удалите alert (он неактуальен).
Handoff: передача смены
Когда: фиксированное время в рабочий день (например, понедельник 10:00). Не в пятницу вечером.
Формат: 5-10 минут sync (Slack thread или short call):
1. Открытые инциденты (если есть) — статус, context, next steps
2. Alerts за прошлую неделю — какие были, actionable ли, нужно ли тюнить
3. Запланированные changes — deployments, migrations, infrastructure work
4. Known issues — «Redis иногда тормозит после 2AM backup, это нормально, не реагировать»
Предотвращение burnout
Компенсация
On-call ограничивает личное время. Инженер не может уехать в поход, выпить вина за ужином, или посмотреть фильм без телефона. Это заслуживает компенсации.
Модели:
— Фиксированная доплата: $200-500 за неделю on-call (зависит от региона и частоты)
— Почасовая оплата за время, проведённое на инцидентах
— Дополнительный PTO: 0.5-1 день отдыха после каждой on-call недели
— Комбинация: фиксированная доплата + дополнительный PTO после тяжёлых смен (3+ ночных alert)
Инвестиции в тишину
Каждый false positive — это техдолг on-call. Выделяйте 10-20% sprint capacity на «on-call improvements»: тюнинг alerts, написание runbooks, исправление flaky tests, устранение root causes повторяющихся инцидентов.
Процесс: после каждой on-call смены — review. Какие alerts были? Actionable? Если нет — создать задачу на fix/tune/remove. Track «alerts per shift» как метрику. Цель: 0 ложных ночных алертов.
Инструменты: AtomPing с quorum confirmation и batch anomaly detection — значительно сокращает false positives. Hysteresis (N consecutive failures before alert) предотвращает flapping.
Toolchain для on-call
Detection: AtomPing — external monitoring с 30s interval, 9 check types, quorum confirmation. Минимум ложных срабатываний.
Alerting: AtomPing → Slack, Telegram, Discord, email, webhooks. Для escalation policies: PagerDuty или OpsGenie (сравнение альтернатив).
Diagnosis: Grafana dashboards (internal metrics), application logs (ELK/Loki).
Communication: Status page (AtomPing) для публичной коммуникации. Slack #incident channel для внутренней.
Post-incident: blameless post-mortem после каждого P1/P2. Action items → sprint backlog.
Checklist: здоровый on-call
Rotation: ≥4 человека, weekly shifts, primary + secondary
Alerts: severity-based routing, P1/P2 — page, P3/P4 — Slack only
False positives: quorum confirmation, hysteresis, \<2 false alerts per week
Runbooks: каждый paging alert имеет runbook
Escalation: documented policy с timeout на каждом уровне
Handoff: structured, in business hours, with context transfer
Compensation: financial or PTO, acknowledged by management
Review: weekly alert review, monthly trend analysis, quarterly process improvement
Связанные материалы
Incident Management Guide — полный цикл от detection до post-mortem
Как сократить ложные срабатывания — quorum confirmation и batch anomaly detection
PagerDuty Alternatives — инструменты для on-call scheduling
SLA vs SLO vs SLI — как метрики надёжности связаны с on-call
FAQ
What is an on-call rotation?
An on-call rotation is a schedule where team members take turns being the primary responder for production incidents. The on-call engineer carries a pager (phone/Slack/PagerDuty) and is responsible for acknowledging and triaging alerts during their shift — typically 1 week, with handoffs on a fixed day.
How long should an on-call shift last?
One week is the most common rotation. Shorter (2-3 days) reduces fatigue but increases handoff overhead. Longer (2 weeks) causes burnout. For small teams (3-4 people), weekly rotation means on-call every 3-4 weeks — sustainable if alert volume is reasonable.
What's the minimum team size for on-call?
4 people minimum for a sustainable rotation. With 3 people, each person is on-call every 3 weeks — borderline. With 2 people, it's every other week — unsustainable long-term. If your team is smaller than 4, consider shared on-call with another team or using a managed incident response service.
How do I reduce on-call alert volume?
Three approaches: (1) Fix the root cause — if the same alert fires weekly, fix the underlying issue, don't just acknowledge it. (2) Tune thresholds — if alerts fire for non-actionable conditions, raise the threshold. (3) Use quorum confirmation — AtomPing's quorum prevents false alarms from waking people up for network glitches.
Should on-call engineers be compensated?
Yes. On-call restricts personal time and causes stress. Common models: flat stipend per on-call week ($200-500), hourly rate for time spent on incidents, extra PTO days per on-call rotation, or a combination. Companies that don't compensate on-call struggle with retention and morale.
What tools do I need for on-call?
Minimum: monitoring (AtomPing for detection), alerting (Slack/Telegram/PagerDuty for notifications), runbooks (documented procedures for common alerts), communication (Slack channel for incident coordination). Advanced: on-call scheduling (PagerDuty, OpsGenie, Better Stack), status page (AtomPing), post-incident review template.