Как-то стал свидетелем разговора двух приятелей и услышал:
«У вас уже внедряют DevOps? Просто у нас в МегаТелеКо все идет полным ходом! Недавно мы набрали команду DevOps из 35 человек!»
Так почему нанять команду DevOps это плохая идея?
В тот момент я удержался от фейспалма в стиле Капитана Пикара. К несчастью, найм сотрудников на должность, содержащую слово DevOps и радость участника этого разговора по этому поводу не случайное заблуждение. По быстрому обзору источников в интернете следует, что множество компаний ищут инженеров DevOps, которые в числе прочих будут заниматься:
- автоматизацией изменений в инфраструктуре
- настройкой JIRA
- администрированием MySQL
- поддержкой масштабных Linux проектов
- ведением всего, что связано с puppet
- написанием скриптов на ruby, python или bash
- оперативным подпиранием «костылями» тут и там
Cписок составлен из кусков реальных вакансий, немного изменен, чтобы не намекать на кого-то конкретного.
В целом, я положительно отношусь к тому, что концепция DevOps становится популярной. Однако, как уже было с Agile, DevOps в опасности получить статус очередного модного термина, а впоследствии и утратить всякий смысл. Сдается мне, большая часть компаний, ищущих DevOps, хотят нанять просто сисадмина, но выглядеть при этом современно. Львиная доля требований в стандартной вакансии DevOps полностью покрывается компетенциями инженера поддержки или системным администратором. При этом особенно забавно, что в этих требованиях зачастую отсутсвует пункт «умение создавать простые и работающие решения». Похоже, вместо того, чтобы работать в направлении взаимодействия разработки и поддержки для улучшения качества, ИТ-индустрия пытается «срезать», просто пожаловав админу новое звание — DevOps.
Так что же действительно нужно для развития DevOps?
Вместо создания новой команды DevOps, попробуйте убрать стену между отделами разработки и поддержки. Разработчикам и сисадминам стоит встречаться на регулярной основе, дабы проговаривать все рабочие моменты, включая установку, настройку софта и его проблемы. Обратная связь и обсуждение идей должны работать в обе стороны. Руководителям проектов следует считать сисадминов такими же пользователями ПО, а значит, рассматривать их сценарии работы и учитывать пожелания, как делают это для внешних пользователей. Разработчикам же следует отнестись с пониманием к требованиям поддержки и ответственно подойти к их реализации. Конечно, две команды должны оставаться самостоятельными, ведь у каждой своя специфика, сильные стороны и компетенции, но совместная работа в рамках «суперкоманды» с общей целью — создавать и сопровождать изящный и качественный продукт для решения непростых задач бизнеса.
Вместо повсеместного скриптования инфраструктуры следует делать софт целостным и логичным. Есть мнение, что термина DevOps нет в Windows по причине отсутствия в этой экосистеме эффективных средств автоматизации как в мире Linux (здесь я намекаю на chef и puppet). Трудно не согласиться, такие инструменты крайне полезны, но я не поддерживаю мнение, что краеугольным камнем DevOps является автоматизация. На самом деле, ваш софт не должен полагаться на нетривиальные скрипты для установки и настройки (не важно perl, puppet). Внедрение должно быть простым, в идеале, как обычный xcopy на целевую машину (хорошо бы, если софт при первом запуске сам себя и установит). Настройки следует получать от конфигурационного сервиса, а не устраивать карнавалы XML файлов. Вместо конструирования очередной машины Голдберга, дабы заскриптовать все особенности и сложности настройки вашего софта, взаимодействуйте, наконец, с разработкой (и с менеджментом), чтобы избавиться от таких проблем и от ненужной сложности.
Не думайте о DevOps как об очередном модном словечке, лучше примите эту философию и распространите ее. В реальности, DevOps нельзя наладить простым наймом специалистов с этим словом в резюме или внедрением монструозного ПО автоматизации. Чтобы постигнуть дзен DevOps, нужен культурный скачок. Разработчики, которые зациклены на конечных пользователях, должны обратить взор на поддержку и ее потребности. Админы, вместо тихого ворчания, должны сообщать о неудобствах продукта и вносить вклад в улучшение процесса работы. Таким образом, налаживание связей внутри компании это первый и важный шаг. Далее, придется уделить время и ресурсы для улучшения продукта до состояния «простой и удобный». Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах — важные задачи на этом пути.
DevOps должен приниматься не для галочки. Эта философия подразумевает общение и взаимодействие, а главное, стремление создавать качественное программное обеспечение, которое разрабатывается, поддерживается и используется с удовольствием.
Автор: anuriq
