Щось на айтішному: DevOps-інженер

— У DevOps я вже понад сім років, — розповідає Олександр. — До цього п’ять років пропрацював у сфері мережевих технологій на різних позиціях, але потім зрозумів, що в мережевій частині розвитку не особливо багато. З грудня 2021 працюю в компанії Naviteq team lead-фахівцем, який займається не тільки проєктами, а й зустрічається з клієнтами, продає послуги, готує архітектуру тощо.

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

Що таке DevOps?

— Мені сподобалося, як мій колега Віктор енциклопедично розповів, що таке DevOps, — ділиться Олександр. — Я ж розповім своє бачення. Коли ми знаємо, що відбувається в IT-компаніях і чуємо про DevOps, то ми приблизно розуміємо, що це ті хлопці, які відповідають за інфраструктуру й роблять якісь автоматизації, щоб у нас усе гарно «літало» й працювало. Це одна точка зору.

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

Третя й особлива точка зору — це точка зору бізнесу. Приходять клієнти, які не знають технічних аспектів, але чули, що DevOps можуть вирішити їхні бізнес-проблеми. У таких клієнтів і замовників спотворений погляд на DevOps. Вони думають, що це така собі «срібна куля»: DevOps-інженер, який усе виправить. Насправді це не так. DevOps — це не конкретна технологія чи інструмент. Це сотні інструментів і десятки різних підходів, і найголовніше, що робить DevOps, — спілкується. Його завдання — допомагати «дружити» департаментами через переговори, через якусь автоматизацію, яка допомагає зменшити кількість цих переговорів. Зокрема це автоматизація всього того, що потрібно бізнесу зрештою для того, щоб спростити й прискорити роботу інших команд, які залучені до створення продукту. Мені ця думка здається дуже цікавою.

Якщо все ж таки говорити класичними словами, то DevOps — це комбінація підходів, патернів, процесів, які встановлюють, і технологій, які впроваджують, щоб вирішувати конкретні технічні та процесуальні проблеми та прискорювати доставку кінцевого програмного продукту клієнтам. Це загалом. Якщо розбивати DevOps на частини, Dev — це розробка, а Ops — супровід. Разом DevOps — це сутність, яка знаходиться всередині. Роман «Проєкт «Фенікс» саме розповідає про проблематику DevOps: є розробники, і є ті, хто змушений те, що роблять розробники, десь розгортати, щоб до цього отримували доступ кінцеві клієнти. Команди, залучені до розробки, постійно перекидаються завданнями, звинувачуючи одне одного. DevOps потрібні, щоб це спілкування оптимізувати шляхом упровадження процесів, технологій, які дають змогу звести його до мінімуму й автоматизувати. Грубо кажучи, ми впроваджуємо правильну систему тікетів (завдань) у якійсь системі типу Jira або ми впроваджуємо якийсь оптимізований пайплайн, який допомагає розробникам автоматично перевіряти свою роботу і, за потреби, автоматично передавати її на тестування, а також автоматично оцінювати якість по ходу й отримувати на виході готове рішення, яке буде десь розгорнуто.

DevOps — це своєрідний buzzword сьогодні. Не всі розуміють, що це, але всі його чули, і деякі представники різних галузей можуть давати абсолютно різні визначення. Усі будуть по-своєму праві. Сьогодні почали з’являтися різні розширення в професії: DevSecOps, MLOps, AIOps тощо. Багато різних абревіатур, за якими ховаються спеціальні напрями або підходи й техніки, що впроваджуються сьогодні. Але під «капотом» це все ті ж люди, які розуміються на операційних системах і розбираються, як працюють мережі, можуть написати код і знають певні інструменти, специфічні для DevOps-світу.

Перспективи професії DevOps

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

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

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

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

Як розуміти DevOps-інженерів краще?

— Ми можемо працювати безпосередньо з DevOps-інженерами, а можемо не взаємодіяти з ними напряму, але чути на дзвінках якісь абревіатури, слова, які інколи можуть викликати нерозуміння, — пояснює Олександр. — Для себе я виокремив такі терміни, які треба знати DevOps-інженеру-початківцю або тим, хто хоче потрапити в цю професію:

• CICD (continuous integration і continuous delivery або continuous deployment) — це такий собі безперервний автоматизований процес доставки програмного коду від ідеї до кінцевого клієнта. Це так звані пайплайни, щоб розробники писали код, відправляли його в систему контролю версій, і під «капотом» відбувалася магія, а саме — збирання коду, його тестування, взаємодія з іншими департаментами. Зрештою ця частинка коду стає доступною кінцевим клієнтам, які користуються нашим продуктом. Ключові метрики оцінки якості CICD — це так звані lead-time: час доставки від ідеї до кінцевого клієнта. Тому CICD напевно є на будь-якому проєкті, пов’язаному з DevOps, за винятком якихось дуже вузькоспрямованих, які працюють тільки з інфраструктурою, але й там, найімовірніше, CICD замішаний.
• Cloud. Усі чули про хмарні обчислення й хмарні технології. Коли ми говоримо «хмара», ми маємо на увазі якийсь рівень абстракції. Ми не ходимо до залізного сервера у нас у підвалі, який сильно шумить, гріється й світиться, як новорічна ялинка. Ми платимо комусь, і цей хтось для нас ці ялинки у великій кількості десь зберігає й обслуговує. Наприклад, ми хочемо з великого сервера отримати якусь кількість ядер та оперативної пам’яті, щоб там розгорнути наш сайт. Ми платимо, нам дають віртуальний шматок пирога, який ми використовуємо. Ось цей рівень абстракції, коли ми взаємодіємо з кимось там десь там, і називається «хмари». Сьогодні на міжнародному ринку є ключові вендори, як-от: Amazon Web Services, Microsoft, Google Cloud Platform, а також інші гравці, які трохи менші, але теж набирають обертів, — Oracle, IBM тощо. Їх насправді багато. Окрім того, деякі замовники будують свої приватні хмари. Що це означає? У них є парк серверів, і вони так само доставляють своїм внутрішнім клієнтам у компанії, департаментам ті самі шматочки пирога. Тільки обслуговують це силами якоїсь команди, яка в них є. Умовний бухгалтер не думає про те, де цей сервер розташований, для нього це просто точка входу в програму, де все працює.
• Configuration management — це певний клас інструментів, який дає змогу описувати якоюсь декларативною мовою необхідний стан системи. Наприклад, у нас є якийсь комп’ютер, і нам треба встановити на нього програмне забезпечення: програму, браузер, що завгодно. Ми це можемо зробити руками, але з часом, якщо ми видалимо цю програму, нам, щоб її встановити знову, потрібно згадати, як ми це робили спочатку. Так от, configuration management дає змогу описати необхідні кроки для встановлення якогось програмного забезпечення мовою, що читається людиною, які згодом програмними засобами перетворюються на безпосередні команди на операційній системі. DevOps-інженери займаються цим, щоб забезпечити швидке відновлення в разі якихось ручних змін і щоб швидко оновлювати конфігурації на сотнях і тисячах серверів.
• Інфраструктура як код (infrastructure as code). Те ж саме, що і в попередньому пункті: ми описуємо декларативною мовою самі сервери. Наприклад, ми говоримо, що хочемо дві віртуальні машини в хмарі. Пишемо відповідно до документації структуру тексту, і завдяки різним інструментам, як-от terraform, у нас автоматично через спеціальні API у хмарі створюються ці сутності. На виході ми можемо їх також дуже швидко змінювати, оновлювати, але не треба зайвий раз клікати мишкою. DevOps-інженери не люблять клікати мишкою. Якщо якась операція робиться більше одного разу, DevOps, найімовірніше, захоче це автоматизувати, щоб згодом це дало змогу не припускатися помилок.
• Alert — найнеулюбленіше й небажане слово для DevOps-фахівця. Alert означає, що DevOps-інженеру треба йти й щось лагодити або розбиратися, що не так. Підтримка якісного й постійного рішення, яке працює та будується, зокрема, під DevOps-підхід, — це те, що обов’язково охоплює моніторинг. А моніторинг потрібен не просто для того, щоб знімати показники системи, він повинен іще відстежувати зміни в негативну сторону. Якщо в нас відбувається щось, чого ми не хочемо, ми отримуємо alert. Наприклад, хтось ненавмисно видалив нашу віртуальну машину, — ми отримуємо alert. Хтось ненавмисно опублікував якусь внутрішню IP-адресу в інтернет, а хтось інший почав її ламати — ми отримаємо дуже велику кількість alerts.
• SRE (site reliability engineering). Це процес, який одним із перших описала компанія Google і який полягає в тому, що інженери, які використовують SRE-підходи, дуже сильно залучені до працездатності застосунку. Якщо з застосунком щось не так, вони перші, хто починає з’ясовувати й виправляти цю помилку. Вони стежать за певними метриками й відстежують, щоб цих alerts була мінімальна кількість. Дуже складно сказати, хто є SRE, хто DevOps. Хтось називає себе так, хтось так. По суті, люди виконують одну й ту саму роботу. Єдина відмінність — вважається, що SRE вміють програмувати більше, ніж DevOps. Якщо щось трапилося з системою, SRE може піти та в коді виправити помилку самостійно.
• SLA (service level agreement). SRE дуже люблять цей термін. Це певна цифра навколо певної характеристики системи. Наприклад, ми говоримо, що наша система буде доступною для клієнта протягом 95% усього часу на рік. Тобто ми стверджуємо, що лише 5% часу на рік наша система буде недоступна. Обидві сторони підписують це, і на цьому будується договір. SRE саме складають ці метрики та стежать за їх дотриманням.
• Script. Це, як правило, текстовий документ, який із використанням певної мови програмування або bash (скриптова мова) дає змогу виконати набір ручних команд в автоматичному режимі. Це робиться для того, щоб автоматизувати те, що ми зробили колись руками й не хочемо повторювати в майбутньому. Це щось, як правило, легке, що робить дуже прості речі, але нам треба, щоб це було автоматизовано. Наприклад, нам треба раз на місяць піти на якийсь сервер і видалити там сміттєві файли, щоб у нас було трохи дискового простору. Ми не будемо це робити раз на місяць руками, ми напишемо script, який автоматично це робитиме за нас на самому сервері.

Вибирай уподобану професію в IT та вивчай сленг:

• Скажи щось айтішною: тестувальник
• Скажи щось айтішною: бізнес-аналітик
• Скажи щось айтішною: Data-аналітик
• Скажи щось на айтішному: UI/UX-дизайнер