Почему бы мне не попробовать нанять 'DevOps Engineer'?

Идея иметь DevOps Engineer стала довольно популярной в последнее время , и кажется привлекательным просто иметь человека, который может подключиться и предоставить многие из преимуществ DevOps, как описано в блоге Puppet :

Организации, использующие практики DevOps, чрезвычайно активны: они развертывают код в 30 раз чаще, чем их конкуренты, и на 50% меньше их развертываний, в соответствии с нашим отчетом о состоянии DevOps за 2015 год.

Тем не менее, я заметил, что многие разработчики DevOps попытались сделать следующие улучшения:

Даже при широком согласии относительно основных атрибутов DevOps, спор окружает термин «инженер DevOps». Некоторые говорят, что сам термин противоречит значениям DevOps. Джез Хамбл, соавтор Continuous Delivery, отмечает, что просто вызов кого-то из инженеров DevOps может создать третий бункер в дополнение к dev и ops - «... явно плохой (и ироничный) способ попытаться решить эти проблемы «.

Почему для бизнеса не может быть хорошей идеей нанять инженера DevOps, чтобы попытаться «внедрить DevOps», в отличие от организационных изменений, пропагандируемых такими блогами ? Будут ли преимущества сведены на нет только наличием изолированной роли DevOps?

TL; DR : Вы никогда не должны пытаться нанять команду DevOps

Существуют три наиболее распространенных роли, которые можно нанять:

1. DevOps Архитектор / Евангелист
2. DevOps Engineer
3. Инженер CI / CD

Эти роли отличаются от 6 основных ролей разработки программного обеспечения, которые традиционно составляют организацию разработки программного обеспечения:

1. Управление продуктом
2. Разработка программного обеспечения
3. Разработка инструментов
4. Безопасность и соответствие
5. Качество и Тестирование
6. Системные Операции (SRE)

Давайте пройдемся по трем ролям одна за другой и посмотрим, как они подходят

DevOps Архитектор или Евангелист

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

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

DevOps Engineer

• Почему :
  1. Устранить разрывы между командами, если они организованы в соответствии с функциональными ролями, упомянутыми выше, для обеспечения межфункционального сотрудничества.
  2. Объединить ориентированные на продукт команды, в каждой из которых есть 6 традиционных ролей, чтобы помочь преодолеть пробелы в знаниях и помочь с внедрением и внедрением новых практик и инструментов.
• Когда : как только вы изложите свои планы, начнется организационная трансформация, и вся управленческая команда будет в курсе.
• Что : Обеспечить межфункциональное взаимодействие, убедиться, что границы групп нарушены, что локальная оптимизация внутри групп не создает барьера для высокой пропускной способности работы по всей цепочке создания стоимости на всем пути от пожеланий клиентов до поставок клиентам.
• Кто : Опытный инженер с навыками как в разработке программного обеспечения, так и в работе систем. Он должен быть опытным в лучших практиках, процессах и культурных изменениях, связанных с трансформацией DevOps.

Инженер CI / CD

• Почему : чтобы помочь реализовать конвейеры CI / CD, интегрируйте свою цепочку инструментов, внедрите инструменты, которые позволят улучшить работу компании.
• Когда : Во время перехода в более крупную организацию, пока вышеперечисленные роли уже заполнены.
• Что : Инженер, который, по сути, является частью команды инструментов, которая сможет настроить конвейеры CI / CD и начать интеграцию внутренних систем таким образом, чтобы устранить трения в производительности.
• Кто : Инженер с опытом работы с инструментами, процессами интеграции, управления выпусками и DevOps. Кто-то, кто понимает, что он заменяет человека в процессе выпуска на Automation.

Я бы сказал, что Devops Engineer, как описано в вашем вопросе, является в основном ролью системного администратора. Процитируем навыки здесь для фона к этому ответу:

Ваше снаряжение для скалолазания.

