Привет, Хабр!

Сегодня предлагаем вам перевод мировоззренческого поста Лиама Виттерика (Liam Witterick) — о заблуждениях в работе DevOps-инженера. Виттерик уже несколько лет помогает внедрять практики DevOps и оценивает, какую выгоду получают компании.

Автор продвигает существенные организационные изменения, внедряя инструменты автоматизации и принципы «бережливого» производства, и помогает эффективно выпускать хорошо масштабируемое ПО с высоким уровнем безопасности и надежности.

За эти годы Виттерик получил немало отзывов от коллег и прочитал достаточно много невероятных историй о том, что другие люди на аналогичных должностях делают в своих компаниях. Однако по сей день к термину «DevOps-инженер» остаются некоторые вопросы. Внесем некоторую ясность и ответим на них.

Если DevOps — это изменение культуры, как с этим может справиться один человек?

DevOps — это не человек и даже не команда. Это набор практик, методология компании в целом.

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

Собственно, это и стало причиной того, что термин «DevOps» неоднократно применялся для описания вещей, которые противоречат его истинному значению.

Одно из самых больших злоупотреблений этим термином — «DevOps-инженер».

Почему?

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

DevOps-инженер не разрабатывает практики DevOps.

DevOps-инженер помогает их внедрять.

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

Итак, откуда вообще появился термин «DevOps-инженер»?

Трудно точно определить, откуда именно взялось это название, но вот мои соображения.

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

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

Со временем эти люди приобрели новый уникальный набор навыков, который отличался от тех, которые традиционно соответствовали роли системного администратора. Теперь они стали неотъемлемой частью процесса доставки программного обеспечения и движущей силой внедрения DevOps.

Их новая задачи включали:

• коммуникацию между командами разработки и эксплуатации;
• реализацию коротких циклов обратной связи с помощью CI-конвейеров;
• подготовку релизов с помощью Continuous Delivery;
• создание повторяемой и масштабируемой инфраструктуры с помощью Infrastructure as Code;
• внедрение инструментов мониторинга, логирования и безопасности.

«И швец, и жнец, и на дуде игрец. — подумал бизнес.  — Как же нам нанять таких, да побольше?» И чтобы отличить обычных сисадминов от тех специалистов, которые обладали вышеописанными навыками, компании при содействии HR’ов придумали им новое название — «DevOps-инженер».

Почему DevOps-инженер — это не просто системный администратор?

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

Прежде чем я поясню свою мысль, хочу подчеркнуть, что я нисколько не умаляю важность роли сисадминов и сам долгое время был одним из них. 

Несмотря на то, что в некоторых аспектах роли администраторов и DevOps-инженеров похожи, они не идентичны. Давайте определимся с обязанностями каждого из них.

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

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

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

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

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

Вместо заключения

Надеемся, что мои мысли внесли некоторую ясность относительно роли DevOps-инженера. 

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

.