Дежурство и эскалация в команде из трёх человек

MAATRIX

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

Почему классическая схема ротации здесь не работает

Стандартная рекомендация — дежурство неделя через неделю (а лучше через три-четыре) при команде из 6-8 человек: инженер дежурит раз в полтора-два месяца, успевает отдохнуть, инцидентов на его смену выпадает разумное число. Вся математика этой схемы держится на количестве людей в пуле.

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

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

# Дежурство: вводные

- В команде 3 человека, дежурят все трое.
- Дежурная неделя выпадает каждому в среднем раз в 3 недели.
- Это выше, чем рекомендуют best practices для крупных команд (там — раз в 6-8 недель).
- Мы принимаем этот risk сознательно, пересматриваем схему при найме 4-го инженера
  или при выгорании кого-то из троих.

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

Что реально мониторить 24/7, а что — только в рабочие часы

Крупная компания может держать NOC, который одинаково пристально следит за сотней метрик круглосуточно. Три человека физически не могут: если будить дежурного на каждый чих, он перестанет реагировать на важное, потому что важное тонет в шуме (подробнее о принципе фильтрации алертов — в статье про алерты, которые не бесят). Задача маленькой команды — не «мониторить всё одинаково», а честно разделить сигналы на три уровня.

Пример конкретных правил для Zabbix/Uptime Kuma (какой инструмент выбрать — см. сравнение Zabbix и Uptime Kuma):

# Критично — эскалация звонком/push 24/7
- check: http_response_code
  target: https://app.example.com/health
  condition: != 200 for 2m
  action: call_oncall

- check: disk_free
  target: /var/lib/postgresql
  condition: < 2GB
  action: call_oncall

# Важно — телеграм, разбор утром
- check: cpu_load
  condition: > 90% for 15m
  action: telegram_notify

- check: disk_free
  condition: < 15% for 30m
  action: telegram_notify

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

Кого и когда будить: матрица эскалации

В крупной компании эскалация — это лестница: дежурный инженер → тимлид дежурного → руководитель направления → инцидент-менеджер с полномочиями поднять кого угодно. В команде из трёх человек лестница физически состоит из двух-трёх ступенек, и это надо прописать явно, а не полагаться на то, что «мы же маленькие, всегда как-нибудь скооперируемся».

Рабочая матрица для команды из трёх:

# Эскалация: кто и когда

Уровень 1 (0 мин): дежурный инженер получает алерт, начинает разбор.
Уровень 2 (15 мин без реакции ИЛИ дежурный сам понял, что не справляется):
  → звонок второму по списку (не «кто ближе», а конкретное имя по ротации).
Уровень 3 (30 мин без реакции обоих ИЛИ инцидент касается денег/данных клиентов):
  → звонок третьему (даже если он формально не дежурит эту неделю).
Уровень 4 (все трое не отвечают 45+ мин):
  → авто-звонок на резервный номер (например, фрилансер-подрядчик
    со знанием инфраструктуры, или основатель компании, если это не он же дежурил).

Настройка такой цепочки в связке с Zabbix/Uptime Kuma и Telegram-ботом:

# Uptime Kuma: несколько уведомлений с задержкой через отдельные монитор-хуки
# Монитор 1 — сразу в Telegram дежурному
# Монитор 2 (тот же чек, delay 15 min, отдельный канал) — звонок через Twilio/сервис голосовых алертов
# Монитор 3 (delay 30 min) — звонок резервному контакту

Если такого готового инструмента для голосовых звонков нет — минимальный рабочий вариант: групповой чат в Telegram с обязательной реакцией (эмодзи/ответом) в течение 15 минут, и человеческое правило «если тишина — звони, а не пиши ещё раз». Технология тут вторична, первично то, что процедура прописана и все трое её видели, а не держится в голове одного человека.

Что делать, если единственный дежурный недоступен

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

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

• Резервный контакт указан поимённо, а не «кто-то из команды». В маленькой команде это обычно второй человек по списку эскалации — тот, кто физически может залогиниться и хотя бы перезапустить сервис, даже если не эксперт в конкретном компоненте.
• Доступы у резервного контакта уже есть, а не выдаются в момент инцидента. Если только один человек в команде имеет root на прод, это системный риск для команды из трёх — см. как раздать доступ команде без выдачи root всем подряд заранее, а не среди ночи, когда единственный обладатель пароля не отвечает на звонки.
• Runbook на 1-2 страницы с самыми частыми инцидентами написан заранее (перезапуск сервиса, откат деплоя, ручное переключение на бэкап) — так, чтобы им мог воспользоваться не только автор:

