Дежурство без выгорания для команды из пяти инженеров

Почему маленькие команды выгорают на дежурствах

В команде из пяти человек каждое оповещение бьёт сильнее. Один человек теряет сон. Другой должен покрыть плановую работу на следующий день. Остальные почти сразу чувствуют пробел.

Крупные команды могут распределить эту боль. Маленькие — нет.

Цена — не только время на исправление. Нарушенный сон проявляется позже в виде замедленного мышления, раздражительности и небрежных решений. 15‑минутное оповещение в 2:00 ночи может испортить половину следующего дня. Если это случается дважды за неделю, люди перестают доверять расписанию и начинают бояться своей очереди.

Выходные утомляют по‑другому. Даже когда ничего не ломается, дежурный часто остаётся в режиме ожидания: рядом с ноутбуком, без долгих планов и с ухом, подслушивающим уведомления. Это фоновое напряжение накапливается. Оно же рождает раздражение к системам, которые тревожат по шуму вместо реальных проблем клиентов.

В маленьких командах меньше места и для нечёткой ответственности. Если оповещение сработало и никто точно не знает — приложение, база, очередь или облако виноваты — восстановление идёт медленно. Люди будят не того коллегу, повторяют одни и те же проверки и угадывают в спешке. Выгорание растёт от этой модели: одна плохая ночь тяжела, а повторяющаяся беспорядочная ночь — истощает по‑настоящему.

Решение скучное — и в этом его сила. Меньше оповещений. Очевидная ответственность за каждую проблему. Короткий путь от оповещения до первого шага. Когда оповещения тише, ответственность ясна, а восстановление быстрее — выходные снова начинают казаться выходными.

Как выглядит хорошее покрытие

Команда из пяти человек должна покрывать отказы, которые прямо сейчас вредят пользователям, а не каждое сообщение, пришедшее вне часов работы. Если всё срочно — ничего не срочно.

Начните с явного перечисления того, что должно кого‑то разбудить. Для большинства команд список короткий: продукт недоступен, не работают вход/оплата, есть риск потери данных или проблема с безопасностью. Медленный отчёт, опечатка или разовый запрос клиента могут подождать рабочее время.

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

Три приоритета обычно хватает. P1 — сервис упал, клиенты не могут пройти основной путь, есть риск потери данных или проблема с безопасностью. Ответ в течение 15 минут в любое время. P2 — ключевая функция деградировала, есть обходной путь: ответ в течение часа днём и до следующего утра ночью или в выходные. P3 — низкоимпактные баги, внутренние запросы и уборочные работы — остаются на рабочие часы.

Держите правила конкретными. Большинство маленьких команд справляются с тремя‑четырьмя уровнями приоритетов; многим и трёх достаточно.

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

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

Так вы защищаете бизнес, не реагируя на каждую внерабочую проблему как на пожар.

Постройте ротацию, с которой можно жить

Команда из пяти человек не должна вести себя как полноценный саппорт‑департамент. Если все постоянно наполовину в дежурстве, никто по‑настоящему не отдыхает.

Простая схема работает лучше: один primary на неделю, один backup и один человек полностью вне ротации. Двое остальных работают обычные часы и могут помочь днём, но не несут ночную ответственность. Та самая «полная неделя вне ротации» важнее, чем кажется: она даёт полноценный перерыв от стресса пейджера и привычки «проверить на всякий случай».

Еженедельная ротация обычно — золотая середина. Ежедневные передачи выглядят справедливо на бумаге, но дают больше путаницы, потерянного контекста и моментов «я думал, что это твоя задача». Полная неделя даёт primary время разобраться в текущем состоянии системы, заметить повторяющиеся проблемы и войти в рутину.

Пятинедельный цикл остаётся простым. В неделю одну Alex — primary, Sam — backup, Priya вне ротации. На второй неделе Sam становится primary, Priya — backup, Jordan — вне ротации. На третьей Priya — primary, Jordan — backup, Alex вне ротации. На четвёртой Jordan — primary, Mei — backup, Sam вне ротации. На пятой Mei — primary, Alex — backup, Priya вне ротации.

Этот узор легко запомнить: люди могут планировать выходные, поездки и глубоко сосредоточиться, не догадываясь, кто в дежурстве.

Напишите правила обмена до того, как кому‑то понадобится одолжение. Если ждать, пока кто‑то заболеет или будет семейное событие, разговор быстро становится неловким. Правила простые: по возможности меняйте целые недели, просите заранее, добивайтесь согласия бэкапа до изменения, сразу обновляйте общий календарь и сохраняйте ответственность текущего primary до подтверждённой передачи.

