7 міфів про DevOps. Спростовує Head of Engineering Department компанії AMO

Що таке DevOps, та хто його створив, хто такий DevOps Engineer, якими навичками він має володіти. Якому бізнесу підходить цей метод та які інструменти краще обрати. А також чому DevOps певною мірою є в кожній компанії, але в чистому вигляді не імплементований майже в жодній. Олег Лавренко, Head of Engineering Department компанії AMO, розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери.

AMO — міжнародна IT-компанія, яка створює продукти й історії для мільйонів користувачів. Має три великі підрозділи: AMO Publishing, AMO Pictures та AMO Apps.

> Міф №1. DevOps — це людина або команда.

> Міф №2. DevOps Шредінгера.

> Міф №3. DevOps зʼявився 2009 року і вже втрачає актуальність.

> Міф №4. DevOps більше підходить стартапам.

> Міф №5. Щоб стати DevOps Engineer, треба опанувати чимало інструментів та технологій.

> Міф №6. DevOps починається з С-level.

> Міф №7. DevOps — змова тестувальників проти розробників.

Міф №1

DevOps — це людина або команда.

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

Міф №2

DevOps Шредінгера.

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

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

Тому ідея повної імплементації DevOps — дещо утопічна: цього усі прагнуть, але в чистому вигляді її ніхто ніколи не бачив.

Міф №3

DevOps зʼявився 2009 року і вже втрачає актуальність.

2009 року цей термін вперше пролунав на конференції розробників «DevOps Days» у Бельгії. Але не можна сказати, що цього методу раніше не існувало. Адже завжди була автоматизація, поняття життєвого циклу програмного забезпечення, яке полягало у тих самих етапах. У доповіді лише зібрали найкращі практики з різних компаній, знайшли у них спільні риси та назвали це DevOps (від англ. development & operations).

Насправді ж DevOps існував у певній формі ще задовго до компʼютерів — можна провести грубу аналогію зі створенням Генрі Фордом першого конвеєра у 1913. Адже DevOps — це своєрідний конвеєр в ІТ.

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

Міф №4

DevOps більше підходить стартапам.

В стартапах важливо швидко перевіряти гіпотези, динамічно змінюватися та шукати своє місце на ринку. Може статися таке явище, як півот, коли компанія кардинально змінює бізнес-модель. Наприклад, Slack, чиї творці задумали створити компʼютерну гру, але зрештою вийшов корпоративний месенджер. Стартапам не варто фокусуватися на процесах та автоматизації. Хаос — це одна з умов виживання стартапів. Коли бізнес вже стоятиме на ногах, почне уповільнювати розробку, зʼявиться потреба зробити її стабільною і рівною, компанії допоможе DevOps.

Як мінімум на примітивному рівні ця методологія може бути інтегрована у всіх ІТ-компаніях. У гігантських компаніях масштабу Oracle вже не настільки звертають увагу на швидкість розробки та delivery. Їхня ставка — на маркетинг та роботу з клієнтами, тому вони можуть рідше випускати фічі, але гарантують стабільність експлуатації. Однак практиками DevOps вони також користуються.

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

Міф №5

Щоб стати DevOps Engineer, треба опанувати чимало інструментів та технологій.

Обговорення DevOps серед спеціалістів часто зводиться до того, який інструмент обрати — Jenkins, Kubernetes, GitHub Actions тощо. Однак в книзі «Проєкт Фенікс», яку вважають біблією DevOps, немає жодного слова про технології, жодної згадки про інструменти та сервіси. Адже суть методу базується на комунікації та взаємодії між спеціалістами, а не на виборі інструментів.

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

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

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

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

В AMO є чітка стратегія, щодо технологій: тут будують cloud-native продукти, тому використовують багато інструментів, що входять до Landscape CNCF (Cloud-Native Computing Foundation). Сервіси, що пишуть в AMO, нативно інтегруються в екосистему Kubernetes, тому в команді кожен постійно вивчає щось нове.

Міф №6

DevOps починається з С-level.

Слова СЕО «давайте зробимо у нас DevOps» — це не те, з чого починається імплементація цього методу в компанії. Все інакше. Наймаючи людину, якій можна довірити технічну частину продукту, CEO доносить, в якому напрямі розвивається компанія, а під нього вже налаштовується процес розробки.

Більш того, рано чи пізно DevOps сам проявиться в тій чи іншій формі навіть без відповідних рішень та найму окремих спеціалістів. Адже досвідченому розробнику точно захочеться як мінімум автоматизувати процес тестування, а потім зʼявиться потреба частіше «деплоїти» нові фічі, щоб перевіряти продуктові гіпотези, далі прийде CI\CD.

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

Міф №7

DevOps — змова тестувальників проти розробників.

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