Хаос-тестирование 429, повторов и изоляции арендаторов до потери выручки

429 — управляющий сигнал, а не обычная ошибка

RFC 6585 определяет 429 Too Many Requests для ограничения скорости и допускает заголовок Retry-After со временем ожидания. Клиент, который немедленно повторяет запрос, превращает защитный сигнал провайдера в дополнительную нагрузку.^[1]

Безопасная политика классифицирует сбои. Ошибка валидации постоянна. 429 можно повторить после задержки провайдера. При timeout состояние побочного эффекта неизвестно. 503 может означать перегрузку. Частично переданный поток иногда невозможно незаметно воспроизвести.

Timeout должен укладываться в бюджет пользовательской операции. Повторы должны быть ограничены, использовать экспоненциальный backoff с jitter и происходить на одном выбранном слое. AWS документирует эти шаблоны, потому что синхронные повторы способны превратить небольшой сбой в полную аварию.^[3][4]

Повторы умножаются между слоями

Google SRE приводит конкретное предупреждение: если слои базы, backend, frontend и JavaScript делают по четыре попытки, одно действие пользователя может создать 64 обращения к базе. Повторы на нескольких слоях умножают попытки, а не складывают их.^[2]

Та же глава моделирует backend на 10 000 QPS, получающий 10 100 QPS. Сто отклонённых запросов повторяются, поднимая следующую секунду до 10 200; retry-нагрузка растёт, пока полезная работа с первой попытки сокращается. Retry budget ограничивает это усиление.

График воспроизводит документированную мультипликативную структуру, а не наблюдавшийся инцидент клиента CapacityLab.

Один шумный арендатор не должен занять всех workers

Общие пулы соединений, очереди workers, квоты model-провайдера и retry budgets связывают арендаторов между собой. Один клиент, перегружающий дорогой метод, может занять concurrency, нужную несвязанным клиентам, даже когда их собственный трафик обычный.

Bulkheads разделяют дефицитные ресурсы. Concurrency, вместимость очереди, бюджеты токенов по арендаторам и справедливое планирование сохраняют перегрузку локальной. Общий admission control всё равно защищает сервис при достижении суммарной безопасной capacity.

Idempotency не даёт повтору стать второй покупкой или задачей. Stripe сохраняет первый результат для idempotency key, а AWS описывает идентификаторы клиентских запросов как основу безопасно повторяемых API.^[6][5]

• Лимиты concurrency по операциям до общего пула зависимости.
• Очередь и retry budgets по арендаторам со справедливым планированием.
• Idempotency keys, сохраняющиеся через timeout и рестарт worker.
• Состояние circuit breaker, которое не синхронизирует всех callers в один шторм проб.
• Dead-letter и expiry для работы, которая уже не выполнит обещание пользователю.

Переведите сбой в риск для выручки

Технический error budget становится полезным для решений, когда связан с продуктовыми операциями. Если каждую минуту приходит 120 операций с маржинальным доходом $18, полный пятнадцатиминутный простой создаёт риск $32 400. Это не зафиксированный убыток: повторы, отложенная конверсия, возвраты и восстановление клиентов меняют итог.

Цель модели — расстановка приоритетов. 429 при преобразовании изображения может ухудшить представление; 429 при подтверждении платежа способен удерживать товар и выручку. Fault tests должны следовать критичности бизнеса, а не моде инфраструктуры.

Grafana k6 документирует xk6-disruptor для fault injection, а Google SRE прямо рекомендует проверять перегрузку и graceful degradation. Запускайте steady-трафик до сбоя, во время него и через восстановление.^[7][2]