Как проектировать обработку ошибок и алертинг в ESB‑решениях

Материал отражает мой личный взгляд на то, как должен выглядеть процесс обработки ошибок и оповещений в интеграционных решениях.

Я не претендую на единственно верное решение. Интеграция — область, где много нюансов и мнений исходя из индивидуального опыта каждого проекта. Если у вас есть более изящное представление, основанное на вашем опыте, или вы столкнулись с другими паттернами, которые хорошо работают, буду рад почитать ваши комментарии и почерпнуть что-то новое для себя!

Введение

Интеграция между информационными системами редко ограничивается успешной передачей сообщения из точки A в точку B. В реальной эксплуатации возникают сетевые сбои, недоступность внешних систем, истечение сертификатов, ошибки авторизации, некорректные данные и неожиданные изменения контрактов.

Проблема обычно не в том, что ошибки возникают. Гораздо опаснее, когда интеграционное решение:

• теряет сообщения;

• бесконечно повторяет неуспешные операции;

• создаёт дубли в целевой системе;

• блокирует обработку всей очереди из-за одного некорректного сообщения;

• отправляет тысячи одинаковых уведомлений;

• не позволяет понять, что именно произошло и как восстановить обработку.

В этой статье разберём, как проектировать обработку ошибок и оповещения в интеграционных решениях, включая ESB, API-интеграции и потоковые процессы.

Основная идея проста:

Каждую ошибку необходимо зафиксировать, но не каждую ошибку следует немедленно показывать оператору.

Ошибка и оповещение — разные события

Одна из наиболее распространённых архитектурных ошибок — считать каждую техническую ошибку поводом для немедленного уведомления ответственного специалиста. Я бы даже сказал, что это зачастую бизнес‑ошибка: бизнес сначала хочет знать обо всём, что происходит в контуре, а потом создаёт «папку‑мусорку» в почте, чтобы уведомления не мешали.

Рассмотрим простой пример:

1. Интеграционная платформа отправляет запрос в целевую систему.

2. Система временно недоступна.

3. Платформа выполняет повторную попытку.

4. Целевая система снова отвечает ошибкой.

5. Следующая попытка оказывается успешной.

6. Сообщение обработано.

Техническая ошибка действительно произошла, однако вмешательство человека не потребовалось. Если отправлять уведомление на каждом этапе, оператор получит несколько сообщений о проблеме, которая уже устранена автоматически.

Поэтому в интеграционном решении следует разделять четыре независимых процесса:

1. Регистрация события — ошибка фиксируется в журнале и метриках.

2. Автоматическое восстановление — выполняются повторные попытки или другие предусмотренные действия.

3. Оповещение — оператор информируется, если проблема сохраняется или требует вмешательства.

4. Эскалация — критическая ситуация передаётся ответственной команде или владельцу бизнес-процесса.

Например, временная недоступность системы может быть зарегистрирована сразу, но оповещение отправится только после исчерпания повторных попыток или превышения допустимого времени ожидания.

Классификация ошибок

Правила повторной обработки и оповещения должны зависеть от типа ошибки. Универсальной реакции «повторить всё» или «сразу положить всё в очередь» не существует.

На практике я видел проекты, где все ошибки без разбора отправлялись в очередь и дублировались в чат команды. В итоге важные инциденты просто тонули в шуме.

Главное правило:

Повторять следует только те операции, которые потенциально могут завершиться успешно без изменения исходного сообщения или бизнес-контекста.

Повторные попытки: сколько и когда

Для временных технических ошибок обычно применяется ограниченное количество повторных попыток.

В качестве стартового значения можно использовать три повтора после первоначальной попытки:

1. первоначальная попытка;

2. повторная попытка №1;

3. повторная попытка №2;

4. повторная попытка №3.

Это не универсальный норматив. Количество попыток следует определять с учётом:

• критичности данных;

• допустимой задержки;

• ожидаемого времени восстановления системы;

• стоимости повторной операции;

• вероятности дублирования;

• нагрузки на целевую систему;

• возможности безопасного ручного восстановления.

Пример базовых параметров

Для критичных операций не стоит автоматически задирать число повторов до десятков. Если система недоступна долго, безопаснее сохранить сообщение в очереди и дождаться восстановления, чем бесконечно нагружать и так проблемный сервис.

Используйте backoff, а не мгновенный повтор

Повторные попытки, выполняемые одна за другой с минимальным интервалом, могут усугубить проблему.

