Регламент работы с продакшеном на одну страницу: минимум, который работает

MAATRIX

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

Почему регламент должен быть коротким, а не полным

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

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

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

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

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

Минимум, который стоит зафиксировать:

• поимённый список тех, у кого есть право деплоить в прод (не «вся команда разработки», а конкретные имена или роли — это одновременно и список доступа, и список ответственности);
• нужно ли подтверждение второго человека перед деплоем, и для каких изменений — например, для миграций базы или правки конфигурации firewall подтверждение обязательно, а для правки текста на странице нет;
• обязателен ли деплой через пайплайн (CI/CD) или прямой доступ по SSH тоже допустим и в каких случаях — если в команде до сих пор практикуется ручной деплой по SSH «потому что так исторически сложилось», это отдельный источник риска, который стоит явно ограничить рамками регламента, а не оставлять как молчаливое допущение;
• как оформляется временный доступ подрядчику или новому сотруднику, и кто выдаёт постоянный.

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

Когда деплоить нельзя

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

Классические ограничения, которые стоит явно прописать:

• не в пятницу вечером и не перед длинными выходными — если релиз ломает прод в субботу, чинить его будет некому до понедельника; логика этого правила и разумные исключения из него разобраны в статье «Правило "не в пятницу": регламент выкаток»;
• не во время пиковой нагрузки — если у сервиса есть предсказуемый час пик (утренний трафик, вечерние продажи), деплой в это окно повышает цену любой ошибки;
• не без свежего проверенного бэкапа — особенно перед изменениями схемы базы данных или миграциями;
• не в одиночку для рискованных изменений — миграция базы, правка firewall, смена DNS должны идти при подтверждении второго человека, даже если формально доступ есть у одного.

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

Куда сообщать об инцидентах

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

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

Инцидент на проде

1. Пишем в канал #incidents (не в личку конкретному человеку — он может быть недоступен)
2. Формат первого сообщения: что сломано, с какого момента, кто уже в курсе
3. Если ответственный не реагирует 10 минут — звонок по телефону: [имя], [телефон]
4. Резервный контакт, если основной недоступен: [имя], [телефон]
5. Статус проекта обновляем в том же треде каждые 30 минут, даже если "пока без изменений"

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

Кто отвечает за бэкапы

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

Регламент должен зафиксировать три вещи одной строкой каждая:

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

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

Где хранить регламент и как его обновлять

Регламент на одну страницу бесполезен, если он лежит там, где о нём забывают, — та же проблема, что убивает и обычную документацию. Практический ориентир простой: файл вроде PRODUCTION.md в корне основного репозитория, рядом с кодом, который он регулирует. Это решает сразу две задачи — документ открывается тем же движением, что и сам проект, и правки в него попадают в обычный Pull Request, а не теряются в отдельной вики.

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

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

Отдельно стоит указать дату последней проверки прямо в файле — простую строку вида Проверено: 2026-08-15. Это работает как маркер доверия: пятистрочный регламент с датой месячной давности внушает больше уверенности, чем регламент без даты, где непонятно, актуален он ещё или про него забыли сразу после написания.

Готовый шаблон на одну страницу

Ниже — рабочий каркас, который можно скопировать в PRODUCTION.md и заполнить конкретными именами и контактами команды. Каждый раздел — то, что разобрано выше, сведённое к минимуму строк.

# Регламент работы с продакшеном

Проверено: [дата]

Кто может деплоить

• Имя 1 — деплой через CI/CD, подтверждение не нужно
• Имя 2 — деплой через CI/CD, подтверждение нужно для миграций БД
• Прямой доступ по SSH: только для аварийного хотфикса, с уведомлением в #incidents

Когда деплоить нельзя

• Не в пятницу после 15:00 и не перед длинными выходными
• Не в часы пиковой нагрузки: [указать окно]
• Не без свежего проверенного бэкапа перед миграцией схемы БД
• Рискованные изменения (миграции, firewall, DNS) — только вдвоём

Исключение: критичная уязвимость или полная недоступность сервиса — решение принимает [имя], катим в любое время.

Куда сообщать об инцидентах

1. Канал #incidents, не личные сообщения
2. Первое сообщение: что сломано, с какого времени, кто уже занимается
3. Ответственный: [имя], телефон [номер]
4. Резервный контакт: [имя], телефон [номер]
5. Статус обновляем каждые 30 минут до закрытия инцидента

Кто отвечает за бэкапы

• Ответственный за создание и мониторинг: [имя]
• Проверка восстановления: раз в месяц, [имя]
• Где лежат бэкапы и у кого есть доступ: [место + список]

Ссылки на подробности

• Паспорт сервера: [ссылка]
• Политика бэкапов: [ссылка]
• Разбор инцидентов: [ссылка]

Последний раздел — «Ссылки на подробности» — важен структурно: он явно отделяет то, что должно быть коротким (сам регламент), от того, что законно длинное и живёт в отдельных документах. Так регламент не разрастается сам собой каждый раз, когда кому-то хочется дописать нюанс, а нюанс уходит туда, где ему место.

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