Chaos Testing — особливий метод перевірки ІТ-продуктів. Йдеться про створення навмисних збоїв у системі задля подальшого аналізу її поведінки та планування дій на випадок реальних перебоїв. Хаос-тестування виявляє слабкі місця застосунку чи сайту, мережі, обладнання чи інфраструктури. Це комплексне тестування, тож його ще називають Chaos Engineering (інженерією хаосу).
Не плутайте зі стрес-тестуванням (Stress Testing) і тестуванням навантаження (Load Testing). Ці підходи, які можна узагальнити під гаслом Perfomance-тестування, теж спрямовані на вивчення поведінки системи в позаштатних ситуаціях. Але порівняно з Chaos Testing є важливі відмінності:
● Фокус. Perfomance-тестування може застосовуватися до системи в цілому або до окремих компонентів, а «хаотичне» — завжди до дуже багатьох факторів у розподілених середовищах. Це те, що треба для мікросервісної архітектури із сотнями зв’язків. Тут часто стаються каскадні збої, коли одна проблема «ламає» систему в кількох інших місцях.
● Мета. Stress Testing і Load Testing перевіряють систему під критичним навантаженням, чи зміниться робота продукту при якихось змінах. А ось у хаос-тестуванні це другорядне. Важливо не те, чи «впаде» система. Головне: як і коли це відбудеться, яким чином ми дізнаємося про проблему, як будуть поводитися користувачі, чи спробує система самостійно відновитися тощо.
● Середовище. Тестування продуктивності зазвичай виконується в test- і stage-середовищах, що не впливає на бізнес-процеси. Chaos Testing може проводитись і на закритих середовищах, зокрема prodlike, але й ще на відкритому — production. Адже деякі проблеми неможливо виявити без реальних користувачів. Наприклад, на проді можна побачити реакцію юзерів на збільшену затримку у завантаженні.
Звідки починається Chaos Testing?
Про схоже тестування можна знайти згадки в роботі Amazon та Google ще у 2000-х, а в команді Apple — навіть у 1980-х роках. Нині вважається, що підхід до «хаотичного» тестування зародився в Netflix, коли у 2011 році компанія почала переносити центри обробки даних в AWS.
Тоді хмари здавалися безперебійними: в них відсутня єдина точка входу, середовища розподілені, легко переспрямовують ресурси й трафік, роблять бекапи, замінюють кластери. Але 2015 року Netflix зазнали простою у кілька годин і щоб краще підготуватися до можливого повтору, команда запровадила глибокі перевірки системи в режимі хаосу.
Що перевіряють за допомогою хаос-тестування
Підхід спрямований на всі складники цифрової системи. Серед основних місць впровадження несправностей можна виокремити такі:
● Інфраструктура. Netflix використовували хаос-тестування якраз для перевірки стійкості своєї інфраструктури. Варіантів, куди спрямувати руйнування, чимало: зупинка випадкових інстансів, відключення окремих зон чи регіонів, від’єднання від повноцінного центру обробки даних тощо.
● Мережа. Це невіддільна частина хаос-інжинірингу для будь-яких систем, особливо розподілених. Тут можна створювати затримки, відправляти пакети у чергу або задавати їх втрату, змінювати файл hosts і налаштування DNS або імітувати пошкодження мережі.
● Ресурси. На цьому рівні впровадити помилки можна в ядро чи кеш CPU, файлову систему, оперативну пам’ять, операційну систему, API, віртуальні машини тощо. Також можна вичерпати місце на жорсткому диску, відключити напругу на сервері або окремі планки пам’яті.
● Застосунок. Цей шар найоб’ємніший, і залежно від структури продукту поламатися можуть сотні частин. На бекенді можуть бути проблеми з базами даних, падіння окремих процесів, наприклад, Java, помилки в лямбда-функції. На фронтенді можуть відмовити плагіни, певні функції сервісу чи вбудовані інтеграції.
● Люди. Критичні сценарії можна запускати на рівні команди. Наприклад, щоб перевірити, як фахівці зреагують та розв’язуватимуть проблему, чи будуть вони слідувати прописаним процедурам тощо. Можна навіть «відключити» ключового інженера (імітація відпустки чи лікарняного) та подивитись, чи зможе команда самотужки забезпечити роботу системи в разі несправності.
З чим допоможе Chaos Testing
● Виявити проблему до «падіння» системи. Вкрай важливо побачити потенційні точки відмови до небажаного моменту. Це дозволить якісно змінити роботу всієї системи, підвищити її стійкість і доступність. Врешті це знизить і втрати компанії: ресурсні, фінансові, репутаційні.
● Знайти приховані проблеми та краще зрозуміти, що відбувається «під капотом». Сучасні розподілені системи подекуди заскладні, з великою кількістю компонентів та зв’язків. Тож навіть досвідчені фахівці можуть не знати всіх їхніх слабких місць. Хаос-тестування виявляє приховані вразливості та показує поведінку системи під час різних за форматом і масштабом збоїв.
● Покращити моніторинг несправностей. Неможливо впровадити Chaos Testing без побудови й налагодження великої системи телеметрії. Вона ж корисна не тільки в процесі хаос-тестування, але й у повсякденній роботі. Операційні команди отримують більше показників для аналізу стану системи та можуть заздалегідь виявляти певні проблеми.
● Розробити «рятівні» сценарії. Одразу виправити всі знайдені проблеми складно, але можливо підготуватися до них. Розуміння ризиків дозволяє прописати детальний план дій на випадок тих чи інших збоїв. Також документація спрощує онбординг новачків у команді, дає змогу швидше розібратися в особливостях побудованої системи.
● Покращити команду роботу. Будь-які збої — завжди стрес. А в таких умовах команда часто зосереджується на пошуку винних, хоч насправді це не розв’язує проблему. Куди важливіше налаштувати процес таким чином, щоб проблема не повторилась. Практика показує: системне хаос-тестування якісно змінює комунікацію в команді та підвищує ефективність роботи.
Пам’ятаймо про недоліки
Збільшення ресурсів. Додатковий етап тестування тягне за собою додаткові витрати по часу і грошах. До того ж Chaos Testing часто об’ємніший, ніж інші QA-задачі. Хоча для ІТ-фахівців користь від змін очевидна, та далеко не кожен власник бізнесу погодиться на впровадження стресових перевірок у власному продукті. Доведеться зібрати аргументи, щоб переконати замовника в необхідності такого тестування на благо проєкту.
Складність виконання. Знадобляться глибокі знання в кількох сферах: програмування, тестування, DevOps, досвід роботи з хмарними середовищами, вміння працювати зі складною архітектурою. І цей список далеко не вичерпний. Щоб тестування пройшло ефективно, потрібно прописати якісні тестові сценарії, налаштувати їх і правильно ввести в систему без зайвих ризиків. На додачу — ще й грамотно проаналізувати результати. Адже у великих розподілених системах причини збоїв можуть бути неочевидними.
Ризик виникнення реальних збоїв. Створюючи помилки в межах хаос-тестування, обов’язково контролюйте їх. Ви не просто запускаєте «хаос» — ви маєте розуміти, в якому напрямку він розвивається та як повернути все назад. Врахуйте, що такі перевірки часто відбуваються на продакшені, і неприпустимо «обвалити» всю систему. Тож треба ретельно готувати бекапи й інші страховки для швидкого відновлення.
Потреба у зміні пріоритетів. Іноді за результатами хаос-інжинірингу зміни доходять до рівня архітектури. Це знову ж тягне за собою додаткові витрати. Замовник може зауважити: зараз важливіші, наприклад, нові фічі. Але який в них сенс, якщо система не працює, як треба? Враховуйте, що й тут потрібен час на обговорення пріоритетів. Але це виправдано, якщо врешті всім потрібен якісний продукт.
Не панацея від проблем, але спробувати варто
Хаос-тестування доцільне в проєктах, яким критично важлива безперебійна робота. Зокрема, цифровим продуктам у сфері фінансів, охорони здоров’я, державним реєстрам, соціально важливій інфраструктурі, телекомунікаціях, логістиці, кібербезпеці, для стрімінгів та eCommerce.
У деяких випадках хаос-тестування зайве. Наприклад, без нього можуть обійтися невеликі статичні проєкти, без тисяч залежностей, із застарілою архітектурою, яку вже не модифікувати. Навряд чи варто ретельно перевіряти стабільність продуктів із низькими вимогами доступності.
Це стосується внутрішніх сервісів компаній, простих корпоративних та освітніх платформ, MVP. І хоч Chaos Testing — не панацея від усіх можливих проблем на проді, але однозначно це дієвий спосіб прокачати на стійкість свою команду і продукт загалом.
Про те, як підготуватися до хаос-тестування, які інструменти для цього потрібні та які етапи передбачає процес, розповімо в наступному матеріалі.
Анна Молодцова, Performance QA Engineer в NIX
Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
