Що не так з назвою DevOps для посади?
Натрапили на цікавий матеріал, де автор розмірковує про назву DevOps як посаду. Публікуємо переклад, щоб задати вектор дискусії, з радістю почитаємо ваші коментарі.
Не треба думати про титули, натомість слід дбати про вміння.
Ми всі можемо погодитися, що в індустрії програмного забезпечення назви посад дуже довільні. Я можу назвати себе розробником програмного забезпечення, інженером програмного забезпечення, архітектором, консультантом, веб-розробником, мобільним розробником, скрам-майстром... це не має значення. У мене є навички, які варіюються від створення базових веб-сайтів до створення та проєктування повномасштабних систем, мобільних додатків, до навчання людей гнучкості, роботи технічним керівником чи скрам-майстром... і я можу навчитися більшому.
Більшість із нас володіє величезним розмаїттям навичок і знань, які неможливо позначити однією назвою.
Мені не дуже подобається використовувати термін «DevOps» у назві посади. Для мене це знову ж таки Agile™, який використовується компаніями для просування свого бренду за допомогою найновіших модних слів, хоча ніхто з присутніх може не мати поняття, що це слово насправді означає.
Що таке DevOps
Давайте почнемо з визначення того, що насправді таке DevOps у дуже широкому масштабі. Я базую свої знання про це на кількох книгах (наведених нижче), які я прочитав на цю тему, звітах про стан DevOps і багатьох надійних джерелах в Інтернеті. Не кажучи вже про фактичну практику.
- The DevOps Handbook
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
- The Phoenix Project
Вікіпедія посилається на кілька джерел і стверджує, що DevOps не має «підтвердженого» визначення, однак містить таке визначення:
DevOps є поєднанням конкретних практик, зміни культури та інструментів.
DevOps — це поєднання культурних філософій, практик та інструментів, які збільшують здатність організації надавати додатки та послуги з високою швидкістю: розвиток і вдосконалення продуктів швидшими темпами, ніж організації, які використовують традиційні процеси розробки програмного забезпечення та управління інфраструктурою.Згідно з моделлю DevOps, команди розробки та операцій більше не є «відокремленими». Іноді ці дві команди об’єднуються в одну команду, де інженери працюють протягом усього життєвого циклу програми, від розробки та тестування до розгортання та операцій, і розвивають низку навичок, не обмежуючись однією функцією.
DevOps — це набір практик, інструментів і культурної філософії, які автоматизують та інтегрують процеси між розробником програмного забезпечення та ІТ-командами. Це збільшує можливості команди, комунікації та співпрацю між командами та автоматизацію технологій.
Отже, у нас є три пункти, які повторюються, що таке DevOps (узагальнено):
- Культура
- Практики
- Інструменти
І в жодному разі не обмежується лише цими трьома пунктами.
Тепер для всіх, хто має звання «DevOps» у своїй посаді — чи справді ваша компанія приймає цю культуру щодня? Це ваша робота — забезпечити її виконання? Слідувати практикам, встановленим DevOps? Культура та практика автоматизації, тісна співпраця між розробкою та операційною системою, інновації та експериментування, створення безпечного місця для навчання на власних помилках, а не звинувачення, впровадження безпеки та тестування на ранніх етапах циклу розробки та швидкий зворотний зв’язок?
DevOps як посада стала синонімом просто роботи Ops
Здається, DevOps став синонімом людей, які працюють у сфері операцій. Це стало роллю з вимогою знати, як керувати інфраструктурою як кодом і автоматизувати щось чи використовувати певний інструмент.
Це не DevOps. Це просто операційна робота, яка пройшла природну еволюцію через навколишнє середовище. Хмара.
Я сам, як розробник, все більше і більше занурювався в те, що я б назвав «операційною роботою». Я можу легко писати шаблони CloudFormation або Bicep для своїх проєктів і налаштовувати конвеєри для розгортання свого коду на проді і т. д. Я вважаю це нормальною еволюцією моєї роботи, спричиненою хмарою.
Але я погано розбираюся в мережах або в налаштуванні автоматичного масштабування, балансувальників навантаження тощо. І я розумію, що мені бракує знань в цих сферах, тому я звертаюся за допомогою до спеціалістів. Я співпрацюю зі своїми колегами з операційної системи, які мають набагато більше знань у цих сферах, щоб переконатися, що все працюватиме так, як очікувалося.
Не дозволяйте складності відволікати вас
Чи стала наша робота (як у розробників, так і в ops-спеціалістів) складнішою? Однозначно так. Чи я чи хтось інший має право на те, щоб назвати культуру праці — посадою? Ні, я так не думаю.
Я можу прийняти практику DevOps. Я можу навчити цьому інших людей. Ми всі можемо співпрацювати, щоб автоматизувати роботу, перенести безпеку та тестування на ранні етапи процесу розробки та спростити наше життя. Маленькими кроками ми можемо побудувати культуру DevOps у нашій компанії.
Але у нас все ще є розробники та «ops» зі своїми обов’язками. Вони просто більше співпрацюють.
Тому, будь ласка, перестаньте вестись на цю назву «інженер DevOps», яку продають компанії. Під час співбесіди на таку посаду обов’язково запитайте людей, які беруть у вас співбесіду, чи знають вони, що насправді таке DevOps.
Натомість чому б не назвати себе хмарними інженерами? Інженерами платформи? Інженерами інфраструктури? Або просто використовувати старі добрі «Operations» в назві вашої посади.

2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів