Яуволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.

Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.

Признаки токсичной ротации

Вы знаете, что у вас проблемы с on‑call, если:

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

В команде есть «герои». «Да ладно, я подежурю за Васю, у него ребенок маленький». «Давайте я возьму выходные, я все равно дома сижу». Герои — это первый признак того, что система не работает. Они выгорают первыми и уходят внезапно, оставляя за собой дыру, которую некому закрыть.

Люди не берут отпуска. «А кто будет дежурить?» — самый страшный вопрос в команде. Если человек не может спокойно уйти в отпуск, потому что некому передать дежурство, у вас большие проблемы.

Ночные вызовы — это норма. Если фраза «ну это же дежурство, конечно тебя будут будить ночью» звучит нормально, пора менять работу. Или процессы. Лучше процессы.

Я видел все эти признаки. Более того, я сам был тем «героем», который дежурил по две недели подряд, потому что «команда маленькая, надо помогать друг другу». Знаете, чем это закончилось? Правильно, выгоранием и увольнением.

Модели ротаций: что работает, а что нет

За годы я перепробовал все модели ротаций. Некоторые работают. Некоторые — путь в ад.

Follow-the-sun: мечта, которая редко работает

Идея прекрасна: команда в Сан‑Франциско дежурит днем по своему времени, передает дежурство в Лондон, те — в Сингапур, и так по кругу. Никто не просыпается ночью, все счастливы.

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

Я видел, как follow‑the‑sun работает ровно в одной компании. У них было 300 SRE‑инженеров по всему миру, единая кодовая база и два года потраченные на отладку процессов. У вас есть 300 SRE? Нет? Забудьте про follow‑the‑sun.

Primary/Secondary: спасательный круг, который работает

Эта модель спасла мою команду от развала. Принцип простой: есть основной дежурный (primary) и подстраховщик (secondary). Primary получает все алерты. Если он не отвечает 15 минут — алерт идет на secondary.

Почему это работает:

• Primary может спокойно принять душ, зная что мир не рухнет

• Secondary обычно спит спокойно, но знает, что может понадобиться

• Можно спокойно сходить в кино в свою неделю дежурства (secondary прикроет)

• Новички могут быть secondary, учась у опытных primary

У нас был случай: primary застрял в лифте как раз когда production упал. Secondary подхватил алерт, все починил, primary даже не успел запаниковать. Система работает!

Volunteer basis: когда у вас много денег

«Кто хочет подежурить в выходные за $1000?» — этот вопрос в Slack всегда находит ответ. Удивительно, как деньги меняют отношение к дежурствам.

Мы ввели эту систему в стартапе, где было критично покрытие 24/7, но команда была маленькая. $500 за будни, $1000 за выходные, $2000 за праздники. Дорого? Да. Но дешевле, чем потерять всю команду от выгорания.

Главное правило: это должно быть действительно добровольно. Никакого «ну ты же понимаешь, надо». Не хочешь — не дежуришь. Точка.

Компенсация: деньги решают не все, но многое

Давайте честно: дежурства — это переработка. И она должна компенсироваться. Я видел разные подходы.

Time off: отдых за бессонные ночи

Простое правило: проснулся ночью на алерт — завтра начинаешь работу позже на столько же времени. Потратил 2 часа с 3 до 5 утра на инцидент — приходишь на работу в 11, а не в 9.

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

Денежная компенсация: сколько стоит ваш сон

Средние цифры по рынку (из моего опыта):

• США: $500-1500 в неделю

• Европа: €400-1000 в неделю

• Россия: ₽30,000-70,000 в неделю

Но есть нюанс. В одной компании платили $2000 в неделю за дежурство. Звучит круто? А теперь представьте, что вас будят каждую ночь по 3–4 раза. За $2000. Это примерно $70 за ночь нормального сна. Дешево продаете свое здоровье.

Ограничения: сколько можно дежурить

Максимум 1 неделя из 4 — это золотой стандарт. Если дежуришь чаще — выгорание гарантировано.

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

Инструменты поддержки: как сделать дежурство терпимым

Runbooks: инструкция для зомби

В 3 часа ночи ваш мозг работает на 20% мощности. Вы — зомби. И runbook должен быть написан для зомби.

Плохой runbook: «Проверьте состояние системы и примите appropriate меры».

Хороший runbook:

1. Скопируйте эту команду: kubectl get pods -n production | grep -v Running
2. Если есть поды в состоянии Error, скопируйте: kubectl delete pod <имя_пода> -n production
3. Подождите 60 секунд
4. Если проблема не решена, звоните Team Lead: +1-234-567-890

Каждый шаг — это конкретное действие, которое можно выполнить не думая.

Автоматизация: робот — лучший дежурный

Мы автоматизировали 80% типичных проблем. Диск заполнился? Скрипт чистит логи. Память течет? Автоматический рестарт. База тормозит? Запускается vacuum.

Первый месяц после внедрения автоматизации количество ночных вызовов упало с 15 до 3 в неделю. Это 12 спокойных ночей для дежурного!

Эскалация: когда пора звать взрослых

Четкие правила эскалации спасают жизни и карьеры:

• 30 минут не можешь решить — зови secondary

• Проблема с данными клиентов — сразу зови team lead

• Больше 100 пользователей affected — зови VP of Engineering