Неудачный сценарий:

Ошибка → через 1 секунду повтор → ошибка → через 1 секунду повтор → ошибка

Если целевая система перегружена или находится в процессе перезапуска, такая стратегия создаёт дополнительную нагрузку и снижает вероятность восстановления.

Лучше использовать увеличивающийся интервал ожидания — backoff.

Например:

В распределённых системах часто используют экспоненциальный backoff с небольшим случайным отклонением — jitter.

Jitter (джиттер) в стратегии повторных попыток — это небольшая случайная добавка к интервалам между запросами. Она нужна, чтобы множество клиентов не «стреляли» одновременно после одинаковой паузы и не создавали пиковую нагрузку на сервер.

Это помогает избежать ситуации, когда большое количество сообщений одновременно повторяет запрос после одинакового интервала.

Пример логики:

Задержка = min(максимальная_задержка, базовая_задержка × 2^номер_попытки) + случайное_отклонение

Параметры должны быть ограничены сверху. Бесконечно увеличивать задержку или повторять операцию без конечного состояния тоже плохая практика.

Какие ошибки не следует повторять

Повторная отправка не исправит ошибку, если проблема в самом сообщении или в бизнес‑правилах: неверная структура, выход за размерность полей и т.п.

К таким случаям относятся:

• отсутствие обязательного поля;

• некорректный формат даты;

• недопустимое значение атрибута;

• нарушение схемы сообщения;

• ошибка преобразования;

• отсутствие обязательного справочника;

• нарушение бизнес-правила;

• недостаток прав;

• неверная конфигурация маршрута.

Для таких ошибок рекомендуется следующая последовательность:

Сообщение → Ошибка → Остановка повторных попыток → Очередь ошибочных сообщений → Оповещение → Исправление причины → Повторный запуск

Это защищает платформу и целевую систему от постоянной обработки заведомо неуспешного сообщения.

Очередь ошибочных сообщений — не «мусорка», про которую нужно забыть

В моей практике такие очереди часто превращались в «чёрную дыру»: сообщения копились месяцами, и никто не помнил, зачем они нужны. Чтобы этого не произошло, очередь должна быть управляемой и регулярно разбираться.

Для важных интеграций необходим механизм сохранения сообщений, которые не удалось обработать автоматически. В разных продуктах он может называться по-разному:

• dead-letter queue;

• error queue;

• parking queue;

• очередь отложенной обработки;

• очередь ручного восстановления.

Назначение у такого механизма одно: сохранить сообщение и контекст ошибки до момента, когда обработку можно будет безопасно продолжить.

В очередь следует помещать сообщения, которые:

• не доставлены после установленного количества попыток;

• требуют исправления данных;

• требуют ручного решения;

• зависят от восстановления внешней системы;

• не могут быть обработаны автоматически;

• имеют высокий риск потери при удалении.

Важно: помещение сообщения в очередь не должно означать его окончательную потерю. Оператор или автоматизированный процесс должен иметь возможность повторного запуска.

Какие данные хранить вместе с сообщением

Одного исходного тела сообщения недостаточно. Для расследования и повторной обработки необходимо сохранять контекст.

Минимальный набор атрибутов:

• уникальный идентификатор сообщения;

• идентификатор бизнес-операции;

• идентификатор цепочки обработки;

• источник;

• назначение;

• тип операции;

• приоритет;

• критичность;

• время первоначального поступления;

• время последней попытки;

• количество выполненных попыток;

• этап, на котором произошла ошибка;

• категория ошибки;

• технический код;

• текст ошибки;

• исходное сообщение или ссылка на защищённое хранилище;

• сведения о последнем результате обработки;

• срок актуальности сообщения.

Идентификаторы позволяют связать между собой:

• исходное сообщение;

• все попытки обработки;

• обращения к внешним системам;

• преобразования;

• ошибки;

• запись в очереди;

• итоговый результат.

Защита от повторного выполнения

Повторная доставка может быть опасной для операций, изменяющих состояние системы:

• создание заказа;

• проведение платежа;

• создание документа;

• списание товара;

• регистрация клиента;

• изменение статуса;

• начисление денежных средств.

В идеале защита от дублей проектируется вместе с владельцами бизнес‑процесса, а не «допиливается» постфактум, когда уже нашли лишние заказы и платежи.

Рассмотрим типичный сценарий:

1. ESB отправляет запрос.

2. Целевая система успешно создаёт заказ.

