Словник для інженерів хаосу

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

---

Інженерія хаосу

** Хаотична інженерія ** це практика запуску контрольованих експериментів на системі, щоб збудувати впевненість у здатності системи витримувати турбулентні, несподівані умови у виробництві.

“Хаотична інженерія не про випадкове руйнування речей - це про запуск принципових експериментів, які перевіряють конкретні гіпотези про стійкість системи.”

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

---

Стабільний стан

** Стабільний стан ** є нормальним, здоровим станом роботи системи — визначеним за вимірюваними метриками, такими як частота помилок, пропускна здатність і затримка. Експеримент хаосу перевіряє, що система повертається до стабільного стану після перерви.

“Перед запуском експерименту, ми визначаємо наш стабільний стан: затримка p99 менше 200 мс, рівень помилок менше 0.1%, і пропускна здатність більше 1000 запитів на секунду.”

• “Успішний експеримент хаосу — це такий, у якому система зберігає або повертається до стабільного стану, незважаючи на введену помилку. Якщо це не так, ми знайшли слабкість.»*

---

Експериментальна гіпотеза

** Експериментальна гіпотеза ** в інженерії хаосу має такий формат: « Якщо ми введемо X- вимушену помилку, система збереже стабільний стан завдяки Y- захисту ». Гіпотеза є конкретною, фальсифікованою і пов’ язаною з вимірюваними результатами.

• “Наша гіпотеза: якщо ми припинимо роботу 50% екземплярів платіжної служби, балансувальник навантаження буде маршрутизувати трафік до решти екземплярів протягом 30 секунд, і рівень помилок не перевищуватиме 1%.” *
• “Ми помилялися щодо нашої гіпотези. Коли ми припинили екземпляри, перевірки стану тривали 90 секунд, щоб почати — набагато довше, ніж ми припускали. “*

---

Несправність ін’єкції

** Введення помилки ** — це акт навмисного введення помилки у систему, наприклад, вбивство процесу, введення затримки мережі, заповнення диска або пошкодження файла налаштувань. Інструменти для введення помилок включають Chaos Monkey, Gremlin, і LitmusChaos.

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

---

Радіус вибуху

** Радіус вибуху ** стосується обсягу впливу — скільки користувачів, служб або компонентів буде задіяно у разі виникнення певної помилки. Контроль радіусу вибуху є безпечним методом в інженерії хаосу: починайте з малого і збільшуйте поступово.

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

---

День гри

** Game day ** це заплановане, спрощене вправу з хаосної інженерії, в якій інженерна команда навмисно викликає невдачі і практикує відповідь на них — подібно до пожежної дії.

• “Ми проводимо квартальний день гри, де ми імітуємо різноманітні сценарії невдач: невдачу зони доступності, зовнішній відключення API і вибори лідерів бази даних. Кожна команда повинна виявити, відповісти і відновити в рамках узгодженого SLA. ”* “Дні ігор виявляють прогалини в процесах управління, попередження та реагування на інциденти, які інакше з’являлися б лише в реальному інциденти - в найгірший можливий момент.”

---

Turbulence

** Турбулентність ** є ширшою метафорою, яку використовують у хаосній інженерії для опису непередбачуваних, хаотичних умов виробництва — несподіваних піків трафіку, апаратних порушень, мережевих розділів і програмних помилок, які поєднуються таким чином, що не передбачалося під час тестування.

• “Наше середовище перевірки стабільне. Наше виробниче середовище - це турбулентність. Хаотична інженерія допомагає нам закрити прогалини між тим, що ми думаємо, що станеться, і тим, що насправді відбувається»

---

Перервати умови

** Умови скасування ** (або умови зупинки) є попередньо визначеними порогами, які автоматично зупиняють експеримент хаосу, якщо ситуація погіршиться за очікуваний результат. Вони є механізмом безпеки, щоб запобігти контрольованим експериментам від перетворення на неконтрольовані відключення.

• “Ми встановили умову скасування: якщо кількість помилок перевищить 5%, експеримент буде автоматично зупинено, а введену помилку буде відкинуто.” *
• “Ніколи не виконувати експеримент хаосу без умов скасування. Суть у тому, щоб знайти слабкі місця — а не викликати інцидент».*

---

Спостережливість в інженерії хаосу

Експерименти хаосу є безглуздими без спостережливості — здатності вимірювати поведінку системи під час і після експерименту. Вам потрібні метричні дані, журнали та сліди, щоб перевірити чи вірна гіпотеза.

