Перила для деплоя: как сделать рукописный одностраничный analog‑runbook — страховочную сетку над каждым релизом

Современные инструменты деплоя гладкие, автоматизированные и быстрые. Но как только что‑то идёт не так, никто не лезет в ваш CI/CD YAML. Все ищут что‑то простое, видимое и человеческое.

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

В этом посте разберём, как спроектировать такой одностраничный analog‑runbook, связать его с чек‑листом перед деплоем и плотно интегрировать с вашими текущими процессами on‑call и incident‑response.

Зачем нужен одностраничный аналоговый safety net

Цифровая документация полезна — но под стрессом она легко подводит:

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

Рукописный, распечатанный, одностраничный runbook прорезает весь этот шум:

Он всегда на виду: на стене рядом с рабочими местами или приклеен к монитору.
Его можно быстро «прочёсывать» под стрессом: крупные заголовки, короткие пункты, никакого скролла.
Он умышленно ограничен по объёму: только самые критичные шаги и контакты.

Эта страница не должна заменять полную документацию. Это стартовая карта на худший случай: «Что‑то сломалось. Что мне делать прямо сейчас?»

1. Начните с сильного, понятного «посадочного» блока

Верхняя треть страницы — священное пространство. Относитесь к ней как к отметке «Вы находитесь здесь» на плане эвакуации.

Самый верх, крупными, вручную написанными буквами:

«ЕСЛИ ЭТОТ ДЕПЛОЙ ПОШЁЛ ПЛОХО — СДЕЛАЙ ЭТО СРАЗУ»

Под этим — три предельно понятных подраздела:

a) Кому звонить (и как)

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

Основной on‑call инженер: имя / телефон / Slack‑ник
Резервный on‑call / эскалация: имя / контакт
Incident commander (если вы используете эту роль): как пейджить или назначить

Это должны быть реальные имена и реальные каналы связи, а не «Смотри расписание on‑call». Когда адреналин зашкаливает, никому не хочется разбираться с календарями.

b) Куда смотреть в первую очередь

Не надо перечислять весь зоопарк тулов. Выберите три–пять стартовых точек:

URL основного мониторингового дашборда
Точка входа в поиск по логам ошибок (например, заранее сохранённый запрос)
Консоль feature‑флагов (если откаты делаете флагами)
Дашборд релизов с состоянием текущего деплоя

Подпишите каждую — зачем она:

«Шаг 1: проверить error rate API — Grafana: дашборд api-prod»
«Шаг 2: проверить, есть ли пользовательские инциденты — внутренний вид Statuspage»

c) Первые три шага под огнём

Сделайте их бинарными и однозначными:

Остановить дальнейшие деплои (как: отключить pipeline / пометить релиз как заблокированный)
Стабилизировать пользовательский опыт (например, откатить, переключить флаг, перевести трафик на стабильную версию)
Объявить об инциденте в стандартном канале (имя или ссылка на канал)

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

2. Интегрируйте runbook с on‑call и incident‑response инструментами

Ваш analog‑runbook — не отдельная вселенная. Это фронт‑дверь в ваши цифровые инструменты.

На странице явно подпишите:

Как пейджить on‑call: «Используем PagerDuty: /pd assign в канале #incidents»
Где регистрировать инциденты: «Создаём инцидент в Incident.io через /incident в Slack»
Где живёт таймлайн инцидента: «Все апдейты в Slack‑канале #incidents»

Цель: никакой двусмысленности насчёт эскалации. Runbook должен отвечать на вопросы:

«Достаточно ли это серьёзно, чтобы открывать инцидент?» → простое пороговое правило на странице.
«Где фиксировать то, что я делаю?» → одна конкретная система и канал.
«Кто принимает решение об откате?» → явно: «Incident commander» или «On‑call SRE».

Если инструмент меняется (PagerDuty → Opsgenie и т.п.), вы обязаны обновить и перепечатать страницу. Analog‑лист должен отражать вашу текущую операционную реальность.

3. Спарьте его с лаконичным чек‑листом перед деплоем

Нижняя половина (или оборот) страницы — это ваш deployment checklist, ваш pre‑flight‑ритуал.

Это не «красивый список задач». Это ворота. Нет галочки — нет деплоя.

