Как организовать on-call дежурства и не выгореть

On-call дежурство — это не «кто сегодня не спит», а процесс, который помогает команде быстро реагировать на инциденты и при этом сохранять нормальный рабочий ритм. Если дежурство устроено плохо, оно превращается в круглосуточную тревожность: телефон рядом с подушкой, ложные алерты ночью, неясные зоны ответственности и ощущение, что продакшен держится на героизме.

Хорошее on-call дежурство строится иначе: понятные сервисы, расписание, правила эскалации, алерты только по значимым для пользователей проблемам, runbook'и и культура постмортемов без поиска виноватых. Такой подход близок к SRE — не просто «чинить падения», а управлять надежностью как инженерной системой.

Ниже — практическая схема, как организовать дежурства для сайта, API, SaaS-сервиса или внутренней платформы и не довести команду до выгорания.

Что такое on-call дежурство и зачем оно нужно

On-call дежурство — это период, когда конкретный инженер или группа инженеров отвечает за первичную реакцию на инциденты вне обычного рабочего потока. Дежурный получает алерт, оценивает ситуацию, выполняет первые действия, при необходимости эскалирует проблему и координирует восстановление.

Главная цель — сократить время обнаружения и реакции. Но это не значит, что любой сбой должен будить человека ночью: дежурство оправдано там, где простой или деградация реально влияет на пользователей, деньги, безопасность или обязательства по SLA.

Типичные задачи дежурного:

• подтвердить, что проблема реальна, а не false positive;
• понять масштаб: один пользователь, регион, сервис, вся система;
• стабилизировать сервис: откатить релиз, переключить трафик, увеличить лимиты, отключить проблемную фичу;
• собрать факты для последующего расследования;
• уведомить заинтересованных людей;
• передать инцидент профильной команде, если причина вне зоны ответственности.

On-call не должен быть заменой нормальной инженерии. Если дежурный каждую ночь вручную перезапускает один и тот же сервис, это не «хорошая реакция», а незакрытый технический долг. Если алерты сыпятся сотнями, проблема не в дежурном, а в системе мониторинга.

Когда on-call действительно нужен

Не каждому проекту нужно круглосуточное дежурство. Для лендинга, личного блога или небольшого внутреннего инструмента часто достаточно мониторинга доступности, уведомлений в рабочее время и понятного плана восстановления. Для интернет-магазина, B2B-сервиса, платежной системы или API, от которого зависят клиенты, on-call становится частью операционной модели.

Чтобы понять, нужно ли дежурство, ответьте на несколько вопросов.

1) Есть ли критичные пользовательские сценарии — например, регистрация, авторизация, оплата, оформление заказа, загрузка документов, вызов API. Если их отказ ночью приводит к потерям или нарушению обязательств, нужна реакция вне рабочего времени.

2) Есть ли измеримые SLO — надежность лучше обсуждать не словами «сайт должен работать всегда», а через показатели доступности, задержки и ошибок. Если команда уже использует SLI/SLO/SLA, дежурство привязывается к ним: реагируем на то, что сжигает error budget, а не на каждый всплеск CPU. Подробнее о различиях между этими понятиями — в статье «Что такое SLI, SLO и SLA».

3) Можно ли восстановить сервис без эксперта — если для любого инцидента нужен один конкретный разработчик, on-call будет токсичным. Перед запуском дежурств документируйте типовые действия, доступы и владельцев сервисов.

4) Есть ли техническая база — мониторинг, логи, трассировки, health checks, статус внешних зависимостей, история релизов. Без наблюдаемости дежурный будет просыпаться не для решения проблемы, а для гадания.

5) Понятна ли цена простоя — если бизнес не может объяснить, сколько стоит час недоступности, команда не сможет разумно выбрать уровень дежурства. Иногда достаточно реакции утром, иногда нужна сменная модель 24/7.

Для проверки внешней доступности сайта полезен отдельный uptime monitoring: сервис с заданным интервалом проверяет URL и присылает уведомление о сбое. Это не заменяет внутренние метрики, но помогает быстро увидеть проблему глазами пользователя. О принципах такого подхода — в статье «Что такое uptime monitoring и как он работает».

Как построить ротацию без перегруза

Расписание — первая точка, где on-call дежурство либо становится устойчивым процессом, либо ломает людей. Главный принцип: дежурство должно быть предсказуемым, справедливым и ограниченным по нагрузке.

1) Делайте короткие смены — неделя on-call часто удобна организационно, но тяжела психологически, особенно если алерты бывают ночью. Для небольших команд можно начать с недельной ротации, но отслеживать фактическую нагрузку. Если тревог много, лучше переходить на более короткие интервалы: сутки, будни/выходные, дневная и ночная смена.