# Runbook: сайт не отвечает

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

• Явный крайний случай: если недоступны вообще все трое (отпуск, форс-мажор), у команды должен быть либо платный контракт с внешним подрядчиком на аварийное реагирование, либо осознанное решение «в этом случае сервис будет недоступен N часов, и мы с этим согласны» — вместо того чтобы делать вид, будто такого не бывает. Честность здесь дешевле репутационного удара от пропавшего на сутки сервиса без объяснений.

Реалистичное распределение нагрузки и разговор про выгорание

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

Практические меры, которые реально применимы в масштабе 3 человек:

• Считать реальную нагрузку, а не расписание. Ведите простую таблицу: кто сколько раз реально был разбужен или отвлечён от дел за месяц, независимо от того, чья была официальная смена.

| Месяц    | Иван (звонков ночью) | Мария (звонков ночью) | Пётр (звонков ночью) |
|----------|-----------------------|------------------------|------------------------|
| Август   | 7                     | 1                      | 2                      |

• Обсуждать перекос открыто и регулярно — раз в месяц 15 минут на созвоне: «Иван, тебя опять будили чаще всех, это нормально для тебя сейчас или нет?». Не ждать, пока человек сам не додумается заявить об усталости — в маленьких командах это часто не происходит, потому что «неудобно подводить остальных».
• Снижать бас-фактор целенаправленно, а не декларативно. Если только Иван умеет чинить базу — значит, следующие 2-3 месяца приоритет №1 (выше новых фич) — довести Марию и Петра до уровня «может закрыть runbook по базе самостоятельно». Иначе разговоры о выгорании останутся разговорами.
• Компенсировать перегруз материально или отгулами, если бизнес это позволяет — даже небольшой знак («после недели с 5+ ночными звонками — отгул») меняет отношение к дежурству с «неизбежное зло» на «справедливо оплаченная нагрузка».
• Не стесняться временно снижать порог критичности, если вся команда вымотана после инцидента — на неделю сократить список того, что будит ночью, до абсолютного минимума, и явно это проговорить, а не терпеть молча.

Инфраструктура для дежурства без лишних затрат

Маленькой команде не нужен PagerDuty за несколько сотен долларов в месяц на старте — вполне достаточно связки открытых инструментов на своём VPS, что заодно снимает вопрос о персональных данных на стороннем сервисе. Разумный минимальный стек:

• Uptime Kuma — самостоятельный мониторинг доступности с уведомлениями в Telegram/email, разворачивается за 10 минут (см. пошаговую установку и настройку).
• Zabbix, если нужны более глубокие метрики (диск, память, кастомные триггеры) — тяжелее в настройке, но гибче (сравнение с Uptime Kuma — в статье Zabbix или Uptime Kuma).
• Telegram-бот с групповым чатом для дежурного канала — дешёвый и надёжный канал уведомлений, но не гарантирует, что человек проснётся: для по-настоящему критичных 24/7 алертов дублируйте пуш звонком через любой сервис голосовых уведомлений (даже банальный будильник-автоответчик на второй SIM-карте лучше, чем ничего).
• Отдельный сервер под мониторинг, не совпадающий физически с тем, что мониторится — иначе при падении основного сервера некому послать алерт. Минимальный VPS с постоянной работой 24/7 для этой роли не требует много ресурсов — важна доступность и независимость от прод-инфраструктуры.

# Быстрый чек-лист перед запуском дежурства
1. Мониторинг развёрнут на ОТДЕЛЬНОМ от прода сервере.
2. Критичные проверки (5-10 штук) настроены и протестированы вручную (искусственно завалить сервис и проверить, что алерт дошёл).
3. Runbook на частые инциденты написан и лежит в общем доступе (не в личных заметках одного человека).
4. У всех троих есть доступ к прод-серверам без ожидания «дайте пароль».
5. Матрица эскалации распечатана/закреплена в чате, а не только в голове.

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