Chaos Engineering English: Vocabulary for GameDays and Resilience Testing (англійською)

Хаотична інженерія - це практика навмисного введення помилок в систему, щоб виявити слабкості, перш ніж вони спричинять справжні інциденти. Команди, які практикують хаотичне проектування, мають певний словник, і написання чіткого документа проектування експерименту вимагає його знання. Цей посібник містить основні терміни і шаблони зв’ язку, що використовуються у хаотичних системах.

Основні інженерні споруди

Term	Definition
Steady-state hypothesis	A description of the system’s normal behaviour that you expect to hold true during the experiment
Blast radius	The scope of potential impact if the experiment causes unexpected harm
Fault injection	Deliberately introducing failures (latency, errors, resource exhaustion) into a system
GameDay	A scheduled event where a team runs chaos experiments together, often in production
Abort condition	A pre-defined trigger that stops the experiment if things go wrong unexpectedly
Hypothesis	Your prediction of how the system will behave under the introduced fault
Observability	The ability to understand the internal state of a system from its external outputs
Resilience	The ability of a system to absorb failures and continue to function
Fallback	A backup behaviour that activates when the primary path fails

Гіпотеза стабільного стану

Гіпотеза стаціонарного стану є найважливішою концепцією в хаосній інженерії. Перед запуском будь- якого експерименту вам слід визначити, як виглядає « нормальна » ситуація, щоб ви могли визначити, чи спричинив експеримент проблему.

** Формат: ** Гіпотеза стабільного стану повинна бути ** вимірюваною ** і ** спостережуваною **.

** Хороші приклади: **

• “АПІ замовлення повертає HTTP 200 для 99.9% запитів з затримкою p99 менше 200 мс.”
• “Служба рекомендацій повертає непорожній список принаймні для 95% запитів.”

** Слабкі приклади: **

• • “Система працює нормально.” * (не вимірюваний)
• • “Користувачі можуть здійснювати покупки.” * (неможливо безпосередньо спостерігати без інструментів)

Описуючи радіус вибуху

Радіус вибуху визначає, наскільки обережні повинні бути ваші експерименти. Зменшити радіус вибуху перед розширенням.

Blast radius	Meaning
Single instance	Only one service instance is affected
Availability zone	An entire data centre zone is simulated as failed
Production traffic	Real user traffic is affected
Read-only traffic	Only read operations are affected, writes are protected

** Фрази для обговорення радіусу вибуху: **

• • “Ми розпочнемо з радіусу вибуху однієї істоти і розширимо до AZ, як тільки ми будемо впевнені в гіпотезі стаціонарного стану.” *
• “Радиус дії вибуху має бути обмежений внутрішнім трафіком для першого запуску, щоб захистити платників.”

Запис документа проекту експерименту

Документ з проектування експерименту хаосу зазвичай містить:

1. Цель — Почему вы проводите этот эксперимент?
2. Гіпотеза стабільного стану — Як виглядає нормальна ситуація?
3. ** Введення помилки ** — Яку помилку ви введете?
4. ** Радіус вибуху ** - Який максимальний потенційний діапазон удару?
5. Условия прерывания — Когда вы прекратите эксперимент?
6. ** Спостереження ** — Які показники ви будете контролювати?
7. ** Очікуваний результат ** — Що, на ваш погляд, станеться?
8. ** Фактичний результат ** — Що насправді сталося? (Заповнено після експерименту)

Ціль експерименту:

• “Перевірити, чи платіжна служба зручно знижує швидкість, коли служба виявлення шахрайства стає недоступною, перевіряючи, чи транзакції повертаються до черги безпечного утримання, а не зазнають невдачі з помилкою 500.” *

Словник слов’янських мов

GameDay - це спільне вправу, де команда проводить експерименти хаосу разом. Мова, що використовується до, під час і після GameDay, відповідає певним шаблонам.

** Перед матчем: **

• “Ми проведемо GameDay у четвер — ціль — рекомендації для спільноти.”
• “Будь ласка, переконайтеся, що ваш телефонний дзвінок активний і що ви переглянули умови скасування.”

** Під час матчу: **

