Топ-10 міфів про DevOps

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

Коротше кажучи, існує безліч хибних уявлень, деякі з них тривіальні, а деякі глибоко вкорінені у свідомості професіоналів.

Міф №1: DevOps може бути виконаний відділом DevOps або інженером

Щоб досягти належного рівня DevOps, ми наймаємо DevOps-інженерів або створюємо DevOps-відділ, і вуаля! У нас в компанії повноцінний DevOps!

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

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

Насправді, в завдання СЕО не входить заглиблюватися у все це. Наприклад, вони з'ясували, як збільшити дохід, покращити потоки value streams, і зрозуміли, що це корелює з цими модними словами.

Тоді команда починає мозковий штурм. Вони прочитали про DevOps у Вікіпедії: "Методологія, яка об'єднує розробників, операції та тестування для безперервної delivery програмного забезпечення".

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

Зрештою, або відділ QA перейменовують на DevOps, або на операційний відділ — залежно від досвіду людей, які в ньому працюють. Але що робити з цим відділом, якщо в ньому працюють інженери з якості/вирішення проблем? Їх теж потрібно перейменувати на DevOps-інженерів?

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

Немає суворої стандартизації чи типізації: від людей, які налаштовують пайплайни на Jenkins, до тестувальників, які пишуть скрипти для автоматизації; від спеціалістів з розгортання на AWS до тих, хто налаштовує моніторинг, розгортає програмне забезпечення тощо. Всі можливі ІТ-професії позначаються як DevOps-інженери.

Виняток становлять невеликі компанії, які справді виробляють цифрові продукти з реальним безперервним постачанням програмного забезпечення. Вони шукають людей, які можуть робити все це, тому що важко визначити конкретну кваліфікацію. Тому вони просто дають оголошення про вакансію DevOps інженера, перераховуючи все — Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus.

DevOps має охоплювати все — від аналітики до реальних операцій. Це не окрема професія і не окрема роль; це лише концепція, яка сприяє швидкому створенню цифрових продуктів.

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

DevOps — це вирішення проблеми виробництва цифрових продуктів. Це методологія. Називати цим терміном окрему людину некоректно.

Якщо ви шукаєте DevOps-інженера, подумайте, навіщо він вам потрібен. Краще вказати конкретний набір навичок і шукати його на ринку, ніж наймати невизначеного фахівця.

Для фінансово ощадливих: зазвичай системний адміністратор зі знанням Docker відрізняється від DevOps-інженера зі знанням Docker не навичками, а ціною.

Міф №2: DevOps — це найм спеціалістів на всі руки

Дозвольте мені поділитися своєю інтерпретацією того, звідки береться ця проблема. Коли вся сага про DevOps тільки починалася, дійсно, вся робота виконувалася фахівцями на всі руки. Наприклад, одна людина будувала конвеєр доставки, налаштовувала моніторинг і так далі. Я починав з того ж самого і робив усе сам, бо не знав, кому делегувати завдання: Мені потрібно було дослідити тут, підправити там, реалізувати ще щось. В результаті я став майстром на всі руки, який налаштовував Linux, писав скрипти Chef, інтегрувався з Zabbix API тощо. Мені доводилося робити все це.

Але в реальності це не працює.

Продуктивність:

• 18 майстрів на всі руки, кожен з яких здатен зробити одну шпильку, виробляють 360 шпильок на день.
• 18 майстрів, розділених на 18 спеціалізацій, виробляють 48 000 шпильок.

Це відомий приклад збільшення виробництва на фабриці шпильок з книги Адама Сміта. Насправді, історія про ці шпильки не була вигадана ним, а запозичена з британської енциклопедії.

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

У книзі "Проєкт “Фенікс”. Роман про те, як DevOps змінює бізнес на краще" є історія про Брендона, який робить все в компанії, а навколо нього — вузькі місця. Це якраз історія талановитого майстра на всі руки.

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

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

DevOps, інші ролі:

Розробник з розумінням архітектури та роботи виробничого програмного забезпечення (пише тести та інфраструктурний код)

Що відрізняє такого розробника від звичайного випускника університету? Розробник зі звичайного університету вміє писати алгоритми — і це все. DevOps-розробник не тільки вміє писати описи, але й знає, як ці описи втілюються в життя.

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

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

Інженер інфраструктури (пише прив'язки для інфраструктури, надає платформу для розробників)

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

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

Розробник інфраструктурних сервісів (DBaS, Monitoring as a Service, Logging as a Service)

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

Реліз-менеджер (керує процесом і залежностями)

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

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

Міф №3: Ми займаємося DevOps з 1995 року

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

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

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

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

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

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

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

Практики DevOps для TTM (Time-to-Market)

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

Стратегії релізу (синьо-зелене розгортання, канаркові релізи, A/B тестування)

Звучить гарно і досить просто — давайте випустимо реліз для 0,1% користувачів. Але для цього потрібні колосальні зусилля, такі як перехід від монолітної архітектури до архітектури мікросервісів.

Безперервний моніторинг

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

Коли ви розгортаєте 0,1%, ви можете зрозуміти, чи працює програмне забезпечення так, як передбачалося, чи щось не так. Немає сенсу розгортати 0.1%, якщо ви не знаєте, що відбувається з програмним забезпеченням.

Наскрізне логування

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

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

Автоматизовані тести (як форма домовленості між командами)

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

Всі описані компоненти практики DevOps для TTM вимагають багато часу і зусиль, якщо ви починаєте не з нуля, а, наприклад, переписуєте моноліт.  

Міф №4: DevOps — це все про "правильні" інструменти

Існує поширена думка, що DevOps можна досягти, просто взявши на озброєння "правильні" інструменти. Це як зібрати набір інструментів з Kubernetes, Ansible, Prometheus, Mesosphere та Docker і очікувати миттєвого успіху DevOps.

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

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

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

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

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

Міф №5: DevOps тільки для великих організацій

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

Міф №6: DevOps підходить лише для стартапів або технологічних компаній

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

Міф №7: DevOps вимагає повної перебудови робочого процесу

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

Міф №8: DevOps замінює традиційні ІТ-ролі

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

Міф №9: DevOps — це одноразове впровадження

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

Міф №10: DevOps підходить лише для хмарних або мікросервісних архітектур

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