Дуже часто у вакансіях пишуть «DevOps Engineer». Що це за роль? І чи роль це? Що таке взагалі DevOps? Які він в себе включає практики? Чому назва позиції DevOps інженер звучить некоректно? Цим питанням і присвячена стаття.
Будь-яка компанія, пов'язана з розробкою або впровадженням програмного забезпечення, прагне рухатися швидше і бути якомога гнучкішою. Для цього потрібна максимальна залученість розробників в усі стадії життєвого циклу процесу розробки ПЗ. Давайте замислимося, з чого починається і чим закінчується цей цикл програмного забезпечення. Починається з планування — це знають практично всі. Але чим він закінчується? Деплойментом? А куди і як ми деплоїмся? Коли закінчується залученість розробника у процес? Чи варто йому залучатися в принципі? І взагалі, чи важливо те, на якій платформі буде розміщуватися написане тобою ПЗ. Чи важливі ресурси, які ви під нього відведете? Як швидко ви будете оновлювати його? Давайте простежимо еволюцію процесу.
Як було раніше
Коли тільки починалася промислова розробка програмного забезпечення, кожен розробник був сам собі бізнес-аналітик, архітектор, верстальник, девелопер, тестувальник, девопс і підтримка 24/7 в одному флаконі. Які це містило в собі недоліки? Іноді виходили досить кострубаті і не зрозумілі для стороннього користувача продукти. Важко було уявити, що відбувалося в голові того чи іншого індивіда. І ще один мінус — зосередження всіх сакральних знань в одній світлій голові, яка могла захворіти, піти до конкурентів, та й просто виїхати відпочивати на Гоа. Однак в цьому були і плюси. Інженер відразу замислювався про повний цикл життя свого продукту. Тут не було надії на всемогутнього адміністратора, який прийде і все вирішить за тебе. За будь-який косяк доводилося розплачуватися самому і це не змушувало себе довго чекати.
Потім сталося те, що завжди відбувається при переході до масового виробництва, — галузевий розподіл. З'явилися адміни, які управляли інфраструктурою додатку, і розробники, які цей додаток розробляли. Я не кажу про верстальників, інженерів з якості, бізнес-аналітиків та інших, анітрохи не применшуючи їх досягнень в процесі розробки. Так ось, після розподілу для багатьох девелоперів цикл життя програмного забезпечення став закінчуватися командою «git push», при закритті останнього бага. Також на ситуацію вплинула специфіка бізнесу — аутсорс став домінувати. Багато хто доставляв код, як сировину, не замислюючись про кінцевий результат, про те, як і де все це буде розміщуватися. Це могло тривати вічно, якби не кілька факторів.
Причини появи культури DevOps
Першим фактором стала поява ряду продуктових контор, в яких задумалися не тільки про те, як локально вирішити ту чи іншу проблему, а про глобальні рішення. Тут не пройде локальна милиця, з якою потім доведеться розбиратися іншим. Треба усвідомлювати, що далі доведеться жити з цією милицею, а тому потрібно вирішувати щось на рівні інфраструктури. Доводиться починати розробляти, спираючись на те, де буде розміщуватися кінцевий продукт.
Якщо перший фактор ще може здатися досить спірним, то другий — більш однозначний. Це широкий розвиток хмарних сервісів, відмова від хостингу на своїх серверах і підтримки своєї інфраструктури як такої. Обрана інфраструктура почала визначати архітектуру програми. AWS, Azure, Heroku, DigitalOcean почали робити за вас вашу роботу. Тепер не треба без особливої потреби вигадувати 1001 варіант написання балансеру або шардінгу — це все доступно з коробки. Це знизило кількість велосипедів на квадратний метр, але цей підхід, в свою чергу, вимагає знання інфраструктури сервісів і адаптації своїх продуктів під них.
Крім того, мікросервісна архітектура внесла свій вклад у переосмислення девелоперами інфраструктури додатку. Тепер недостатньо «настворювати» черговий модуль і залити його у репозиторій, надавши деплоймент-інженерам вгадувати змінні конфіги. Ні, тепер треба думати, як це все буде взаємодіяти одне з одним, тому що ця конфігурація може не злетіти навіть у вашій пісочниці, а відправляти неперевірений код — це якось вже зовсім занадто.
Платформи почали визначати реалізацію програм, тому розробник не може написати хороший додаток без знань про платформи. Розробників стали залучати до операційної роботи. З'явилася культура DevOps. Чому не роль? Тому що DevOps практики, про які йтиметься нижче, повинні впроваджуватися на рівні компанії, а не на рівні відділу або групи. Люди в компанії повинні знати і про розробку програмного забезпечення, і тонкощі використання інфраструктури.
DevOps-культура, по-моєму, — це наступний щабель еволюції FullStack-парадигми, в якій команди реалізують не окремі частини програми, а вирішують всю задачу. Одній людині охопити ці завдання досить складно, і такий процес треба вести у всій компанії або групі. Причому перше, що треба зробити, прибрати роль DevOps-інженера як таку.
Практики DevOps
Тепер давайте поговоримо про практики DevOps. Вони досить непогано описані в книзі «DevSecOps The Road to Faster, Better and Stronger Software». Давайте розглянемо основні з них.
- «Automate everything» — автоматизуй все, що можна. Зменшуй кількість «ручної» операційної роботи. Робиш, щось два рази — придумай, як це автоматизувати. Це прискорить всі процеси і зведе кількість помилок до мінімуму. Працювати повинен робот, людина повинна відпочивати і займатися розумовим процесом!
- «Configuration management». Docker приходить до нас на допомогу в конфігурації, збереженні та менеджменті всього, що нам потрібно для успішної роботи програми. Оркестрації контейнерів можуть здійснюватися за допомогою таких тулів, як Kubernetes або Docker Swarm.
- «Infrastructure as Code». Мається на увазі, що підхід до конфігурації додатків повинен бути таким же, як і до коду. Якщо раніше в конфігурації системи через консоль не було нічого поганого, то сьогодні стало вже поганим тоном не використовувати для цих цілей інструменти автоматизації, такі як Terraform, Chef, Puppet і т. д. Ця практика дозволяє оптимізувати ресурси, а також значно прискорити час поставки.
- «Continuous Deployment». Автоматичне викочування готових фич на робоче оточення. І якщо раніше CD-системи були іграшкою тільки для розробників, то тепер вони активно використовуються для автоматизації накатки змін у конфігураціях. Ця практика дозволяє оптимізувати ресурси, а також зводить участь людини в процесі поставки до мінімуму.
- «Application monitoring». Якщо раніше системи моніторингу являли собою різні способи «скиртування» логів, то тепер це потужний інструмент для моніторингу стану вашої програми. На аналіз логів не треба витрачати дні і тижні, ви можете налаштуватися на ту чи іншу метрику і дивитися за змінами в режимі реального часу. Крім суто технічних моментів, наприклад кількості запитів, перформансу, завантаження CPU, ви за допомогою таких систем, як Prometheus, можете збирати і внутрішні характеристики додатку, значимі для вашого бізнесу.
Це далеко не всі практики, які складають культуру DevOps. Однак, як ми можемо помітити, вони являють собою набір методів та інструментів, при використанні яких можна вирішити проблему швидкого та якісного постачання ПЗ кінцевому споживачу, а також якомога швидше отримати від нього зворотний зв'язок як метрику.
Висновки
DevOps культура — це те, що повинно культивуватися на рівні компанії. Команди повинні не тільки вміти реалізувати фичу, а й організувати процес тестування, доставки і зворотного зв'язку з кінцевим споживачем. DevOps практики покликані полегшити життя всім — розробникам, операціоністам, бізнесу, тому що саме вони є тонкими ниточками між, на перший погляд несумісними галузями.
