Як ми проґавили ідею DevОps як методології, та яким нині має бути DevOps-інженер

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

DevOps — це не професія. Це методологія, яка... бла-бла-бла-бла....

Давайте будемо відвертими, за більш ніж 15 років з того часу як відбулась доповідь «Agile Infrastructure» в Торонто та перша конференція DevOpsDays у Генті (Бельгія), термін «DevOps» де-факто так і не став методологією чи філософією, як того бажали б його ідеологи чи філософи. І можна скільки завгодно з піною у рота сперечатись що це не так, що не існує такої професії, але сотні тисяч вакансій з назвою «DevOps engineer» по всьому світу доводять нам протилежне. Тож, давайте спробуємо розібратись, чому ми все ж таки «програли» (поки що) цю битву, і чим в ідеалі, на мою думку, має займатись DevOps engineer.

Для початку, згадаємо з чого все починалось, якою була ідея, і які проблеми мала б вирішувати DevOps методологія.
Уявімо типову компанію 2008 року. Ми маємо кілька відділів (Dev, QA, Ops...), де кожен відділ займається своєю справою. Девелопери додають нові фічі, віддають їх на тестування QA, а потім Ops команда копіює файли, редагує конфіги, додає змінні, ранить скрипти, перезапускає сервери, і тому подібне.

Але в тому були проблеми: девелопери запевняли, що локально в них все працює (нічого не змінилось до сьогодні), QA жалілись що все потрібно переробити (аналогічно і зараз), а Ops команда взагалі не розуміла в який бубен потрібно вдарити, адже «продакшн оточення зовсім інше» (нічого не нагадує?). І от для вирішення цих проблем вигадали DevOps ідеологію:

• DevOps має на меті зменшити «розрив» між командами «Dev» та «Ops», зробити їх наче одним цілим
• Ті, хто створюють програму, повинні нести відповідальність і за її роботу в production
• «Я написав код. Далі це проблема Ops.» змінюється на «Тепер це наша спільна відповідальність»
• Необхідно автоматизувати все, що тільки можна автоматизувати, щоб зменшити час на розгортання і кількість помилок під час мануальної роботи

Але, натомість, після 15 років спроб покращити ситуацію концептуально нічого не змінилось — кожна команда просто «футболить м’яча» на протилежну сторону поля, перекладаючи відповідальність на інших. За ці роки команда «Ops», по суті, просто трансформувалась зі звичайних адміністраторів в адміністраторів, які все автоматизують. Треба віддати належне, що рівень такої автоматизації дійсно змінився. ЇЇ стало значно більше, як і інструментів для неї (Terraform, Ansible, Docker, K8s, Helm, Jenkins....). Це значною мірою пришвидшило time to market, але не вирішило основної проблеми — зменшення «розриву» між командами.

Чому так вийшло? Ну, по-перше, ролі людей і сфери відповідальності залишились такими ж. Хто писав код — продовжив писати код. Хто займався інфраструктурою і конфігураціями — продовжив займатись тим же. Тобто, спеціалізація і розподілення обов’язків майже не змінились (стіна між командами залишилась).

Так, існують кейси, коли в компаніях типу Google є позиція SRE engineer, де людина займається автоматизацією, бере участь в on-call чергуваннях, вміє писати код, та відповідає за роботу цього коду на продакшені. Але чи багато таких компаній? І чи багато є людей, які в змозі тримати весь цей багаж знань і зоопарк технологій в голові, одночасно виконуючи роботу декількох ролей?

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

«Критикуєш — пропонуй!» ©

Щоб змінити нинішню ситуацію нам потрібно переосмислити саму суть позиції DevOps інженера (і доведеться вже визнати, що така де-факто існує).
Чим займається DevOps інженер зараз: опис і розгортання інфраструктури, налаштування конфігурацій, розробка та підтримка CI/CD, мейтененс та моніторинг цього всього.... Тобто, займається всим тим, чим НЕ займаються девелопери. А, коли у останніх все працює локально, але не працює на серверах — вони біжать до DevOps інженера, щоб той глянув/додав/змінив/пофіксив. І дуже часто буває, що в цьому болоті додавання/фіксання грузнеш настільки, що не вистачає часу на будь-які «покращення», розробку, чи технічний борг. А девелопери тим часом чекають тебе....

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