3. Ответ теряется из-за сетевого сбоя.

4. ESB считает операцию неуспешной.

5. Сообщение отправляется повторно.

6. В системе появляется второй заказ.

Чтобы избежать этого, должна использоваться идемпотентность или другой механизм защиты от дублей.

Варианты реализации:

• передача уникального идентификатора операции;

• хранение обработанных идентификаторов в целевой системе;

• проверка существования объекта перед созданием;

• использование идемпотентного ключа в API;

• применение паттерна outbox/inbox;

• отдельная операция проверки результата;

• дедупликация на стороне брокера или интеграционной платформы.

Критическая операция должна повторяться только в том случае, если архитектура гарантирует, что повтор не приведёт к нежелательному изменению состояния.

HTTP-коды не заменяют классификацию ошибок

HTTP-код полезен, но сам по себе не всегда определяет, что делать дальше.

Один и тот же код может иметь разный смысл.

Например, 404 Not Found:

• при запросе существующего заказа — вероятная ошибка;

• при проверке отсутствия объекта — нормальный результат;

• при удалении уже удалённого объекта — возможно, идемпотентно успешный сценарий.

Поэтому решение должно учитывать не только транспортный код, но и:

• тип операции;

• бизнес-контекст;

• контракт интерфейса;

• ожидаемое поведение целевой системы.

Особенности кодов 429 и 5xx

HTTP 429

Код 429 Too Many Requests означает, что система ограничивает интенсивность запросов.

В этом случае не следует продолжать отправку с прежней скоростью. Рекомендуется:

• увеличить интервал между попытками;

• учитывать заголовок Retry-After, если он передан;

• временно снизить скорость обработки;

• контролировать рост очереди;

• формировать оповещение при длительном превышении лимита.

HTTP 5xx

Ошибки класса 5xx часто являются временными, но не всегда. Например, 500 Internal Server Error может быть как кратковременным сбоем, так и следствием постоянной ошибки приложения.

Базовая схема:

5xx → повтор с backoff → повтор → очередь → агрегированное оповещение

Не следует немедленно отправлять каждое сообщение с ошибкой 5xx в очередь, если внешняя система, вероятно, восстановится через несколько секунд. Однако число попыток и общее время ожидания должны быть ограничены.

Агрегируйте одинаковые оповещения

Массовая ошибка может привести к лавине уведомлений.

Предположим, внешняя система недоступна в течение десяти минут, а за это время поступило 50 000 сообщений. Отправлять оператору 50 000 одинаковых уведомлений — идея так себе.

Вместо этого следует формировать агрегированное оповещение:

Система «ERP» недоступна. За последние 10 минут не обработано 12 438 сообщений. Выполнено 37 314 повторных попыток. 8 521 сообщение находится в очереди ошибочных сообщений.

После восстановления полезно отправить отдельное уведомление:

Система «ERP» восстановлена. Обработка возобновлена. Обработано 12 438 накопленных сообщений. Ошибок повторной обработки не обнаружено.

Практический принцип:

Одна первопричина — одно оповещение, дополненное агрегированной статистикой.

Для этого можно использовать:

• дедупликацию событий;

• группировку по источнику и назначению;

• временное окно агрегации;

• подавление повторных уведомлений;

• отдельное событие восстановления;

• эскалацию при сохранении проблемы.

Уровни оповещений

Уведомления удобно разделить на четыре уровня.

Информационный

Не требует вмешательства.

Примеры:

• временная ошибка устранена повторной попыткой;

• обработка восстановлена;

• очередь уменьшается после восстановления системы.

Предупреждение

Ситуация требует наблюдения.

Примеры:

• увеличилось количество повторных попыток;

• очередь начала расти;

• увеличилось среднее время обработки;

• система отвечает медленнее обычного.

Ошибка

Требуется вмешательство.

Примеры:

• исчерпаны автоматические попытки;

• сообщения перемещены в очередь ошибочных сообщений;

• невозможно пройти аутентификацию;

• обнаружена массовая ошибка преобразования.

Критическая ошибка

Нарушен критически важный бизнес-процесс.

Примеры:

• не передаются финансовые документы;

• очередь критичных сообщений превысила допустимый предел;

• возраст самого старого сообщения превысил SLA;

• существует риск потери или дублирования данных.

По каким метрикам строить оповещения

Оповещение только по факту наличия ошибки редко бывает полезным. Лучше использовать несколько показателей одновременно.

