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

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

Похоже, это относится ко многим профессионалам DevOps, с которыми я общаюсь. Что можно сделать, чтобы инженеры DevOps чувствовали себя менее одинокими волками?

Моя первая мысль: «Почему он единственный, кто занимается операциями в команде разработчиков, особенно когда ему приходится работать с большим количеством средств автоматизации?». Я думаю, что есть возможность решить проблему синдрома одинокого волка; В частности, в среде разработчиков инфраструктура как код обеспечивает отличную основу для распределения нагрузки. Специалисты должны быть экспертами в определении и определении потребностей инфраструктуры для приложений, но они также должны быть в состоянии построить платформу, позволяющую разработчикам делать столько, сколько они могут независимо.

Это звучит как бункер в команде; Старые привычки умирают с трудом. Программист может не чувствовать себя комфортно, раскручивая и укрепляя сервер, но в чистой модели devops они должны иметь инструменты для этого. Сотрудник команды разработчиков не должен нести ответственность за предоставление инфраструктуры для самого приложения, но он должен дать некоторое представление о том, что необходимо, и некоторые рекомендации о том, как разработчики приложения могут сделать это самостоятельно. Это почти модель мета-инфраструктуры; Инженеры ops создают инфраструктуру, которая может создавать инфраструктуру по требованию по запросу команды разработчиков.

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

Я думаю, что первый недостаток в этом предложении:

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

DevOps - это культурный сдвиг, направленный на удаление силосов. Если бункеры останутся, то этот инженер, как вы хотите назвать, называет его; инженер, занимающийся эксплуатационными разработками, эксперт по автоматизации, разработчик инфраструктуры автоматизации - но этот инженер не инженер DevOps.
На самом деле, «DevOps Engineer» - это не настоящая роль , это скорее «вводная часть», поскольку она может охватывать разработчиков, системных администраторов, тестировщиков QA и архитекторов, работающих в общей команде.

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

Как вы описываете, этот инженер - единственный, кто выполняет Ops в команде разработчиков. Это не делает его «инженером DevOps». (Что бы это ни значило в его организации). Он работает изолированно, потому что работа представлена ​​как «Инженер DevOps», но, похоже, другие люди в его команде не хотят работать над операциями.

Давайте будем честными, всегда будут ops и dev, основная идея devops заключается в том, чтобы разделить обязанности таким образом, чтобы не было никакой передачи продукта от dev к ops или просто предоставления платформ ops для dev. Основная цель - привнести больше сотрудничества в команду. Называя эту роль «DevOps Engineer», она ломает эту идею, предлагая от имени, что вы можете делать оба на одном уровне опыта - что редко бывает правдой.

По моему мнению, первое, что нужно сделать, - это представить операционные инструменты команде и дать всем базовые знания об инструментах, а затем передать ответственность за настройку / кодирование операционных инструментов всей команде. Основная идея заключается в том, чтобы перейти от «тот, кто делает все операции» к «тот, который поддерживает и дает ссылки реализации для команды».

Это дополняет другие ответы, предлагая что-то более простое в качестве первого шага, чем реорганизация управления.

Самым важным для инженеров DevOps в подобных ситуациях является получение (а) обязательств по управлению и (б) необходимых бюджетов . Читайте дальше, чтобы узнать больше об обоих ...

Получить обязательство по управлению

Как только это будет сделано, для таких разработчиков DevOps все станет проще. Особенно, когда в игру вступает сопротивление (со всех сторон). Поверьте мне, будет такое сопротивление, которое бросает вызов таким как:

• Почему мы должны измениться? Я хочу продолжать делать то, что делал уже Х лет!
• Я не хочу терять (техническую) силу, которой я обладаю, и выполнять все виды процедур рабочего процесса, чтобы получить глупое исправление в производстве, которое должно занять у меня 5 минут вместо 5 часов (или дней ...).
• ... (Я мог бы добавить еще дюжину пуль здесь ...).

Когда бы ни возникали эти проблемы, все, что должен сказать инженер DevOps:

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

Получить необходимые бюджеты

Эффективный способ получить Обязательные бюджеты - это создать / представить соответствующее экономическое обоснование, которое объясняет материальные и нематериальные преимущества различных практик DevOps, применяя их к некоторым реальным случаям, которые относятся к самой компании.

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

1. Преимущества автоматизации

Из-за некоторого удара только от 2 (!!!) компьютерных операторов (которые больше не набирали консольные команды, которые они ожидали набрать), поезда пришлось остановить где-то на полпути между двумя фабриками (так как система на заводе Куда направлялся поезд, был остановлен, важные данные об обработке поезда отсутствовали).

Благодаря внедрению системы SCM многие команды оператора были автоматизированы.

2. Сократить стоимость лицензий на программное обеспечение

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

Бюджет проекта был равен ежегодной плате, которую они не хотели продолжать платить. Это включало полеты инженеров с других континентов (таких как я), чтобы проект был успешным.

