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

32

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

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

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

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

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

Aurora0001
источник
Вы должны делать все, что наиболее эффективно для вашего бизнеса, команды и проекта. Вы должны экспериментировать, чтобы выяснить, что является наиболее эффективным. Ловкость - это изменение, соответствующее вашей конкретной ситуации. Как сказал Кент Бек, «любой достойный ответ на интересный вопрос начинается,« это зависит ... »»
Адриан

Ответы:

24

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.
Иржи Клауда
источник
11
Я с трудом связываю ваш телефон с остальным ответом, где вы даете повод для найма ...
Тенсибай
Остальные ответы объясняют, как ни одна из ролей, связанных с DevOps, не способствует созданию команды из этих людей. Не нанимайте новую команду, встраивайте людей в определенные места в вашей организации в зависимости от потребностей.
Иржи Клауда
5
@JiriKlouda отличный ответ, я почти на 100% согласен, если не считать термина «Системные операции (SRE)» - Системные операции! = Инженер по надежности сайта, последний является моделью Google для DevOps, которая до сих пор воплощает основные принципы DevOps, но сохраняет некоторые из Преимущества наличия команды специалистов операторов.
Ричард Слейтер
Я имел в виду операционную команду в любой форме, традиционной или SRE, или любую другую форму управления инфраструктурой или платформой. И поверьте мне, у вас могут быть команды Site Reliabikity без полного внедрения DevOps :)
Jiri Klouda
1
Честно говоря, там просто недостаточно. Инженер CI / CD должен знать достаточно для проектирования трубопроводов. Архитектор DevOps может выполнять работу на высоком уровне на организационном уровне. Я отделил эту роль от инженера DevOps, потому что у него разные характеристики. Это инструментальная работа, ориентированная на инструменты, и она может быть легко частью команды (команда инструментов / интеграции / внутренних приложений). Это то, за что люди в основном принимают инженеров DevOps. Это эволюция релиз-инженеров, но с автоматизацией. Вместо стробирования они теперь просто строят и контролируют автоматизацию.
Иржи Клауда
10

Я бы сказал, что 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, а также шаг в изменении, который принесет пользу и поможет добиться успеха.

Tensibai
источник
1
Как бы вы предложили провести различие между системным администратором, который умеет читать код для диагностики проблем, облачной инфраструктурой и автоматизацией, и традиционными системными администраторами, которые имеют большой опыт, но не обладают этими навыками?
avi
@avi по их резюме, мое для примера, с которым мне удобнее сравнивать, имеет те, которые еще называются Net / Sysadmin. У меня есть ссылки на организацию Devops для некоторых проектов, с которыми я работал. И я обычно не балуюсь за предложение с использованием devops в качестве модного слова из-за предостережений, о которых я упоминаю в этом ответе (один раз был
затронут
@Avi, если вы имеете в виду в предложении о работе, в деталях предложения требуемая квалификация значительно отличается от той, которая указана в вопросе и в ответе Джири, чтобы сохранить
должное звание должным образом
1
Я склонен сказать, что системный администратор, который не знаком с автоматизацией, - это просто неопытный системный администратор, а не другая должность. Смотрите также это эссе Джона Оллспоу .
Сюн Чямов
6

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

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

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

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

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

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

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

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

user2965205
источник
Очень полезно, спасибо. Интересно услышать, как вы по сути стали тем, что другие могут косвенно называть «инженером DevOps», и я думаю (из того, что сказали другие ответы), что ваш путь больше соответствует философии DevOps о том, что у вас нет абсолютно отдельных DevOps отдел. Похоже, это хорошо сработало для вас до сих пор!
Aurora0001
Так в принципе ты сам все делаешь? Что произойдет, если вы покинете компанию? Сможет ли бизнес выжить? Какова точка зрения вашего руководства на это?
030
Инфраструктура управляется сама собой. Он полностью задокументирован, и мы используем Terraform & Puppet для организации инфраструктуры и управления конфигурациями серверов. Таким образом, на самом деле любой инженер-марионеток и терраформ с опытом работы в AWS может подключиться. Я теперь являюсь акционером в этом бизнесе, и наша команда разработчиков значительно выросла. К счастью, теперь все знают, как протекает инфраструктура
user2965205
4

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

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

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

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

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

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

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

Джеймс Шивей
источник
Так что все эти должностные инструкции просто пух, чтобы увидеть, кто подает заявку? Кажется, они хотят всего на свете. Я смотрю на это и думаю, я знаю это, то, это, и не то, не то, не то ... Может быть, весь бизнес описывает мир и видит, что он получает.
Джонни
1
@johnny Я слышал истории о компаниях, которым требуется 7 лет опыта в технологиях, которые были созданы всего 5 лет назад ... да, это списки пожеланий. Не жесткие требования.
Джеймс Шивей
Спасибо. Список пожеланий - это фраза, которую я искал.
Джонни
3

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

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

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

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

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

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

Ян Маргеттс
источник
3

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

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

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

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

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

surrealchemist
источник
1

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

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

Эрик Фанкенбуш
источник
1
Пожалуйста, немного расширите свою позицию, этот ответ слишком короток для вопроса в этом вопросе.
Тенсибай
1
@ Тенсибай - Единственное, что я хочу сказать, это просто название. Называть кого-то инженером DevOps не имеет значения, если вы действительно не следуете принципам DevOps
Эрик