Больше всего людей защищает не хитрый график, а меньшее число передач и ясная ответственность. Люди справятся с тяжёлой неделей время от времени. Что их изматывает — покрытие, которое кажется путаным и никогда не кончается.

Пишите инструкции, которыми люди будут пользоваться

У инструкции одна задача: помочь сонному инженеру сделать первый безопасный шаг за минуту.

Если человека разбудили в 2:00, ему не должно приходиться догадываться, искать в чате или вспоминать то, что слышал шесть месяцев назад. Начните с одной страницы на сервис: назовите сервис, опишите его одну строкой и укажите владельца или запасного владельца. В маленькой команде это само по себе снимает много стресса — люди знают, к кому обратиться с редким вопросом.

Каждое руководство должно покрывать один и тот же небольшой набор деталей: первые проверки, самые вероятные причины, точный шаг отката или отключения, команда или дашборд для использования, где лежат логи и когда on‑call должен будить кого‑то ещё.

Простой язык лучше идеальной теории. Пишите первый шаг так, как вы написали бы коллеге в чате: «Сначала проверьте уровень ошибок. Если он прыгнул после последнего деплоя — откатьте релиз.» Это гораздо полезнее, чем гора теории.

Держите всё в одном месте. Если инструкция говорит «открыть Grafana», укажите имя дашборда. Если «проверить логи» — укажите сервис и фильтр. Команды, которые используют Grafana, Prometheus и Sentry, должны перечислить точные сохранённые представления или названия запросов, а не просто инструмент. Маленькие пробелы тратят больше всего времени.

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

Пересматривайте руководство после каждого реального пейджа. Убирайте устаревшие шаги, добавляйте подсказку, которая действительно помогла, и сокращайте всё, чем никто не пользовался. Эта привычка делает больше, чем написание огромного справочника один раз и забывание о нём.

Обрежьте оповещения до телефона

Большинство маленьких команд не имеют проблемы инцидентов. У них проблема фильтрации.

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

Это особенно важно в пятерке. Один шумный уикенд может отравить оставшуюся часть месяца.

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

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

Группировка важнее, чем многие думают. В Prometheus, Grafana или Sentry одно замедление базы может вызвать несколько тревог. Дежурному не нужно пять звонков. Ему нужен один инцидент с достаточным контекстом, чтобы начать работу.

Тихие часы тоже помогают. Если заполнение диска растёт, но до 9:00 ещё много резерва — пусть подождёт. Ночные звонки сохраняйте для проблем, которые живы, видимы и ухудшаются.

Жёсткий тест очистки работает: посмотрите последние 20 оповещений и спросите: «Кто‑то сделал явное действие из‑за этого?» Если нет — поменяйте или удалите.

Внедряйте по шагам

Начните с малого. Если пытаться переделать все сервисы, оповещения и передачи за одну неделю, команда устанет ещё до старта ротации.

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

Запишите, сколько пейджей получил каждый человек за эту неделю. Разделите счёт на общее количество и количество после полуночи. Эти числа рассказывают разные истории: десять дневных оповещений могут надоедать, а два оповещения в 2:00 ночи могут испортить уикенд.

Затем почините самое шумное оповещение до добавления новых правил. Худший нарушитель часто — оповещение с низким сигналом, которое срабатывает, очищается и снова срабатывает. Затяните порог, добавьте временное окно или удалите, если никто на него не реагирует.

Создайте короткую инструкцию для выбранного сервиса. Держите её простой: что ломалось раньше, что проверять в первую очередь, как подтвердить влияние на клиента и когда эскалировать. Если инженер не сможет использовать её полусонный — она слишком длинная.

Заканчивайте каждую дежурную неделю короткой заметкой о передаче. Кратко: открытые вопросы, нестабильные оповещения, недавние деплои и всё, что может разбудить следующего человека. Затем проверьте эту заметку: попросите следующего инженера следовать ей и указать, чего не хватает.

Пропустите две‑три ротации перед окончательной оценкой. Потом меняйте порядок, правила бэкапа или времена на основе реальных данных, а не догадок.

Такой постепенный запуск работает лучше, чем большой политический документ. Маленькие команды учатся больше на одном шумном сервисе, чем на десяти чистых диаграммах. Если вы уже отслеживаете ошибки и аптайм в Sentry, Grafana или Prometheus — используйте эти данные, чтобы держать настрой честным. Цель проста: меньше неожиданных звонков, спокойнее выходные и ротация, которой люди не боятся.

Пример уикенд‑инцидента, обработанного правильно

Суббота, 8:12 утра: джоб платежей начал падать после небольшой смены конфигурации. Заказы по‑прежнему приходят, но расчёты перестали двигаться. Оповещение идёт только primary, и только ему. Другие не получают шумного пробуждения из‑за проблемы, которую один инженер, скорее всего, починит за пару минут.

