Передача дежурства: пять пунктов, без которых смена начнётся с аварии

MAATRIX

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

Почему «всё нормально» — самая опасная фраза передачи дежурства

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

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

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

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

Пункт 1: что произошло за смену — включая мелкие аномалии

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

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

# события Kubernetes за смену, отсортированные по времени
kubectl get events --sort-by=.lastTimestamp -A | tail -n 50

# перезапуски и рестарты systemd-юнитов за последние 8 часов
journalctl --since "-8 hours" | grep -iE "restart|oom|failed"

# история срабатываний в Zabbix/Uptime Kuma — экспорт за смену
# (в Uptime Kuma: Settings → Monitor History, либо API /api/status-page)

Формат записи в таймлайне — три строки на событие, не больше:

Таймлайн смены 08.09.2026, 08:00–20:00 UTC

• 03:14 — pod api-gateway-7f9d рестартнулся по OOM, поднялся сам за 40 сек,

метрики в норме. Второй раз за неделю (первый — 04.09, тикет OPS-441).

• 09:20 — краткий скачок latency на платёжном шлюзе (p95 380мс → 1.1с),

длился 3 минуты, алерт не сработал (порог 2с), сам вернулся в норму.

• 14:05 — вручную перезапущен воркер очереди email, завис на джобе,

очередь разгребена, причина зависания не выяснена.

• Инцидентов с даунтаймом не было.

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

Пункт 2: что осталось в незавершённом состоянии

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

Классический пример: нагрузка выросла, вы вручную увеличили число реплик с 3 до 6, потому что автоскейлинг не среагировал вовремя. Инцидент формально закрыт, сервис отвечает нормально. Но если это не передать явно, следующий дежурный увидит «избыточные» 6 реплик при обычной нагрузке, решит, что это ошибка, и откатит обратно на 3 — а причина, по которой автоскейлинг не сработал, так и останется непочиненной. То же самое с временно отключенным cron, вручную применённым hotfix без нормального PR, изменённым порогом алерта «чтобы не спамило», заблокированным IP на фаерволе.

Удобный формат — таблица состояний, а не проза:

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

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

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

Типичный набор такого рода деградаций: место на диске одной из нод медленно растёт третью неделю подряд и ещё не критично, но тренд есть; сертификат на staging не переиздаётся автоматически из-за бага в ACME-клиенте, обновляется руками; сторонний API периодически отвечает 503 под нагрузкой, это учтено в retry-логике, но само по себе не чинится.

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

# Known issues — актуально на 08.09.2026

| Система | Симптом | С какого числа | Обходной путь | Тикет | Ответственный |
|---|---|---|---|---|---|
| node-3 (диск) | Рост занятого места ~1%/день | 25.08 | Мониторим, порог алерта 85% | OPS-438 | @dmitry |
| staging cert | Не переиздаётся автоматически | 30.08 | Ручной renew раз в неделю | OPS-440 | @dmitry |
| payment-api (3rd party) | 503 под нагрузкой, ~2%/день | давно | Retry с backoff уже есть | — | известный лимит вендора |

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

Пункт 4: что запланировано на ближайшее время

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

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

# запланированные задачи cron на сервере
crontab -l

# systemd-таймеры и время следующего запуска
systemctl list-timers --all

# ближайшие истекающие сертификаты (если используете certbot)
certbot certificates | grep -A2 "Certificate Name"

Формулировка в передаче должна быть конкретной, с временем и ожидаемым эффектом, а не общей ссылкой на календарь:

Запланировано на ближайшие 12 часов

• 14:00 UTC — миграция схемы на primary-БД (PR #482, ревью пройдено).

Ожидается lock на таблице orders ~20-30 сек, приложение должно отработать это как обычный таймаут, без алерта.

• 16:00 UTC — деплой backend v2.14.0, canary 10% → 100% за час.
• Домен partner-api.example.com — SSL истекает 11.09, автопродление

должно сработать 10.09, но перепроверить.

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

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

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

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

Рабочий формат — таблица «система → человек → способ связи → запасной вариант», актуализируемая при каждом изменении состава команды или контактов вендоров:

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

Как оформить передачу дежурства на практике

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

# Передача дежурства: [дата, ФИО сдающего] → [ФИО принимающего]

1. Что произошло за смену

(таймлайн событий, включая мелочи без алерта)

2. Незавершённое, требует продолжения

(таблица: система / действие / причина / кто доводит до конца)

3. Известные проблемы (ссылка на общий документ)

→ [ссылка на known-issues] Изменения с прошлой смены: (если есть)

4. Запланировано на ближайшее время

(релизы, работы, окна, истекающие сертификаты)

5. Контакты по системам

→ [ссылка на таблицу контактов], изменений нет / изменилось: ...

Принимающий подтвердил приём: [ ] да

Если у команды есть инструмент вроде Grafana OnCall, Opsgenie или PagerDuty — в них есть встроенные заметки при передаче смены (handoff notes), и лучше использовать их, а не отдельный документ: тогда история передач привязана к таймлайну инцидентов и не теряется отдельно от системы алертинга. Для небольших команд без такого инструмента вполне достаточно закреплённого сообщения в Telegram-канале дежурства или страницы в вики — важно не то, какой инструмент, а то, что формат зафиксирован и одинаков каждый раз.

Два правила, которые стоит внедрить сразу. Первое — «нет подтверждённой передачи, нет официального начала смены»: принимающий явно подтверждает, что прочитал все пять пунктов, а не просто видит сообщение в чате. Второе — если событий за смену настолько много, что они не укладываются в 10-15 минут переписки, это сигнал созвониться голосом вместо текста. И отдельно стоит убедиться, что у принимающего есть все нужные доступы до начала смены — VPN, SSH-ключи, 2FA к панелям: проверка доступов до инцидента экономит критичные первые минуты во время него.

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