Когда каждый деплой — новая история: ловушка Ad Hoc доставки

У вас небольшая команда. Человек пять-шесть. Приложение работает. Пользователи довольны. Деплои происходят, но никто особо не обсуждает, как именно. Один разработчик копирует файлы на сервер по FTP. Другой запускает скрипт со своего ноутбука. Третий просто заходит в продакшен и вносит изменения напрямую.

Никто не жалуется, потому что в основном всё работает. Пока не перестаёт.

Тот, кто «знает, как деплоить», уходит в отпуск. Нужно срочно выкатить критический багфикс, но никто больше не может разобраться в шагах. Деплой занимает три часа вместо двадцати минут. Кто-то выполняет не ту SQL-команду на продакшен-базе. Откатить невозможно.

Это Уровень 1 зрелости доставки: Ad Hoc. Всё вручную. Всё каждый раз по-разному. И весь процесс зависит от того, кто доступен, а не от того, что задокументировано или автоматизировано.

Проблема зависимости от одного человека

Самый явный признак Ad Hoc-процесса — знания хранятся в головах людей, а не в общей системе. Когда знание о деплое есть только у одного человека, он становится узким местом. Если он в отпуске — деплои останавливаются. Если он увольняется — знания уходят вместе с ним.

Даже если документация существует, она обычно устаревшая. Кто-то написал README полгода назад. С тех пор шаги деплоя менялись пять раз. Никто не обновил документ. Новые члены команды учатся методом проб и ошибок, спрашивая того, кто кажется знающим.

Следующая блок-схема иллюстрирует, как ad-hoc деплой может разветвляться на непредсказуемые пути, каждый со своими рисками:

flowchart TD A[Разработчик начинает деплой] --> B{Какой метод?} B --> C[FTP файлов на сервер] B --> D[Запуск личного скрипта] B --> E[Прямое редактирование на проде] C --> F[Файлы могут быть неполными] D --> G[Скрипт работает только на одной машине] E --> H[Риск неверной SQL-команды] F --> I[Деплой молча падает] G --> J[Другой разработчик не может запустить] H --> K[Откат невозможен] I --> L[Человек в отпуске — фикса нет] J --> L K --> L L --> M[Деплой занимает часы]

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

Ручной деплой: ни один не похож на другой

В Ad Hoc-среде нет стандартной процедуры деплоя. У каждого разработчика свой метод. Один может зайти по SSH на сервер, стянуть последний код и перезапустить сервис. Другой — загрузить zip-архив через веб-интерфейс. Третий — запустить локальный скрипт, который работает только на его машине.

Поскольку нет единого источника правды, никто не может проверить, был ли деплой выполнен корректно. Когда что-то ломается, деплоящий начинает гадать. Он пробует разные команды, перезапускает сервисы, смотрит логи и надеется, что что-то сработает. Если застрял — звонит кому-то, кто может знать больше.

Такой подход работает, когда вы деплоите раз в месяц. Он становится болезненным, когда нужно деплоить еженедельно или ежедневно. Каждый деплой несёт тот же риск, потому что процесс никогда не улучшается. Ошибки повторяются. Время тратится на переоткрытие одних и тех же решений.

Изменения в БД без страховки

Управление базами данных на Уровне 1 особенно опасно. Изменения схемы применяются напрямую к продакшен-базе. Разработчик заходит на сервер БД, выполняет ALTER TABLE и надеется, что ничего не сломается.

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

У команды нет способа узнать, какая версия схемы сейчас работает. Если два разработчика вносят изменения одновременно, конфликты остаются незамеченными, пока что-то не ломается. Продакшен-данные могут быть потеряны, повреждены или оставлены в несогласованном состоянии.

Инфраструктура, управляемая памятью

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

Нет Infrastructure as Code. Нет автоматического развёртывания. Нет повторяемого процесса настройки. Команда полагается на память, стикеры и добрую волю того, кто настраивал исходный сервер.

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

Почему команды остаются на Уровне 1

Оставаться на Уровне 1 — не признак лени или отсутствия навыков. Многие команды остаются здесь по уважительным причинам:

  • Команда очень маленькая, и ручные процессы достаточно быстры.
  • Деплои происходят редко, поэтому боль непостоянна.
  • Приложение не критично, поэтому сбои имеют низкое влияние.
  • У команды есть другие приоритеты, которые кажутся более срочными.

Эти причины имеют смысл в краткосрочной перспективе. Но они создают скрытые издержки. Каждый ручной деплой несёт риск. Каждый недокументированный шаг создаёт зависимость. Каждое прямое изменение БД увеличивает шанс потери данных.

Проблема не в том, что команда делает что-то неправильно. Проблема в том, что текущий подход не масштабируется. Когда команда растёт, деплои становятся чаще или приложение становится более критичным, Ad Hoc-процесс превращается в обузу.

Первый шаг — не покупка инструмента

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

Прежде чем что-то автоматизировать, нужно знать, что вы автоматизируете. Прежде чем строить пайплайн, нужно согласовать шаги. Прежде чем покупать CI/CD-платформу, нужно понять свой собственный рабочий процесс.

Практический чеклист для выхода за рамки Ad Hoc

Если вы узнали свою команду в этом описании, вот с чего начать:

  • Запишите точные шаги деплоя, включая каждую команду и каждую точку принятия решения.
  • Определите, кто владеет критическими знаниями и что произойдёт, когда этот человек недоступен.
  • Перечислите все ручные шаги, которые могут привести к сбою при неправильном выполнении.
  • Документируйте текущую схему БД и то, как применяются изменения.
  • Запишите процесс настройки сервера, включая все пакеты, конфигурации и зависимости.

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

Конкретный вывод

Ad Hoc-доставка работает, пока не перестаёт. В тот момент, когда деплой падает и никто не знает, как его починить, или человек, который знает, недоступен, цена ручных процессов становится очевидной. Путь вперёд — пока не об инструментах или автоматизации. Он о признании, что текущий способ хрупок, и о начале записи того, что вы делаете, чтобы в конечном итоге делать это лучше.