DevOps - это сначала культура, потом инструменты
Почему покупка инструментов CI/CD не делает компанию DevOps и что нужно изменить раньше, чем выбирать платформу.
Разговор про DevOps в компаниях почти всегда начинается с инструментов. Какую систему CI/CD выбрать, как настроить деплой, какой инструмент мониторинга поставить. За этим следует покупка или установка чего-то, несколько месяцев настройки - и примерно такой же хаос, как был до этого, только теперь с дополнительным слоем инфраструктуры.
Я видел этот сценарий достаточно раз, чтобы сказать прямо: проблема не в инструменте. Проблема в том, что вопрос задаётся не в том порядке.
Что DevOps означает в реальности
DevOps - это способ организовать работу так, чтобы разработка и эксплуатация не были отдельными островами с отдельными целями. Разработчики хотят выкатить изменения быстро, эксплуатация хочет стабильности. Если это два разных отдела с разными KPI - они будут тормозить друг друга независимо от того, какой инструмент стоит между ними.
Инструменты DevOps созданы для того, чтобы автоматизировать и ускорить то, что уже работает как процесс. Они не создают процесс из ничего.
Где обычно ломается переход
Первая проблема - это зоны ответственности. Если никто не понимает, кто отвечает за то, что код работает в продакшене - разработчик, тестировщик или системный администратор - автоматизация ничего не решит. Она только быстрее доставит неразбериху в продакшен.
Вторая проблема - это отношение к инцидентам. В компаниях, где инциденты - это повод найти виноватого, никакой DevOps не приживётся. Командам нужна возможность честно анализировать, что сломалось и почему, без риска для карьеры. Без этого люди прячут проблемы, а не решают их.
Третья проблема - это скорость изменений. DevOps предполагает, что изменения выходят небольшими и часто. Если культура требует большого согласования перед каждым релизом - автоматизация пайплайна не поможет, она упрётся в те же согласования.
Что стоит сделать раньше, чем выбирать платформу
Я обычно предлагаю клиентам ответить на несколько вопросов, прежде чем двигаться к инструментам.
Кто принимает решение о том, что изменение готово к продакшену - и по каким критериям? Если ответ "ну, мы договариваемся" - это не процесс.
Как сейчас выглядит деплой? Сколько ручных шагов? Кто их делает? Есть ли документация или только носитель знаний в голове?
Что происходит, когда деплой что-то ломает? Кто замечает, кто решает, кто несёт ответственность?
Если на эти вопросы нет чётких ответов - начинать надо с ответов, а не с платформы.
Роль руководителя
Это не технический вопрос в первую очередь. DevOps требует того, чтобы руководитель осознанно изменил структуру стимулов и зон ответственности. Не купил инструмент, а поменял то, за что люди получают признание и за что несут ответственность.
Инструменты придут следом и встанут на место естественным образом - когда есть понятный процесс, который нужно автоматизировать, и команда, которая понимает, зачем это нужно.
Несколько вопросов для проверки готовности
Перед тем как подписывать контракт на CI/CD платформу, стоит проверить:
- Есть ли договорённость между командами о том, что значит "готово к релизу"?
- Есть ли практика разбора инцидентов без поиска виноватых?
- Есть ли у разработчиков доступ к информации о том, как их код ведёт себя в продакшене?
- Могут ли небольшие изменения выходить без большого согласования?
- Есть ли человек, который отвечает за качество процесса доставки - не только за инфраструктуру?
Если большинство ответов "нет" - инструмент подождёт. Сначала нужен разговор о процессе.