3. Сократить эксплуатационные расходы

Некоторая крупная страховая компания использовала программное обеспечение FTP для передачи исправлений программного обеспечения примерно на 13 000 компьютеров среднего уровня (AS / 400) по всей стране, и это всякий раз, когда исправление «а» стало доступным. Стоимость одного такого перевода составила около 4 долларов США (13 000 x 4 = 52 000 долларов США за один перевод ...). Программное обеспечение состояло из 120 000 компонентов, разработанных / поддерживаемых около 150 разработчиками. Посчитайте вероятность того, что 1 разработчик допустил 1 (крошечную) ошибку в любом из этих 120 000 компонентов, что привело к производству и потребовало срочного исправления, что обошлось бы еще в 52 000 долларов США (только для переноса!).

Благодаря внедрению адекватной системы SCM (с управляемыми средами тестирования, одобрениями и т. Д.) Эта компания добилась значительного сокращения затрат. Подумайте об этом: если система SCM может предотвратить необходимость только 20 передач срочных исправлений, это приведет к снижению затрат на 52 000 x 20 = 1 040 000 долларов США (достаточно бюджета для внедрения системы SCM, им нужна только доля из этой суммы, чтобы сделать работу).

4. Сократить затраты на недоступность

Если приведенные выше случаи недостаточно убедительны, подумайте о том, что система (и) крупной компании, выпускающей кредитные карты, недоступна во всем мире. Мне сказали, что 1 секунда недоступности стоит им 1.000.000 долларов США.

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

TL; DR: Поскольку высшее руководство обычно непостоянно и склонно к гневу, я бы посоветовал попытаться немного склонить свой разум, чтобы получить другую точку зрения, постепенно меняя положение вещей к лучшему.

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

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

Единственное, чего не должно происходить, это то, что парень из DevOps делает свою автоматизацию, а все остальные стараются изо всех сил избегать упомянутой автоматизации (то есть обходят конвейер CI / CD и делают вещи вручную в одной из сред). Это ИМО - это главное, что нужно остановить. Одним из решений этой проблемы было бы очень настойчиво продвигаться к подходу «крупный рогатый скот, а не к домашним животным», то есть неуклонно разрушать виртуальные машины или контейнеры влево и вправо как можно быстрее и непрерывно раскручивать новые.

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

В-третьих, «один парень», конечно, должен следить за тем, чтобы он не выполнял черных повседневных задач для своих коллег (например, создавая Dockerfile после Dockerfile для их артефактов ...).

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

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

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

Здесь я вижу много хороших ответов, рассказывающих о DevOps как о культуре, предложениях о том, как работать с руководством, и о том, как определить, что нужно делать, а что нет, команде DevOps или инженеру. Я думаю, что каждый из них великолепен, и действительно показательный ответ на многие вопросы может быть на 100% правильным, и все же быть очень отличным или даже совершенно неоднозначным, друг от друга ... Это DevOps!

Этот ответ - только моя уникальная точка зрения из опыта, и может не указывать на нормы или лучшие практики ...

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

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

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

Возможно, ваш коллега осознает или еще не осознал, что ему или ей не нравится быть инженером DevOps .

Условно говоря, концепция Devops является новой и все еще определяет себя, на мой взгляд. В настоящее время я выполняю роль инженера Devops. Для меня это означает, что я облегчаю и разрабатываю инструменты и процессы, используемые нашими командами разработчиков и разработчиков, освобождая их для того, чтобы сосредоточиться на продукте, который приносит доход компании. Команды ops и dev раскручивают свои собственные серверы и тому подобное по мере необходимости. Я просто подключаю КИ к нашим продуктам, проверяю, что наши процессы имеют смысл, и выясняю, какие процессы можно улучшить / автоматизировать. Я встречаюсь со всеми нашими отделами, от продаж до склада, с разработчиками и операциями (QA и менеджеры по выпуску), чтобы увидеть, что они делают и как я могу улучшить их процесс.

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

• Ожидается, что члены команды с опытом работы с Ops будут делать то, что у них получается лучше всего (например, Ops), обучать других основам того, что они делают лучше всего (например, Ops), а также обучаться и выполнять задания в смежных областях (например, задачи Dev).
• Ожидается, что члены команды с опытом разработки Dev будут делать то, что у них получается лучше всего (например, Dev), обучать других основам того, что они делают лучше всего (например, Dev), а также обучаться и выполнять задания в смежных областях (например, задачи Ops).

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

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

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

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

Что можно сделать, чтобы инженеры DevOps чувствовали себя менее одинокими волками?

Перефразируя - что может инженер DevOps сделать сам / сама , чтобы чувствовать себя менее , как одинокий волк?

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

Поэтому - не чувствуй себя одиноким волком; участвуйте в сообществах DevOps, таких как это здесь, или в группах, посвященных инструментам, и GitHub - по крайней мере, вы чувствуете, что вы не единственный волк-одиночка ;-)