DevOps был действительно трансформирующим подходом, который позволял командам разрабатывать, развёртывать и обновлять программное обеспечение быстро, легко и без традиционных разногласий (или стычек) между стражами райских врат, операционной командой, и наступающими ордами разработчиков. Он возглавил волну инноваций в автоматизации, мониторинге и создании ПО, способствовал практически повсеместному использованию виртуализации и контейнеризации и был, в широком смысле, глотком свежего воздуха в отрасли, последним крупным изменением подходов в которой была методология Agile. Я горжусь работой, которую проделал в сфере DevOps, и я провел много времени, усердно внушая людям веру в его чудеса.

А теперь для DevOps пришло время умереть.

Пока вы не отправились рассказывать всем, что я сошёл с ума, или, что еще хуже, не нашли кнопку “Комментировать”, выслушайте меня. DevOps, как методология, имеет крайне важное значение для поставки технологий в современных условиях. Мы не должны возвращаться в обнесенные стенами сады прошлого – туда, где функционально разделённые технологические департаменты смотрят друг на друга сквозь туман недоверия и взаимных сомнений в квалификации, и иногда подбрасывают друг другу релизы. Методология DevOps превосходна и в настоящий момент созрела для расширения с помощью других методологий, например таких, как MetOps. В любом случае использование аббревиатуры DevOps в названиях должностей или в качестве дополнения к названию должности нужно прекратить.

Помимо нелепости самой идеи назвать должность в честь методологии (вы же, например, не нанимаете «гибких»), это также противоречит ключевому принципу DevOps: объединение разработчиков и операционной команды. Называя кого-то «DevOps» или «DevOps Engineer», вы всё еще делаете их «другими»; хотя они вместе с разработчиками сидят на корточках в одном КПЗ.

Для большинства разработчиков крупных предприятий ничего не изменилось. У них по-прежнему есть привратник, просто теперь он стал ближе к разработчикам. Во многих организациях DevOps-инженеры преобразовались в отделы мини-операций. Мы по-прежнему “проталкиваем” релизы, просто теперь их надо “толкать” на более короткой дистанции.

Это может и будет создавать разногласия внутри команды, но при этом традиционное противоборство «Разработки и Эксплуатации» теперь принимает вид столкновений внутри маленьких команд, а не глобальных “войн”. Всё это вызывает неприятный побочный эффект в виде появления у технического директора уверенности в том, что операционный отдел больше не нужен. Не правда ли, если у нас столько людей с приставкой «Ops» в должности, то нам не нужны дополнительные ops-департаменты?

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

Как же мы оказались в такой ситуации, учитывая всеобщий восторг в отношении DevOps и автоматизации? Как правило, это связано с корпоративной культурой и инерцией. В какой-то момент разработчиков заклеймили, как слишком небезопасных, чтобы быть допущенными к инфраструктуре беспрепятственно и без надзора. Аргумент, во многом аналогичный тому, что никто не должен иметь доступ к созданию кода приложения и его выпуску в продуктивную среду без должного контроля. Эта проблема разработки давно была решена с помощью современного SDLC (жизненного цикла разработки программного обеспечения). Разве автоматизация не обещала устранение этой проблемы и наступление эры свободы разработчика? Не в этом ли весь смысл методологии DevOps?

Совершенно правильно, автоматизированная инфраструктура и выпуск ПО могут управляться так же, как программный код. Код инфраструктуры специфицируется бизнес-аналитиком, проверяется архитектором, реализуется разработчиком вместе с модульными тестами и механизмами мониторинга, контролируется службой качества и, наконец, пройдя через различные тестовые среды, выпускается. Когда необходимо добавить новую функцию в инфраструктуру, формируется отдельная ветвь разработки, функция разрабатывается, затем выпускается запрос на развёртывание, который проверяется и принимается. Нет никакой причины для того, чтобы ограничивать разработчика приложения в возможностях по созданию отдельной ветви разработки кода инфраструктуры, внесению улучшений и регистрации запроса на развёртывание. Этот запрос затем может быть рассмотрен разработчиками инфраструктуры. Если это “хорошее” изменение, оно принимается и развёртывается. Если его необходимо доработать, разработчики инфраструктуры дадут обратную связь, и первоначальный разработчик сможет внести корректировки и повторно отправить запрос на развёртывание. И если запрос отклонен, разработчики инфраструктуры должны во всеуслышание объяснить причины.

Итак, почему, если всё это сейчас возможно, у многих разработчиков есть ощущение, что они ждут чего-то от «DevOps команды»? На мой взгляд, причин тут две.

