Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile. На практике же TTM (Time-to-Market) часто не только не падает, но и растет. Почему? Потому что была совершена подмена понятий. Изначально, DevOps задумывался как способ стереть границу между кодом и инфраструктурой, сократить время ожидания разработчика на готовое окружение для разработки. В итоге мы построили новую «админскую стену», только теперь обложенную YAML-файлами.
В среде современного DevOps часто господствует «админский» подход. Люди месяцами спорят о выборе между Terraform, Pulumi, Helm, Kustomize или Ansible, выбирая «марку молотка», в то время как дом всё ещё не построен, а чертежи никто не видел. Забывается главная цель DevOps — сокращение TTM. Если выбор инструмента не ускоряет доставку фич, спор становится пустым: ресурсы тратятся на освоение инструментария, а не на доставку ценности. Такой подход заставляет внедрять решение просто потому, что команда его знает, а не потому, что оно оптимально (например, тащить Ansible туда, где достаточно простого Containerfile или Dockerfile). В этих спорах теряется принцип Shared Responsibility: важно не то, насколько красив манифест, а может ли разработчик самостоятельно внести в него правки, не дожидаясь администратора.
Проблема усугубляется еще тем фактом, что многие компании создают «DevOps-подразделения», которые на самом деле являются просто отделами администрирования. Нередко это происходит так: руководство читает отчеты Gartner и видит, что «успешные компании используют Kubernetes и Terraform». В итоге покупается дорогой «молоток», нанимаются «мастера молотка», но гвоздей в компании нет. Инженерам приходится придумывать себе работу, создавая сложнейшие абстракции над простыми вещами, чтобы оправдать свое существование. Нередко автоматизируются те процессы, которые вообще не должны были существовать, или тратится время на написание сложных абстракций в каком-нибудь Helm, которые никто кроме автора не может понять. Но DevOps — это про коммуникацию, а не про то, как вы лихо умеете писать плейбуки в Ansible.
Между тем, мы убили SysOps, заменив его эфемерным DevOps’ом. В компаниях, где нет своего кода, своей разработки, мы наблюдаем парад абсурда: люди внедряют технологии для Continuous Deployment туда, где деплоить нечего. Тратятся бюджеты на поддержку инфраструктуры для автоматизации самой автоматизации, стыдливо избегая честного слова «эксплуатация». Сейчас, признать, что вам нужен просто надежный SysOps — значит разрушить сложившийся миф и признать, что половина ваших модных инструментов — это просто балласт.
Признать, что вам нужен качественный SysOps вместо карго-культового DevOps — это не шаг назад. Это шаг к эффективности. Ведь в конечном итоге бизнесу нужны работающие сервисы, а не красивые графики в ArgoCD, за которыми скрывается пустота.
А что же не так с компаниями, в которых явно присутствует этап разработки программного обеспечения, теми компаниями, которые можно смело отнести к ISV? В компаниях-разработчиках админский DevOps нередко превращается в изощренную форму саботажа. Здесь выбор «марки молотка» напрямую бьет по прибыли: пока инженеры по эксплуатации полируют свои идеальные пайплайны, разработчики бьются лбом об ограничения инфраструктуры, которые им навязали «для их же блага». В итоге мы получаем продукт, который оброс костылями не из-за плохого кода, а из-за того, что его пытались засунуть в чуждую ему, избыточно сложную среду.
Почему же DevOps стал инструментом администраторов, ведь CI/CD задумывался как способ дать разработчику контроль над доставкой кода (Self-Service)? Одна из причин заключается в том, что технологический порог входа стал так высок, что инструмент оказался в руках специалистов по инфраструктуре. Разработчикам становится всё сложнее поддерживать YAML-файлы на тысячи строк, они теперь должны быть наполовину системными программистами. Вместо написания бизнес-логики разработчики ПО вынуждены изучать HCL, копаться в репозиториях инфраструктуры и ждать завершения CI/CD-пайплайна, который падает из-за лишнего пробела. Кроме того, на российском рынке в крупных корпорациях (банки, госсектор) разделение на «тех, кто пишет» и «тех, кто катит» до сих пор сильнее, чем на Западе, из-за жестких требований безопасности и бюрократии. К тому же сложившийся дефицит кадров привел к тому, что проще нанять одного «звездного» DevOps-инженера, который настроит всё для десятка разработчиков, чем обучать всю команду нюансам инфраструктуры. В итоге, для разработчика программного обеспечения самообслуживание превратилось в самоистязание.
В современных условиях DevOps-команда должна перестать быть «обслуживающим персоналом» или «хранителями ключей». Она должна стать продуктовой командой, чей продукт — это платформа, а ее клиент — это разработчик ПО. Целью должно стать создание условий, чтобы разработчик мог развернуть необходимый ему сервис, не вникая в YAML-описания конфигурации развертывания, без знания какая «марка молотка» использована под капотом. Необходимо выстраивание Internal Developer Platform (IDP), где разработчик нажимает кнопку «Создать среду» и получает готовое окружение за минуты, а не часы или даже дни. Необходимо перестать мерить успех количеством «закрытых тикетов» или «написанных скриптов». Метрикой успеха должно стать время, потраченное разработчиком на инфраструктуру. Если он тратит более 5% — модель DevOps убыточна. Переход к платформенной модели способен сократить цикл разработки с недель до часов. Это прямое снижения операционных расходов и реальный рывок в капитализации.
Автоматизация ради автоматизации — это дорогое хобби, которое бизнес больше не может себе позволить. Настоящий DevOps начинается не с выбора между Terraform и Pulumi, а с вопроса: «Как это изменение поможет нам доставлять код быстрее и надежнее?». Если внедрение нового инструмента увеличивает TTM и строит новые заборы между командами — значит, вы просто сменили вывеску «Системное администрирование» на более модную, сохранив старые проблемы. Пора перестать коллекционировать «молотки» и начать, наконец, забивать гвозди. Чтобы ваша автоматизация не превратилась в «новые грабли», проведите ревизию процессов прямо сейчас:
· Упрощайте. Если задачу можно решить простым Containerfile, не тащите туда сложный Helm.
· Стирайте границы. Разработчик должен иметь возможность сам управлять окружением. Используйте rootless-решения, которые позволяют запускать контейнеры без прав суперпользователя — это дает командам автономность, не создавая дыр в безопасности и лишних тикетов на админов.
· Считайте метрики. Главный показатель успеха — это сокращение времени от идеи до выпуска в промышленную эксплуатацию, а не количество закрытых задач по автоматизации. DevOps — это мост, а не новая стена. Не дайте технологическому стеку стать препятствием на пути к здравому смыслу.