Структурируйте его в три блока:

a) Готовность релиза

Пакет изменений просмотрен: «Я понимаю, что именно выкатывается и зачем.»
Оценён blast radius: «Что самое плохое может случиться? Кто пострадает?»
План отката понятен: «Могу ли я безопасно откатить? И за какое время?»

b) Операционная среда

Мониторинг настроен: Метрики и логи есть для новых/изменённых компонент.
Алерты оттюнингованы: Вы действительно заметите, если деплой поедет в кювет.
Feature‑флаги (если используются) готовы: Безопасные тумблеры настроены.

c) Люди и коммуникация

On‑call в курсе: Человек, которому ловить последствия, знает о деплое.
Окно изменений адекватно: Не в заведомо опасное время (пик трафика, крупное событие и т.п.).
Стейкхолдеры предупреждены, если риск высокий: Например, саппорт, продакт оунер.

Держите чек‑лист настолько коротким, чтобы его можно было прочитать менее чем за минуту. Если он становится нудной обязанностью, по нему начнут просто «ставить галочки».

4. Вшейте в него QA‑гейты

Помимо общих проверок, в чек‑листе runbook’а должны быть явные QA‑гейты:

a) Проверка на staging

Деплой на staging завершился успешно.
Ключевые пользовательские сценарии проверены на staging (пропишите 3–5 ключевых потоков: «Регистрация», «Оформление заказа», «Сброс пароля»).
Staging достаточно близок к production для затронутых компонент (feature‑флаги, конфиги и т.д.).

Нет staging? Тогда признайте это честно: «Staging нет; сделать smoke‑тест этих сценариев в production на низкорисковых аккаунтах». Не оставляйте серых зон.

b) Peer review

Код прошёл ревью коллегой (имя или инициалы).
Рискованные миграции или изменения схемы дополнительно просмотрены сеньор‑инженером.

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

c) Подтверждение release candidate

Явно перечислите, что входит в этот деплой:

Тикеты в составе релиза: PROJ-123, PROJ-456, BUG-789.
Ни один непроверенный тикет не «подсел» в релиз (никаких сюрприз‑коммитов в main).

Это заставляет убедиться, что деплой — это осознанный release candidate, а не просто «то, что сейчас лежит в default‑ветке».

5. Держите его аналоговым, рукописным и на виду

Сила этого runbook’а во многом в его осязаемости и видимости.

Почему важен ручной почерк

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

Куда его повесить

Распечатайте и повесьте рядом с основной рабочей зоной команды.
Приклейте рядом с on‑call ноутбуком.
Разложите копии в war‑room’ах или созвон‑комнатах, которые используете во время инцидентов.

Небольшой совет: используйте жирный маркер, крупные заголовки и много «воздуха». Это визуальный артефакт, а не компактный роман.

6. Переписывайте его после каждого инцидента и постмортема

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

После каждого инцидента или нервного деплоя спросите себя:

«Чего нам не хватало на этой странице?»
«Какую её часть мы проигнорировали — и почему?»
«Где мы всё равно теряли время или застревали?»

Затем:

Обновите страницу от руки.
Явно укажите дату и версию: «Версия: 2026‑02‑25».
Перепечатайте и замените старые копии.

В постмортемах отдельно проверяйте:

Пользовались ли мы чек‑листом перед этим деплоем?
Пользовались ли мы «посадочным» блоком runbook’а во время инцидента?
Были ли контакты и инструменты на листе актуальными?

Runbook — это живой артефакт ваших реальных режимов отказа. Со временем он становится самым честным отражением того, как система на самом деле ломается — и как команда на самом деле эффективно реагирует.

Собираем всё вместе

Сильный одностраничный deployment‑runbook будет:

Находиться физически над каждым деплоем как заметный триггер к действию.
Давать понятный «посадочный» блок на случай, когда всё идёт не так.
Быть напрямую связан с вашими on‑call и incident‑инструментами, убирая неясности.
Задавать чек‑лист перед деплоем с конкретными QA‑гейтами.
Оставаться коротким, рукописным и удобным под стрессом.
Непрерывно дорабатываться на основе реальных инцидентов и постмортемов.

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

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