2) Разделяйте primary и secondary — основной дежурный принимает алерт и начинает разбор, резервный подключается, если primary не отвечает, устал или нужна помощь. Secondary — не декоративная роль, а реальная страховка.

3) Фиксируйте правила эскалации — кто отвечает за базу данных, кто за сеть, кто за платежи, кто за инфраструктуру. У дежурного не должно быть задачи «найти в чате хоть кого-нибудь»: карта владельцев сервисов должна быть готова заранее.

4) Учитывайте отпуска, болезни и часовые пояса — расписание должно быть доступно всей команде. Нельзя строить процесс на устных договоренностях вроде «кажется, сегодня дежурит Петя». Используйте календарь, систему инцидент-менеджмента или хотя бы общую таблицу с ответственными.

5) Компенсируйте нагрузку — если человек работал ночью, он не должен утром в 9:00 вести планерку как ни в чем не бывало. Нужны отгулы, сдвиг рабочего дня или финансовая компенсация. Без этого on-call быстро воспринимается как скрытая переработка.

6) Не ставьте новичка одного — новый инженер сначала наблюдает, затем дежурит вместе с опытным коллегой и только потом выходит в самостоятельную смену. Иначе первый же ночной инцидент станет стресс-тестом не системы, а человека.

Для команды из 3–5 человек честнее признать ограничения: настоящее 24/7 покрытие с малым числом людей почти всегда приводит к усталости. В таком случае лучше сократить список ночных алертов до критичных, автоматизировать восстановление и договориться с бизнесом о реалистичных SLO.

Алерты: будить только по делу

Самая частая причина выгорания на on-call — плохие алерты. Если дежурного будят из-за краткого скачка CPU, единичного 500, перезапуска контейнера без влияния на пользователей или истекающего через месяц сертификата, команда быстро перестает доверять мониторингу.

Хороший алерт должен отвечать на три вопроса: что сломалось, как это влияет на пользователей и что делать в первые 5–10 минут. Если ответов нет, это не алерт, а шум.

1) Алерт должен быть actionable — по нему можно выполнить действие: откатить релиз, включить резерв, почистить очередь, увеличить лимит, отключить фичу, позвать владельца. Если действие не требуется, событие лучше отправлять в лог, дашборд или дневной отчет.

2) Ночные алерты — только по критичному влиянию — недоступность сайта, массовые ошибки авторизации, рост 5xx, отказ платежей, переполнение очереди с потерей данных, деградация latency на критичном API. Все остальное можно разбирать утром.

3) Используйте SLO и burn rate — SRE-подход помогает не реагировать на каждую точку графика, а смотреть, насколько быстро система тратит бюджет ошибок. Если SLO нарушается быстро, алерт срочный, если медленно — можно создать тикет. Подробнее об этом — в статье «Что такое burn rate alerts и почему их рекомендует Google SRE».

4) Уменьшайте ложные срабатывания — добавляйте пороги по времени, проверку из нескольких локаций, дедупликацию и подавление зависимых алертов. Если упала база, не нужно отдельно будить за каждый сервис, который начал отдавать ошибки из-за этой базы.

5) Разделяйте каналы уведомлений — критичные инциденты идут в звонок, push или SMS, предупреждения — в мессенджер, информационные события — в канал наблюдаемости или тикеты. Один общий чат для всего быстро превращается в шум.

Если алерты уже раздражают команду, стоит пересмотреть правила — хорошая отправная точка — материал «Как строить алерты, которые не раздражают».

Runbook'и, доступы и автоматизация

Дежурный не должен вспоминать ночью, где лежат логи, как перезапустить сервис и у кого доступ к панели провайдера — все типовые действия нужно описать заранее.

Runbook — это короткая инструкция для конкретной проблемы или сервиса: не документация на 40 страниц, а практический сценарий — симптомы, проверки, команды, возможные причины, безопасные действия, критерии эскалации.

Хороший runbook содержит:

• название сервиса и владельцев;
• ссылки на дашборды, логи, трассировки;
• команды диагностики;
• список частых причин;
• действия, которые можно выполнять без согласования;
• действия, которые требуют подтверждения;
• контакты для эскалации;
• ссылку на прошлые инциденты по теме.

Пример структуры без лишней формальности:

• симптом: 5xx > 5% на /api/checkout;
• проверить: ошибки приложения, состояние базы, очередь заказов, последний релиз;
• быстрые действия: отключить feature flag новой оплаты, откатить деплой, перевести платежи на резервного провайдера;
• эскалация: команда платежей, владелец базы, менеджер продукта;
• коммуникация: обновить статус-страницу, написать в канал инцидента.

