Чому я не хочу спробувати найняти "Інженера DevOps"?

Ідея створення інженера DevOps стала досить популярною останнім часом , і, здається, привабливою є просто людина, яка може взяти участь у грі і надати багато переваг DevOps, як описано в блозі Puppet :

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

Однак я помітив чимало голосових протилежностей ідеї інженера DevOps, щоб спробувати зробити ці вдосконалення:

Навіть за широкої згоди щодо основних атрибутів DevOps суперечки оточують термін "інженер DevOps". Деякі кажуть, що сам термін суперечить значенням DevOps. Джез Хумбл, співавтор компанії "Постійні доставки", зазначає, що лише зателефонувавши комусь інженеру DevOps, можна створити третій силос на додаток до розробників та операторів - "... явно поганий (і іронічний) спосіб спробувати вирішити ці проблеми. . "

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

TL; DR : Ніколи не слід намагатися найняти команду DevOps

По суті є три найпоширеніших ролі, які потрібно найняти для:

1. DevOps архітектор / євангеліст
2. Інженер DevOps
3. CI / CD інженер

Ці ролі відрізняються від 6 основних ролей розробки програмного забезпечення, які традиційно складають організацію інженерії програмного забезпечення:

1. Менеджмент продукту
2. Розробка програмного забезпечення
3. Розробка інструментів
4. Безпека та відповідність
5. Якість та тестування
6. Операції в системі (SRE)

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

DevOps архітектор або євангеліст

• Чому : Якщо ви загубилися, повільно, розбиті і не знаєте, що робити.
• Коли : на початку процесу на етапах стругання.
• Що : Роль рівня управління для керівництва всіма менеджерами та потенційними клієнтами у всьому органі. Ця людина планує всю трансформацію вашої інженерної організації у високо функціонуючий стан.
• Хто : Консалтинговий член, добре розбирається в теорії, управлінській практиці, культурологічних темах та операціях, який безпосередньо звітує перед ВП з ​​програмного забезпечення.

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

Інженер DevOps

• Чому :
  1. Щоб подолати прогалини між командами, якщо вони організовані за функціональними ролями, згаданими вище, для забезпечення взаємодії на функціональному рівні.
  2. Створити команду, орієнтовану на виріб, яка має в команді кожну з 6 традиційних ролей, щоб допомогти усунути прогалини в знаннях та допомогти у впровадженні та прийнятті нових практик та інструментів.
• Коли : Після того, як ви склали свої плани, розпочнеться організаційна трансформація, і вся управлінська команда працює.
• Що : Увімкніть міжфункціональну співпрацю, переконайтеся, що межі команди розбиті, що локальні оптимізації в командах не створюють перешкод для високої пропускної здатності роботи в ланцюжках цінності, аж до побажань замовника до поставок клієнтів.
• Хто : досвідчений інженер, який має навички як в розробці програмного забезпечення, так і в системних операціях. Він повинен бути досвідченим в кращих практиках, змінах процесів і культури, пов'язаних з трансформацією DevOps.

CI / CD інженер

• Чому : Щоб допомогти реалізувати трубопроводи CI / CD, інтегруйте свою ланцюжок інструментів, введіть інструменти, які дозволять краще працювати в компанії.
• Коли : Під час переходу до більшої організації, тоді як вищезазначені ролі вже були заповнені.
• Що : Інженер, який по суті є частиною команди інструментів, яка зможе налаштувати CI / CD трубопроводи та почати інтегрувати внутрішні системи таким чином, щоб усунути тертя від пропускної здатності роботи.
• Хто : інженер з досвідом роботи з інструментами, інтеграційним процесом, управлінням випусками та практикою DevOps. Хтось, хто розуміє, замінює людські ґрати в процесі випуску автоматизацією.

Я заперечую, що інженер Devops, як описано у вашому посиланні на запитання , головним чином виконує роль sysadmin. Цитуючи тут навички для перегляду цієї відповіді:

Ваша альпіністка.

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

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

Це слабко пов’язано з практикою DevOps та культурою розриву силосу між розробниками та операційними системами, як це видно в цьому питанні. У чому різниця між Sysadmin та DevOps Engineer?

