Распределённые системы
Retry amplification: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — математика fan-out, metastable-петли, jitter, retry budget и circuit breaker под нагрузкой.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь посреди инцидента — не определение для заучивания, а число fan-out, которое надо посчитать, и фикс, который надо проранжировать, пока бэкенд горит.
Цель
Убедись, что связываешь математику retry-fan-out, metastable-петлю и лестницу защит — jitter, retry budget, circuit breaker, идемпотентность, проброс дедлайна — тот синтез, к которому вёл весь юнит.
Викторина
Completed
Запрос проходит через 5 слоёв сервисов, и каждый слой делает 3 ретрая при сбое. Сколько в худшем случае вызовов придёт к самой глубокой зависимости на один сбойный запрос и почему это застаёт врасплох?
Heads-up Ретраи умножаются, а не складываются. Ретрай каждого слоя заново прогоняет всю цепочку ретраев под ним, поэтому амплификация — это retries^depth (3⁵ = 243), а не retries × depth (15).
Heads-up Каждый слой со своей политикой ретраев добавляет множитель. Тройка листа — лишь самый внутренний член произведения 3 × 3 × 3 × 3 × 3.
Heads-up Амплификация — про повторение одного сбойного пути на каждом уровне на пути вниз, а не про одновременные независимые сбои. Один сбойный запрос сам по себе даёт 3⁵.
Викторина
Completed
8-секундный failover базы, запустивший инцидент, завершился 30 минут назад, но флот всё ещё лежит под retry storm. Что на самом деле держит его внизу?
Heads-up Определяющее свойство metastable failure — что он сохраняется после устранения триггера. Охота за уже зажившим триггером — классическая потеря времени; реальная причина — самоподдерживающаяся петля ретраев.
Heads-up Новый баг не нужен. Сама петля обратной связи ретраев (таймауты → ретраи → больше нагрузки → больше таймаутов) удерживает систему в деградированном устойчивом состоянии.
Heads-up Metastable failure обычно не самоисцеляется, потому что нагрузка, которая его держит, не падает. Операторам приходится сбрасывать нагрузку, открывать breaker'ы или рестартить уровни, чтобы вернуть систему в здоровое состояние.
Викторина
Completed
Команда добавляет ретраи с фиксированным интервалом (жди 200 мс, ретрай, жди 200 мс, ретрай) на каждом слое, чтобы «быть помягче». В следующий blip зависимости простой оказывается хуже прежнего. Почему?
Heads-up Более длинный фиксированный интервал всё равно ресинхронизирует толпу; все просто топают вместе на более медленном такте. Дефект — отсутствие случайности (jitter), а не конкретная длина интервала.
Heads-up Ретраи с jitter и budget реально помогают — большинство транзиентных blip'ов успешны со второй попытки. Проблема тут в фиксированном тайминге без jitter, а не в существовании ретраев.
Heads-up Синхронный всплеск нанесён себе самим фиксированным интервалом. Jitter разносит попытки и доказуемо снижает и общее число вызовов, и время восстановления против фиксированного или чистого exponential backoff.
Викторина
Completed
Ты уже выкатил exponential backoff с full jitter на каждом слое, но полный outage зависимости всё равно гонит бэкенд к ~80x нормальной нагрузки. Чего jitter не купил и что ты добавляешь?
Heads-up Jitter лишь расцепляет клиентов во времени. Он никогда не ограничивает суммарное число ретраев — именно для этого и существует retry budget.
Heads-up Подъём лимита на запрос увеличивает попытки, а не уменьшает. Чтобы ограничить амплификацию, нужен бюджет на весь флот (ретраи как доля трафика), а не счётчик на запрос.
Heads-up Retry budget ~10% превращает неограниченный геометрический рост в максимум ~10% сверх базовой нагрузки даже в полном outage. 80x — ровно то, что budget и предотвращает.
Викторина
Completed
Circuit breaker открывается, когда частота сбоев к зависимости пересекает порог. Что это даёт такого, чего не даёт один retry budget?
Heads-up Breaker — не постоянный рубильник. После cooldown он переходит в half-open: проба успешна — он закрывается и трафик возобновляется; проба сбоит — он снова открывается. Восстановление автоматическое.
Heads-up Breaker не трогает внутренности зависимости. Он мешает вызывающему слать обречённые запросы, что косвенно даёт бэкенду восстановиться, убрав нагрузку ретраев.
Heads-up Breaker, budget и backoff с jitter — дополняющие слои: jitter формирует тайминг, budget ограничивает объём, breaker даёт окно нулевого трафика для восстановления. Нужны все три, а не один вместо других.
Викторина
Completed
Просматривая retry-конфиг сервиса, ты находишь, что он ретраит любой сбой до 3 раз — включая 400, 409-конфликты и неидемпотентные POST — без проброса дедлайна. Какие два правила он нарушает и почему они важнее всего под нагрузкой?
Heads-up Больше ретраев на non-retryable-ошибках и мёртвых запросах лишь умножает амплификацию. Фикс — меньше и умнее: только retryable-ошибки, только в пределах живого дедлайна.
Heads-up 400 — детерминированная клиентская ошибка; её ретрай всегда снова сбоит и тратит вызов бэкенда. Ретраить надо только транзиентные retryable-ошибки (таймауты, 503, сброс соединения).
Heads-up Без проброса дедлайна слой спокойно ретраит запрос, чей вызывающий уже затаймаутился — чистая бесполезная работа, дающая лишь больше нагрузки, что и питает metastable storm.
Итог
Сквозная линия — одно дерево решений: ретраи складываются умножением (retries^depth, поэтому 3⁵ = 243), и крошечная доля ошибок превращается в самонанесённый DDoS; затем storm самоподдерживается как metastable failure ещё долго после устранения триггера. Защиты ложатся от самой широкой к самой тонкой — jitter расцепляет толпу во времени, retry budget ~10% ограничивает объём, circuit breaker даёт окно нулевого трафика ретраев — а неоспоримые правила: ретраить только идемпотентные операции и retryable-ошибки и пробрасывать дедлайн, чтобы ни один слой не ретраил уже мёртвый запрос.