non-functionalchaos-engineeringresiliencereliabilityqa

Chaos Engineering для QA: как намеренно ломать систему, чтобы проверить отказоустойчивость

«У нас всё с ретраями и фейловером» — звучит надёжно, пока не случится реальный сбой и не выяснится, что ретраи добивают упавшую базу, а фейловер не настроен. Chaos Engineering — это про то, чтобы узнать правду заранее: контролируемо внести сбой и проверить, выживает ли система. Не «найти баг наугад», а проверить конкретную гипотезу об устойчивости. Разберём, как это делать осмысленно и безопасно, и при чём тут QA.

Это не «сломать прод», а проверить гипотезу

Ключевое отличие от вандализма — steady-state hypothesis. Сначала фиксируешь, как выглядит «нормально», в измеримых терминах (бизнес-метрика или SLI: заказы/мин, p99 latency, error rate). Затем формулируешь гипотезу: «при отказе кэша система продолжит обслуживать заказы с той же частотой». И только потом вносишь сбой и проверяешь, удержалась ли метрика. Если да — уверенность подтверждена; если нет — нашёл слабое место до того, как его нашёл прод. Канон — Principles of Chaos Engineering.

Blast radius: начинать с малого и уметь откатить

Главное правило безопасности — минимальный радиус поражения. Не «убить весь кластер», а один инстанс. Не 100% трафика, а 1%. И обязательно — кнопка аборта: эксперимент должен мгновенно останавливаться и откатываться, если метрика проседает сильнее порога.

  • Начинай в стейджинге, переходи в прод только когда уверен в инструментах отката.
  • Ограничь область: один сервис, одна зона, доля пользователей.
  • Зафиксируй порог автоматической остановки заранее (abort conditions).
  • Предупреди команду и согласуй окно — это эксперимент, а не диверсия.

Какие сбои вносят

  • Смерть инстанса/пода — внезапно убить процесс (классика Netflix Chaos Monkey): проверяем авто-восстановление и перебалансировку.
  • Latency injection — добавить задержку в ответ зависимости: проверяем таймауты и то, не складываются ли задержки в каскад.
  • Сетевые сбои — packet loss, обрыв, недоступность порта: ведёт ли себя клиент с ретраями разумно.
  • Отказ зависимости — отключить БД, кэш, сторонний API: есть ли graceful degradation и fallback.
  • Исчерпание ресурсов — забить CPU, память, диск, пул коннектов: что деградирует первым и предсказуемо ли.
  • Зональный/региональный отказ — выключить целую AZ: реально ли работает фейловер.

Инструменты

  • Chaos Monkey (Netflix) — случайно убивает инстансы; с этого всё началось.
  • Gremlin — коммерческая платформа: CPU/память/сеть/latency/shutdown с управлением blast radius и abort.
  • Chaos Mesh и Litmus — хаос для Kubernetes (под-килл, network/IO faults, stress).
  • AWS Fault Injection Service и Azure Chaos Studio — нативный fault injection в облаке.
  • Toxiproxy (Shopify) — прокси, добавляющий latency/обрывы; удобно для локальных и CI-экспериментов.

Game Days — учения для команды

Game Day — это запланированное мероприятие, где вы вносите сбой и всей командой наблюдаете, как реагируют и система, и люди. Проверяется не только код: успел ли сработать алерт, нашли ли дежурные нужный дашборд, понятен ли раннбук, кто принимает решение об откате. Часто самое ценное открытие Game Day — не в коде, а в том, что алерт не настроен или раннбук устарел.

При чём тут QA

Chaos Engineering — естественное расширение нефункционального тестирования, и QA тут не сторонний наблюдатель:

  • Проектировать эксперименты: какая гипотеза, какой сбой, какая метрика, какой порог отката.
  • Валидировать graceful degradation: при отказе зависимости фича выключается мягко, а не роняет всё приложение.
  • Проверять ретраи и circuit breakers: нет ли retry-storm, размыкается ли цепь.
  • Проверять наблюдаемость: сбой виден на дашборде, алерт сработал, в трейсе видно, где упало.
  • Документировать находки как баги/риски и прогонять повторно после фикса.

Чего НЕ делать

  • Хаос без гипотезы и без метрики — это просто поломка, а не эксперимент.
  • Эксперимент без мониторинга — не увидишь ни проблему, ни момент, когда пора жать abort.
  • Сразу 100% прода без kill switch — так теряют деньги и доверие.
  • Хаос в пик нагрузки или во время релиза — выбирай окно осознанно.
  • Не предупредить команду — паника и реальный инцидент вместо учений.

Чек-лист безопасного хаос-эксперимента

  • Сформулирована гипотеза в терминах измеримой метрики (SLI/бизнес)
  • Зафиксирован steady state «до»
  • Минимальный blast radius (1 инстанс / 1% трафика / 1 зона)
  • Есть кнопка аборта и автоматические условия остановки
  • Включён мониторинг и алерты на время эксперимента
  • Команда предупреждена, согласовано окно (не релиз, не пик)
  • Начали со стейджинга, в прод — только с проверенным откатом
  • Проверены graceful degradation, ретраи, circuit breaker
  • Зафиксирован результат: гипотеза удержалась или нет
  • Найденные слабые места заведены и перепроверены после фикса

Итог

Отказоустойчивость, которую не проверяли намеренным сбоем, — это предположение, а не факт. Chaos Engineering превращает «вроде переживём» в проверяемую гипотезу: фиксируешь норму, ломаешь по чуть-чуть с кнопкой аборта, смотришь, держится ли метрика. Для QA это логичный следующий шаг после нагрузочного и observability — проверять не только «работает ли под нагрузкой», но и «выживает ли, когда часть отвалилась».

Источники: Principles of Chaos Engineering, Gremlin — Chaos Engineering: history & principles, Netflix Chaos Monkey, Chaos Mesh, AWS Fault Injection Service, Toxiproxy.