Це не буде хорошою ідеєю, оскільки системний адміністратор, наскільки він комфортний, може бути присвячений практиці та культурі, не є правильною людиною, яка веде трансформацію компанії. Ви не будете наймати цю людину з урахуванням зміни культури, але з переглядом конфігурації інструменту, який не допоможе зламати процеси. Це також може бути погано сприйняте його колегами, і ви просто чините опір змінам, якщо заздалегідь не планується зміна культури.

За успішною схемою на шляху здобуття девп, відповідь @ Jiri Klouda дає чудовий огляд прийнятної ролі інженера DevOps разом із кроком у зміні, який би приніс цінність та допоможе досягти успіху.

Я усвідомлюю, що ця відповідь може не бути ідеальною для вас, але ось що я зробив

Я був першим розробником, який працював у запуску електронної комерції із надзвичайно високим трафіком. Я усвідомлюю, що компанія була ще молодою, і я певний час був єдиним технічним ресурсом.

Знаючи це, я вирішив структурувати свою інфраструктуру таким чином, що мені доведеться займатися адміністрацією систем ZERO.

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

Це дозволило мені, як розробнику, взяти на себе цю роль. Я створив засоби звільнення коду з python, тканини. Я використовував той самий сценарій, щоб завантажувати свою програму на нові сервери, які розміщені автоматично.

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

Якщо система має знижену продуктивність, я просто припиняю її, а на її місці вивертається інша.

Сподіваюся, ця відповідь могла б вам якось принести користь

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

DevOps - це обов'язково команда, що базується на команді, і ви, можливо, не можете сподіватися, що одна людина підтримає очікування всієї команди. Розглянемо сферу використання DevOps. Одна людина не може:

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

Деякі із зазначених вище навіть суб дисципліни, такі як Windows систем Адміністратор vs. Linux / Unix системного адміністратора або , може бути , ви використовуєте більш однієї мови кодування в вашому.

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

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

Це означає, що кожен, хто скаже вам, що знає всі аспекти DevOps, напевно, бреше вас. Найміть фахівця в тій галузі, в якій ви найслабші, і яка працювала в команді DevOps, а не в інженері DevOps.

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

Що ми зробили:

• втрачаємо термін інженерів DevOps, DevOps - це те, що ми повинні всі робити, а не наша посадова робота, тому ми називали їх чимось іншим.

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

• зберігав центральну функцію, а також виступав центром компетентності та вирішував питання підприємства, що стосується всіх команд

У міру розвитку ми переглядаємо цю модель, але для нас вона працює ефективно

Я не думаю, що ви не зможете отримати остаточну відповідь на це, тому що, здається, є багато чинників.

• Як на борту компанії працює практика DevOps
• Яку програму чи послугу надає компанія
• Структура вашої компанії

Я щойно провів співбесіду на посади і закінчив титул інженера DevOps, але дещо з того, що я роблю, - це робота Sys Admin. Це просто неможливо через розмір компанії та характер керованої програми. Деякі посади, з якими я брав інтерв'ю, мали аналогічну назву, і вони шукали більше когось із сторони розвитку речей, які вважаються мудрими. Вони очікували більше написання коду, а не системного адміністратора, який робить автоматизацію. SRE, схоже, заголовок набирає популярність, так що це може бути шлях. Я був своїм системним адміністратором та інженером автоматизації як останньою своєю роботою, бо частину часу я писав на відповідальні та шеф-кухарі. Компанія слідкувала за досить хорошою моделлю девес, де всі були на борту, а розробники працювали поряд з операційними системами, але я думаю, що їх майбутнє не стало

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

Тому я думаю, що вам слід розібратися в описі вакансії і не так сильно переживати за назву, якщо тільки вона не буде якось платити, або ви думаєте, що те чи інше приверне потрібних людей.

Якщо ви переймаєтесь значенням DevOps та дотримуєтесь "одного справжнього шляху". Ви не повинні наймати інженера DevOps. Вам слід найняти інженера автоматизації, або інженера з розгортання, або архітектора платформи, або ряд інших ролей, які виконують те, що вам потрібно.

Якщо справжній практик DevOps для вас не важливий, тоді ви можете називати його все, що завгодно.