Правило «не в пятницу»: регламент выкаток и его законные исключения

MAATRIX

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

От чего на самом деле защищает правило

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

Смоделируйте два сценария одного и того же релиза с багом, который проявляется не сразу, а через несколько часов под нагрузкой. Во вторник в 11:00 баг проявляется к 15:00: на связи вся команда, DBA доступен для срочной миграции, вендор техподдержки отвечает в течение часа по SLA — инцидент закрыт до конца рабочего дня. В пятницу в 17:00 тот же баг проявляется в субботу утром, когда трафик подрос после ночного затишья: дежурный один, доступа к продовой базе у него нет — только у DBA, который уехал без ноутбука, а тикет в поддержку вендора обрабатывается уже по SLA выходного дня — это часто сутки, а не часы. Пользователи весь уикенд видят деградацию, а разбор откладывается до понедельника, потому что чинить всерьёз некому.

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

Как маленькая проблема в пятницу вечером превращается в проблему всех выходных

Механика провала почти всегда одна и та же, и она хорошо описывается цепочкой, а не единичным событием.

1. Релиз выкатывается в пятницу днём или вечером, всё выглядит штатно — тесты прошли, smoke-check зелёный.
2. Проблема не проявляется мгновенно: она зависит от накопления состояния (утечка соединений с базой, переполнение очереди, деградация кеша), которое достигает критической точки через несколько часов или на следующий день под другим профилем нагрузки.
3. К моменту, когда проблема заметна, большая часть команды уже недоступна — кто-то в дороге, кто-то физически не смотрит в рабочие чаты до понедельника.
4. Дежурный, если он вообще есть, сталкивается с багом, для разбора которого нужен контекст релиза, которого у него нет — потому что деплоил не он.
5. Откат оказывается не таким простым, как казалось: за прошедшие часы в базу уже записались данные в новой схеме, и просто вернуть предыдущую версию кода нельзя без потери данных или ручной миграции обратно.
6. Разбор и полноценное исправление откладываются до понедельника, а всё это время пользователи получают деградированный сервис.

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

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

Что здесь можно измерить, а что — нет

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

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

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

Законное исключение №1: мелкий критичный фикс безопасности

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

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

Чтобы исключение оставалось законным, а не отговоркой, полезно проверять фикс по чек-листу:

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

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

Законное исключение №2: команда с полноценным круглосуточным дежурством

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

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

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

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

Что исключением не является — частые самообманы

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

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

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

Как формализовать правило регламентом, а не держать его на честном слове

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

Практический минимум формализации:

1. Письменно зафиксировать точную границу. Не «не катить в пятницу» вообще, а конкретное время отсечки — например, «крупные релизы не выкатываются после 14:00 в пятницу и в выходные», с явным определением, что считается «крупным» (миграция базы, изменение биллинга, изменение схемы аутентификации, релиз в часы пиковой нагрузки).
2. Явно перечислить исключения и условия их применения — критичный security-патч по чек-листу и наличие полноценного дежурства, с указанием, какая именно ротация считается «полноценной» в вашей компании.
3. Назначить, кто утверждает исключение. Это право не должно принадлежать тому, кто хочет выкатить прямо сейчас — иначе любое желание задеплоить в пятницу превратится в «ну это же критично». Подтверждение даёт тимлид или дежурный инженер, не участвующий в подготовке релиза.
4. Перенести правило в инструменты, а не только в документ. Документ читают редко, автоматическая проверка срабатывает всегда. Пример гейта в GitLab CI, блокирующего джобу деплоя в пятницу вечером и в выходные без лейбла исключения:

deploy_prod:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: '$CI_MERGE_REQUEST_LABELS =~ /friday-exception/'
      when: on_success
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: manual
      allow_failure: false

А сама проверка дня недели и времени может жить прямо в скрипте деплоя как последний защитный барьер, даже если CI-гейт кто-то обошёл:

#!/usr/bin/env bash
# deploy_guard.sh — грубая проверка перед стартом деплоя
day=$(date +%u)   # 1=понедельник ... 7=воскресенье
hour=$(date +%H)

if [[ "$day" -ge 5 && "$hour" -ge 14 ]] || [[ "$day" -ge 6 ]]; then
  if [[ "$DEPLOY_EXCEPTION" != "security-hotfix" && "$DEPLOY_EXCEPTION" != "oncall-full" ]]; then
    echo "Блок: релиз после 14:00 пятницы или в выходные без флага исключения."
    echo "Передайте DEPLOY_EXCEPTION=security-hotfix или oncall-full, если это законное исключение."
    exit 1
  fi
  echo "Деплой разрешён по исключению: $DEPLOY_EXCEPTION"
fi

./deploy.sh

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

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

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