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

Почему ручное развёртывание не масштабируется

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

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

С чего начать на практике

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

  • Сборка одной командой. Соберите проект из исходников без ручных правок. Подойдёт сервер непрерывной интеграции – Jenkins или Hudson – который запускает сборку и тесты на каждый коммит.
  • Единое описание окружения. Опишите конфигурацию серверов кодом. Puppet и Chef как раз для этого: вместо инструкции «установите пакеты A, B, C» вы храните манифест, который приводит сервер к нужному состоянию и делает это одинаково на десяти машинах.
  • Идемпотентный деплой. Скрипт развёртывания должен давать один и тот же результат при повторном запуске. Это страховка от наполовину выполненных релизов.
  • Откат. Заранее продумайте возврат к предыдущей версии. Без отката автоматизация только ускоряет распространение ошибки.

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

Культура важнее тулинга

Инструменты дают эффект только там, где команды разработки и эксплуатации делят общую цель. Если за деплой отвечает один отдел, а за стабильность – другой, любой Jenkins превратится в новый предмет спора. Поэтому мы начинаем с процесса: общая ответственность за релиз, единые метрики, прозрачный журнал изменений. Дисциплина проектирования инфраструктуры под нагрузку, которую мы отрабатывали на крупных проектах вроде системы видеонаблюдения за выборами, здесь работает напрямую: автоматизация надёжна ровно настолько, насколько продумана среда, в которой она выполняется.

Порядок в развёртывании и эксплуатации держится на проектировании и сопровождении инфраструктуры, где процесс выстроен сквозным образом от сборки до боевого запуска.

Вывод

Автоматизация развёртывания – не разовый проект, а первый шаг к культуре, в которой релиз перестаёт быть риском. Начните с малого: соберите проект одной командой, опишите окружение кодом, добавьте откат. Дальше процесс начнёт улучшать себя сам, потому что каждую ошибку вы будете чинить один раз – в коде, а не в инструкции.