• • “Було запущено введення помилки. «Світло в темряві» (англ
• “Ми досягли умови переривання експерименту - ми зупиняємо експеримент зараз.”
• • “Система відновлюється, як очікувалося — статичні показники повертаються до базового стану.” *

После матча:

• “Гіпотеза була сформульована - резервна поведінка була правильно активована протягом 3 секунд.”
• • “Ми виявили раніше невідомий режим аварії: автоматичний виключник не було налаштовано на рівні кешу.” *

Приклади висловлювань

1. «Гіпотеза стабільного стану для цього експерименту полягає в тому, що API-шлюз підтримує затримку p99 нижче 400 мс і рівень успішності вище 99% під нормальним навантаженням»
2. «Ми обмежимо радіус вибуху до однієї зони доступності і виключимо виробничий трафік для першої ітерації цього експерименту»
3. «Умова скасування викликається, якщо рівень помилок на будь-якій службі, що звертається до клієнта, перевищує 5% протягом більше 30 секунд»
4. «Під час GameDay, введення помилки виявило, що логіка повторних спроб в службі сповіщення не дотримувалася стану обривника, що призвело до громового стада під час відновлення»
5. «Експеримент підтвердив нашу гіпотезу: коли служба запасів недоступна, сторінка продукту деградує грациозно, показуючи кешовану інформацію про запаси, а не повертаючи сторінку помилки»

Національний мовний стандарт: підготовка до впровадження

Для розробників, які вивчають професійну англійську, особливо в такій області, як Chaos Engineering, де точність є найважливішою, розуміння тонких фраз може бути настільки ж важливим, як і оволодіння основними концепціями. Це не просто про те, щоб знати * що * сказати; це про те, щоб передати це значення чітко і ефективно, мінімізуючи неоднозначність, яка може призвести до неправильного тлумачення або марних зусиль. Поширеною проблемою для носіїв мови, яка не є рідною, є боротьба з часто непрямими способами обговорення технічних питань - особливо при описі проблем і запропоновані рішення. Мова стійкості не завжди проста, сильно покладаючись на гіпотетичні і потенційні сценарії.

Розглянемо сценарій: Під час перегляду коду, старший інженер залишає коментар на запиті на витяг: «Ця функція, здається, демонструє несподівану поведінку під високим навантаженням. Вивчіть проблеми з одночасністю — можливо, у вас виникають умови перегонів. ” Розробник, який не знайомий з певною термінологією, може легко неправильно інтерпретувати цей звіт як простий звіт про помилку. Фраза “виявляючи несподівану поведінку” навмисно нечітка, встановлюючи гіпотезу, яка потребує перевірки. Аналогічно, «гоночні умови» не відразу очевидні для когось, хто не глибоко знайомий з концепціями паралельного програмування. Ключовим тут є визнання цієї навмисної непрозорості - це тактика, яку використовують досвідчені інженери хаосу, щоб заохочувати глибше дослідження і активне мислення. Це вимагає більше, ніж просто виправлення негайного симптому; це вимагає розуміння основних системних вразливостей.

Інша часто зустрічається ситуація в каналах Slack, можливо, при повідомленні про проблему, виявлену під час імітації GameDay: «Ми викликали каскадну помилку, пов’язану з обмеженнями з’єднання з базою даних. Радіус вибуху, здається, впливає на виклики API для автентифікації користувача. » Знову ж таки, такі терміни, як « каскадна помилка » і « радіус вибуху » мають значення, яке виходить за рамки їх буквального визначення. « Радіус вибуху » стосується не лише фізичних пошкоджень; він позначає * обсяг * впливу — наскільки далеко проблема може поширитися у системі. При описі цього у PR- описі ви можете сказати: « У ході моделювання було виявлено вразливість, за якої перевищення 10 одночасних з’ єднань з базою даних призвело до перевищення часу очікування API розпізнавання, що свідчить про радіус вибуху, який впливає приблизно на 30% сеансів користувача ». Цей рівень деталізації є ключовим для передачі значення і потенційних наслідків.

Нарешті, пам’ятайте, що документація - особливо при описі * гіпотези стаціонарного стану * - часто сильно опирається на умовну мову. Фрази на кшталт «за звичайних обставин» або «при відсутності зовнішнього втручання» часто використовуються для створення сценаріїв. Вони не мають бути обмежуючими; вони розроблені для встановлення базису, проти якого відхилення можуть бути надійно виміряні і проаналізовані. Це про те, щоб підготувати сцену для контрольованого експерименту.

# Example: Simulating database connection overload using `stress` (a common tool)
stress -c 15 -t 60 --vm-bytes 2G --io-blocksize 4k --vm-max-threads 100 /path/to/application

Цей приклад, хоча і простий, демонструє вид моніторингу і ведення журналу, який є критичним при перевірці гіпотези стаціонарного стану. Спостереження за використанням ресурсів під час цього імітованого перевантаження надає вам змогу оцінити потенційний вплив виявленої вразливості.