Количество ошибок

Например: более 10 окончательных ошибок за пять минут.

Доля ошибок

Например: более 5% сообщений завершились ошибкой за последние десять минут.

Этот показатель полезнее абсолютного количества при неравномерной нагрузке.

Размер очереди

Например: в очереди ожидает более 1 000 сообщений.

Скорость роста очереди

Даже небольшая очередь может быть опасной, если она непрерывно увеличивается.

Возраст самого старого сообщения

Сообщение, ожидающее обработки два часа, может быть критичнее сотен свежих временных ошибок.

Длительность недоступности системы

Например: целевая система не отвечает более пяти минут.

Количество окончательно неуспешных сообщений

Показывает реальные проблемы после завершения автоматического восстановления.

Время восстановления

Позволяет оценивать, насколько быстро интеграция возвращается к нормальной работе.

На практике полезно комбинировать условия:

Размер очереди > 1000 ИЛИ возраст старого сообщения > 15 минут ИЛИ доля ошибок > 5% ИЛИ система недоступна более 5 минут

Конкретные цифры, разумеется, зависят от проекта. Главное — не строить алерты только по факту «была ошибка», а смотреть на состояние потока в целом.

Почему размер очереди иногда важнее количества ошибок

Рассмотрим два сценария.

Сценарий A

За десять минут произошло 500 технических ошибок, но все сообщения успешно обработаны после повторной попытки.

Сценарий B

Произошло только 10 ошибок, однако сообщения находятся в очереди уже два часа.

С точки зрения бизнеса сценарий B может быть существенно опаснее. Поэтому мониторинг должен учитывать не только количество сбоев, но и:

• размер необработанной очереди;

• возраст самого старого сообщения;

• критичность сообщений;

• скорость роста очереди;

• допустимое время задержки;

• количество окончательных ошибок.

Как не допустить блокировки очереди

Особенно опасен сценарий, при котором одно проблемное сообщение блокирует все последующие:

Сообщение №1 → ошибка → повтор → ошибка → повтор Сообщение №2 → не обрабатывается Сообщение №3 → не обрабатывается

Для предотвращения «залипания» рекомендуется:

• ограничивать количество повторных попыток;

• перемещать проблемные сообщения в отдельную очередь;

• разделять потоки по типам и приоритетам;

• использовать параллельную обработку независимых сообщений;

• не удерживать основной поток из-за одной постоянной ошибки;

• предусмотреть механизм временной приостановки;

• контролировать максимальное время нахождения сообщения в обработке.

При этом параллельная обработка не должна нарушать порядок сообщений там, где порядок является бизнес-требованием.

Критичность данных

Правила повторной обработки должны зависеть от критичности данных.

Критический уровень

Потеря или задержка данных может привести к:

• финансовым потерям;

• юридическим последствиям;

• остановке ключевого процесса;

• нарушению обязательств перед клиентами;

• существенному нарушению работы предприятия.

Для таких сообщений необходимы:

• гарантированное сохранение;

• уникальный идентификатор;

• очередь ошибочных сообщений;

• повторная доставка;

• контроль возраста сообщения;

• уведомление после исчерпания автоматических попыток;

• возможность ручного повторного запуска;

• защита от дублей.

Важный уровень

Потеря нежелательна, но не приводит непосредственно к критическим последствиям.

Обычно достаточно:

• ограниченных повторных попыток;

• сохранения окончательно ошибочных сообщений;

• контроля очереди;

• агрегированных уведомлений.

Стандартный уровень

Данные могут быть восстановлены из исходной системы или задержка несущественна.

Допустима упрощённая схема:

• журналирование;

• ограниченное количество повторов;

• уведомление при устойчивой проблеме.

Что должно содержать оповещение

Получатель должен понять проблему без дополнительного поиска по нескольким системам.

Минимальный состав уведомления:

• идентификатор сообщения;

• идентификатор бизнес-операции;

• источник;

• назначение;

• тип операции;

• категория ошибки;

• технический код;

• понятное описание;

• количество выполненных попыток;

• время последней попытки;

• этап обработки;

• приоритет;

• количество затронутых сообщений;

• рекомендуемое действие;

• ссылка на журнал или карточку инцидента.

Плохой вариант:

Ошибка подключения.

Хороший вариант:

Не удалось передать заказ №12345 из системы «Заказы» в ERP. Целевая система не отвечает. Выполнено 3 попытки. Следующая попытка будет выполнена через 2 минуты. После исчерпания попыток сообщение будет перемещено в очередь ошибочных сообщений. Ответственная команда: интеграционная платформа.

