Что такое on-call: как устроены дежурства в DevOps и SRE — ротация, эскалация, severity, MTTA и MTTR
Команда KAI Lab · · 9 мин чтения
On-call — это дежурство, во время которого инженер обязан быть на связи и в оговорённое время начать разбираться с инцидентом, даже ночью и в выходные. Держится оно на пяти вещах: график дежурств (ротация primary и secondary), алерты, которые будят только по важному, путь эскалации, runbook для типовых проблем и договорённость, какой инцидент насколько серьёзен (severity).
Дежурят DevOps-инженеры, SRE, сисадмины, а во многих компаниях и разработчики — по принципу «сам написал, сам отвечаешь за работу в проде». Ниже — как это устроено по открытым описаниям Google (книга Site Reliability Engineering) и PagerDuty.
Как выглядит дежурство
- Срабатывает алерт, система оповещения отправляет его дежурному: пуш, SMS, звонок.
- Дежурный подтверждает (acknowledge), что взял алерт в работу. Пока не подтвердил, система считает, что до него не достучались.
- Разбирается, насколько всё плохо, и снимает влияние на пользователей: откатывает релиз, переключает трафик, добавляет ресурсы.
- Если сам не справляется или проблема не его зоны — эскалирует.
- После инцидента — разбор и задачи, чтобы не повторилось.
Сколько времени на реакцию, договариваются команда и бизнес. В книге Google типичные значения — 5 минут для сервисов, с которыми работают пользователи, и 30 минут для менее критичных. Если сервис должен быть доступен 99,99% времени за квартал, на простой остаётся около 13 минут за квартал, и реагировать приходится за минуты.
Днём дежурному достаётся и несрочное — тикеты, проверка релизов, — но пейдж, вызов по алерту, важнее почти любой другой работы.
Primary и secondary
Primary — основной дежурный: алерты приходят сначала ему. Secondary (backup) — второй: страхует первого. Как делить обязанности, каждая команда решает сама. В книге Google описаны два варианта: secondary получает пейджи, которые пропустил primary, или primary занимается только пейджами, а secondary — всей остальной несрочной работой в проде.
PagerDuty советует всегда иметь backup: основному дежурному спокойнее, когда он знает, кого звать. Смену backup лучше ставить сразу после смены primary: вчерашний основной дежурный передаёт контекст и не может «оставить проблему следующим». Третий уровень эскалации — вся команда.
Ротация: сколько людей нужно
Обычно дежурят сменами по неделе, реже по суткам. Google ограничивает дежурства четвертью рабочего времени инженера, и из этого правила выводит минимум: чтобы круглосуточно держать primary и secondary силами одной площадки, нужно восемь человек — тогда каждый дежурит одну неделю в месяц. Для двух площадок в разных часовых поясах — минимум шесть человек на каждой.
| Схема | Как устроена | Что важно знать |
|---|---|---|
| Недельная ротация | каждый дежурит неделю, по очереди | простая, но ночи достаются всем |
| Follow the sun | площадки в разных часовых поясах передают дежурство друг другу | ночных смен нет, зато сложнее координация |
| Рабочее и нерабочее время | днём одна ротация, ночью и в выходные другая | дневные и ночные часы можно раздать разным людям |
Такие схемы собираются в сервисах оповещения — PagerDuty, Opsgenie и похожих: расписание, ротации, подмены (override), правила уведомлений. Если вы на Opsgenie, учтите: Atlassian прекратила его продажу 4 июня 2025 года, поддержка заканчивается 5 апреля 2027 года, а функции дежурств и алертов переехали в Jira Service Management.
Дежурить слишком редко тоже плохо: инженер отвыкает от прода и узнаёт о пробелах в знаниях посреди инцидента. Google советует, чтобы каждый дежурил хотя бы раз-два в квартал.
Эскалация
Эскалация — правило, кого звать дальше, если дежурный не ответил или не справляется. Типовая политика из документации Opsgenie:
- Уведомить того, кто сейчас на дежурстве.
- Если за 5 минут алерт не подтверждён и не закрыт — уведомить следующего в ротации.
- Если и через 10 минут никто не подтвердил — уведомить всю команду.
PagerDuty тоже рекомендует таймаут эскалации 5 минут: кто не смог подтвердить алерт за это время, скорее всего, не в состоянии им заниматься.
Эскалация бывает и по смыслу, а не только по таймауту: дежурный понял, что проблема в базе или у сетевиков, и зовёт экспертов. Девиз в руководстве PagerDuty — «Never hesitate to escalate», никогда не стесняйтесь эскалировать. В книге Google понятные пути эскалации стоят первыми в списке того, что делает дежурство менее страшным. Рядом — чёткий процесс работы с инцидентами и разборы без поиска виноватых.
Severity: насколько всё плохо
Severity — уровень серьёзности инцидента. От него зависит, будить ли людей ночью, собирать ли большую команду и сообщать ли клиентам. Меньший номер — серьёзнее. Сокращённо по открытой схеме PagerDuty:
| Уровень | Что это | Реакция |
|---|---|---|
| SEV-1 | критично: затронуто много клиентов, SLA нарушен или найдена уязвимость, открывающая данные клиентов | крупный инцидент, координатор, уведомление руководства и клиентов |
| SEV-2 | критичная проблема мешает многим клиентам пользоваться продуктом | крупный инцидент, координатор |
| SEV-3 | частичная потеря функций или риск перерасти в SEV-2 | срочный пейдж команде сервиса |
| SEV-4 | нужно действие, но клиенты не страдают: упал один узел, не отработал cron | несрочный пейдж, заняться раньше обычных задач |
| SEV-5 | косметика, баги без влияния на работу | задача в трекере |
Два правила оттуда же. Если сомневаетесь между уровнями — считайте инцидент более серьёзным и спорьте об уровне на разборе, а не во время аварии. И описывайте уровни в цифрах, например через долю затронутых пользователей, чтобы дежурный не решал на глаз.
Runbook
Runbook (в книге Google — playbook) — инструкция к конкретному алерту: что он означает, как проверить, что делать, кого звать. Хороший runbook отвечает на вопросы дежурного в три часа ночи: где дашборд, какими командами смотреть, что безопасно делать без согласования, а что — только с владельцем сервиса.
Google оценивает эффект так: продуманные и записанные заранее практики дают примерно трёхкратное улучшение MTTR по сравнению с импровизацией. Правило PagerDuty для дежурных: если информацию было трудно найти — запишите её. Так runbook растёт из реальных инцидентов, а не из фантазий о них.
Как устроены алерты
Google делит сигналы мониторинга на три вида: алерты, на которые человек должен отреагировать сразу; тикеты, которые требуют действий, но не прямо сейчас; и логи, которые никто не читает, пока не понадобятся. Будить человека стоит только первым.
Из той же книги — четыре правила для пейджей:
- на каждый пейдж дежурный должен реагировать срочно, а срочно реагировать можно лишь несколько раз в день, дальше наступает усталость;
- каждый пейдж должен требовать действия;
- ответ на пейдж должен требовать мысли: если хватает механического действия, это работа для автоматики;
- пейдж должен сообщать о новой проблеме, а не о той, что уже известна.
Главный принцип — алертить по симптомам, а не по причинам. «Пользователи получают ошибки 500» — симптом, «база отказывает в подключениях» — одна из возможных причин.
| Шумный алерт | Почему плохой | Лучше |
|---|---|---|
| CPU выше 90% на одном сервере | причина, а не симптом: пользователи могут ничего не замечать | доля ошибок или задержка выше SLO |
| Диск заполнен на 85% | не срочно и не говорит, когда станет плохо | прогноз: диск заполнится в ближайшие 4 часа |
| Каждая ошибка 500 | одна ошибка из миллиона запросов — не авария | доля ошибок выше порога в течение 5 минут |
Алерты по SLO и бюджету ошибок разобраны в статье SLO, SLI и бюджет ошибок, а прогноз заполнения диска — в статье закончилось место на диске.
MTTA и MTTR
MTTA (mean time to acknowledge) — среднее время от срабатывания алерта до того, как дежурный его подтвердил.
MTTR — с ним осторожнее: у аббревиатуры четыре расшифровки, и PagerDuty прямо советует договориться, какую вы используете. Mean time to repair — среднее время ремонта. Mean time to recovery — до восстановления нормальной работы, это простой, делённый на число инцидентов. Mean time to respond — до реакции. Mean time to resolve — до полного закрытия, включая меры против повторения.
Пример: за месяц два инцидента, сервис лежал 20 и 40 минут. MTTR в смысле recovery — (20 + 40) / 2 = 30 минут. Средние скрывают выбросы, поэтому один долгий инцидент стоит разобрать отдельно, а не растворять в среднем.
Нагрузка на дежурных тоже измеряется. Google считает, что работа с одним инцидентом — разбор, исправление, постмортем — в среднем занимает 6 часов, поэтому за 12-часовую смену разумно не больше двух инцидентов. Если пейджи приходят каждый день, это перегрузка: чинить надо систему, а не терпеть.
После инцидента
Дежурство не заканчивается, когда сервис поднялся. Нужен разбор: что произошло, почему система это позволила и какие задачи закроют дыру. Как его писать, — в статьях как писать постмортем и blameless-постмортем. А если дежурство вам предстоит впервые, начните с практического чек-листа первого дежурства.
В симуляторе DevOps KAI Lab девять дежурств — по одному на каждый месяц работы в вымышленной компании Qoima. Алерты приходят пачкой, нужно отделить то, что горит, от шума, а после смены — написать постмортем. Начать можно с бесплатного теста навыков DevOps: 18 ситуаций, 10–15 минут, без регистрации.
Частые вопросы
Что значит on-call? Режим, при котором инженер в течение смены доступен по вызову и за оговорённое время начинает работать с инцидентом — в том числе ночью и в выходные.
Сколько длится дежурство? Чаще всего неделю, иногда сутки или только нерабочие часы. Google ограничивает дежурства четвертью рабочего времени инженера: при восьми людях в ротации каждый дежурит неделю в месяц.
Чем primary отличается от secondary? Primary получает алерты первым. Secondary страхует: получает то, что primary пропустил, или берёт несрочную работу, чтобы primary занимался только вызовами. Точное разделение команда задаёт сама.
Платят ли за дежурства? Зависит от компании. Google, например, компенсирует дежурства в нерабочее время отгулами или деньгами с потолком — этот потолок заодно ограничивает, сколько дежурств может взять один человек.
Источники
- Google. Site Reliability Engineering, глава 11 «Being On-Call» — время реакции, primary и secondary, правило 25%, восемь инженеров, 6 часов на инцидент, компенсация.
- Google. Site Reliability Engineering, глава 6 «Monitoring Distributed Systems» — симптомы и причины, правила для пейджей.
- Google. Site Reliability Engineering, глава 1 «Introduction» — алерты, тикеты и логи; playbook и трёхкратное улучшение MTTR.
- PagerDuty Incident Response. Being On-Call — обязанности, backup, таймаут эскалации 5 минут, «Never hesitate to escalate».
- PagerDuty Incident Response. Severity Levels — SEV-1…SEV-5.
- PagerDuty. What is MTTR? — четыре значения MTTR и MTTA.
- Atlassian. How do escalations work in Opsgenie? и Manage on-call schedules and rotations.
- Atlassian. Migrate from Opsgenie — конец продаж 04.06.2025, конец поддержки 05.04.2027.