У попередній статті йшлося про те, що таке Chaos Testing, чим корисний такий підхід до перевірки стійкості продуктів, а також коли хаос-тестування зайве. У цьому ж матеріалі розберемо основні етапи й інструменти Chaos Testing.
Підготовка
Перш ніж експериментувати, врахуйте деякі моменти.
Дослідіть історію попередніх збоїв
Цілей для дослідження хаосу в роботі системи безліч, але важливі пріоритети. Найпростіший шлях — звернутися до логів. Вони покажуть, які проблеми вже «горять». Звісно, далеко не все навіть в історії збоїв може бути зрозумілим. Шукайте закономірності, обговоріть із колегами неочевидні причини проблеми. У процесі брейнстормінгу стане у пригоді візуалізація даних.
Якщо певні частини системи жодного разу «не падали», це не означає, що їх не потрібно перевірити. Поряд із дослідженням слабких місць додайте в план «сплячі» проблеми.
Побудуйте мапу залежностей
Проєкти на мікросервісній архітектурі можуть бути настільки складними, що вкрай важко визначити вплив однієї частини на інші. Мапа залежностей тут доречна, навіть якщо ви не будете проводити хаос-тестування. Вона дозволить правильно додавати та змінювати фічі. Для хаос-тестінгу схема взаємозв’язків незамінна: в ній ви побачите, яких частин продукту стосуються різні залежності та які з них є критичними.
Побудову залежностей можна автоматизувати, наприклад, за допомогою AWS X-Ray.
Налаштуйте алерти та бекапи
Без страховки ніяк, і тут важливі два моменти. Перший — моніторинг. Замало спрямувати його лише на ту частину, яку тестуєте. Злам одного компонента може спровокувати збої в іншому місці, тому потрібні алерти про будь-які зміни системи. За потреби можна швидко зупинити експеримент. Друга страховка — бекапи. Всі дані та компоненти мають бути збережені. В ідеалі налаштувати все так, щоб відкат відбувався автоматично або за однією кнопкою. Це мінімізує втрати, якщо щось піде не за планом.
Сплануйте всі роботи
Якщо ви тестуєте щось на production, то стартувати краще з невеликих компонентів і простих тестів. Так ви зможете досліджувати систему поступово і знизите ризик виникнення масштабних проблем у реальності. В будь-якому разі до початку тестів оцініть можливий рівень ураження по кожному з напрямів. Також варто викочувати зміни на обмежену кількість користувачів. Це дасть реалістичну картинку, але не призведе до великого падіння продажів чи зниження рівня задоволеності юзерів.
Якщо ж йдеться про тестування на закритих середовищах, можна діяти протилежним чином. Спочатку запускайте перевірки на всій системі, щоб виявити bottle necks, проблемні місця, де можна очікувати падіння перфомансу. Потім переходьте до тестування окремих компонентів.
Як провести Chaos Testing
Суть полягає у створенні контрольованого збою для вивчення поведінки застосунку поза межами нормальних умов. У цьому процесі виокремлюють такі етапи:
1. Зафіксувати нормальний стан системи
До початку експерименту потрібно зрозуміти, як все працює за замовчуванням. На це є дві причини. По-перше, ви маєте від чогось відштовхуватися, щоб знати, що пішло не так. По-друге, після тестування потрібно переконатися, що все стало на свої місця. Адже не виключено, що збій у межах тестування призведе до непередбачуваних наслідків і негативно вплине на роботу всієї системи. Інколи навіть після відновлення пошкоджених компонентів застосунок може працювати хибно.
2. Сформулювати гіпотезу
Подібно до наукових експериментів у Chaos Testing теж має бути гіпотеза. Спробуйте передбачити поведінку певних компонентів під час збою із заданими форматом та масштабом. Наприклад, чи зможе система перенаправити трафік на інші регіони, якщо один перестане працювати? Як зміниться показник відмов юзерів при збільшенні затримки на 200 мілісекунд? Що трапиться, коли переповниться кеш і як система повідомить про це? Краще почати тестування з однієї простої чіткої гіпотези.
Але проста гіпотеза — не значить очевидна. Навіщо перевіряти те, що однозначно «впаде»? Корисніше спрямувати зусилля на ті компоненти, поведінка яких здається стабільною. Тоді є шанс знайти цікаві інсайти та використати їх задля покращення продукту.
Залучайте до обговорення гіпотези всю команду. Розробники, тестувальники, девопси, дизайнери та менеджери можуть зауважити те, на що ви не звертали увагу в поведінці системи, або підказати шляхи пошуку слабких місць.
3. Визначити межі експерименту
Маєте гіпотезу — пропишіть умови тестування. Потрібні чіткі KPI, що підтвердять або спростують ваші здогадки. Наприклад, кількість і частота помилок, затримка, відмови, пропускна можливість тощо. При визначенні KPI орієнтуйтеся на конкретний сервіс. Наприклад, у Netflix вимірюють SPS, starts-per-second. Це кількість кліків на Play. Коли сервіс гальмує, люди часто повторно тиснуть на цю кнопку. Ця метрика вказує, що є й технічна, і користувацька проблема.
На цьому етапі також слід прорахувати тривалість експерименту та зону ураження (її ще називають радіусом вибуху). Мова про конкретні частини системи, функціонал застосунку та кількість юзерів, які зіткнуться з проблемою. Якщо ви тільки дебютуєте у Chaos Engineering, краще обмежитись не просто малою частиною системи й аудиторії, а взагалі локальним середовищем. На старті навіть на цьому рівні вся команда дізнається чимало нового про поведінку системи. Хоча прод-середовище — пріоритет.
4. Провести тестування
Слідуйте прописаному тестовому сценарію. Будь-яке відхилення від плану може спотворити результати відносно початкової гіпотези. Будьте готові швидко завершити експеримент, якщо виникли суттєві проблеми, яких ви не очікували.
Обов’язково попередьте всіх учасників команди про старт «хаосу». Але якщо сценарій передбачає таємність процесу для певних фахівців (щоб перевірити їхню реакцію та подальші дії), то, звісно, дотримуйтеся «режиму інкогніто».
Виконувати хаос-тестування можна кількома способами:
- Мануально — самостійно вносити деструктивні елементи в роботу системи, коду, обладнання тощо. Так ви повністю контролюватимете процес, але це потребує досвіду.
- Автоматизовано — за допомогою спеціальних інструментів. Це можуть бути вбудовані механізми Linux та хмар або застосунки чи сервіси, які надають контейнери для інтеграції в середовище (детальніше про інструменти поговоримо нижче).
5. Проаналізувати результати
Підготуйте детальний звіт з виявленими проблемами та інсайтами. Опишіть, що відбувалося в системі та як реагувала команда. Також звіт має пояснювати вплив тестового збою на юзерів. Головне — показати реальні причини руйнації, дати інсайти про поведінку системи у кризових умовах і надати поради щодо попередження схожих збоїв у реальності.
Також важливо ставити часові мітки у звітах. Вони покажуть, у якому стані була система на кожному етапі. Відповіді на ці питання дадуть чимало корисної інформації для роздумів та подальших покращень:
- Коли почалися проблеми?
- Скільки часу минуло до появи алертів на пошті чи в месенджері?
- У який момент продукт зазнав найбільшої втрати функціоналу?
- Через який проміжок часу система запустила автоматичне відновлення (якщо взагалі почала)?
- Коли все повернулося до початкового стану?
6. Внести зміни в системі
Передусім зміни можуть стосуватися тих частин застосунку, які виявилися нестабільними. Змініть усе, що несе в собі ризики подальших збоїв. А потім знову перевірте, як «падає» ця частина системи. Варто переконатися, що засвоєні уроки дійсно принесли користь для продукту та користувачів. Повторюйте експеримент і модифікуйте його, поки не впевнитеся в стабільності системи. Подекуди може бути дві-три, а то й більше ітерацій.
Другий напрям для змін — інтеграція хаос-тестування в конвеєри CI/CD. Це тестування може виконуватися разово чи як окрема послуга (наприклад, на аутсорсі), але насправді помітний ефект хаос-тестінг дає лише при системному підході. DevOps-інженери разом із девелоперами та QA мають побудувати комплексну систему хаос-інжинірингу. Це вимагає кардинальних змін робочих процесів і залучення додаткового бюджету. Але реальні несправності можуть коштувати бізнесу набагато більше.
Інструменти для хаос-тестування
Спеціальні утиліти
Це невеликі консольні програми під вузькі задачі, найбільш корисні на початку тестування. Наприклад, за допомогою iptables можна змінювати роботу брандмауера, wrk створений для бенчмаркінгу HTTP, а stress-ng може перевантажити ресурси системи. Інструмент tc використовують для конфігурації планувальника пакетів ядра, а pkill — для завершення окремих процесів.
Комплексні програми
А це вже повноцінні сервіси та платформи для хаос-інжинірингу, які виконують оркестрацію несправностей різного типу й масштабу. Серед таких інструментів варто виділити Chaos Toolkit. Він має відкритий API, підтримує інтеграцію з AWS, Azure та GCP, має розширення з наборами тестів (можна створювати свої сценарії).
Поширений також Gremlin — для експериментів з усіма частинами системи. Він здатен пріоритезувати знайдені проблеми. Існують і сервіси для окремих середовищ, такі як LitmusChaos для Kubernetes і Pumba для Docker.
Simian Army створили айтівці в Netflix для тестів на AWS. На жаль, цей проєкт закритий, але окремі його частини доступні. Simian Army об’єднував кілька тулзів для збоїв різного типу й масштабу. Наприклад, Chaos Monkey, який нині розвивається як опенсорс-проєкт, може рандомно відключати інстанси. Latency Monkey створював затримки між клієнтом і сервером, Chaos Gorilla викликав збій зони AWS, а Chaos Kong — збої в цілому регіоні. Doctor Monkey перевіряв працездатність окремих екземплярів і компонентів системи, а Janitor Monkey знаходив та видаляв ресурси, які не використовуються (зараз ця тулза відома як Swabbie).
Збої є невіддільною частиною життя будь-якого цифрового продукту. Навіть у супернадійному на перший погляд проєкті коли-небудь щось-таки трапиться. На це можуть впливати помилки розробників, дії користувачів чи хакерів, відмови обладнання та інші зовнішні фактори. Головне — пам’ятати про це і готуватися, а саме — впроваджувати хаос-тестування. Звісно, це не вбереже від усіх можливих негараздів, але принаймні зменшить імовірність збоїв та їхні наслідки, а це збереже чимало часу, грошей і нервів.
Анна Молодцова, Performance QA Engineer в NIX
Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
