Дежурство в праздники: минимальная схема для команды из двух человек

MAATRIX

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

Почему "оба всегда на связи" — не подстраховка, а выгорание

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

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

Как разделить праздники на отрезки ответственности

Задача не в том, чтобы вычислить "справедливые 50/50 часов" с точностью до минуты — это не отпуск с почасовой оплатой. Задача — чтобы в любой момент праздников было понятно, кто конкретно первым получает алерт и обязан среагировать, а не "оба, но как получится". Практический способ — блоки по 24-48 часов, привязанные к календарным дням, а не к абстрактным сменам.

Пример разбивки на новогодние праздники (30 декабря — 8 января, 10 дней):

Здесь у Марии зафиксирован самый спокойный по задачам блок (1-2 января, когда прод обычно наименее нагружен и меньше плановых работ), а у Ивана — более рабочие даты в начале и в конце периода. Это осознанный выбор, а не автоматическое чередование через день — при распределении учитывайте, у кого какие личные планы на конкретные даты, а не только арифметику "поровну".

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

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

Что должно быть готово у второго человека заранее

Ключевая ошибка минимальной схемы на двоих — формальное дежурство без реальной готовности. Если второй человек не работал с конкретным сервисом последние два месяца, писать его в график "ответственным" бессмысленно: в момент инцидента он не сможет ничего сделать, кроме как написать первому "у тебя не отвечает телефон, что делать?". Готовность нужно проверить и обеспечить заранее, за 1-2 недели до праздников, а не декларировать.

Обязательный минимум перед началом периода:

• Рабочий доступ у обоих, а не выдача пароля "по запросу в моменте". SSH-ключ второго человека уже добавлен на все продовые серверы, доступ к панели хостинга и к DNS уже проверен входом, а не предполагается рабочим.
• Короткий runbook по частым проблемам, написанный так, чтобы им мог воспользоваться не только автор:

# Runbook: сайт не отвечает (проверить в таком порядке)

1. Проверить нагрузку и место на диске:
   htop
   df -h
2. Проверить, жив ли процесс приложения:
   systemctl status app
3. Посмотреть последние ошибки:
   journalctl -u app -n 200 --no-pager
4. Перезапуск, если процесс упал:
   systemctl restart app
5. Если диск заполнен логами:
   find /var/log -name "*.log.*" -mtime +7 -delete
6. Если после перезапуска не помогло за 10 минут —
   звонить второму по списку, даже если сейчас не его отрезок.

• Список внешних зависимостей с датами, которые могут "взорваться" именно во время праздников без вмешательства человека: срок действия TLS-сертификата (если выпуск не полностью автоматизирован через certbot), продление домена, лимиты платёжного шлюза, квота у облачного провайдера. Проверьте эти даты заранее — многие инциденты на праздники это не нагрузка, а истёкший сертификат или неоплаченный счёт, который никто не заметил вовремя.
• Настроенные и проверенные уведомления, которые реально доходят до обоих на личные телефоны, а не только в рабочий Slack, который никто не открывает в отпуске — как минимум Telegram-бот с алертами; пошаговая настройка описана в статье как установить и настроить алерты в Telegram на VPS.
• Короткая репетиция за несколько дней до праздников: искусственно остановите тестовый сервис или non-prod окружение и попросите второго человека восстановить его по runbook без подсказок. Если не справился за разумное время — это сигнал доработать runbook или доступы, а не повод понадеяться "в реальности разберёмся".

Что считается критичным во время праздников, а что подождёт

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

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

Честно ограничьте список первого уровня 5-8 проверками, не больше. Каждая проверка, которая может разбудить дежурного ночью в праздник, должна отвечать на вопрос "если не починить в ближайший час, бизнес реально теряет деньги или данные?" — если ответ "нет", это вторая или третья строка таблицы.

Передача отрезка: короткий ритуал на стыке

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

Минимальный шаблон сообщения при передаче отрезка (пишется в общий чат, не голосом — чтобы осталась запись):

# Передача: Иван → Мария, 1 января, 10:00

Статус: всё штатно, инцидентов за отрезок не было.
Открытые вопросы: нет.
Что смотреть в первую очередь: вчера был всплеск нагрузки
  в 23:00-23:30 (Новый год), в пределах нормы, но если повторится
  сегодня ночью — не паниковать, это ожидаемо.
Доступы проверены: да (зашла на сервер за 5 минут до передачи).
Контакт на экстренный случай: Иван на связи по критичному
  до 12:00 (долетает), дальше офлайн до вечера.

Пять минут на такое сообщение экономят часы неопределённости, если что-то случится в первые часы нового отрезка. Отдельно проговорите окно "перекрытия" — 1-2 часа, когда предыдущий ответственный формально ещё доступен для вопросов, даже если отрезок уже перешёл к другому, на случай нетипичной ситуации, требующей контекста.

Если единственный ответственный недоступен — запасной сценарий

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

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

• Уровень "критично" будит второго человека даже не в его отрезок, если первый не ответил в течение согласованного окна (например, 20-30 минут). Это не нарушение схемы, а её часть — второй уровень эскалации, просто состоящий из одного человека, а не из цепочки.
• Договоритесь заранее о конкретных "неприкасаемых" окнах каждого — например, вечер 31 декабря с 22:00 до 2:00 или конкретный семейный день, когда даже критичный алерт разумно попробовать решить самостоятельно тем, кто на связи, прежде чем звонить второму. Это не "второй никогда не звонит в этот час", а "звонить в последнюю очередь, после попытки справиться самому".
• Если оба реально недоступны одновременно (у обоих поездка без связи, например) — это осознанный риск, который стоит явно принять или закрыть внешним подрядчиком на конкретные даты. Дешевле заплатить за разовое дежурство фрилансера-инфраструктурщика на 2-3 суток полной недоступности, чем понять постфактум, что сервис лежал 8 часов, а объяснить клиентам нечем.
• Не полагайтесь на "кто-то из нас точно увидит" без технической подстраховки. Настройте эскалацию через сервис уведомлений так, чтобы при отсутствии реакции на первый пуш автоматически шёл повторный алерт или звонок второму контакту — вручную в стрессе про это легко забыть.

Частые вопросы