Попри наявність Docker та Kubernetes, які дають змогу контролювати та автоматизувати багато процесів, розробники та DevOps-фахівці все одно зіштовхуються з низкою завдань, для яких потрібно шукати кастомні рішення. Одне з них — посилений контроль бізнес-метрик під час деплою.
На прикладі Argo Rollouts розбираємо кейси моніторингу технічних та бізнес-метрик, а також способи прогнозування та автоматизації відкату. Ними поділився Кирило Мельничук, кофаундер та CTO компанії Uspacy. Він розповідав про досвід команди на DevOps fwdays’24, а ми публікуємо головне з його виступу.
Необхідність контролю
Почнемо з короткого огляду еволюції процесу доставки коду. Приблизно 15 років тому, коли популярними були браузерні застосунки на хостинг-панелях, весь код деплоїли через FTP. Потім виник класичний метод, коли користувач логіниться на сервер, переходить у відповідну папку й виконує git pull origin master для деплою через SSH. Пізніше з’явилися SaltStack та Ansible, що допомагали автоматизувати процес деплою.
Поява Docker і Kubernetes дали змогу повністю автоматизувати доставку коду, забезпечити безперервність та контроль цього процесу. Здавалося, чого ще хотіти, але ми зрозуміли, що потребуємо більше контролю — за середовищем, метриками та релізами. Ось низка труднощів, з якими ми зіштовхнулися:
релізи важко контролювати;
релізи накладаються одне на одного, через що важко зрозуміти, який із них спричинив проблеми;
хоч як би якісно не тестувалися дані на стейджі, на проді все може піти інакше;
фронтенд та бекенд написані на різних мовах, які мають різні умови існування, а значить — по різному відпрацьовуватимуть у прод-середовищі. Через це з них потрібно повністю знімати усі метрики;
QA не встигають тестувати усі сервіси;
контроль вручну неможливо масштабувати.
З цієї мети формувалося кілька завдань: більш безпечні деплої (щоби забезпечити якісний результат для клієнтів), менше навантаження на команду та мінімізація можливостей для помилки.
З чого ми починали
На старті у нас були такі технології та процеси:
ArgoCD;
GitOps, де описано абсолютно всі процеси;
merge після трьох погоджень. Кожен pull request має затверджувати код-рев'ювер, продакт-оунер, який відповідає за фічу, та QA-фахівець, який усе перевірив на проді;
після merge в main ми автоматично деплоїли на всі регіональні кластери;
Datadog, OpenSearch для моніторингу помилок та аномалій;
стандартні Grafana та Prometheus;
ручний відкат за потреби. Про критичні моменти повідомляли в нашому власному чаті (ми не користуємося Slack, а маємо власний внутрішній чат в Uspacy, доступний і всім нашим клієнтам), а потім робили ролбек.
Як все організували
Коли merge йде у main, у нас відбувається build-deploy. Ми працюємо за методом канаркових деплоїв, коли перед релізом код перевіряється у контрольованому середовищі на невеликій групі користувачів. У нашому випадку це набір прод-порталів в різних регіонах, на які (і тільки на які) викачується новий код. Подальший деплой зупиняється, поки не відбудуться певні процеси. Всередині команди процес називається «відправляти [код] на Канари.
Спочатку ми запускаємо автотести на тих сервісах, де вони є. Якщо вони не пройшли, ми одразу автоматично робимо ролбек. Якщо пройшли, повідомляємо про в наш реліз-чатик, що певна фіча виїхала на канаркові домени і її можна перевіряти там.
Далі йдуть ручна перевірка QA і підтвердження від Product Owner, що фіча працює, як треба. Апрув на Git — і подальший реліз запускається автоматично. Ми робимо це поступово — по 10%, 25%, 50% і 100%. На кожному етапі перевіряємо, щоб все працювало, як треба, а метрики в зоні норми не перевищували критичні показники. Якщо ж на якому етапі процес «ламається», відбувається автоматичний ролбек, а у чат з релізами надсилають повідомлення, яка фіча чи pull request відкочені.
Найкраще технічне рішення
Ми розглядали кілька інструментів: Flagger, CodeFresh, Jenkins та Spinnaker. У результаті зупинилися на Argo Rollouts. Це Kubernetes контролер, що додає нові Kubernetes обʼєкти, які дають змогу задавати темплейти аналізаторів, запускати ці аналізатори, розділяти сервіс на Canary і стабільні репліка-сети, а далі прогресивно змінювати їх кількість, і залежно від правил, які ви задали в аналізаторі, йти далі чи відкачуватися назад.
Ми обрали його з кількох причин. По-перше, інструмент входить до екосистеми Argo, тож чудово поєднується з нашим Argo CD. По-друге, його можна використовувати на «голому» Kubernetes. Він заміняє стандартні deployment-object, розширюючи маніфести й надаючи додаткові можливості. По-третє, Argo Rollouts містить вбудовані CRD для роботи в Kubernetes, систему плагінів аналізатора та підтримку різних ingress-контролерів.
Налаштування з коробки дають змогу під'єднати кілька аналітик. Наприклад, Prometheus Query дає змогу витягнути ту чи іншу метрику з вашого Prometheus, й залежно від її значення робите populate далі чи відкатати його. Підключившись до Datadog, New Relic, Wayfront, можна одержувати все, що дозволяє API тих сервісів.
Наш основний інструмент — Kubernetes Job. Його перевага в тому, що можна налаштувати будь-яку job в Kubernetes і, якщо вона успішно завершується, ми й далі робимо populate нашого релізу. У випадку невдачі, ми робимо відкат. Іншими словами, ми можемо вставити в Job будь-який код будь-якою мовою програмування, який нам зручний, щоб збирати будь-які бізнес-метрики.
Які технології ми використовуємо зараз
GitHub Actions — через них йдуть деплої;
Uspacy Chat (так називається наш власний чат);
ArgoCD;
OpenSearch;
Prometheus;
метрики Datadog;
власні кастомні метрики.
Нижче видно, який вигляд має наш GitHub Actions, коли ми випускаємо оновлення на наших Canary-доменах, і деплой призупиняється. Після цього ставиться запит на перегляд для людини, яка має повноваження його схвалити. Зазвичай це керівники команд розробки фронтенду та бекенду або продакт-оунери. Потім у наш чат пишуть відповідне повідомлення. Якщо все добре, то у чаті ставлять галочку, якщо ні — хрестик. Так кожен може швидко дізнатися про статус релізу.
Правила ролбеків
1. Всі сервіси мають шаблони в GitHub. У цих шаблонах — JSON-файлах — описані всі репозиторії та правила деплою. Крім того, є загальні правила, які охоплюють, наприклад, рівень помилок, час відповіді, навантаження на базу даних (якщо така є в сервісі), кількість помилок на фронтенді (для фронтенд-сервісів). Також сервіси додатково налаштовуються. Ми додаємо власні метрики, оскільки кожен з сервісів відповідає за конкретні завдання й потребує індивідуальних підходів.
2. Контроль частки зміни error чи access логів. Важливо, чи люди загалом продовжують користуватися функціоналом, чи не почав він видавати велику кількість помилок.
3. Crashloop.
4. Кількість 5xx за проміжок часу. Ми виміряємо за останні 5 хвилин.
5. Метрики баз даних. У нас це CPU Utilization, кількість slow queries і середній час запиту.
6. Datadog. Тут дивимося на аномалії, появи спайків та response time.
7. Бізнес-метрики. Наразі ми відстежуємо кількість нових реєстрацій, щоби переконатися, що вона не знизилася, а також аналізуємо активність користувачів на наших порталах протягом останнього періоду. У фронтенд-частині ми моніторимо також кількість помилок на стороні клієнта. Плануємо додати ще оцінку швидкості завантаження та рендеру сторінок.
Висновки та плани на майбутнє
Попри те, що ми зіштовхнулися з низкою нових труднощів, як-от хибнопозитивні чи хибнонегативні ролаути та ролбеки, чи необхідність вручну вносити зміни щодо бізнес-метрик, нині процес деплою виглядає значно спокійнішим, ніж раніше.
Тепер нікому не потрібно постійно моніторити те, як саме минув деплой — цим по суті займається сам деплой. Релізи не накладаються одне не одного, адже кожен реліз автоматично пригальмовує подальший пайплайн. Екшн-план на майбутнє виглядає ось так:
1. Повністю інтегрувати Argo-екосистему. Так ми зможемо ще більш гнучко керувати доставкою коду до користувачів.
2. Автоматизувати апдейт порогів метрик. Зараз ми прописуємо показники для ролбеків вручну, але прагнемо знімати всі дані з Datadog або OpenSearch автоматично та змінювати їх через Terraform.
3. Запровадити динамічні стейджі. Це складно, коли є 60 мікросервісів, і потрібно протестувати різні версії коду різних сервісів одночасно. Зараз це відбувається вручну, але ми хочемо прийти до автоматизації.
4. Управляти процесом просто з чату, щоб там можна було робити populate релізу, відкатувати його, повідомляти про це тощо.
5. Зробити загальний дашборд, який показуватиме стан релізу всіх наших сервісів.