QA-Логия

Controlled fault injection в продакшене: как проверять fallback-логики без расширения blast radius Fallback часто есть в коде и unit-тестах, но ломается в реальном prod из-за таймаутов, ретраев, кешей, circuit breaker, feature flags или форматов ошибок. Типичная ошибка QA и dev - проверять только happy path деградации в staging. Что стоит проверять - timeout pricing-api: checkout берет последнюю валидную цену из кеша - 5xx от recommendations: показываем дефолтный блок, а не пустой экран - 200 с invalid schema: не падаем на десериализации - частичная деградация downstream: основной user journey завершается Как не расширить blast radius - allowlist вместо “1% пользователей”: synthetic user, test tenant, internal account, request header - scope на одну зависимость и endpoint, а не “ломаем сеть сервису” - TTL 5-15 минут, чтобы fault выключился сам - kill switch без деплоя - rate limit, чтобы не создать лавину ретраев - dashboards до старта: fallback hit rate, latency, error rate, saturation, бизнес-метрика flow Минимальный guardrail

if fault_enabled(req, "pricing-api"):
    raise TimeoutError("controlled fault")

try:
    price = pricing.get(item_id)
except TimeoutError:
    metrics.inc("fallback.pricing")
    price = cache.last_valid(item_id)

Практический сценарий Гипотеза: если pricing-api не отвечает до 2 секунд, checkout использует cached price и заказ завершается. Запускаем только для synthetic user, одного endpoint, одного fault, TTL 10 минут, с trace id и stop condition: p95 latency выше лимита, error rate растет или ошибки вышли за targeted cohort. Предупреждение: не встраивайте fault injection хаотично в бизнес-код. Лучше слой клиента, middleware, proxy, service mesh или платформенный механизм, иначе стоимость поддержки быстро превысит пользу. Вывод: controlled fault injection ценен не “поломкой прода”, а проверяемым, ограниченным и наблюдаемым доказательством, что fallback реально снижает риск инцидента.