Краткий ответ
Разделите сбои на временные, постоянные и ошибки с неизвестным результатом. Временные повторяйте с растущей задержкой, случайным разбросом и общим сроком ожидания. При неизвестном результате сначала проверьте статус операции и защиту от дублей. Неверные данные направляйте в карантин, исчерпанные попытки — в очередь недоставленных сообщений. Для каждого исхода назначьте владельца и правило безопасного ручного запуска.
Почему единая реакция на все ошибки не работает
Обработка ошибок и повторные попытки в интеграциях нужны, чтобы довести операцию до понятного результата без лишних побочных действий. Но отсутствие ответа ещё не означает, что удалённая система ничего не сделала.
Рассмотрим гипотетический пример: платформа оптовых заказов передаёт резерв на склад, затем создаёт счёт в учётной системе. Команда решает повторять любой неудачный запрос. При тайм-ауте резерв уже создан, а ответ потерян. Новый запрос создаёт ещё один резерв, и свободный остаток уменьшается повторно.
Менеджер замечает: товар есть, продать его нельзя. Цель пережить обрыв связи подменена стремлением добиться успешного ответа любой ценой. Склад честно выполнил оба запроса. Отсутствие ответа было ошибочно принято за отсутствие действия.
Начните с карточки операции: что меняется у получателя, как проверить результат, разрешено ли повторение, когда заказ теряет актуальность. Для чтения остатков и создания резерва карточки будут разными. Такой договор нужен владельцу продукта не меньше, чем разработчику: именно бизнес определяет, допустимо ли ожидание вместо отказа.
Сначала составьте реестр интеграций: он поможет найти операции с побочными действиями и назначить владельцев. Иначе единая настройка повторов распространится и на чтение каталога, и на создание финансовых документов.
Классификация интеграционных сбоев
Классифицируйте сбой по возможности исправления и определённости результата. Код ответа полезен, но решение зависит также от операции и договора с конкретным API.
Тайм-ауты и временная недоступность требуют разных вопросов. Если соединение не установилось, запрос мог не попасть к получателю. Если ожидание закончилось после отправки, результат неизвестен. В примере со складом нельзя создавать новый резерв, пока не проверен прежний по устойчивому идентификатору.
Частично выполненная операция — это уже изменение состояния: склад зарезервировал товар, но счёт не создан. Дублирующееся сообщение, напротив, может описывать уже завершённое действие. Его нужно распознать и подтвердить без повторного эффекта, а не записывать как очередную неисправность связи.
Некорректные данные и нарушение контракта не исправляются ожиданием. Неизвестный код товара требует решения владельца справочника; неверный формат даты — исправления отправителя. Отказ в доступе требует проверки полномочий. Повтор того же пакета причину не устранит.
Недоступность внешней зависимости может пережить срок полезности заказа. Сетевая блокировка, отключённая учётная запись или прекращение работы сервиса не равны краткой перегрузке. Для российских компаний важно отдельно проверить доступность из своей инфраструктуры: перенос приложения сам по себе не меняет условия доступа к чужому API.
Обработка ошибок и повторные попытки в интеграциях: правила автоматики
Автоматически повторяйте только потенциально временный сбой, если повтор безопасен и операция ещё нужна бизнесу. При неизвестном результате сначала используйте проверку статуса либо предусмотренное получателем подавление дублей.
Разделяйте разрешение на повтор и его расписание. Сигнал перегрузки или временной недоступности допускает повтор лишь с учётом документации API. Ошибка данных его запрещает. Для записи с тайм-аутом проверка безопасности обязательна даже тогда, когда библиотека клиента предлагает повтор по умолчанию.
Лимиты повторных попыток и увеличение интервалов задавайте вместе с общим сроком выполнения. Предлагаемый подход: после каждой неудачи увеличивать паузу до установленного потолка и добавлять случайный разброс. Так клиенты не возвращаются к перегруженной системе одновременно. Указанную сервером задержку учитывайте в пределах бизнес-срока.
Для нашего гипотетического заказа примем такие настройки: исходный вызов и не более трёх повторов, каждый с тайм-аутом две секунды; предельные паузы перед повторами — одна, две и четыре секунды. Фактическую паузу выбираем случайно от нуля до соответствующего предела. Общий предел ожидания — пятнадцать секунд, без учёта накладных расходов.
Проверка бюджета проста: четыре вызова по две секунды и паузы суммарно до семи секунд дают пятнадцать секунд. Это иллюстрация, а не рекомендуемый норматив. Реальный предельный срок проверяйте перед каждым вызовом, оставляя запас на обработку. Если пауза или следующий вызов в него не помещаются, переводите заказ в ожидание, а не растягивайте ответ пользователю.
Проверьте повторы в библиотеке, шлюзе и обработчике очереди: вложенные механизмы могут незаметно перемножить число обращений. Назначьте уровень, который управляет бюджетом. При устойчивом отказе временно прекратите обращения к зависимости и возобновляйте их ограниченно, иначе восстановившийся сервис получит всю накопленную нагрузку сразу.
Идемпотентность и работа с частичными результатами
Идемпотентность означает, что повтор той же логической операции не создаёт нового эффекта. Она нужна и для сетевых повторов, и для повторной доставки сообщений, и для ручного восстановления.
Платформа из примера теперь присваивает резервированию постоянный ключ операции и сохраняет его до отправки. Все повторы используют тот же ключ. Получатель связывает его с параметрами и результатом; запрос с изменённым содержимым под прежним ключом отклоняется. Новый сетевой запрос не должен означать новый бизнес-заказ.
Простая проверка наличия ключа перед записью недостаточна: параллельные обработчики могут одновременно увидеть его отсутствие. Нужны уникальность ключа и согласованная фиксация эффекта с результатом. Если получатель не поддерживает такую защиту, локальная отметка об отправке не доказывает, что удалённое действие выполнено безопасно.
При частичном успехе платформа сохраняет состояния шагов: резерв подтверждён, счёт ожидается. Повторяется создание счёта, а не вся цепочка. Если заказ отменён, запускается отдельное снятие резерва с собственной защитой от дублей. Компенсация — новое бизнес-действие, а не перемотка времени: товар уже мог попасть в сборку.
Срок хранения ключей должен покрывать разрешённый период повторной доставки и ручного запуска. После его истечения старое сообщение нельзя слепо отправить заново. Если результат нельзя выяснить, заказ получает статус неопределённости и владельца решения. Показывать покупателю отказ и одновременно продолжать скрытые попытки опасно: он может оформить замену.
Очередь недоставленных сообщений: отказ, ожидание или эскалация
Очередь сохраняет ещё полезную работу, карантин отделяет данные, требующие исправления, а очередь недоставленных сообщений удерживает операции после исчерпания автоматических попыток. Эти состояния должны иметь разные выходы.
Если учётная система недоступна, но отложенный счёт допустим, сохраните задание в устойчивой очереди. Подтвердите приём после надёжной записи. Если заказ потерял актуальность, повтор запрещён. Доставка задания и выполнение заказа — разные события: очередь ещё не даёт оснований обещать отгрузку.
В карантине сохраняйте причину отклонения, версию формата и ссылку на исходную операцию. Исправлять данные должен назначенный владелец, а не оператор наугад. Если содержание меняется, явно оформите исправленную операцию и её связь с исходной; прежний ключ идемпотентности нельзя незаметно использовать для нового смысла.
Ручное восстановление начинается с проверки удалённого результата и актуальности заказа. Затем ответственный выбирает продолжение незавершённого шага, компенсацию либо окончательное отклонение. Повторный запуск проходит через тот же обработчик с теми же проверками ключа и срока. Кнопка повторить всё не должна обходить правила ради удобства.
Ограничьте доступ к очередям и ручному запуску по ролям. Фиксируйте инициатора, основание и итог вмешательства; вместо содержимого заказов используйте идентификаторы. Выясните, кто хранит сообщения и сможет восстановить обработку без доступа к кабинету внешнего поставщика.
Матрица политики обработки сбоев
Закрепите правила в матрице по операциям, а не только по кодам ошибок. Ниже — предлагаемый шаблон для гипотетической платформы; лимит и паузы для временного сбоя берутся из рассмотренного примера.
| Сбой | Автоматика и защита | Куда направить | Ответственный и восстановление |
|---|---|---|---|
| Тайм-аут записи, результат неизвестен | Проверить статус по ключу; повтор лишь при гарантии отсутствия нового эффекта | Ожидание проверки, затем эскалация | Владелец интеграции; продолжить после установления результата |
| Временная недоступность | В рамках гипотетической политики: до трёх повторов с растущими паузами и тем же ключом | После лимита — очередь недоставленных сообщений | Владелец интеграции; запуск после проверки доступности и срока заказа |
| Частичный успех | Не повторять подтверждённый шаг; продолжить незавершённый | Очередь продолжения либо компенсации | Владелец заказа; подтвердить завершение или снятие резерва |
| Дубликат сообщения | Вернуть сохранённый результат, новый эффект запрещён | Подтвердить обработку | Владелец системы-получателя; проверить сохранность ключа |
| Неверные данные или формат | Без автоматического повтора исходного пакета | Карантин или окончательное отклонение | Владелец данных; исправить причину и проверить новую операцию |
| Длительно недоступная зависимость | Приостановить обращения; сохранять только актуальные задания | Очередь и эскалация бизнесу | Владелец сервиса; разрешить ограниченное возобновление |
Для каждой строки добавьте срок реакции и критерий восстановления. Срок выводится из допустимого ожидания конкретного заказа, а не из удобства дежурного. В примере менеджер должен узнать о неподтверждённом резерве до обещания отгрузки. Восстановление означает подтверждённый результат операции, а не просто доступный адрес сервиса.
Разделите владельца технического исправления и человека, который решает судьбу заказа. Модель ответственности за программный сервис поможет закрепить границы, если интеграцию обслуживает подрядчик. Иначе поставщик исправит соединение, а очередь с просроченными заказами останется без хозяина.
Уведомление бизнеса и наблюдаемость без лишнего шума
Бизнесу нужен статус обязательства: заказ ожидает, требует исправления или отклонён. Владельцам систем нужны причина сбоя и история попыток. Не превращайте каждый краткий сетевой отказ в отдельное управленческое событие.
Свяжите записи отправителя, очереди и получателя общим идентификатором операции. Сохраняйте класс ошибки, номер попытки, длительность, назначенную паузу и итог. Для контроля политики достаточно видеть возраст ожидающих заданий, исчерпание попыток и подавленные дубли. Рост возраста очереди важен даже при редких ошибках: работа всё равно стоит.
Уведомление менеджеру формулируйте через действие: резерв не подтверждён, отгрузку пока не обещать, ответственный назначен. Укажите срок пересмотра статуса. Техническая трассировка остаётся у исполнителя. Порядок дежурств и расследования — отдельная задача; здесь уведомление завершает ветку политики.
Как тестировать сценарии отказа до выпуска
Проверяйте не появление ошибки на экране, а итоговые действия систем. Для примера со складом успешный тест доказывает, что потерянный ответ не создаёт лишнего резерва, а отказ учётной системы не запускает всю цепочку заново.
На испытательном стенде оборвите ответ после сохранения резерва, повторно доставьте сообщение и одновременно запустите его обработку. Затем подайте неверный код товара, задержите зависимость и перезапустите обработчик между удалённым успехом и локальной записью. Каждый опыт должен иметь ожидаемый статус заказа и способ продолжения.
Отдельно проверьте истечение срока заказа и ручной запуск старого сообщения: обхода запрета быть не должно. Для сквозной проверки используйте сценарии тестирования от начала до конца — они связывают действия пользователя с резервом и счётом. Автоматический тест транспорта не покажет, что менеджер получил ложное обещание готовности.
Команда из примера оставляет повторы для безопасных шагов, сохраняет подтверждённый резерв и отдельно доводит счёт до результата. Перед выпуском владелец продукта утверждает матрицу, разработчик реализует переходы, ответственный за эксплуатацию демонстрирует восстановление. Политика становится проверяемым условием готовности.
Закрепите политику сбоев до запуска
Когда правила повторов влияют на обещания клиенту, их стоит согласовать ещё при планировании интеграции и включить в критерии выпуска. Материал «Жизненный цикл ПО» помогает связать эти решения с этапами разработки, контролем сроков, бюджета и качества.
Часто задаваемые вопросы
Можно ли повторять любой запрос после тайм-аута?
Нет. Получатель мог выполнить действие до потери ответа. Для записи сначала проверьте результат по ключу операции либо используйте гарантированную получателем защиту от повторного эффекта.
Сколько повторных попыток нужно настроить?
Универсального числа нет. Лимит должен укладываться в допустимый срок операции вместе с тайм-аутами и паузами. После его исчерпания нужен явный переход в ожидание, отказ или эскалацию.
Зачем нужен случайный разброс интервалов?
Он разносит обращения клиентов во времени. Без разброса одинаковые задержки могут собрать синхронную волну повторов и снова перегрузить восстанавливающуюся зависимость.
Чем очередь недоставленных сообщений отличается от карантина?
В предлагаемой схеме первая хранит задания после исчерпания попыток, а карантин — данные, которые нельзя обработать без исправления. Названия могут отличаться, но причины остановки и правила выхода должны быть явными.
Достаточно ли сохранить идентификатор запроса у отправителя?
Нет. Отправитель не может этим обеспечить уникальность удалённого действия. Нужна поддержка получателя либо достоверная проверка результата и отдельный порядок разрешения неопределённости.
Что делать, если выполнена только часть цепочки?
Зафиксируйте завершённые шаги и продолжайте незавершённый. Если заказ больше не нужен, согласуйте компенсацию. Не запускайте всю цепочку заново без проверки уже созданных эффектов.
Кто должен разрешать ручной повтор?
Технический исполнитель проверяет безопасность запуска, а владелец бизнес-операции — её актуальность. Права, основание вмешательства и результат следует фиксировать, сохраняя защиту от дублей.
Когда восстановление можно считать завершённым?
Когда установлен итог операции, снята неопределённость для бизнеса и обработаны актуальные отложенные задания. Само восстановление соединения ещё не подтверждает судьбу конкретного заказа.
Продуктовый дизайнер в Scrile. Фокусируется на пользовательской ценности и бизнес-результатах. Пишет про интерфейсные решения, экономику design-system и где UX-инвестиции реально окупаются.