В уведомлении также следует разделять техническую причину и бизнес-контекст. Это будет полезно для анализа ситуации с разных сторон

Журналирование и защита данных

Для каждой операции рекомендуется фиксировать:

• время начала;

• время окончания;

• источник;

• назначение;

• тип операции;

• идентификатор сообщения;

• идентификатор цепочки;

• результат;

• категорию ошибки;

• технический код;

• номер попытки;

• длительность;

• сведения о повторной обработке.

При этом нельзя без необходимости записывать в журнал полный текст сообщения. Особенно осторожно нужно обращаться с:

• персональными данными;

• паролями;

• токенами;

• ключами доступа;

• платёжными реквизитами;

• коммерческой информацией;

• медицинскими и иными чувствительными данными.

Вместо полного сообщения можно хранить:

• маскированное представление;

• технические атрибуты;

• хэш;

• защищённую ссылку на отдельное хранилище;

• ограниченный набор полей, необходимый для диагностики.

Приостановка интеграции

Иногда правильное решение — временно остановить или ограничить обработку.

Это может потребоваться, если:

• целевая система находится на техническом обслуживании;

• внешняя система перегружена;

• обнаружена массовая ошибка;

• изменился контракт интерфейса;

• существует риск повреждения данных;

• истёк сертификат;

• обнаружена ошибка конфигурации.

При остановке важно не удалять сообщения. Они должны сохраняться в очереди или другом надёжном хранилище до восстановления возможности обработки.

После восстановления необходимо:

1. убедиться, что причина устранена;

2. проверить тестовое сообщение;

3. возобновить обработку ограниченной партией;

4. проконтролировать отсутствие дублей;

5. постепенно снять ограничение;

6. сформировать уведомление о восстановлении.

Базовый профиль для нового решения

Если требования заказчика ещё не определены, можно начать со следующего профиля:

Это только стартовый профиль. Под каждый проект его стоит пересматривать вместе с владельцами процессов и командой эксплуатации.

Матрица согласования с заказчиком

До начала реализации полезно зафиксировать правила в отдельной таблице.

Такая матрица помогает избежать ситуации, когда команда интеграции считает ошибку временной, а бизнес ожидает немедленной эскалации.

Контрольные показатели

Для каждой интеграции рекомендуется отслеживать:

• общее количество поступивших сообщений;

• количество успешно обработанных сообщений;

• долю ошибок;

• количество повторных попыток;

• количество окончательно неуспешных сообщений;

• размер очереди ошибок;

• возраст самого старого сообщения;

• время обработки;

• длительность недоступности внешней системы;

• время восстановления;

• количество повторно обработанных сообщений;

• количество обнаруженных дублей.

Приоритет следует отдавать не только техническим ошибкам, но и бизнес-эффекту. Например, одна финансовая операция, ожидающая обработки несколько часов, может быть важнее тысячи автоматически восстановленных некритичных сообщений.

Краткая памятка

Заключение

Хорошая система обработки ошибок не стремится отправить как можно больше уведомлений. Её задача — автоматически устранить типовой временный сбой, сохранить сообщение при невозможности доставки и привлечь человека только тогда, когда без его участия нельзя безопасно продолжить обработку.

Правильно спроектированное интеграционное решение должно уметь:

• обнаруживать временные сбои;

• выполнять ограниченные повторные попытки;

• использовать увеличивающиеся интервалы ожидания;

• отличать временные ошибки от постоянных;

• сохранять сообщения, которые не удалось обработать;

• отделять проблемные сообщения от основного потока;

• защищать операции от дублирования;

• агрегировать массовые однотипные ошибки;

• сообщать о восстановлении;

• предоставлять возможность ручного повторного запуска;

• сохранять достаточный контекст для расследования.

Итоговый принцип можно сформулировать так:

Сначала обеспечьте сохранность и управляемость сообщения, затем пытайтесь его доставить. Оповещайте человека не о каждом сбое, а о состоянии, которое действительно требует решения.

Если вы дочитали до этого места — большое спасибо. Я потратил немало времени на подготовку материала, потому что мне важно, чтобы статья была не просто набором рекомендаций, а чем‑то, что реально поможет в проектах.

Если нашли неточности или видите, как можно сделать лучше — обязательно пишите, сделаем статью лучше вместе.