Статті

Що таке DevOps для системного адміністратора?

Що таке DevOps?

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

Істина десь посередині. DevOps — це все, що перераховано разом. Його головне завдання — прискорити доставку продукту від бізнесу до споживача, якщо сказати простими словами, що таке DevOps. Сам термін придумав незалежний IT-консультант Патрік Дебуа приблизно дванадцять років тому. Він хотів зруйнувати метафоричну стіну між розробниками (dev) і сисадмінами (ops), об’єднати їх в один ефективний підрозділ, який може створювати ПЗ швидше, викочувати релізи частіше і з меншою кількістю помилок.

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

Хвилинка нудної статистики. За дослідженням DORA (DevOps Research and Assessment), крос-функціональні команди, що використовують DevOps-підхід:

у 208 разів частіше розгортають код;
у 106 разів скорочують час від коміту до розгортання;
у 2,604 раза швидше відновлюють системи після збоїв;
у 7 разів знижують сам шанс збою внаслідок змін.

Звичайно, саме по собі об’єднання dev і ops не призводить до такої ефективності. DevOps-підхід охоплює використання безлічі нових інструментів розробки, тестування і розгортання для організації CI\CD (концепція безперервної інтеграції та доставки). Серед найвідоміших:

Git і GitHub — системи управління вихідним кодом;
Jenkins — сервер автоматизації для створення конвеєрів CI/CD;
Docker — ПЗ для автоматизації деплою та управління додатками в середовищах із підтримкою контейнеризації;
Kubernetes — відкрита система оркестрування контейнерів;
Chef, Puppet і Ansible — засоби для автоматичного конфігурування та розгортання;
Selenium — рішення для автоматизації тестування;
Prometheus і Nagios — програми для моніторингу серверів;
Grafana — рішення для збору та аналізу метрик.

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

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

Чим займається DevOps-інженер

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

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

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

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

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

Це теж моя робота: обов’язки DevOps

Професіонал намагається по-максимуму все автоматизувати, щоб процес відбувався менш болісно. Відомий випадок у невеликій компанії, коли в рамках тестування крос-бекапів і відмовостійкості інфраструктури вдалося перенести сервіси із США до Швейцарії за 10 хвилин і дорогою оновити все, що було потрібно. Для сучасних технологій це, звісно, не величезне досягнення. Але для невеликої компанії — великий крок уперед.

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

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

І, звісно, впровадження DevOps-підходу тісно пов’язане з вимірюванням. Наскільки змінився час відгуку? Як часто виникають навіть передбачені помилки? Раніше системний адміністратор часто не уявляв, як можна вимірювати ці речі. Додатки були чорними скриньками, залишалися тільки базові характеристики: завантаження процесора, споживання пам’яті, трафік. А під час розгортання нової версії ні сисадмін, ні програміст не могли швидко визначити, що все пішло не зовсім так, як планувалося. Лишилось чекати гнівних звернень у техпідтримку.

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

Скільки заробляють DevOps-інженери?

Зарплата DevOps-інженера залежить від навичок, місця роботи та регіону проживання. Середній річний дохід у Штатах, як кажуть деякі HR, коливається від 100 до 125 тисяч доларів США, згідно з даними, опублікованими компанією Puppet. В Австралії та Новій Зеландії — 75-100 тисяч доларів США. У Європі — 50-75 тисяч доларів США. В Азії DevOps-інженери отримують не більше 25 тисяч доларів США на рік.

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