Оповещение короткое и полезное: написано, что воркер платежей провалился три раза подряд, указано затронутое сервис и имя инструкции.

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

В логах инженер видит ошибку парсинга, связанную с утренним деплоем. Инструкция предлагает подтвердить, застряли ли платежи или только задерживаются. Быстрая проверка показывает около 40 заказов в очереди, без двойных списаний и без потерянных данных. Это важно: задержка серьёзна, но отличается от порчи данных.

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

Это важно: бэкап должен помогать, когда primary застрял, когда проблема распространяется или когда исправление может усугубить ситуацию. Бэкап не должен подключаться по умолчанию только потому, что сработало оповещение.

В понедельник команда вносит небольшое обновление в инструкцию: добавляет точный фильтр логов, который и показал ошибку парсинга, чтобы следующий человек нашёл её за секунды, а не искал. Маленькие правки вроде этой делают больше, чем длинные постмортемы. Со временем они превращают уикенд‑реагирование из командного потрясения в короткую, локализованную задачу.

Ошибки, которые рушат расписание

Большинство расписаний ломаются задолго до того, как кто‑то увольняется. Они ломаются, когда телефон звонит из‑за шума, когда никто не доверяет передаче, и когда один маленький баг будит половину команды.

Самый быстрый способ испортить ротацию — слать на телефон каждую ошибку. Упавшая фонова задача, один медленный запрос или ретрай, который самоисцелился — не должны будить человека. Звоните только по проблемам, которые клиенты ощущают прямо сейчас, или по тем, что скоро превратятся в боль для клиента.

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

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

Многие команды тоже зовут двух‑трёх человек на одну проблему. Это паника, а не процесс. Один человек должен владеть первичным откликом. Он может подключить второго, только если в инструкции есть чёткая причина, например риск потери данных или сломанный платёжный поток.

Внутренним инструментам нужен более высокий порог, чем внешним. Если внутренняя панель упала в полночь, но клиенты по‑прежнему могут купить и войти, это может подождать до утра. Отношение ко всем внутренним сбоям как к публичным аутейджам обучает команду думать, что приоритеты — фикция.

Простой здравый смысл помогает: заметит ли клиент это прямо сейчас? Под угрозой ли деньги, данные или безопасность? Может ли один человек следовать записанному сценарию? Что ухудшится, если отложить до утра?

Если на большинство вопросов ответ — «нет», не звоните. Защита выходных часто не про героизм, а про спокойное «это может подождать».

Проверки перед запуском

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

Начните с страниц за прошлый месяц. Посчитайте, сколько оповещений сработало, затем пометьте, сколько из них было шумом. Если половина пейджей не требовала человека — исправляйте это сначала. В пятёрке у команды недостаточно запаса, чтобы долго нести усталость от оповещений.

Короткая предпусковая проверка работает: посчитайте общее количество пейджей за месяц и отметьте ложные срабатывания. Убедитесь, что у каждого оповещения есть один явный владелец, а не «команда». Откройте три случайных руководства и засеките, сколько времени занимает поиск первого шага. Проверьте недели отпусков и назовите бэкапа на каждую дыру. Попросите каждого инженера объяснить ротацию за минуту: кто меняет смены и когда начинается эскалация.

Этот тест руковoдств важнее, чем ожидают. Если кто‑то открыл инструкцию в 2:10 и тратит пять минут на поиск первой команды — документ провалился. Хорошие инструкции начинаются с первого безопасного шага, ожидаемого результата и момента, когда стоит будить кого‑то ещё.

Сделайте одну сухую прогонку перед первой полной неделей. Выберите небольшой инцидент, отправьте пейдж и наблюдайте. Если люди колеблются, спорят о покрытии или не могут объяснить ротацию — приостановитесь и исправьте. Этот час уборки делает больше, чем любой красивый график.

Что делать дальше

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

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

Короткий ревью в конце месяца хватает. Сохраняйте те оповещения, которые приводят к действию в считанные минуты. Удаляйте или понижайте важность оповещений, которые люди постоянно закрывают без действий. Почините самую повторяющуюся проблему прежде, чем добавлять новые правила. Проверьте, не тащил ли кто‑то более тяжёлые смены, чем остальные.

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

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

Иногда команде нужен внешний обзор, потому что они слишком близки к проблеме. Oleg Sotnikov на oleg.is делает такую работу как fractional CTO, особенно для небольших компаний: он помогает чистить оповещения, передачи и руковoдства, одновременно двигаясь к более AI‑помогающим операциям. Короткий обзор может поймать шумные правила пейджинга, тонкие инструкции и пробелы в расписании до того, как каждый уикенд превратится в пожарную тревогу.