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

Стена между Dev и Ops

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

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

Автоматизация как следствие, а не цель

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

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

Что это значит для заказчика

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

В 2014 году эта предсказуемость особенно ценна. Курс на импортонезависимость в ИТ заставляет команды переносить системы на новые платформы и open source, а такой переезд без отлаженных автоматических сборок превращается в лотерею. Параллельно растут требования к безопасности: итоги года показали, что число атак на инфраструктуру увеличивается, и контроль над каждым изменением в боевой среде становится не роскошью, а необходимостью.

Вывод

DevOps нельзя купить – его выстраивают. Сначала меняется культура: общая ответственность, прозрачность, готовность разработки и эксплуатации работать как одна команда. Затем приходят инструменты, которые эту культуру обслуживают. Российским командам, особенно в госсекторе, переход даётся непросто, но он окупается стабильностью, скоростью и контролем над тем, что происходит в продакшене. А это именно то, чего бизнес и государство ждут от ИТ сегодня.