Проблеми DevOps: чи все добре з методологією?

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

Але було це в сиву давнину. Коли з кожного приймача нестримно кричала пісня «Poker Face» Леді Гаги, а Intel анонсувала лінійку процесорів Core i5. Коли Windows на повну розповсюджувала свою «сімку», а Майкл Джексон спочив з миром. 

Зараз далеко не 2009 рік. І за 13 років багато сфер нашого життя зазнали змін. Тому, DevOps вже не той. А от що із цим робити — дізнаєтеся далі. 

То в чому проблема? 

Ну, по-перше, розробники скаржаться, що не хочуть займатися адмініструванням (цілком розумно, оскільки це не їхня основна експертиза, вони тут Dev, а не Ops). А тим часом команди Ops скаржаться, що вони перевантажені щоденними дрібними вимогами від розробників. 

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

Але це лише вершина айсберга, нумо копати глибше 👇

Постановка проблеми

Ми стали свідками того, як DevOps божився привнести ковток свіжого повітря у (тісну кімнату без вікон) розробку ПЗ. Але це було давно. Зараз, все пішло не так, як ми сподівалися. Здебільшого це пов’язано з новими та непередбаченими викликами, які виникли як у розробці, так і в експлуатації.

Виклики для команд Dev:

• Швидша інтеграція та цикли доставляння
• Втрата ретельного тестування випусків (його принесли в жертву швидкості)
• Набір технологій виріс
• Розподілені програми зі складною архітектурою мікросервісів
• Проблеми з безпекою та вразливості ланцюжка постачання ПЗ
• Брак часу/стимулів дізнатися більше про операційну сторону справи 

Виклики для груп Ops:

• Відсутність чіткої відповідальності за SDLC
• Безперервний моніторинг та спостереження, безпека та дотримання нормативних вимог
• Адаптація робочих процесів для інтеграції рішень IAC з урахуванням безпеки та узгодженості
• Усунення несправностей абстрактних систем (наприклад, Kubernetes) 
• Треба розумітися на аспектах стека розробників та в інструментах для розв’язання проблем

Спільні проблеми для обох команд:

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

Нарешті, проблема, з якою бореться вся спільнота, це «податок на інструменти». Також відомий як «розповсюдження інструментів». Як пише Шерон Годен з GitLab: 

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

Існує багато чудових інструментів DevOps. Але коли їх занадто багато, все виходить з-під контролю. Уявіть, команди використовують у середньому від 20 до 50 різних інструментів DevOps 🤯

Що будемо робити?

Self-serve DevOps — не рішення?

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

Деякі компанії прийшли до підходу «самообслуговування DevOps». І в теорії це звучить як мрія. Self-serve DevOps обіцяє зняти рутинні вимоги з плечей операційних команд. Як? Розробникам просто надаватимуть усі необхідні інструменти, інфраструктуру та послуги за допомогою простих ефективних запитів.

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

1. Внутрішня платформа розробника
2. Засоби автоматизації робочого процесу
3. Сервісні каталоги
4. Торгові майданчики API

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

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

А модель headless — рішення?

Забудьмо про правила перекладу і назвемо цю модель «безголовою». І ось вона, на відміну від self-serve, пропонує щось справді цікаве.

Термін «headless» з’явився у світі вебсайтів (CMS) та електронної комерції. Він означає, що інформація (контент, записи в каталозі, ціни тощо) незалежні від презентації. 

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

Для вебсайтів і додатків відсутня інформація може спростити розробку або тестування:

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

Безголовий підхід також може допомогти під іншим кутом подивитися на DevOps. І розробка, і операції сьогодні переповнені інструментами. Але що, якби обидві команди могли виконувати свою роботу інтуїтивно зрозуміло? І без цілого списку інструментів й інтерфейсів користувача? Утопія 🤔

То може відокремити робочі процеси й конвеєри DevOps?

Має бути єдиний і оптимізований спосіб доступу до всього робочого процесу DevOps. навіщо? Щоб розробникам та DevOps-інженерам не треба було освоювати нові інструменти та постійно отримувати доступи. Типу хмарна інфраструктура, CI/CD та постачальники ідентифікаційних даних. Немає нових систем для вивчення — немає перемикання контексту.

Лише один простий інтерфейс, щоб керувати усім.

Якщо ви думаєте, що ми збираємося запропонувати додати ще один інструмент, щоб полегшити життя DevOps, то ні. Насправді ми пропонуємо протилежний підхід, а саме «роз’єднання» DevOps:

1. Від’єднайте критично важливі функції від усіх систем та інтерфейсів користувача, які зараз використовують ваші розробники та DevOps-інженери
2. Дайте їм можливість робити все в одному місці

Де? Десь розробники та DevOps-інженери вже працюють, інформація — 100%. Це може бути Slack, який використовують 40% компаній зі списку Fortune 100. Може бути MS Teams, яка має 270 мільйонів користувачів на момент написання цього тексту.  

Headless DevOps відбувається скрізь, де ваші команди спілкуються щодня. Тому що лише тоді вони зможуть реалізувати реальну перспективу self-serve з легким і безпечним доступом до хмарної інфраструктури, конвеєрів CI/CD, інформації тощо.

Замість висновку — нова «безголова» реальність

І ми знову про модель headles, а не про реалії життя у рф. 

Ви прагнете зробити свої команди DevOps більш продуктивними? Яку б систему вони не обирали, будь то Slack або Teams (або навіть CLI), вам потрібно перетворити її на універсальний інтерфейс користувача DevOps.

Навіщо? Бо це безпрограшний варіант:

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

Використовуючи діалоговий штучний інтелект, вбудований у Slack, MS Teams або CLI, ви можете забезпечити детальний контроль доступу. Бо тут усе можна автоматизувати.

Переваг безліч, ось лише частина:

1. Ви усунете перемикання контексту та повторювання завдань. Більше не потрібно жонглювати запитами в Slack, тікетами в Jira тощо.
2. Зробите автоматизацію високодоступною. В розробці не потрібно буде покладатися на команди Ops для пошуку та запуску відповідних робочих процесів. Буде менше людського втручання та затримки.
3. Забезпечите підзвітність. Кожна функція DevOps буде в межах однієї системи.
4. Покращите безпеку. Розробникам будуть надавати своєчасний та надійний доступ.
5. Припините конфлікти. Напруги між відділами не буде, якщо ви дасте розробникам те, що вони хочуть, коли вони цього хочуть.

Словом, ваші команди будуть працювати ефективно, як ніколи раніше.

І що найкраще, ви зробите все це не шляхом додавання ще одного нового інструменту. Ви перетворите усім знайомий і зручний Slack (чи MS Teams), на потужний DevOps-інструмент. 

Хочете бути у DevOps, як риба у воді? Обирайте курси про адміністрування AWS, Docker, Kubernetes та Ansible від ITEDU. Обіцяємо, це буде складно, але продуктивно. Щоб отримати результат — тисніть сюди.