QA, который ломает прод не случайно
Кажется, после последних постов я сам стал забывать, что всё-таки я QA. Поэтому сегодня хочу рассказать про такую практику, как хаос-тестирование: зачем оно нужно, когда может быть полезно и какие есть готовые решения, чтобы потыкаться руками.
Если коротко, хаос-тестирование — это когда мы специально ломаем систему, чтобы проверить, как она переживает сбои.
Не «а давайте уроним всё и посмотрим, что будет», а аккуратный инженерный эксперимент: — отключить один инстанс сервиса; — добавить задержку в сеть; — оборвать соединение с базой; — ограничить CPU или память; — проверить, что будет при деградации внешней зависимости.
Звучит немного дико, но на самом деле идея очень QA-шная. Мы ведь и так постоянно спрашиваем: «А что будет, если пользователь сделает не то?» «А что будет, если API вернёт ошибку?» «А что будет, если данные не придут?» Хаос-тестирование задаёт тот же вопрос, только на уровне инфраструктуры и распределённых систем.
Зачем это нужно?
Во-первых, чтобы проверить не happy path, а реальную устойчивость системы. На бумаге у нас может быть retry, fallback, circuit breaker и graceful degradation. Но пока зависимость реально не начала тормозить или падать, мы не знаем, работает ли это как задумано. Во-вторых, чтобы найти скрытые связи между сервисами. Иногда оказывается, что падение «неважного» сервиса внезапно ломает критичный сценарий. Не потому что кто-то плохо написал код, а потому что система со временем обросла неочевидными зависимостями. В-третьих, чтобы команда не паниковала во время настоящего инцидента.
Если мы уже видели похожий отказ в контролируемом эксперименте, то в проде меньше магии и больше понятного плана действий.
Когда это может быть полезно: — у вас микросервисная архитектура; — есть критичные пользовательские сценарии; — сервисы зависят от внешних API, очередей, баз, кэшей; — команда уже умеет в мониторинг и алерты; — хочется проверить не только «работает», но и «нормально деградирует».
Важный момент: хаос-тестирование не стоит начинать с прода и кнопки «сломать всё».
Нормальный старт выглядит скучнее: 1. Выбираем один понятный сценарий. 2. Формулируем гипотезу: «если база станет медленной, пользователь увидит понятную ошибку, а сервис не положит соседей». 3. Ограничиваем радиус поражения. 4. Запускаем эксперимент. 5. Смотрим метрики, логи, алерты и поведение продукта. 6. Чиним найденное.
Из инструментов, которые можно посмотреть: — Chaos Monkey — классика от Netflix, скорее как концептуальная отправная точка; — Gremlin — коммерческая платформа для chaos engineering; — LitmusChaos — open source для Kubernetes; — Chaos Mesh — ещё один популярный вариант для Kubernetes; — Pumba — можно ломать Docker-контейнеры локально; — Toxiproxy — удобен, чтобы симулировать сетевые проблемы между сервисами.
Мне кажется, для QA это довольно интересная зона роста. Потому что здесь тестирование выходит за пределы «проверить фичу по требованиям» и начинает отвечать на более взрослый вопрос: а что будет с продуктом, когда реальный мир начнёт вести себя плохо?
Всем чистого кода и бэклога без багов!