• Не знаешь что делать — ВСЕГДА зови кого‑то

У нас был junior, который 3 часа пытался починить production сам, потому что «не хотел беспокоить». В итоге беспокоил CEO, который узнал о 3-часовом простое от клиентов. Не будьте как тот junior.

Истории с передовой

История первая: неделя из ада

Это было в моей второй компании. Маленький стартап, 5 инженеров, дежурим по очереди. Моя неделя началась в понедельник в 2 ночи с алерта «Database connection pool exhausted». Починил, лег спать.

Вторник, 3:30 — «Out of memory». Среда, 1:15 — «API timeout». Четверг, 4:45 — «Disk full». К пятнице я был овощем. В субботу я проспал три алерта подряд. PagerDuty названивал 40 минут, я не слышал. Проснулся от звонка CEO.

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

История вторая: автоматизация, которая спасла команду

Пришел я как‑то в новую компанию. Первый вопрос на стендапе: «Кто дежурит на этой неделе?» Ответ: «Да мы тут по очереди как‑то, Вася вот уже месяц дежурит, он привык».

Вася выглядел как персонаж из «Ходячих мертвецов». Оказалось, основная проблема — каждую ночь в 3 AM падал один и тот же cronjob из‑за нехватки памяти. Каждую. Ночь. Месяцами.

Починить cronjob? Не, «бизнес не дает время на техдолг». Ок. Написал скрипт, который мониторит память и рестартит job до того, как он упадет. 20 минут работы. Вася чуть не расплакался от счастья, когда первый раз за месяц проспал всю ночь.

История третья: дежурный, который сказал "нет"

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

Петя ответил: «Нет».

Менеджер в шоке: «Как нет? А кто будет дежурить?»

Петя: «Не знаю. Не мои проблемы. У меня билеты в театр с женой.»

И знаете что? Мир не рухнул. Менеджер сам подежурил. И после этого случая у нас внезапно нашлись деньги на расширение команды.

Метрики здоровья on-call

Как понять, что ваша ротация убивает людей? Я собираю эти метрики:

Количество ночных вызовов в неделю. Больше 2 — проблема. Больше 5 — катастрофа.

Время до ответа на алерт. Растет со временем? Люди выгорают.

Turnover в команде. Если каждые полгода уходит кто‑то из дежурящих — это не совпадение.

Добровольные подмены. Если никто никогда не хочет подменить коллегу — система токсична.

Количество повторяющихся инцидентов. Если один и тот же алерт срабатывает каждую неделю — это не инцидент, это пытка.

Мои правила выживания в on-call

После всех этих лет я вывел несколько правил, которые помогают не сойти с ума:

Правило 1: Сон священен. Если вас разбудили ночью, вы имеете право прийти позже или уйти раньше. Без объяснений.

Правило 2: Нет геройству. Не дежурьте за других без крайней необходимости. Вы не помогаете — вы поддерживаете сломанную систему.

Правило 3: Документируйте все. Каждый инцидент, каждый ночной вызов. Это ваши аргументы для улучшения процессов или повышения зарплаты.

Правило 4: Имейте запасной план. Если дежурства становятся невыносимыми — уходите. Жизнь слишком коротка для токсичного on‑call.

Правило 5: Автоматизируйте безжалостно. Каждый повторяющийся инцидент должен быть автоматизирован. Без исключений.

Идеальная ротация: к чему стремиться

Если бы я строил идеальную on‑call ротацию с нуля, вот что бы я сделал:

Команда минимум из 6 человек. Меньше — это путь к выгоранию. 6 человек = дежуришь раз в 6 недель. Терпимо.

Primary/Secondary модель. Всегда есть подстраховка. Всегда.

Автоматическая компенсация. Проснулся ночью — автоматически получаешь time off. Без одобрений и бюрократии.

Денежная компенсация от $1000 в неделю. Меньше — это неуважение к личному времени.

Runbook для каждого алерта. Нет runbook — алерт отключается. Жестко, но эффективно.

Автоматизация всего, что повторяется. Второй раз тот же инцидент — срочная задача на автоматизацию.

Ретроспективы после каждой недели. Что было тяжело? Что можно улучшить? Быстрая обратная связь.

Право вето. Любой может отказаться от дежурства без объяснения причин. Раз в квартал, например.

Заключение: жизнь после дежурств

Помните историю с начала статьи? Про семь ночей подряд? Сейчас я работаю в компании, где меня будят ночью в среднем раз в два месяца. За последний год я ни разу не пропустил семейный ужин из‑за инцидента. Моя жена забыла, как звучит PagerDuty.

Это возможно. Но для этого нужно перестать принимать токсичные дежурства как данность. «Ну это же SRE, конечно тебя будут будить» — нет, не конечно. «Кто‑то же должен дежурить» — да, но не ценой здоровья.

Если ваша текущая on‑call ротация вас убивает — меняйте ее. Если не можете изменить — уходите. Серьезно. Никакая работа не стоит вашего здоровья и отношений с близкими.

И последнее. Тот Вася, который месяц дежурил без перерыва? Сейчас он тимлид в крупной компании. Первое, что он сделал на новом месте — построил человеческую on‑call ротацию. «Я знаю, каково это — не спать неделями», — сказал он на первой встрече с командой.

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