Дэймон Эдвардс / 8 ноября, 2010

С того момента как Патрик Дебуа организовал первую конференцию DevOps Days и явил миру термин “DevOps” не может быть сомнений, что DevOps развился до уровня глобального движения.

Безусловно, DevOps движение имеет своих хулителей. Негативные мнения варьируются от ошибочных («DevOps — это новое название для сисадминов») и пренебрежительных («DevOps — это просто какие-то безумные разработчики (Devs), которые пытаются избавиться от админов (Ops)» или «DevOps — это какие-то безумные админы, которые хотят казаться разработчиками, чтобы их больше любили») до выражений обиды (как правило, с аргументами, не поддающимися логике).

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

DevOps это не проблема технологий.

Технологии играют ключевую роль в создании решений тех проблем, которые пытается решить DevOps. Однако, DevOps, по своему определению, является проблемой бизнеса.

Какое отношение бизнес имеет к DevOps?
Основополагающий бизнес-процесс в любой компании — взять идею от момента ее рождения в голове и донести ее туда, где она будет приносить деньги.



Внутри этого бизнес-процесса происходят многие виды разных активностей, которые нужны, чтобы идея реализовалась. Часть из этих активностей движимы технологией, часть — зависит от людей. В этот момент начинает играть свою роль IT: разработчики, тестировщики, архитекторы, release-инженеры, специалисты по безопасности, люди из эксплуатации и другие — все они выполняют свою часть работы в этом общем процессе реализации идеи.



Но если убрать контекст бизнес-процесса, что у вас в итоге останется? У вас остается кучка людей и разных групп, делающих что-то сами по себе и живущих своей жизнью. Вы теряете реальный стимул бороться с неэффективностью, ненужной переработкой, конфликтами и отсутствием связи между этими группами. В буквальном смысле получаем ситуацию, где каждый сам за себя.



А знаете, что еще случится, если убрать контекст бизнес-процесса? Со временем вы лишитесь работы. Только благодаря тому, что мы даем возможность работы бизнесу, мы получаем зарплату и возможность делать то, что мы делаем.

Если нет самого бизнеса или мы не даем этому бизнесу реализовывать свои идеи, вся наша работа превращается не больше чем в простое хобби. И, по своему определению, довольно сложно получать зарплату за хобби.

Весь смысл DevOps состоит именно в том, чтобы дать возможность бизнесу реагировать на движущие силы рынка как можно быстрее, эффективнее и надежнее. Без бизнеса, у нас нет иных причин, чтобы говорить о DevOps проблемах, и совсем нет смысла заниматься их решением.



Разве это не похоже на цели Agile?

Если цели DevOps и выглядят похожими на цели Agile, то это потому, что они на самом деле похожи. Но Agile и DevOps — это разные вещи. Вы можете идеально выстроить разработку по Agile, но, тем не менее, иметь много DevOps проблем. С другой стороны, вы можете хорошо справиться с устранением DevOps проблем, при этом совсем не используя разработку согласно Agile принципам (хотя это достаточно маловероятно).

Мне нравится описывать Agile и DevOps как две родственные идеи, которые берут общие корни из Lean методологии, но работают на разных уровнях. В то время, как Agile фокусируется на улучшении одной IT функции (доставка ПО), DevOps работает над улучшением взаимодействия и работы всех IT функций (покрывающих весь жизненный цикл продукта: от разработки до сопровождения).
Но я думал, что DevOps — это про крутые инструменты?

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



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

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

Поскольку зарождающееся DevOps движение в основном состоит из инженеров, несложно понять, откуда берется такой азарт сразу же погрузиться в обсуждение инструментария. Но возможно, нам нужно приложить больше усилий, чтобы удостоверится, что все достаточно вникли и понимают, почему нужны те или иные инструменты и что является желаемыми улучшениями бизнес-процесса, прежде, чем окунуться в обычные споры «Puppet vs. Chef» или «Files Centric vs. Package Centric».



Если DevOps — это про бизнес-процессы, тогда почему это вообще называется «DevOps»?
На мой взгляд, одна из ошибок ранних разговоров о DevOps заключалась в том, что не было сразу понятно, насколько большой масштаб той проблемы, о которой велась речь. Теперь, когда за нашими плечами уже год опыта, становится ясно, что мы работаем над одной из самых больших проблем бизнеса: как предоставить бизнесу возможность реагировать на рыночные силы так быстро, насколько это вообще возможно.

Этот разговор должен был где-то начаться, и он, увы, тяготел к обсуждению всеобщей проблемы конфликта и отсутствия связи между разработчиками (Dev) и эксплуатацией (Ops). Организационная структура каждой компании различна, но, тем не менее, можно довольно легко карикатурно разделить мир на Dev-лагерь и Ops-лагерь и, таким образом, иметь общие ориентиры для обсуждения (хотя мы и понимаем, что мир намного сложнее и отнюдь не черно-белый).



В этом карикатурном Dev/Ops примере, основная часть внимания DevOps методологии на раннем этапе была обращена на улучшение процесса деплоя. И, поскольку процесс внесения изменений составляет львиную долю работы в IT организациях, это было также логическим и естественным местом для начала.

Возможно, Патрику стоило назвать первую конференцию «BizDevQASecurityOpsCloudUsers Days» или «SolvingABroaderProblemThanAgile Days»… Но я сомневаюсь, что кто-то бы пришел.