Chaos Engineering: чому відмова спливає в проді
Сервіс виходить у продакшн, пройшовши навантажувальні тести, і виглядає здоровим: вузли живі, метрики рівні, алерти мовчать.
Але зв’язки між компонентами майже ніколи не перевіряють на відмову — клієнт до черги без обмеження повторів, спільний пул з’єднань на кілька залежностей, синхронний виклик у середині критичного сценарію. Кожен такий зв’язок залишається неперевіреною залежністю і до першого збою поводиться як надійний.
Відмова в продакшні рідко виглядає як «впав один вузол». Частіше це ланцюгова реакція: недоступною стає одна зона, повтори множать потік запитів, черга переповнюється, і падає вже те, що з початковою причиною не пов’язане.
Стійкість сервісу визначається не середнім часом відповіді, а поведінкою на межі — коли залежність відповідає повільніше звичайного або відповідає помилкою.
Команда дізнається про це від користувачів, а не від моніторингу: алерти налаштовані на явне падіння, а усереднені метрики згладжують деградацію, поки вона ще локальна.
Гіпотези про причину починають перевіряти прямо на живому контурі — тобто на тих самих користувачах, а розбір іде за логами після факту.
Розбираємо, як це закривається: експерименти на відмову запускаються в контрольованому контурі, повторюються на кожному релізі й перетворюють здогадки на перевірювані твердження.
Для цього ми використовуємо Chaos Mesh — сценарії відключення вузла, затримки та помилок залежності описуються декларативно й відкочуються за таймером, не залишаючи слідів у проді.
Керовані відмови: що змінюється в експлуатації
Поки відмови не вносять навмисно, система перевіряється лише користувачами. Зростання затримок, таймаути до зовнішніх сервісів, деградація репліки бази виявляються за зверненнями до підтримки, а не за графіком.
Сценарії Chaos Mesh перевертають цей порядок: мережеві затримки, обрив зв’язку із залежністю, падіння екземпляра сервісу, тиск на диск відтворюються за розкладом з обмеженим радіусом — за міткою або простором імен, — і експеримент зупиняється автоматично, щойно спостережуваний показник виходить за поріг.
Насамперед змінюється час виявлення деградації. Пороги оповіщень калібруються на реально внесених збоях, а не на здогадках: якщо зростання затримки не піднімає тривогу, це видно в той самий прогін.
Там же перевіряються таймаути й політики повторів — зазвичай саме там налаштування розходиться з фактичною поведінкою системи під навантаженням.
Далі зникає цілий клас відмов: каскадні повтори, відсутній запобіжник на залежності, що деградує, таймаут, коротший за реальний час відповіді. Це перестає доживати до продакшну, бо ламається в контрольованих умовах.
Готовність до збоїв стає вимірюваною — частка експериментів, що пройшли без виходу за встановлені значення.
Скорочення простою тримається на часі відновлення. Перемикання при відмові вузла або зони, поведінка черги при недоступності обробника, порядок дій чергового відпрацьовуються завчасно — в інциденті не витрачають перші хвилини на з’ясування того, як система поводиться при відмові.
Chaos Engineering: режими експериментів та обмеження
Chaos Mesh описує перевірку як окремий об’єкт: селектори визначають, які екземпляри потрапляють під удар, режим задає сам сценарій відмови, а вікно експерименту — тривалість і розклад. Звідси три рівні впливу: одна репліка, сервіс загалом, ізоляція сегмента.
Чим ширша зона ураження, тим вища цінність перевірки й жорсткіші вимоги до відкату — експеримент має зніматися за таймером, а не за пам’яттю чергового. Нижче — чим режими відрізняються і де в кожного межа.
| Режим експерименту | Коли підходить | Обмеження |
|---|---|---|
| Відключення одного екземпляра | Перевіряємо, що сервіс переживає втрату репліки і трафік переходить на живі | Не показує, як поводитиметься система при відмові сервісу загалом |
| Мережева деградація: затримка, втрати | Перевіряємо таймаути, повтори, каскадні деградації | Потребує тонкого налаштування, інакше самі повтори добивають сусідні сервіси |
| Ізоляція сегмента загалом | Перевіряємо відмовостійкість зони й поведінку кворуму | Потрібні резервні потужності та план евакуації; у сервісів зі станом ризик втрати даних |
| Навантаження на ресурси вузла | Дивимося, як сервіс поводиться при нестачі обчислювальних ресурсів | Заважає сусіднім робочим навантаженням — запускаємо на виділених вузлах |
| Відмова зовнішньої залежності | Перевіряємо реакцію на недоступність стороннього сервісу | Зовнішню систему так не перевірити, лише її відмову на нашій стороні |
Є й загальні обмеження методу. Перевірки відтворюють відмови всередині кластера, але не відмову фізичного обладнання й не втрату зони доступності загалом.
Для сервісів зі станом і кворумом широкий сценарій узгоджуємо окремо, а запускаємо через зупинку й відновлення: перервати експеримент можна однією командою.
Етапи впровадження: від аудиту до передачі зміні
Етапи впровадження будуються так, щоб керована відмова спочатку перевірялася там, де її наслідки оборотні, і лише потім допускалася до робочого контуру.
Завдання першого проходу — не «зламати й подивитися», а отримати карту залежностей і заздалегідь описане очікуване поводження системи на кожен вплив. Нижче — послідовність, яку проходимо з командою замовника.
- Аудит інфраструктури та інвентаризація залежностей. Збираємо карту сервісів, зовнішніх викликів і черг, позначаємо єдині точки відмови та ділянки без резервування — без цього сценарії б’ють повз ціль.
- Схема відмов і матриця гіпотез. На кожен вузол формулюємо гіпотезу: що станеться при недоступності екземпляра, зростанні затримки відповіді, відмові зони або бази. Фіксуємо очікувану поведінку та допустимий рівень деградації.
- Налаштування сценаріїв з обмеженням радіуса. Вплив адресується за мітками, охоплення обмежуємо часткою екземплярів, додаємо автоматичну зупинку за граничним часом і за відхиленням ключових метрик.
- Прогін у безпечному контурі. Перші запуски — на тестовому середовищі та на копії продуктивного трафіку, щоб відкалібрувати пороги й переконатися, що сценарій не виходить за межі вибірки.
- Робота в продакшні в узгоджені вікна перевірок. Один сценарій за раз, черговий на зв’язку, готовий план відкату; спостерігаємо за метриками, трасуваннями й логами, критерії зупинки прописані заздалегідь.
- Розбір результатів. Зводимо час виявлення й відновлення, дивимося, які гіпотези не підтвердилися, і виправляємо першопричини: повтори запитів, перевірки живості, ліміти, маршрутизацію.
- Передача черговій зміні. Віддаємо каталог сценаріїв, чек-лист запуску й зупинки, пороги оповіщень і власників — далі зміна проводить перевірки самостійно за регламентом.
Що залишається у вашому репозиторії після робіт
Роботи закінчуються не звітом у пошті, а набором файлів, який живе поруч із вашими маніфестами й оновлюється тими самими комітами. Інакше за пів року ніхто не згадає, який сценарій валив платіжний контур і чому його вимкнули. Що залишається на руках:
- Документація за сценаріями — на кожен експеримент: гіпотеза, цільові об’єкти, тривалість, очікувана поведінка системи та ознака, за якою збій вважається відтвореним. Описи лежать як код, а не у вікі.
- Схеми залежностей — карта сервісів із зазначенням, що деградує при відмові вузла, де немає резерву і які ділянки тримають навантаження при частковій втраті ємності.
- Конфігурації перевірок — пороги метрик, за яких експеримент переривається автоматично, і правила відновлення вихідного стану після прогону.
- Розмежування доступів — ролі на запуск експерименту, на зміну сценарію й на перегляд результатів, щоб запуск не був доступний кожному з правом деплою.
- Регламент зупинки — хто уповноважений перервати прогін, як це робиться і за який час система повертається до норми.
- Інструкції для чергових — коротка пам’ятка: що робити при спрацюванні перевірки, куди дивитися, які алерти вважати очікуваними під час експерименту.
- Регламент розбору — як фіксується результат: гіпотеза підтвердилася чи ні, які зміни в архітектуру та моніторинг за цим слідують.
Кожен пункт версіонується, проходить рев’ю й видаляється разом із застарілим сценарієм. Так набір не перетворюється на звалище інструкцій, а залишається робочим інструментом чергової зміни.
Кейс: як знайшли відмову зони до аварії
Сервіс жив у трьох зонах доступності, але пережити втрату однієї не міг: балансувальник продовжував слати запити в ізольовану зону, клієнти чекали відповіді до таймауту, а повторні спроби добивали решту.
Аварія розтяглася майже на 40 хвилин, хоча відмова зачепила лише третину потужностей. Причина — поведінку системи при відмові зони ніхто не перевіряв: конфігурації вивіряли на папері, а не під навантаженням.
Що змінили
Сценарії відмов описали як код і прогнали спочатку в тестовому контурі, потім на бойовому — у вікно низького навантаження, через Chaos Mesh. Набір простий: ізоляція зони, затримка відповідей, втрата частини пакетів, відмова вузла.
У кожного експерименту — умова зупинки при виході метрик за межі та автоматичний відкат після завершення.
Метрики до та після
До впровадження при ізоляції зони частка успішних відповідей падала до 60%, перемикання займало хвилини, відновлення потребувало ручного втручання.
Після серії експериментів і правок перевірок готовності, таймаутів і повторних спроб відмова перестала виходити за межі однієї зони: перемикання вкладається в десятки секунд, частка успішних відповідей тримається вище 99%, відновлення займає 3–5 хвилин. Стійкість під навантаженням тепер вимірюється до релізу, а не з’ясовується в аварію.
Що робити, якщо кластер уже працює під навантаженням
Працюючий кластер під навантаженням — не перешкода для перевірок: вони запускаються без зупинки сервісу, але не «на всьому одразу».
<cite>Chaos Mesh</cite> окреслює зону ураження, за яку експеримент не вийде за жодного розвитку подій: конкретний контур, група реплік за міткою, тип відмови та тривалість. Критичний шлях обробки запитів у перевірку не потрапляє.
Далі — поетапне розширення. Перший прогін іде на одній репліці в тестовому середовищі, потім на частці робочих реплік в одиниці відсотків, і лише після підтвердженої стійкості частка зростає.
Окремо фіксується, які сценарії перевіряються на кожному кроці: спочатку відмова окремого пода, потім відмова вузла, потім деградація зв’язку між сервісами.
Між кроками дивляться не «чи все живе», а конкретні метрики: частку помилок, час відповіді на хвості розподілу, глибину черг.
Умови зупинки задаються до запуску, а не по ходу. Автопауза за таймером, вимкнення за флагом, зняття експерименту при виході метрик за поріг — усе це спрацьовує без чергового інженера біля пульта.
До цього додається заздалегідь прописаний відкат: яким способом повертаються налаштування і за який час контур приходить у вихідний стан.
Саме з цих трьох речей — меж, кроків і стоп-умов — складається безпечний експеримент. Він дає те, заради чого все затівається: гіпотези про відмови перевіряються на реальному трафіку в робочі години. Опишіть ваш контур і відмови, які викликають питання, — повернемося з планом перевірок та оцінкою.
Обмеження методу та технічні сумніви
Метод працює там, де ми контролюємо інфраструктуру, і перестає працювати на межі. Поди, мережу всередині кластера, томи й конфігурації ми ламаємо керовано; зовнішню чергу, платіжний шлюз або чужу СУБД так не перевіриш.
Для них сценарій перебудовують: недоступність емулюють на своїй стороні — таймаут, обрив з’єднання, відповідь із помилкою — і дивляться, як застосунок її переживає.
Тут легко отримати хибну картину. Якщо затримку виставити на всіх вихідних викликах, сервіс почне падати через наш же стенд, і висновок «архітектура не тримає» виявиться неправильним.
Ін’єкцію тому обмежують однією залежністю, задають вікно й позначають експеримент, щоб відокремити його ефект від фонової деградації.
Окрема стаття — хибні спрацювання. Перевірки живості бачать ту саму картину, що й реальний збій, і запускають перезапуски поверх експерименту: сигнал тоне в шумі. Допомагають заздалегідь зняті показники норми, ізоляція контуру й пауза авто-відновлення на час вікна.
Права на запуск обмежують жорстко: можливість інжектувати відмову дорівнює можливості вронити продуктивний контур. Її видають ролями на конкретні простори імен, а для сценаріїв із широким радіусом підключають підтвердження другим інженером.
Чи можна запускати експерименти на робочому контурі?
Так, але з обмеженнями: частка зачеплених екземплярів, вікно в години низького навантаження, запобіжник за часом і поріг за помилками, за якого ін’єкція знімається без участі оператора.
Сценарії, що зачіпають спільні залежності, спочатку проганяють на стенді з тим самим профілем трафіку.
Обговорімо задачу: з чого починається перевірка
Перший крок — не готовий список експериментів, а ваша розповідь про задачу. Достатньо своїми словами: які сервіси критичні, де проходить межа між контурами, що вже ламалося і яка відмова обходиться дорожче за все. Важливий і стан спостережуваності — без метрик і трасування перевірка перетворюється на ворожіння.
Далі ми повертаємося з оцінкою та планом. До них входить:
- карта залежностей: що саме тримає сервіс і як він поведеться при відмові кожної ланки
- межі експерименту — окремий контур, ізоляція та обмеження зони впливу
- пілотний сценарій із критеріями зупинки та правилами швидкого відкату
- план робіт за етапами зі строками, точками контролю та складом команди
- перелік доопрацювань спостережуваності, без яких заміри безглузді
- формат звіту після пілота: знайдені дефекти та їхній пріоритет
Експерименти ставимо у вашому контурі — на Chaos Mesh, якщо він уже використовується, або на інструменті під ваш стек.
Опишіть задачу у вільній формі — повернемося з оцінкою, планом і переліком перших сценаріїв, які дадуть максимальний ефект.