• “Перед запуском експерименту переконайтеся, що стек спостережуваності встановлено. Якщо ви не можете виміряти стабільний стан, ви не можете визначити, чи пройшов експеримент чи ні.”*

---

Практичні фрази для хаосних інженерів

• “Давайте визначимо стабільний стан перед тим, як ми розробимо експеримент.”
• “Гіпотеза: якщо ми вводимо 200 мс затримки на платіжному шлюзі, поток оплати граціозно погіршується з видимим для користувача попередженням, а не безшумною помилкою.”
• “Ми розпочнемо з радіусу 10% від трафіку і розширимо, якщо система зможе витримати.”
• “День гри заплановано на наступний четвер. Команди повинні переглянути свої runbooks заздалегідь.”
• • “Умова скасування: загальна кількість помилок перевищує 2%. Якщо ми вдаримо по цьому, ми негайно зупинимося»
• “Експеримент пройшов успішно - система зберігала стабільний стан протягом усього періоду введення збою.”

---

Лексика хаос-інженерії відображає філософію дисципліни: систематична, наукова і безпечна. Освоєння цих термінів допоможе вам розробляти жорсткі експерименти, повідомляти про ризики для продукту і бізнес-зацікавлених сторін, а також будувати справді стійкі системи, які переживають турбулентність реальних виробничих середовищ.

Навигація хаосу: Принцип для інженерів

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

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

Давайте розглянемо деякі ключові слова:

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

2. Стабільний стан: Бажання операційного стану для системи. Це не обов’язково ідеальне, але це базова лінія, яку ми намагаємося захистити від розладів. Підтримання цього «стабільного стану» вимагає постійної обережності і проактивного тестування. Варто відзначити, що «стабільний стан» рідко є по-справжньому статичним — завжди буде певний рівень «турбулентності».

** 3. Гіпотеза експерименту: ** Кожне введення помилки * повинно * починатися з чіткої гіпотези - що ми намагаємося дізнатися? Наприклад, « Якщо ми введемо цей пік затримки під час годин пік, чи буде рівень кешування все ще ефективно зменшувати вплив? » Це стосується формулювання перевіряних передбачень.

** 4. Введення помилок: ** Навмисне введення помилок або помилок в систему для спостереження за її поведінкою і ідентифікації вразливостей. Це не про випадкове руйнування речей; це про систематичне дослідження стійкості системи.

5. День гри: Вказаний період часу, протягом якого ви активно стежите за роботою вашої системи, зосереджуючись на потенційних точках введення помилок. Это фаза выполнения вашего эксперимента, требующая повышенной осведомленности и быстрого реагирования.

** 6. Турбулентність: ** Представляє звичайні коливання і варіації в системі - речі, які не обов’язково є помилками, але все ще можуть перервати операції, якщо вони ескалуються або поєднуються з введеними помилками. Розгляньте затримку мережі, велике навантаження користувача або несподівані схеми трафіку.

# Example: Introducing Latency via a Network Emulator (using `tc`)

# This command simulates increased network latency to test caching performance.
# Requires root/sudo privileges and knowledge of your network topology.
#  This is for illustrative purposes only - use with caution!
sudo tc qdisc add dev eth0 root netem delay 100ms loss 5%

** 7. Ціль часу відновлення (RTO) і відновлення в момент часу (PITR): ** Це * операційні * метрики, а не лексика хаосної інженерії сама по собі, але життєво важливо розуміти разом з філософськими концепціями. RTO визначає, скільки часу знадобиться для відновлення служби після переривання роботи. PITR стосується відновлення системи до певного моменту часу, часто корисне, коли підозрюється пошкодження даних.

Тепер розглянемо практичний сценарій:

** Повідомлення Slack: ** « Привіт, команда, запускаємо експеримент « день гри » з новою схемою бази даних. Мы вводим задержку и спорадические ошибки соединения, чтобы проверить наши пороги оповещения. Радіус вибуху зараз обмежений панеллю звітів - ми будемо уважно стежити за будь-якими каскадними помилками. Гіпотеза: Якщо ми збільшимо рівень помилок понад 10%, автоматичне відновлення не буде запускатися достатньо швидко

** PR Description: ** “Реалізація функції X, введення контрольованого введення збою за допомогою синтетичного генерування трафіку для перевірки стійкості до сценаріїв високої навантаження. Моніторинг ключових показників - затримка, рівень помилок і використання ресурсів - допоможе внести корективи в конфігурацію стаціонарного стану. ”

Зрозуміти ці терміни і постійно вдосконалювати своє мислення навколо стабільності системи і розладів - це те, що піднімає вас від простого управління системами до * інженерної * стійкості.