Що таке DevOps, та хто його створив, хто такий DevOps Engineer, якими навичками він має володіти. Якому бізнесу підходить цей метод та які інструменти краще обрати. А також чому DevOps певною мірою є в кожній компанії, але в чистому вигляді не імплементований майже в жодній. Олег Лавренко, Head of Engineering Department компанії AMO, розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери.
AMO — міжнародна IT-компанія, яка створює продукти й історії для мільйонів користувачів. Має три великі підрозділи: AMO Publishing, AMO Pictures та AMO Apps.
Міф №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 — змова тестувальників проти розробників.
Скоріше це змова всіх інженерів, яким стало нудно і захотілося зменшити рутину. Тих, для кого діє правило: якщо ти двічі зробив одну й ту саму дію та отримав однаковий результат, маєш це автоматизувати, щоб не витрачати час на монотонну рутину, а концентруватися на цікавіших завданнях.