Доступы тоже должны быть готовы заранее. Если ночью выясняется, что у дежурного нет прав на kubectl, SSH, облачную консоль, CI/CD или систему feature flags, процесс не работает. При этом доступы не должны быть безграничными: используйте роли, аудит, временные привилегии и принцип минимально необходимого доступа.

Автоматизация снижает нагрузку: типовые операции можно оформлять в безопасные скрипты, кнопки в панели, runbook automation или CI/CD jobs — перезапуск воркеров, переключение read replica, очистка зависших задач, включение maintenance mode. Но автоматизация должна быть предсказуемой: дежурный обязан понимать, что именно делает кнопка.

Что делать во время инцидента

Во время инцидента легко начать хаотично переключаться между чатами, графиками и гипотезами — нужен простой порядок действий.

1) Подтвердить проблему — проверить внешний симптом: сайт не открывается, API отдает 500, растет latency, не проходят платежи. Если алерт пришел от внешнего мониторинга (например, Statuser), сопоставьте его с внутренними метриками, логами и статусом инфраструктуры.

2) Оценить масштаб — проблема у всех или у части пользователей? Один регион или все? Один endpoint или весь сервис? Есть ли влияние на данные? Это помогает выбрать уровень инцидента.

3) Создать канал инцидента — отдельный чат или тред, где фиксируются факты, решения и время. Не стоит вести расследование в общем канале разработки: там быстро теряется контекст.

4) Назначить роли — даже в небольшой команде полезно разделить функции: incident commander координирует, responder чинит, communicator пишет обновления, scribe фиксирует таймлайн. Один человек может совмещать роли, но они должны быть названы.

5) Сначала стабилизировать, потом искать корень — если сервис лежит после релиза, часто правильнее откатить изменения, а не сразу искать точную строку кода. Root cause analysis можно сделать после восстановления.

6) Коммуницировать коротко и регулярно — пользователям и бизнесу не нужен поток технических деталей, им нужны статус, влияние, временные обходные пути и следующее обновление. Если у сервиса есть статус-страница, обновляйте ее по фактам.

7) Фиксировать все действия — кто что сделал, когда, какой был эффект. Это снижает риск повторных действий и помогает в постмортеме.

Для небольших команд полезен отдельный процесс инцидент-менеджмента: уровни серьезности, роли, шаблоны сообщений, правила эскалации. Подробная схема — в статье «Инцидент-менеджмент для небольших команд».

После инцидента: постмортем без поиска виноватых

On-call дежурство становится легче не потому, что команда «привыкает к ночным алертам», а потому что каждый инцидент уменьшает вероятность повторения. Для этого нужен постмортем.

Постмортем — это разбор случившегося: что произошло, как обнаружили, как реагировали, почему система допустила сбой и какие действия предотвратят повтор. Цель — улучшить систему, а не найти виновного.

В постмортеме стоит фиксировать:

• таймлайн событий;
• пользовательское влияние;
• факторы, которые ускорили восстановление;
• факторы, которые мешали;
• технические причины;
• организационные причины;
• список follow-up задач с владельцами и сроками.

Фраза «инженер ошибся при деплое» почти никогда не является полноценной причиной. Лучше спрашивать глубже: почему деплой мог нарушить работу? Почему тесты не поймали проблему? Почему не было canary? Почему откат занял 40 минут? Почему алерт пришел позже жалобы клиента?

Постмортем должен приводить к изменениям: новый алерт, улучшенный runbook, автоматический rollback, feature flag, лимит, тест, дашборд, изменение процесса релиза. Если разборы не создают задач или задачи не закрываются, команда быстро перестает видеть в них смысл.

Хороший шаблон и примеры — в статье «Как писать постмортемы».

Как не выгореть на on-call

Выгорание редко возникает от одного тяжелого инцидента. Чаще его создают постоянная непредсказуемость, чувство одиночной ответственности и отсутствие улучшений после сбоев. Команда выдерживает напряженные периоды, если видит контроль над ситуацией, и ломается, когда ночь за ночью тушит одни и те же пожары.

1) Ограничьте число ночных пробуждений — заведите правило: каждый ночной алерт разбирается отдельно. Если он был не нужен, его нужно удалить, понизить приоритет или изменить порог. Ночной шум нельзя считать нормой.

2) Давайте восстановление после смены — дежурный после тяжелой ночи должен иметь право начать позже, отменить встречи или взять отгул. Это не бонус, а часть устойчивого процесса.

