Уявіть, що ви будуєте будинок і перевіряєте, чи рівно стоять стіни, чи не тече дах, чи відкриваються двері. Однак ви не тестуєте, як будинок поводиться під час надзвичайних ситуацій, наприклад, вибуху газу чи землетрусу, а лише сподіваєтеся, що цього не станеться.
Більшість IT-команд тестує застосунки лише за ідеальних умов і не враховує, що може статись у разі збою. Chaos Testing змінює цей підхід: замість уникнення збоїв ця практика передбачає їх навмисне створення для підвищення стійкості системи.
Щоб проілюструвати це, наведу приклад із власного досвіду. Ця історія показує, чому хаос-тестування необхідне для будь-якої команди.
ІСТОРІЯ, ЯКА ЗМІНИЛА МІЙ ПІДХІД
Кілька років тому я працювала QA Engineer у команді над edtech-застосунком. Усе було стандартно: користувачі реєструвалися, завантажували файли, працювали з даними. Ми були впевнені у стабільній роботі застосунку, поки не виникла проблема.
ЯК МИ СТВОРИЛИ ПРОБЛЕМУ СВОЇМИ РУКАМИ
На початку проекту команда прийняла просте, але критичне рішення: зберігати всі завантажені користувачами файли (фото, PDF-документи, експорти) безпосередньо в базі даних у вигляді BLOB або Base64-рядків. Без стискання, оптимізації чи автоматичного очищення. Файли просто додавались у таблицю attachments і залишалися там.
На перший погляд це здається безпечним, але далі виникли проблеми:
- Місяць 3. Моніторинг показав, що диск із базою даних заповнений на 72%. DevOps збільшив EBS-том через консоль AWS. Після кількох кліків проблему було вирішено, і команда заспокоїлася.
- Місяць 5. Проблема повторилася, і том знову збільшили кілька разів. DevOps уже не пам'ятав початкового розміру — 100 ГБ чи 200 ГБ. До цього моменту обсяг досяг півтерабайта, а проблема стала виникати все частіше. Водночас зростали й щомісячні витрати на хмарне сховище.
- Місяць 6. Користувачі масово завантажили великі документи, і вільне місце на диску бази даних вичерпалося.
Після цього почалися серйозні проблеми.
ЩО СТАЛОСЯ, КОЛИ ДИСК ЗАПОВНИВСЯ
Коли на диску не залишилося вільного місця, застосунок не лише перестав приймати файли, а й повністю припинив роботу.
- База даних (PostgreSQL) не змогла створити тимчасовий файл для виконання навіть найпростішого запиту.
- Автовакуум (очищення старих даних) зупинився через неможливість запису.
- Система логування не могла записати помилку.
- Кеш (Redis) впав через неможливість зробити резервну копію на диск.
У результаті вся система зупинилася: не працювала авторизація, не відкривалися сторінки, API повертав помилки 500. Користувачі бачили не повідомлення про тимчасову недоступність, а повний колапс.
Команда витратила 4 години на відновлення: вручну очищала таблиці через SQL-запити, видаляла старі BLOB-об'єкти, вимикала сервіси, налаштовувала екстрене вивантаження файлів у S3. Через два місяці ситуація повторилася ще раз. Замість вирішення причини ми лише збільшували обсяг диска.
Ціна ігнорування
Цей кейс обійшовся нам у:
- Тисячі доларів на постійне збільшення хмарних томів (які ми, до речі, продовжували оплачувати навіть тоді, коли вони були напівпорожні після чисток).
- Тижні сукупної роботи з аварійного відновлення.
- Нерви команди, яка щоразу кидала всі справи, щоб «рятувати прод».
- Довіру користувачів, які бачили, що сервіс падає.
Найголовніше: цієї ситуації можна було уникнути завдяки простому експерименту. Як QA Engineer, я переконана, що найкращі помилки — ті, які виявлені до релізу, а не під час інциденту.
ЯК CHAOS TESTING ВРЯТУВАВ БИ НАС
Якби наша команда впровадила Chaos Testing на другому місяці розробки, це виглядало б так:
Крок 1. Запустити експеримент на тестовому середовищі
Разом із DevOps ми написали б простий скрипт, який штучно заповнює диск тестового сервера файлами. У хмарному середовищі це ще простіше: можна створити окремий невеликий том, підключити його та заповнити, не впливаючи на основну систему. Це не впливає на реальних користувачів і не створює ризиків. Мета — перевірити, що станеться, якщо місце закінчиться.
Крок 2. Побачити слабкі місця за 5 хвилин
Експеримент дозволив би виявити три критичні проблеми:
| Що можно було б побачити | Чому це проблема |
|---|---|
| Застосунок падає повністю, а не показує повідомлення про помилку | Код не обробляє виняток бази даних No space left on device або disk full |
| Файли зберігаються в БД у вигляді BLOB без стискання | Кожен мегабайт одразу роздуває розмір бази даних, ускладнює бекапи та сповільнює запити. А ми платимо хмарному провайдеру за зберігання «сирих» даних |
| Старі файли ніколи не видаляються | 80% даних у таблиці attachments — це «мертві» архіви, до яких ніхто не звертається місяцями, але ми продовжуємо платити за їхнє зберігання щомісяця |
Крок 3. Виправити це до того, як це вплине на користувачів
Ось які рішення можливо було б впровадити одразу:
- Додати обробку помилок. Під час заповнення диска вимикається лише функція завантаження файлів, а решта застосунку продовжує працювати. Користувач отримує чітке повідомлення: «Сервіс тимчасово недоступний — спробуйте пізніше».
- Впровадити автоматичну оптимізацію. Кожен файл перед збереженням стискається (наприклад, зображення зменшуються без втрати якості). Розмір файлів зменшується у 3–4 рази, що, відповідно, знижує витрати на хмарне сховище.
- Впровадити політику життєвого циклу (Lifecycle Policy). Файли, старші за 30 днів, автоматично переміщуються у дешеве хмарне сховище (наприклад, AWS S3 Glacier або Deep Archive), а на локальному диску залишаються лише актуальні дані. Це дозволяє знизити витрати на зберігання ще на 80%.
Результат: тестування і виправлення зайняли б лише два тиждня замість пів року на усунення наслідків і постійне збільшення хмарних томів.
ЩО ТАКЕ CHAOS TESTING (ПРОСТИМИ СЛОВАМИ)
Ось просте визначення:
Chaos Testing — це практика навмисного внесення збоїв у систему, щоб переконатися, що вона витримає несподівані проблеми в реальному світі.
Замість сподівань, що «все працюватиме», створюється аварійна ситуація у безпечному середовищі та аналізується реакція системи.
Проста аналогія
Систему можна порівняти з людиною.
- Звичайне тестування — перевірка, чи може людина пробігти 5 км у сприятливих умовах.
- Chaos Testing — перевірка, чи зможе вона пробігти ті ж 5 км у складних умовах, наприклад, за обмеженого руху або під час несприятливої погоди.
Цей підхід може здатися суворим, але саме так система навчається працювати у реальних умовах, де збої є звичайним явищем.
ЗВІДКИ ВЗЯЛАСЯ ЦЯ ПРАКТИКА?
Найвідоміший приклад — Chaos Monkey від Netflix. Цей інструмент випадково вимикав сервери у робочому середовищі Netflix, навмисно створюючи збої.
Інженери Netflix дійшли висновку: якщо система витримує вимкнення серверів у робочий час, вона буде стійкою і під час реальної аварії. Це схоже на вакцинацію: введення слабкої дози «хвороби» допомагає виробити імунітет.
ЯК ПРОВЕСТИ СВІЙ ПЕРШИЙ ЕКСПЕРИМЕНТ (ПОКРОКОВА ІНСТРУКЦІЯ)
Не рекомендується одразу запускати Chaos Monkey у продакшн-середовищі, як це робить Netflix. Коли ви пропонуєте ідею хаос-тестування команді чи менеджеру, підкресліть, що це допомагає заощадити на інцидентах і витратах завдяки виявленню проблем на ранньому етапі — ще до впровадження системи в роботу.
Запропонуйте почати з тестового або staging-середовища, наприклад, одного безпечного експерименту з простим сценарієм. Це дозволить команді швидко переконатись у перевагах підходу без ризиків. Ось базовий план для початківців:
Крок 1. Визначте «стабільний стан»
Визначте, як виглядає система у стабільному стані. Наприклад:
- Час відповіді API < 200 мс.
- Кількість помилок < 1%.
- Диск заповнений не більше ніж на 70%.
Крок 2. Сформулюйте гіпотезу
Сформулюйте гіпотезу: якщо відбудеться збій X, система має поводитися за очікуванням. Наприклад:
- «Якщо на диску закінчиться місце, застосунок перестане приймати файли, але не впаде повністю»
- «Якщо один сервер вимкнеться, користувачі не помітять нічого, оскільки трафік перерозподілиться»
Крок 3. Проведіть експеримент (у тестовому середовищі!)
Оберіть один тип збою і створіть його штучно:
- Місце на диску закінчилося — заповніть диск тестовими файлами (як у наведеному прикладі). У хмарному середовищі можна створити окремий том і заповнити його, щоб не ризикувати основними даними.
- Висока затримка мережі — додайте штучну затримку за допомогою інструментів типу tc (traffic control).
- Відмова сервісу — просто вимкніть один із мікросервісів або базу даних.
- Різке зростання навантаження — запустіть одночасно велику кількість запитів (за допомогою інструментів на кшталт JMeter або k8).
Крок 4. Проаналізуйте результати
Порівняйте отримані результати з гіпотезою:
- Якщо система поводиться очікувано, це означає, що вона готова до такого збою.
- Якщо система впала або поводиться непередбачувано — це вказує на слабке місце. Його слід виправити і повторити експеримент.
Крок 5. Автоматизуйте
Після освоєння ручних експериментів варто автоматизувати їх у процесі CI/CD. Наприклад, перед кожним релізом запускати тест, який імітує заповнення диска. Якщо застосунок падає, реліз зупиняється до усунення проблеми.
ЧАСТІ ЗАПИТАННЯ ПОЧАТКІВЦІВ
«А чи не нашкодить це продакшену?»
Так, якщо експеримент проводити у бойовому середовищі без підготовки. Тому рекомендується починати з тестового або staging-середовища. Netflix може дозволити собі Chaos Monkey у продакшені завдяки великій команді й численним системам дублювання. Для більшості команд це поки не є необхідним.
«А що, якщо моя система і так працює добре?»
«Працює добре» — це лише припущення до першого збою. Стійкість системи можна перевірити лише експериментально, особливо в хмарному середовищі, де постійне збільшення кількості дисків призводить до значних витрат.
«Це ж дорого і складно?»
Навпаки. Перший експеримент може зайняти лише 15 хвилин: написання скрипту для заповнення диска на тестовому сервері — це кілька рядків коду. Виявлення слабких місць перед інцидентом дозволяє суттєво заощадити на витратах у хмарі.
Рекомендуємо курси по темі
ТЕСТУЙТЕ НА СТІЙКІСТЬ, ЩОБ УНИКНУТИ ЗБОЇВ
Chaos Testing — це не навмисне руйнування системи, а підготовка до збоїв і здатність ефективно на них реагувати. Це також спосіб оптимізувати витрати, особливо у хмарних середовищах.
У нашій команді постійне заповнення дисків призводило до регулярного збільшення томів в AWS, що пояснювалося зростанням обсягів проєкту. Насправді це спричиняло неконтрольовані витрати, яких можна було уникнути завдяки оптимізації.
Передбачити всі збої неможливо, але можна підготувати систему до них, проводячи контрольовані експерименти. Це також допомагає оптимізувати хмарний бюджет.
Сьогодні у нашому CI/CD-процесі є обов'язковий крок — chaos-disk-fill. Перед кожним релізом диск у тестовому середовищі заповнюється для перевірки стійкості системи. З того часу не було жодного збою через заповнення диска, а витрати на зберігання зменшилися у п'ять разів.
ПЕРШИЙ КРОК МОЖНА ЗРОБИТИ ВЖЕ СЬОГОДНІ
Варто визначити найуразливіший компонент (диск, базу даних або мережу) — і протестувати його у тестовому середовищі. Це дозволить виявити приховані проблеми й оптимізувати витрати.
Після усунення цих проблем система стане надійнішою. Це значно ефективніше, ніж покладатися на випадковість або необмежений хмарний бюджет.
