Страх и ненависть DevOps-специалиста: что не так с профессией в России

DevOps — междисциплинарный набор инструментов, который обеспечивает непрерывную разработку. Специальности, связанные с этой методологией, признают одними из самых высокооплачиваемых. HeadHunter предлагает более 1 400 вакансий по Москве с указанной зарплатой от 100 000 до 425 000 рублей.

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

Алексей Шевченко

ведущий DevOps-инженер онлайн-университета Skillbox

Чем занимается DevOps-инженер

Для начала чуть истории: термин Development Operations, или «операции внутри разработки» первым использовал IT-консультант Патрик Дебуа десять лет назад. Это методология, которая направлена на более эффективное создание цифровых продуктов. DevOps устраняет разрыв между IT-специалистами и помогает создать продукт на конвейере. Методология применяет целый набор инструментов разработки, программной инженерии, продакт-менеджмента и других специальностей.

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

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

Погоня за популярной методологией

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

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

Однако для больших IT-компаний, финансовых и торговых предприятий, крупных производств интеграция DevOps-культуры принесет выгоду. К примеру, в 2017 году «Альфа-банк» отчитался, что DevOps помог ускорить разработку в 60 раз.

Тотальное выгорание: DevOps-сотрудник вместо целой команды

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

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

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

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

DevOps — культура, а не умения

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

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

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

«Кирпичная стена» DevOps в России

Компании зачастую предпочитают вводить отдельные инструменты DevOps, а не применять всю философию к процессам работы. Однако вырванные из логики методологии инструменты вряд ли повлияют на скорость работы. Скорее, наоборот, они могут привести к так называемой «кирпичной стене» — изоляции команд разработчиков и системных администраторов. Кооперация IT-команд становится сложной и менее продуктивной: разработчики просто закидывают администраторам приложения.

Другая проблема — недостаток разработанной корпоративной базы знаний. По информации DORA за 2019 год, команды, которые использовали внутренние источники информации компании, были почти в 2 раза продуктивнее других. Инструменты устаревают вместе с уходом сотрудников-носителей знаний, а документация не обновляется. В итоге результативность введения DevOps стремится к нулю.