Сегодня многие компании, ищущие решения своих потребностей в эксплуатации программных решений, размещают вакансии для DevOps (от англ. Development – развитие, Operations — эксплуатация), причем далеко не все специалисты по кадрам понимают, что это такое. Казалось бы все просто: есть программисты на Perl и PHP, значит, по аналогии, есть инженеры, которые знают какую-то там технологию DevOps. Однако, DevOps – это не технология и не язык программирования.

Методология DevOps возникла в 2009 году, но ее составные части известны с 90-х годов и успешно применялись на разных стадиях автоматизации разработки и эксплуатации ИТ-решений. Поскольку это понятие относительно новое, то у нас оно хорошо известно лишь в инженерной среде, а все остальные только примерно понимают, что это такое. Отсюда и возникло неверное представление, что Devоps – это некая суперсовременная технология, за которую надо просить и давать большие деньги. На самом деле DevOps – это методология, которая объединяет в себе управленческие и технические возможности.

Итак, DevOps состоит из четырех основных составных частей, которые должны реализовываться одновременно. Первый называется Culture (Культура — англ.) и подразумевает, что необходимо из двух отделов – развития и эксплуатации сделать единую структуру. При этом надо понимать, что изначально они являются антагонистами: программисты из отдела Development будут по требованию руководства как можно скорее пытаться внедрить новые фичи, а системные инженеры будут грудью вставать за старые разработки, которые имеют высокую отказоустойчивость. Поэтому совместить эти две разнонаправленные тенденции и примирить системных инженеров и программистов – это задача требующая определенных управленческих навыков.

Про Automation (автоматизация – англ.) говорить нет смысла. Она активно применяется в решении практически любых ИТ-задач и для этого необязательно применять упомянутую методологию.

Потребность в Measurement (измерения – англ.) у бизнеса возникает тогда, когда что-то в функционировании IT-системы идет не так. Тогда они обращаются к системному инженеру и просят найти причину. При использовании DevOps все происходит по-другому. Измерительные инструменты вроде стека StatsD/CollectD/InfluxDB/Graphana устанавливаются сразу, а измеряемые метрики внедряют прямо в код новой программы.

И, наконец, Sharing (обмен — англ.). Он предполагает, что все решения будут приниматься открыто, специфические знания для данного проекта будут накапливаться в каком-то едином, доступном для всех технических сотрудников месте. Это задача тоже относится к разряду управленческих, поскольку надо не только выложить и систематизировать используемые решения, но и, самое главное, убедить всех его участников поделиться своими персональными наработками.

А теперь пару слов об опасности неправильного использования методологии DevOps. Во-первых, если ее использовать по частям, беря скажем лишь инженерную составляющую (Automation & Measurement), то ожидать большого эффекта для бизнеса не стоит. Технические параметры создаваемого продукта, возможно, будут улучшены, но это может быть сделано силами команды Ops, а Developers будут по-прежнему существовать и думать отдельно.

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

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