• Сильный опыт работы в администрировании Linux / Unix с автоматизацией / управлением конфигурацией с использованием Puppet, Chef или аналогичного
• Возможность использования широкого спектра технологий с открытым исходным кодом и облачных сервисов (необходим опыт работы с AWS)
• Большой опыт работы с SQL и MySQL (опыт работы с NoSQL тоже плюс, так как мы также используем Redis)
• Рабочее понимание кода и скрипта (PHP, Python, Perl и / или Ruby)
• Знание лучших практик и ИТ-операций в постоянно действующей, всегда доступной услуге

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

Это слабо связано с практикой DevOps и разрозненной культурой между dev и ops, как видно из этого вопроса. В чем разница между Sysadmin и DevOps Engineer?

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

В ответе @ Jiri Klouda на успешную модель достижения прибыли от devops представлен отличный обзор приемлемой роли DevOps Engineer, а также шаг в изменении, который принесет пользу и поможет добиться успеха.

Я понимаю, что этот ответ может быть не совсем подходящим для вас, но вот что я сделал

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

Зная это, я решил структурировать свою инфраструктуру таким образом, чтобы мне пришлось заниматься администрированием систем ZERO.

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

Это позволило мне, как разработчику, взять на себя эту роль Devops. Я построил инструменты выпуска кода, на Python, Fabric. Я использовал тот же сценарий для начальной загрузки моего приложения на новые серверы, которые автоматически масштабируются.

Это сработало очень хорошо, и сегодня, 3 года спустя, я до сих пор не занимаюсь обслуживанием системы. У нас есть системный администратор (тот же инженер AWS) по 10 часов в месяц, и я стараюсь структурировать его спринты таким образом, чтобы я не стал для него раздражением. Таким образом, я уважаю его время и управляю его спринтами как можно лучше.

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

Я надеюсь, что этот ответ может как-то помочь вам

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

DevOps - это обязательно работа, основанная на команде, и вы не можете ожидать, что один человек поддержит ожидания всей команды. Рассмотрим сферу DevOps. Один человек не может:

• Будьте разработчиком Rockstar на [язык]
• Будьте сетевым гуру, зная все необходимые RFC
• Быть системным администратором
• Будьте экспертом в тестировании QA
• Быть администратором базы данных
• Специализируюсь на хранении и резервном копировании
• Знать надежность сайта
• Потенциально и другие дисциплины

Некоторые из вышеперечисленных даже имеют под дисциплины, такие как системный администратор Windows или системный администратор Linux / Unix или, возможно, вы используете более одного языка кодирования в своем.

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

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

Это означает, что любой, кто говорит вам, что знает все аспекты DevOps, вероятно, лжет вам. Наймите специалиста в области, в которой вы слабее всего работали в команде DevOps, а не «Инженер DevOps».

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

То, что мы сделали, было:

• Потеряв термин инженеров DevOps, DevOps - это то, что мы все должны делать, а не название нашей работы, поэтому мы назвали их чем-то другим.

• выкатывали их в команды, но только 1 на 3, это означало, что они не могли быть деятелями, но должны были рассматриваться как компетенция, чтобы помочь командам стать лучше и решать свои собственные проблемы (с руководством)

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

По мере развития мы пересматриваем эту модель, но пока она работает эффективно.

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

• Как на борту компании с практикой DevOps
• Какое приложение или услугу предоставляет компания
• Структура вашей компании

Я только что прошел собеседование на должности и получил звание инженера DevOps, но кое-что из того, что я делаю, - работа Sys Admin. Это просто необходимо из-за размера компании и характера управляемых приложений. Некоторые должности, на которые я брал интервью, имели похожее название, и они больше искали кого-то с точки зрения развития событий. Они ожидали больше написания кода, а не системного администратора, который занимается автоматизацией. SRE, похоже, завоевывает популярность, так что это может быть путь. Я был моим системным администратором и инженером по автоматизации в качестве моей последней работы, потому что я писал ансайлы, а шеф-повар работал стогом времени. Компания следовала довольно хорошей модели Devops, где все были на борту, и разработчики работали вместе с OPS, но я думаю, что их будущее не '

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

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

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

Если вам не важно быть настоящим практиком DevOps, вы можете называть это как хотите.