3) Ротируйте знания, а не только людей — если один человек понимает базу данных, а другой — только фронтенд, формальная ротация не поможет. Нужны парные разборы, внутренние демо, документация, совместные дежурства.

4) Уменьшайте blast radius — чем меньше область поражения у ошибки, тем меньше стресс. Помогают feature flags, canary deploy, blue-green deployment, rate limits, circuit breaker, изоляция очередей, резервные зависимости.

5) Не героизируйте ночную работу — культура «спасателей продакшена» выглядит эффектно, но дорого обходится. Ценить нужно не бессонные ночи, а изменения, после которых алерт больше не повторяется.

6) Держите реалистичные SLO — обещание «100% доступности» почти всегда превращается в бесконечное давление. SLO должен отражать ожидания пользователей и возможности системы: error budget помогает говорить о надежности предметно и решать, можно ли ускорять релизы или нужно заняться стабильностью.

7) Следите за нагрузкой на дежурных — считайте количество алертов, ночных пробуждений, среднее время реакции, число эскалаций, повторяющиеся причины. Эти метрики нужны не для контроля людей, а для улучшения процесса.

8) Убирайте хронические источники боли — если сервис регулярно падает из-за нехватки соединений к базе, утечек памяти, переполнения диска или проблемного cron, это должно попасть в инженерный план. Иначе on-call превращается в ручную компенсацию архитектурных проблем.

Выгорание предотвращается не мотивационными встречами, а инженерными решениями: меньше шума, меньше ручной работы, понятные зоны ответственности, право на отдых и реальное исправление причин.

Минимальный план внедрения

Если дежурств еще нет, не нужно сразу строить сложную SRE-платформу. Начните с минимального набора, который даст контроль и не перегрузит команду.

1) Определите критичные сервисы — сайт, API, база, очередь, платежи, авторизация, внешние зависимости. Для каждого назначьте владельца.

2) Выберите пользовательские сигналы — доступность, 5xx, latency, успешность ключевых операций. CPU и RAM полезны для диагностики, но не всегда подходят для ночных алертов.

3) Настройте мониторинг доступности и внутренние метрики — внешняя проверка покажет, что видит пользователь, а внутренние метрики помогут понять причину. При выборе частоты проверок учитывайте критичность сервиса и допустимое время обнаружения; подробнее — в статье «Как выбрать интервал проверки сайта».

4) Создайте расписание primary/secondary — опубликуйте его, добавьте правила замены и эскалации.

5) Напишите первые runbook'и — не для всего сразу, а для 5–10 самых вероятных проблем: сайт недоступен, много 500, база не отвечает, очередь растет, сертификат истек, диск заполнен.

6) Проведите тренировочный инцидент — симуляция показывает пробелы лучше любой встречи. Проверьте, доходят ли уведомления, есть ли доступы, понятны ли роли, работает ли эскалация.

7) Разбирайте каждый серьезный случай — даже короткий постмортем лучше, чем устное «ну, вроде починили». Главное — закрывать follow-up задачи.

8) Пересматривайте процесс раз в месяц — какие алерты были шумными, где не хватило доступа, какие runbook'и устарели, кто перегружен, какие сервисы требуют инженерных улучшений.

Если сайт уже упал и нужен быстрый порядок действий, пригодится отдельный чеклист: «Что делать, если упал сайт». Его можно адаптировать как первый runbook для дежурного.

FAQ

Что лучше: дежурство всей командой или отдельной SRE-группой?

Зависит от размера и зрелости продукта. На раннем этапе лучше, чтобы разработчики участвовали в дежурствах за свои сервисы: так быстрее закрывается технический долг. В больших системах SRE-команда может вести платформу и процесс, но владельцы сервисов все равно должны участвовать в эскалации.

Нужно ли будить дежурного из-за роста CPU?

Обычно нет, если нет пользовательского влияния. Рост CPU может быть диагностическим сигналом, но ночной алерт лучше привязывать к ошибкам, latency, недоступности, saturation критичного ресурса или быстрому сжиганию error budget.

Как часто нужно менять расписание on-call?

Расписание должно быть стабильным, но не застывшим. Пересматривайте его при изменении состава команды, росте числа сервисов, увеличении ночных алертов и после отпусков. Если один человек регулярно получает больше нагрузки, ротацию нужно менять.

Что делать, если команда слишком маленькая для 24/7?

Сократите ночные алерты до действительно критичных, автоматизируйте восстановление, настройте внешнюю проверку доступности, договоритесь о реалистичных SLO и явно зафиксируйте часы поддержки. Псевдо-24/7 на двух людях почти всегда заканчивается выгоранием.