{
  "index": 67,
  "slug": "editorial-2026-02-field-resilience",
  "title": "Когда retry усиливает отказ: как ограничить каскад запросов",
  "excerpt": "Медленный внешний API превращает повторы, fallback и репликацию в новый источник нагрузки. Разбираем, где поставить единую границу, как проверить трассу и когда остановиться.",
  "contentHtml": "<p>Внешний API начинает отвечать за 3 секунды вместо 200 миллисекунд. Ваш сервис не падает сразу: он повторяет запрос, пробует другую реплику и запускает fallback. Через минуту очередь растёт, рабочие потоки заняты ожиданием, а внутренние запросы получают таймауты. Ошибка внешней зависимости превращается в отказ собственного приложения.</p>\n<p>Цена каскада состоит не только из лишних запросов. Команда теряет связь между исходным запросом и его повторами. Логи показывают несколько похожих ошибок. Метрики смешивают первичную работу и повторную. Пользователь получает задержку вместо ответа, а перегруженный сервис продолжает принимать новую работу. Если система не знает, где остановиться, каждая защитная мера увеличивает масштаб отказа.</p>\n<p>Главный тезис прост: retry, fallback и репликация должны подчиняться одному явному бюджету. Его нужно применять до расширения маршрута. У повторной попытки должен быть один владелец, у fan-out — целочисленный предел, у fallback — имя и конечный результат. Когда бюджет исчерпан, система должна выполнить terminal action. Она не должна незаметно создавать ещё один уровень попыток.</p>\n<figure><img src=\"/assets/editorial/2026/resilience-2026-limit-feedback-loop.svg\" alt=\"Каскад отказа: ошибка зависимости проходит через retry, репликацию и fallback, а единая граница ограничивает расширение маршрута\" loading=\"lazy\" /><figcaption>Единая граница отделяет ограниченное восстановление от нового витка нагрузки. Красная ветка заканчивается окончательным действием, а не очередной попыткой.</figcaption></figure>\n<h2>Как возникает усиление отказа</h2>\n<p>Представим два логических запроса. Для каждого сервис делает первичный вызов и разрешает одну дополнительную попытку. Если каждый слой владеет retry, число физических вызовов растёт быстрее, чем ожидает владелец верхнего слоя. Edge может повторить вызов адаптера, а адаптер — повторить тот же вызов внешнего API. В результате одна ошибка получает два независимых счётчика.</p>\n<p>Репликация добавляет ширину. Правило «попробовать все доступные реплики» не ограничивает работу. При задержке или частичном отказе оно запускает несколько запросов до того, как первый результат станет понятен. Fallback добавляет ещё одну ветку. Если fallback сам умеет повторять вызов, его нельзя считать запасным результатом: это второй retry-контур.</p>\n<p>Ограниченный маршрут устроен иначе. Edge владеет двумя попытками. Каждая попытка выбирает одну реплику. Fallback получает управление только после именованного исхода, например `optional-result-unavailable`, и не создаёт retry. После второй попытки система возвращает заранее определённый деградированный результат или явно отказывает. Такая схема не обещает восстановить полный ответ. Она ограничивает стоимость отказа и оставляет понятную трассу.</p>\n<h2>Что должно быть названо в контракте</h2>\n<p>Сначала назовите отказ. `temporary-timeout` отличается от ошибки контракта или отказа авторизации. Повтор допустим только для исходов, для которых владелец операции подтвердил безопасность и полезность повторения. HTTP 503 сообщает о временной неспособности обработать запрос, но сам по себе не доказывает, что конкретную операцию можно безопасно повторить. То же относится к заголовку `Retry-After`: он передаёт подсказку о времени, но не назначает владельца retry.</p>\n<p>Затем назовите владельца. В системе может быть несколько компонентов, которые технически способны повторять запрос. Это не значит, что каждый должен это делать. Зафиксируйте один слой, его `maxAttempts`, список повторяемых исходов и момент, когда он прекращает работу. Если два слоя имеют `enabled: true`, проверьте их совместно: верхний повтор может повторять уже повторённую работу.</p>\n<p>После этого назовите предел маршрута. `maxFanout: 1` означает, что одна попытка выбирает одну реплику. Список из трёх реплик не даёт права обращаться ко всем трём одновременно. Если предел не задан, его нельзя вывести из количества имён в списке. Неявный предел не является защитой.</p>\n<p>Последним назовите terminal action. Это может быть деградированный ответ, ошибка с понятным кодом или сохранение результата частичной операции. Он зависит от предметной области. Для операции с финансовым побочным эффектом нельзя бездумно возвращать «неполный успех». Важен сам принцип: после terminal action нет скрытого retry и нового fallback.</p>\n<h2>Пример ограниченного маршрута</h2>\n<p>Ниже приведён самодостаточный JavaScript-пример. Он работает только с переданным объектом и не вызывает сеть. Числа показывают форму контракта, а не рекомендуемые значения для production. Перед переносом в сервис их нужно заменить правилами конкретной операции и подтвердить безопасность повтора.</p>\n<pre><code>const route = {\n  retry: {\n    owner: 'edge',\n    maxAttempts: 2,\n    retryable: ['temporary-timeout'],\n  },\n  replicas: {\n    names: ['primary-a', 'primary-b', 'primary-c'],\n    maxFanout: 1,\n  },\n  fallback: {\n    name: 'named-summary',\n    trigger: 'optional-result-unavailable',\n    addsRetry: false,\n    output: 'degraded-summary',\n  },\n  limit: {\n    point: 'before-route-expansion',\n    onExhaustion: 'return-degraded-result',\n  },\n};\n\nfunction nextStep(outcome, attempt) {\n  if (route.retry.retryable.includes(outcome) &&\n      attempt &lt; route.retry.maxAttempts) {\n    return { action: 'retry', owner: route.retry.owner };\n  }\n\n  if (outcome === route.fallback.trigger) {\n    return { action: 'fallback', name: route.fallback.name };\n  }\n\n  return { action: route.limit.onExhaustion };\n}\n\nconsole.log(nextStep('temporary-timeout', 2));\n// { action: 'return-degraded-result' }</code></pre>\n<p>Функция не измеряет задержку и не проверяет реальную доступность реплики. Она показывает важную границу: после второй попытки результат не переходит к новому retry. Для реальной реализации нужно дополнительно передать идентификатор логического запроса, сохранить причину остановки и связать события одной трассой. Не следует считать этот вывод доказательством устойчивости сервиса.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика каскада без смешения гипотез</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Число внешних вызовов выше числа пользовательских запросов</td><td>Повторяют несколько слоёв</td><td>Сопоставить owner и attempt в trace</td><td>Оставить одного владельца retry</td></tr><tr><td>При одном timeout растёт нагрузка на все реплики</td><td>Не задан fan-out на попытку</td><td>Посчитать выбранные реплики для одного logical request</td><td>Задать целочисленный maxFanout и проверить его до расширения маршрута</td></tr><tr><td>Fallback запускается после каждой ошибки</td><td>Не различены retryable и terminal outcomes</td><td>Проверить trigger и список повторяемых исходов</td><td>Назвать trigger и запретить fallback создавать retry</td></tr><tr><td>В trace появляются действия без владельца</td><td>Логика скрыта в библиотеке или промежуточном адаптере</td><td>Найти первый span, который создаёт новый вызов</td><td>Добавить owner и событие расхода бюджета</td></tr><tr><td>После исчерпания попыток запрос продолжает жить</td><td>Нет terminal action или отмены in-flight работы</td><td>Проверить последнюю запись trace и состояние очереди</td><td>Вернуть явный результат и прекратить дальнейшее расширение</td></tr><tr><td>Два сценария дают разные цифры, но считаются сопоставимыми</td><td>Различаются logical load или failure injection</td><td>Сверить baseline key, число запросов и исход отказа</td><td>Разделить сценарии и не усреднять результаты</td></tr></tbody></table></div>\n<h2>Порядок проверки</h2>\n<ol><li>Зафиксируйте один логический запрос и его ожидаемый результат. Отделите его от физических вызовов к зависимостям.</li><li>Назовите failure injection: цель, исход и область действия. Не заменяйте конкретный timeout общим словом «сбой».</li><li>Найдите всех владельцев retry. Оставьте один слой, если операция не требует другой схемы с доказанным бюджетом.</li><li>Задайте `maxAttempts` и список `retryable` outcomes. Для каждого исхода проверьте идемпотентность и смысл повтора.</li><li>Опишите реплики и `maxFanout`. Убедитесь, что одна попытка выбирает не больше разрешённого числа направлений.</li><li>Опишите fallback: имя, trigger, результат и отсутствие собственного retry. Если ветка делает несколько вызовов, вынесите её в отдельный ограниченный контракт.</li><li>Поставьте limit point до расширения маршрута. Запишите, что происходит при исчерпании бюджета.</li><li>Соберите trace из событий одного logical request. Каждый новый вызов должен иметь причину, владельца и номер попытки.</li><li>Повторите отрицательные сценарии: второй retry owner, пустой fallback, `maxFanout: null`, отсутствующий limit и несовпадающий baseline.</li><li>Сверьте результат с тем же сигналом, который обнаружил проблему. Не заменяйте проверку заявлением о будущей эффективности.</li></ol>\n<h2>Отрицательный путь важнее зелёного примера</h2>\n<p>Ограничение считается рабочим только тогда, когда оно останавливает неправильные конфигурации. Включите retry у edge и adapter одновременно. Проверка должна вернуть статус о нескольких владельцах, а не выбрать один молча. Удалите имя fallback. Результатом должна стать остановка с причиной, а не переход к безымянному ответу. Замените `maxFanout: 1` на `null`. Проверка обязана остановить сценарий до выбора реплик.</p>\n<p>Удалите limit point. Не подставляйте его из `maxAttempts`: это разные свойства. `maxAttempts` ограничивает конкретный счётчик попыток. Limit point отвечает за порядок: бюджет должен быть проверен до того, как начнётся новое расширение маршрута. Если сценарий использует семь логических запросов вместо двух или другой failure injection, его нельзя сравнивать с базовым примером. Сначала выровняйте входы, затем сравнивайте trace.</p>\n<p>Отдельно проверьте постоянную ошибку контракта. Её нельзя автоматически считать временным timeout. Повтор не исправит несовместимую схему и может увеличить нагрузку. Для неё нужен другой путь: быстрый отказ, карантин сообщения или согласованная миграция. Универсальный retry по любому статусу — частая причина каскада.</p>\n<h2>Что покажет трасса</h2>\n<p>Полезная трасса отвечает на четыре вопроса: какой логический запрос начал работу, какой исход получил каждый вызов, кто решил повторить и где система остановилась. Для ограниченного примера последовательность может выглядеть так: `logical-01 → primary-a → temporary-timeout`; `edge → retry budget 2 → 1`; `logical-01 → primary-b → complete`. Для второго запроса: `primary-c → optional-result-unavailable`; затем `named-summary → degraded-summary`.</p>\n<p>Такой список не является метрикой производительности. Он нужен, чтобы восстановить решение. Если в нём есть вызов, которого нет в retry plan, fallback или replication policy, модель неполна. Если последний span заканчивается ошибкой, но очередь продолжает принимать работу того же класса, причина может находиться выше: лимит стоит слишком поздно, а не просто имеет неправильное число.</p>\n<p>Связывайте повтор с логическим идентификатором, но не записывайте в trace секреты и пользовательские данные. Внешний trace id помогает найти событие, но не является доказательством личности или разрешением на доступ. Наблюдаемость должна объяснять расход бюджета и границу остановки.</p>\n<h2>Ограничения применимости</h2>\n<p>Описанный механизм не выбирает оптимальный timeout. Он не знает пропускную способность сервиса, размер очереди, стоимость подключения, deadline клиента и долю ошибок зависимости. Маленький `maxAttempts` может быть правильным для одного чтения и опасным для другой операции. Значение нужно выводить из контракта и capacity модели, а не копировать из примера.</p>\n<p>Механизм не подтверждает идемпотентность. Повтор чтения обычно отличается от повтора платежа, создания заказа или отправки письма. Если запрос мог изменить состояние, сначала определите ключ идемпотентности и границу подтверждения. При отсутствии такого контракта безопаснее остановиться, чем включить retry ради доступности.</p>\n<p>Механизм не заменяет отмену in-flight работы. Если верхний слой уже вернул terminal action, нижний вызов может продолжать занимать соединение. Нужны deadline, cancellation и проверка поведения клиента. Также отдельной проверки требуют circuit breaker, rate limit, очередь и политика деградации. Единый бюджет не устраняет эти компоненты, но не даёт им бесконтрольно складывать новые попытки.</p>\n<p>Примеры в статье фиксируют значения только для объяснения механизма. Они не содержат production-трафик, реальные latency, измерения восстановления или обещания SLA. Нельзя писать в отчёте «сервис выдерживает отказ» только потому, что объект прошёл проверку. Доказательство требует воспроизводимого сценария в целевой системе и согласованного критерия результата.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Для одного класса операции есть заполненные failure injection, retry owner, `maxAttempts`, retryable outcomes, `maxFanout`, fallback и terminal action. Trace связывает каждый физический вызов с одним logical request. Неправильные конфигурации останавливаются с отдельными причинами: несколько retry owners, безымянный fallback, неограниченный fan-out, отсутствие limit point и несопоставимый сценарий.</p>\n<p>Проверка считается завершённой, если команда может воспроизвести положительный и отрицательный пути на фиксированных входах, а затем повторить тот же сценарий в тестовой среде с разрешённым наблюдением. На последнем шаге видно, где прекратилось создание новой работы, сколько попыток получил запрос и какой terminal action вернулся. Если любой из этих фактов неизвестен, готовность не доказана.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — официальная семантика статусов 503 и поля Retry-After. RFC не определяет владельца retry, идемпотентность конкретной операции или допустимый fan-out.</li><li><a href=\"https://raw.githubusercontent.com/grpc/proposal/dc9fd4fe5b94b90b82fe2833ad1d80938e6a49c1/A6-client-retries.md\" target=\"_blank\" rel=\"noopener noreferrer\">gRPC A6: Client Retries</a> — официальный design-документ о maxAttempts, throttling, pushback и различии retry и hedging. Документ не подтверждает значения из примера и не является результатом проверки конкретного сервиса.</li><li><a href=\"https://sre.google/sre-book/addressing-cascading-failures/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Addressing Cascading Failures</a> — официальная глава о положительной обратной связи и каскадных отказах. Она даёт контекст для анализа, но не заменяет trace, capacity-проверку и решение владельца операции.</li></ul>"
}