Профессия DevOps-специалиста регулярно входит в рейтинги высокооплачиваемых и перспективных должностей в ИТ-индустрии. Так, по данным исследования сервиса HeadHunter, в первой половине 2019 года специальность вошла в десятку самых востребованных на рынке. Тем не менее, в России отсутствует независимая исследовательская экспертиза индустрии. В единственном крупном исследовании DevOps от Google в прошлом году участвовало менее 60 отечественных специалистов. Алексей Шевченко, ведущий DevOps-инженер в онлайн-университете Skillbox, рассказал о мифах, которые преследуют отечественный рынок, и о том, существует ли вообще DevOps в России.
Что такое DevOps и какие задачи выполняет DevOps-инженер
Термин DevOps (Development Operations, или операции внутри разработки — «Хайтек») впервые использовал в 2009 году ИТ-консультант Патрик Дебуа. По сути, он означает не просто вакансию, а целую методологию, которая позволяет создавать цифровые продукты эффективнее и быстрее. Смежный набор инструментов из разработки, продакт-менеджмента, программной инженерии и других специальностей обеспечивает непрерывный процесс создания ПО.
Богатый арсенал практик сближает DevOps с другим популярному в ИТ-сфере методом Agile. Это итеративный подход к проекту, который позволяет подстраиваться под меняющиеся требования. Соответственно, DevOps-специалист старается сделать продукт качественнее, а бизнес-процессы — предсказуемее и прозрачнее. Еще он улучшает бизнес-метрики, например, сокращает Time-to-Market. Это отрезок времени от начала разработки продукта до его выхода на рынок. Знание факторов, которые растягивают время создания ПО, и системный подход позволяют DevOps-инженеру сделать производство непрерывным и быстрым. Чтобы стало понятнее, можно провести аналогию с конвейером по сборке автомобилей. Все детали заранее проектируют так, чтобы они идеально подошли друг к другу на сборке. Инженеры, которые разрабатывают двигатель, думают о его работе в связке с колесами, тормозной системой и так далее. Тем же занимается и DevOps: берет на себя ответственность за большую часть продукта, чем разработчик, следит, чтобы все команды сотрудничали.
Мир розовых пони: гонка за модной философией
Тем не менее, DevOps нужен не всем компаниям. Например, в коллективах без уже существующих ИТ-отделов, которые не занимаются производством digital-продукта, философия DevOps вовсе не применима. К этим сферам относятся компании, чья прибыль не зависит напрямую от того, насколько клиенты удовлетворены ИТ-продуктом, с которым они взаимодействуют. Кроме того, часто она не подходит малому бизнесу. Методология требует изменений многих выстроенных бизнес-процессов и даже корпоративной культуры. Небольшие компании могут попросту не вынести таких изменений с точки зрения экономики проекта.
Модная болезнь digital-трансформаций зачастую касается руководителей таких компаний. В погоне за бесконечной оптимизацией они забывают про другие факторы, которые влияют на бизнес. В итоге компании теряют деньги, эффективность, а в худшем случае и бизнес-процессы, которые выстраивали годами.Другое дело — ИТ-гиганты, банки, крупные торговые и производственные мероприятия. Для них внедрение DevOps может принести большую выгоду. Так, по годовому отчету «Альфа-банка» за 2017 год, внедрение методологии позволило ускорить разработку и внедрение в 60 раз.
Стахановец-многостаночник вместо цеха сотрудников
Конечно, такой обширный функционал тяжело выполнять одному сотруднику, поэтому в идеале DevOps занимается целая кросс-функциональная команда. В нее входят специалисты, выполняющие роли и менеджеров процессов и продукта, разработчика инфраструктурного кода, инженера и еще много других ролей. Тем не менее, в российской практике DevOps-специалист часто может стать модным способом сэкономить деньги на создании продукта. Обычно такая ситуация происходит после того, как топ-менеджер компании решает, что наступило время digital-трансформации. В компанию экстренно набирают новых специалистов или расширяют список обязанностей уже существующих разработчиков и системных администраторов. В итоге на рекрутинговых сервисах появляются вакансии не DevOps-инженера, а многостаночника.
Такого сотрудника могут обязать единолично настраивать серверы, прокладывать кабельные системы, а потом отслеживать ошибки, настраивать базы данных и хостинг проектов и так далее. Это пример экстремальный, но реальный. В результате сотрудники быстро выгорают, а внедрение методологии в работу компании проваливается. Отношение к DevOps-специалисту как к волшебнику, который способен одновременно управляться с большим количеством задач вкупе с мониторингом работы всей системы, не принесет бизнесу прибыли.
Другая распространенная проблема связана с разделением коллектива на две группы, которые не могут ужиться друг с другом. Представим, что в ИТ-компании появляется отдел DevOps, которому разрешают менять привычные регламенты работы. При этом эти правила остаются обязательными для других разработчиков. Конечно, о кооперации и «бесшовности» работы говорить в таком случае не приходится. Две команды начинают конфликтовать, и продуктивность падает.
Бочка пороха в трюме: DevOps — не просто навыки
Одна из задач DevOps-отдела — налаживание коммуникации между разными ИТ-специалистами компании. DevOps-инженеры должны не просто внедрять технологии и отлаживать процессы, но и погружать команду разработки в курс дела — разделять полномочия, помогать повысить компетенции. Тем не менее, часто такие специалисты занимаются сугубо техническими задачами, обычно по причине банальной нехватки времени и у них, и у тех, чьи компетенции требуется наращивать.
В итоге из-за того, что внедренными модными технологиями пользуются все, а знания и навыки сконцентрированы в рамках одного отдела, возникают проблемные ситуации, в том числе катастрофического характера. Новые решения, которые создают DevOps-инженеры, без слаженной работы разных подразделений могут принести столько же проблем, сколько должны были решить изначально.Это не значит, что DevOps-специалисты должны с нуля создавать корпоративную культуру, как, по всей видимости, часто считают отечественные руководители. Единство «конвейера» digital-производства и поощрение передачи новых навыков и общения должно исходить от руководителей компании. Без этого даже DevOps-команда будет слабо развиваться и не станет делиться знаниями с коллективом.
Эти проблемы не решает ни аутсорс DevOps, ни консалтинг со специалистом со стороны. В первом случае внешняя команда ориентируется не на нужды компании-заказчика, а на стандартный набор технологий, который котируется по рынку. Для клиента это лотерея: сотрудники на аутсорсе пользуются размытыми представлениями о DevOps на рынке. В итоге бизнес-процессы усложняются все больше, но это не приносит бизнесу никаких преимуществ. Зачастую сами компании поощряют такой подход — например, просят не менять процессы разработки. Понятно, что это противоречит самому понятию DevOps.
Долго, дорого, проблемно: суровый DevOps по-русски
Вместо того, чтобы применять философию DevOps ко всем бизнес-процессам, отечественные компании часто предпочитают работу над инструментарием, который не повлияет на скорость работы. Одним из итогов, например, является «кирпичная стена» — Operations, то есть команда системных администраторов, остается в изоляции, а разработчики просто закидывают им приложения. Конечно, в результате набор инструментов все равно улучшается. Однако фундаментальных изменений не происходит, прозрачность не растет, а кооперация ИТ-команд не становится успешнее.
Еще одна загвоздка, на которую натыкаются менеджеры при внедрении DevOps — отсутствие корпоративных баз знаний. По данным отчета DORA за 2019 год, команды, которые использовали внутренние источники информации компании, были в 1,73 раза эффективнее других. Эта проблема снова сводится к закрытости культуры многих российских компаний, в которых коллектив не обменивается знаниями. Из-за этой закрытости компании начинают накапливать технический долг. Инструментарий устаревает, артефакты не удаляют, документацию не обновляют.
Объективная потребность бизнеса к стабильности производства, а значит, и прибыли, вкупе с устаревшей базой технологий и техническим долгом приводят к неудачному применению DevOps.
Все это часто приводит к тому, что после долгих мучений новые решения, которые предлагает DevOps-команда, просто выбрасываются, и процессы «откатываются» назад.
У каждой компании свой путь digital-трансформации. В большинстве случаев она действительно меняет разработку и развертывание кода к лучшему. Значит, DevOps в России все-таки существует: каждый месяц на рынке появляется множество вакансий, связанных с этой методологией. Другое дело, что стоят за ними разные определения специальности и практические задачи. Тем не менее, компаниям стоит перестать гнаться за призрачными идеальными ИТ-системами и критически относиться к переходу на модную, но не обязательно выгодную философию, отдавая больший приоритет собственным потребностям.
Читайте также:
В черных дырах могут быть вселенные. Рассказываем о новом открытии
На 3 день болезни большинство больных COVID-19 теряют обоняние и часто страдают насморком