Давайте розбирати на прикладах:

Поганий кейс: девелопери приходять до тебе з проханням створити базу даних на PSQL сервері — ти кидаєш свою поточну таску, і йдеш створювати для них базу. Контекст задачі, над якою ти щойно працював — втрачений, концентрація втрачена, 10-15 хвилин на створення бази втрачено, девелопери чекають....

Хороший кейс: ти відокремив Terraform модуль (чи скрипт) для створення баз даних в окремий CI/CD pipeline/terraform-infrastructure-layer, де просто вказуєш назви баз та їх конфіги в окремому config.tfvars файлі. Потім налаштовуєш правила для цієї пайплайни по типу: «не можна мерджати код в «main», чи запускати пайплайну на прод, якщо немає хоча б одного «Approve» від Eligible users. Після надання девелоперам прав на цю пайплайну, описуєш покроково Runbook під назвою «Як додати базу даних на PSQL сервер» — тебе ніхто не відволікає, девелопери створюють все самі (просто за допомогою натискання клавіші «Run»), таски робляться, ніхто нікого не чекає.

Поганий кейс: ти йдеш додавати змінну оточення в якесь місце, щоб вона потім «магічно» з’явилась всередині K8s як secret/змінна в контейнері.

Хороший кейс: девелопери самі можуть «прокинути» назву і значення нової змінної всередину K8s за допомогою скриптів або централізованого місця управління секретами/конфігураціями (по типу Hashicorp Vault, Azure KeyVault, CloudTruth, Spring Cloud Config...), та нативними K8s операторами, які будуть автоматично стягувати будь-які нові змінні/секрети.

Поганий кейс: насетапити OpenVPN сервер мануально та піти у відпустку. А потім сердитись, що VM, на якій він хоститься, впала, і тобі треба терміново брати комп’ютер в руки поки інші засмагають на пляжі

Хороший кейс: автоматизувати створення OpenVPN сервера (щось на грані задротства), або, як мінімум, створити Runbook, де детально (зі скриншотами) будуть описані всі кроки для його створення. Дуже важлива деталь: цей Runbook має бути таким, щоб навіть ваш HR при необхідності міг по ньому все зробити. Хороший Runbook — це коли його може зрозуміти навіть 7-річна дитина.

Поганий кейс: створювати Git репозиторій і всі правила/RBAC для нього, коли в цьому з’являється необхідність

Хороший кейс: написати за допомогою АІ скрипт, який створюватиме новий репозиторій разом з усіма необхідними налаштуваннями, варто лиш вказати назву цього репозиторію при запуску. Нехай деви самі все створюють!

І таких прикладів можна вигадати безліч. Потрібно лише змінити сприйняття своєї роботи з «треба зробити/пофіксити/додати Х» на «я створюю механізми для девелоперів». Тоді ніхто нікого не чекатиме, зникне залежність на конкретну людину/команду, і кожен зможе виконувати свої таски без перебивання м’яча на сторону «противника». Тепер ви — одна команда!

Зручність і простота використання — основні вимоги для таких механізмів. Задача DevOps інженера — придумати, як полегшити команді життя. А не ускладнювати його «незрозумілими» технологіями та інструкціями до них. Адже погодьтесь, якось не «по-православному» делегувати девелоперам дебагінг додатку всередині K8’s, якщо з механізмів у них лише «kubectl logs» замість нормальної системи логування з хорошою візуалізацією. Тож, питайте тих, для кого ви робите, яким має бути результат вашої роботи, збирайте фідбеки, і не бійтесь переробляти допоки всі не будуть задоволені.

Додатки роблять для юзерів, щоб отримати від них гроші. Для DevOps інженера такими юзерами є девелопери, а їхнє схвалення — валютою.