В первую очередь, многие проекты, утверждающие, что они следуют методологии DevOps и развивают автоматизацию, по факту этого не делают. Довольно часто они лишь прикрылись DevOps-инженером в команде (или, что еще хуже, самой «DevOps-командой»), как фиговым листом, чтобы показать, что они молодцы и идут в ногу со временем и Силиконовой долиной. Копните глубже, и вы увидите всё те же старые процессы. В результате вместо операционного отдела у вас масса бегающих вокруг “мини-ops”, которые контролируют отдельные компоненты и которым предоставлен эксклюзивный доступ к инфраструктуре для создания компонентов вручную. Я всё ещё жду встречи с бизнесом, где могут объективно утверждать, что полностью всё автоматизировали. На определённом уровне, будь то обновление записей DNS, управление сетью или что-то еще, автоматизация у них всё равно отсутствует, и сотрудникам нужно преодолевать бюрократические преграды, чтобы вносить изменения в эту часть инфраструктуры. Несмотря на то, что это не вина «местного» DevOps-инженера, это по-прежнему воспринимается, как операционный “тормоз”.

Во-вторых, у вас есть нетерпеливые разработчики. Все хорошие разработчики хотят поставить код, который является функциональным, безопасным и, прежде всего, классным и забавным. Их невероятно разочаровывает, если они не могут делать так из-за «ненужного» ожидания новых вычислительных мощностей, средств хранения данных, создания сетей и т.д.

Однако DevOps-инженеры часто защищают этих разработчиков от большей части корпоративной несуразицы. Разработчики не осознают, что неотъемлемые сложности бухгалтерского учета, обеспечения безопасности или просто соблюдения политик, часто делают мучительным только лишь путь к той точке, в которой вы сможете «развернуть несколько серверов» в консоли AWS.

Другая проблема заключается в том, что разработчики приложений могут “зависать” в ожидании реализации новых функций, необходимых для дальнейшего движения, разработчиками инфраструктуры. Иногда это может быть сложнее, чем внедрение новой функции приложения. Это может включать уточнение требований и упрощение существующего бизнес-процесса, прежде чем его можно будет автоматизировать. Когда автоматизация становится возможной, необходимый код, как правило, достаточно тривиален, но при этом заставляет пересмотреть сформировавшиеся за десятилетия подходы к бюджетированию выделения новых мощностей или управлению DNS-записями.

Решение заключается в привлечении разработчиков приложений. Если разработчик приложения вынужден приостановить свою работу в ожидании новой функции инфраструктуры, появление которой задерживается вследствие “долгого” процесса, то позовите разработчика приложения на встречи, где обсуждается этот процесс. Это поможет им осознать существующие нетехнические барьеры и получить лучшее понимание процесса.

Итак, как нам сотрудничать эффективнее? Я бы посоветовал начать с распространения “сверху-вниз” следующих правил:

1. Есть только разработчики. Нет «DevOps», «QC» и прочих. Существуют «разработчики инфраструктуры», «разработчики приложений», «разработчики тестов» и так далее.
2. Все изменения инфраструктуры осуществляются с помощью кода, и весь код инфраструктуры доступен для разработки.

Первое избавляет нас от синдрома противопоставления “мы-они”. Нет отдельной роли, просто разработчики с различной специализацией. Они управляются одинаково, следуют тем же процессам, что и другие разработчики, и во всех отношениях просто являются членами команды разработчиков. Если разработчик не может выполнить свою работу из-за отсутствия инфраструктуры, это просто случай плохого управления спринтом; необходимая функциональность инфраструктуры должна быть идентифицирована, оценена и реализована до того, как её отсутствие станет барьером. То же относится к любой функции приложения. Такое изменение процесса не будет слишком затруднительным.

Второе изменение реализовать несколько сложнее. Когда мы говорим, что единственный способ изменения инфраструктуры – с помощью кода, это правило действует в рамках всего предприятия. Хотите новую DNS-запись верхнего уровня? Это изменение кода. Хотите выделить новое устройство хранения? Код. Хотите нового пользователя? Код. И так далее.

Нет причин, по которым вы не можете разрешить любому разработчику в компании изменять код и выдавать запрос на перенос, если эти элементы автоматизированы. Почему бы не позволить добавлять нового пользователя в рамках проектов? Ведь проекты регистрируются, включают в себя автоматизированный аудит, могут быть скорректированы и отклонены. Почему бы не позволить добавлять ресурсы верхнего уровня через код? Нет никаких непреодолимых или просто веских причин, почему этого нельзя делать. Как ничто другое, предлагаемый подход немедленно избавит вас от недостатка автоматизации внутри компании, а также будет стимулировать сотрудничество с операционными командами, которые следят за инфраструктурой. Если код является “lingua franca” (базой для единого языка, на котором осуществляется коммуникация, прим.перев.) при осуществлении изменений, происходящее и его причины прозрачны и понятны для всех заинтересованных лиц.

Итак, примите DevOps-методологию и искорените DevOps-должность. Теперь мы все разработчики, просто отличаемся специализацией. Мы все хотим одного и того же – возможности сосредоточиться на написании классного программного обеспечения, которое делает удивительные вещи.

Оригинал We need to kill DevOps, автор Майк Даффи (Mike Duffy)

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы