Почему on-call процедуры ломаются на третьем инциденте
Первый ночной вызов дежурный закрывает по ранбуку, второй — по памяти, а третий вскрывает дефекты самой процедуры. Зона ответственности размыта: непонятно, какой сервис кому принадлежит, кто подтверждает инцидент и по какому маршруту идёт эскалация. Формально дежурство инженеров круглосуточное, фактически оно держится на личной ответственности двух-трёх человек.
Оповещения сыпятся в общий канал, где их видят все и не отвечает никто. Пороги срабатывают на штатных колебаниях нагрузки, часть сигналов дублируется разными системами, и дежурный тратит смену на фильтрацию шума вместо диагностики. Эскалация инцидентов уходит в личные сообщения — тому, кто «обычно помогает».
Цена проявляется не сразу. Ночные вызовы концентрируются на одних и тех же инженерах, время до восстановления растёт от инцидента к инциденту, потому что маршрут каждый раз собирается заново. Дальше — усталость дежурных, пропущенные сигналы, отказ брать смену вне очереди и попытки гасить проблему до того, как о ней узнают.
Разбираем, как это закрывается: матрица владения сервисами, эскалация с явными уровнями и таймаутами, чистка шумных оповещений и ротация, которую выдерживают люди, а не герои.
Что даёт регламент дежурств: время реакции и снятые отказы
Регламент дежурств переводит реакцию на отказ из режима «кто первым заметил» в процесс с измеримыми границами. Пока зоны ответственности и порядок эскалации живут только в головах, время до первого отклика гуляет от минуты до часов, а разбор инцидента превращается в поиск виноватого. Регламент фиксирует, кто держит смену, что считается сигналом и через сколько минут подключается вторая линия.
Время до первого отклика становится управляемой величиной: расписание смен покрывает сутки целиком, у каждого уровня своя зона, а эскалация срабатывает по таймеру, а не по звонку. Дежурный получает только те сигналы, где нужно его вмешательство, — маршрутизация отсекает шум и не будит ночью из-за отклонения, которое дождётся утра. Вместе это сжимает реакцию с десятков минут до единиц и убирает провалы на передаче смены.
Пропущенные оповещения редко связаны с невнимательностью — чаще виноват перегруженный канал: однотипные уведомления, отсутствие подтверждения приёма, одиночное дежурство без подстраховки. Регламент вводит подтверждение приёма, дублирование на вторую линию и лимит смен подряд, чтобы к третьей ночи дежурный не терял бдительность; такая логика лежит в основе PagerDuty и открытых аналогов. Доля сигналов без ответа уходит в ноль — это видно по журналу, а не на словах.
Разбор инцидентов описывается отдельным блоком: какой сигнал сработал первым, почему так поздно, какие изменения закрепляем. Хронология без персональных выводов — детали не скрывают, и причина находится, а не назначается. Нагрузка на дежурных становится измеримой: ночные подъёмы на смену, доля повторных отказов, сервисы-источники основной части сигналов.
Варианты организации дежурств: сравнение подходов
Режим дежурства выбирают не по привычке команды, а по профилю нагрузки: критичность сервиса, разброс часов пиковой активности, внешние обязательства по времени реакции. Один и тот же график смен не подойдёт и платёжному шлюзу, и внутреннему инструменту отчётности — во втором случае круглосуточная поддержка обходится дороже, чем редкий простой.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Круглосуточная смена | Сервисы с непрерывным потоком операций и обещанной доступностью | Нужна ротация из 4-6 инженеров, иначе к третьей ночной смене растёт доля ошибок разбора |
| Дежурство по вызову | Нагрузка с выраженными пиками, ночью отказы редки | Время реакции зависит от того, как быстро инженер берёт оповещение; без регламента эскалации вызов зависает |
| Гибридная схема | Ядро сервиса критично, периферийные модули терпят паузу | Сложнее администрировать: два набора правил эскалации и разные целевые времена реакции |
| Дежурство только в рабочие часы | Внутренние сервисы, где ночной простой не блокирует бизнес | Ночные инциденты ждут утра, поэтому нужен автоматический перевод системы в безопасный режим |
Каждая строка — компромисс между временем реакции и ресурсом команды, и в процедуре это фиксируется явно: кто берёт вызов, через сколько минут подключается второй уровень, когда оповещение превращается в инцидент. Гибридную схему на практике собирают чаще всего — критичный контур закрывают посменным дежурством, остальное переводят на вызовы с расширенным окном реакции. Дальше описываем, как этот выбор закрепляется в документе.
Этапы разработки on-call процедур под ключ
Разработка регламента начинается не с шаблона, а с инвентаризации того, что уже происходит: кто получает сигналы, по каким каналам, где они теряются. Без этого документа описывает желаемое состояние и расходится с реальностью на первой же ночной аварии.
Как выглядит порядок работ
-
Аудит дежурств. Смотрим фактические графики, как передаётся контекст между сменами, сколько сигналов приходит за неделю и какая доля требует вмешательства. На выходе — список зон, где ответственность размыта.
-
Маршрут эскалации. Фиксируем уровни: кто принимает сигнал первым, кому передаёт при молчании, в какой момент подключается руководитель. Отдельная ветка — причина вне зоны ответственности дежурного.
-
Настройка оповещений. Сигналы привязываем к людям и сменам, убираем общие адреса и дубли, разделяем приоритеты: что будит ночью, а что ждёт утра. Ложные срабатывания уходят в отдельный разбор.
-
Учебный вызов. Прогоняем регламент на контролируемом инциденте: доходит ли сигнал до нужного человека, срабатывает ли эскалация, укладывается ли команда в целевое время реакции.
-
Передача регламента. Отдаём документ, схему маршрутов и чек-листы дежурного, разбираем их с командой на живой сессии, а не письмом.
-
Сопровождение. Первые недели разбираем отклонения от регламента и правим формулировки, пока он не станет рабочим инструментом.
Итог — регламент, по которому можно дежурить без устных договорённостей: понятно, кто реагирует, за какое время и что считается нарушением.
Комплект документации: матрица эскалации и регламенты
Документация по дежурствам ценна не объёмом, а тем, что по ней можно действовать в три часа ночи — без автора рядом и без переписки в чате. Поэтому комплект собираем как рабочий инструмент: каждое действие дежурного, эскалатора и руководителя описано до того, как инцидент начался. Ниже — что именно уходит на руки и в каком виде.
- Регламент дежурств — календарь ротаций, длительность смены, правила замен и компенсации переработок, требования к доступности и времени реакции дежурного.
- Матрица эскалации — первая, вторая и третья линии с таймаутами: сколько ждёт дежурный до подъёма следующего уровня, кто вправе остановить релиз или перевести сервис в щадящий режим.
- Инструкция дежурного — пошаговые сценарии на типовые отказы: что проверить, какие панели мониторинга открыть, где граница самостоятельных действий и что делать запрещено.
- Порядок передачи смены — шаблон, куда вносят незакрытые инциденты, запланированные работы и «хвосты» мониторинга; смена считается принятой только после явного подтверждения.
- Журнал инцидентов — единая форма записи: время обнаружения, реагирования и восстановления, влияние на пользователей, рабочая гипотеза причины и фактическая.
- Порядок разбора инцидентов — разбор без поиска виноватых, сроки проведения, что становится отдельной задачей и кто проверяет её выполнение.
- Матрица контактов и доступов — кого из смежных команд, поставщиков и внешних сервисов поднимать по каждому классу отказа и в каком порядке.
- Регламент актуализации — кто и с какой периодичностью пересматривает документы и как в них попадают изменения инфраструктуры, чтобы бумага не расходилась с реальностью.
Кейс: как сократили время реакции дежурной смены
До: обращения терялись между каналами
Дежурная смена существовала, но единой точки входа не было: часть запросов приходила в личные сообщения, часть — в общий чат, что-то всплывало только на утреннем разборе. По нашей оценке за несколько месяцев около 40% обращений вообще не попадали в систему учёта, поэтому метрики дежурств не считались: ни времени до первого отклика, ни доли инцидентов, закрытых на первой линии поддержки.
После: сигнал, ротация, эскалация
Сигналы дежурств перевели в PagerDuty: расписания, подтверждение приёма и эскалация по таймауту — если дежурный не отреагировал, сигнал уходит второму. Для первой линии поддержки собрали чек-листы и короткие инструкции по частым классам отказов, чтобы типовое закрывалось на месте, а не уходило в разработку.
Через два месяца картина такая: время до первого отклика — медиана с 26 до 4 минут, 95-й процентиль с 1 ч 40 мин до 11 минут, доля обращений, оставшихся в личных каналах, — с 40% до 3%. Доля инцидентов, закрытых на первой линии, выросла с 38% до 72%, а число проблем, о которых первыми сообщали пользователи, а не мониторинг, сократилось вдвое.
Эффект дал не инструмент сам по себе, а зафиксированные правила: кто и в какой срок подтверждает сигнал, когда эскалирует, что обязан оставить в заявке после закрытия. Эти же правила стали основой для ежемесячного разбора дежурств — по метрикам видно, какой класс отказов уходит на вторую линию и что стоит закрыть инструкцией.
Чем отличается дежурство по расписанию от круглосуточной поддержки?
Разница начинается с зоны ответственности, а не с графика. Дежурство по расписанию: инженер днём занят разработкой и сопровождением, а в своё окно обязан первым ответить на срабатывание мониторинга и довести инцидент до локализации. Круглосуточная поддержка — это смены, закрывающие все сутки, с первой линией, приёмом обращений и эскалацией на профильных специалистов.
Дежурный по расписанию отвечает только за то, что покрыто правилами мониторинга и проверками доступности. Всё, что не даёт сигнала, живёт в общей очереди задач и разбирается в рабочее время. Круглосуточная смена берёт на себя весь входящий поток, включая обращения, которые ещё не автоматизированы и не описаны регламентом.
Класс отказов определяет выбор. Массовые и хорошо детектируемые сбои — недоступность узла, рост доли ошибок, просадка отклика, расхождение реплик — закрываются дежурством по расписанию: сигнал приходит сам, дежурный реагирует по инструкции. Тихие отказы, единичные жалобы и вопросы по данным требуют живого канала поддержки, иначе они накапливаются до крупного инцидента.
Скорость реакции задаётся не режимом, а временем до обнаружения и глубиной эскалации. В расписании целевое время фиксируется для срабатывания и для взятия инцидента в разбор; в круглосуточной схеме добавляется время ответа на обращение. Нагрузка на команду при ротации из нескольких инженеров с окнами по половине суток остаётся переносимой, а полноценные суточные смены требуют либо расширения состава, либо распределённых смен в разных часовых поясах.
На практике чаще работает гибрид: дежурство по расписанию на инфраструктурные отказы плюс окно поддержки для продуктовых обращений, с единым регламентом эскалации. Мы разбираем, какие классы отказов реально случаются, и под них собираем расписание, инструкции и порядок передачи смены.
Ограничения дежурств и частые технические сомнения
Ограничения дежурств почти всегда упираются в одно и то же: маленькая команда, уже работающий график, сервисы, поделённые со смежными подразделениями, и отпуска в разгар квартала. Ниже — разборы сомнений, которые всплывают до старта, с инженерной логикой, а не обещаниями.
У нас три инженера — дежурства вообще возможны?
Возможны, но режим строится иначе, чем в команде из десяти человек: один основной дежурный, один подстраховка на смещённых часах, ротация по неделе. Ночные вызовы ограничиваем автоматикой — дежурного поднимают только по подтверждённому сигналу, а не по первому отклонению метрики. После ночного разбора инженер выходит из ротации на сутки: иначе график разваливается за месяц.
Дежурства уже есть, но всё держится на устных договорённостях
Снимаем фактическую практику: по журналу оповещений и разборам инцидентов восстанавливаем, кто кого и как поднимает. Дальше сверяем с заявленным — расхождения обычно в уровнях эскалации и таймаутах подтверждения. Итог: регламент описывает то, что команда делает на самом деле, а не то, как удобно нарисовать.
Часть сервисов принадлежит смежным командам
По каждому сервису фиксируем владельца, зону ответственности и точку передачи: с каким таймаутом дежурный эскалирует наружу и кто отвечает за ответ. Стык описывается протоколом, иначе дежурный часами висит на чужом инциденте, а свой не разбирает. Границы согласуем с руководителями смежных команд до публикации документа.
Что делать с отпусками и нежеланием ночных смен?
График строится с учётом отсутствий заранее, подстраховка подставляется до ухода человека, а не в день смены. Ночной формат не обязателен: для части сервисов достаточно дневных окон реагирования, если согласованы допустимые сроки восстановления. Где они жёсткие — оставляем один ночной уровень, остальное уходит в рабочее время.
Обсудим задачу: план дежурств и оценка сроков
Чтобы план дежурств был рабочим, а не декларативным, на первом разговоре уточняем несколько вещей: какие сервисы закрывает on-call, нужен ли круглосуточный режим или достаточно часов поддержки, как сейчас приходят сигналы об инцидентах и кто вправе приостановить релиз. Отдельно разбираем роли — первичный дежурный, эскалация, ответственный за связь с бизнесом — и уровень доступа, который нужен каждому.
По итогам обсуждения присылаем не общие формулировки, а конкретный набор:
- схема дежурств с ротациями, выходными и правилами подмены — график не разваливается в отпусках и на больничных;
- матрица эскалации: уровень, время реакции, кому передаётся инцидент и в какой момент;
- этапы внедрения процедур со сроками и точками согласования на каждом шаге;
- порядок передачи документации: какие артефакты, в каком виде и кто их принимает;
- шаблоны инструкций по типовым инцидентам — дежурный действует по шагам, а не по памяти;
- регламент пост-разбора: что фиксируем после сбоя и как правки попадают в документацию.
Опишите задачу: какие сервисы в контуре, как устроены дежурства сейчас и что мешает. Вернёмся с оценкой сроков, схемой дежурств и планом этапов внедрения.
