Защитите свои компоненты, задав эти вопросы

«Стойкость основана на сострадании к себе, а также на сострадании к другим». — Шэрон Зальцберг

Давайте рассмотрим несколько вещей, которые следует учитывать при интеграции компонента с внешней зависимостью.

Безопасно ли соединение?

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

Соединение контролируется?

Компонент, который инициирует соединение с внешней зависимостью, несет ответственность за правильное управление таким соединением.

  • Используйте асинхронный и неблокирующий шаблон для обработки взаимодействия между компонентом и внешней зависимостью. Например, используйте Promise, чтобы инициировать соединение, а затем отреагировать на событие или перехватить исключение, при этом не блокируя другую обработку.
  • Используйте приемлемый тайм-аут для закрытия зависших соединений.
  • Примите стратегию повторных попыток, где это уместно. Часто бывает достаточно повторить попытку один раз.
  • Обработка противодавления, исходящего от внешней зависимости. Используйте Dead Letter Queue для сохранения неудачных событий и повторяйте эти события в течение указанного периода хранения, чтобы избежать бесконечного повторения событий.
  • Используйте стратегию по умолчанию, когда не удается установить соединение с внешней зависимостью.

Обрабатываются ли исключения?

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

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

Полезны ли журналы ошибок?

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

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

Журналы ошибок датируются с использованием какой-либо временной метки, например 2022–05–31T15:11:25.349Z..

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

Предлагаемый формат кода ошибки:[{COMPONENT}-{DEPENDENCY}-{SYSTEM|DATA}]

Например, следующий код [ABC-XYZ-SYSTEM] сообщает нам, что компонент ABC испытывает системную проблему при обмене данными с зависимостью XYZ.

Код ошибки [ABC-XYZ-DATA] говорит нам, что компонент ABC обменивается неверными ДАННЫМИ с зависимостью XYZ. Он информирует о функции внутри компонента, на которую влияет эта ошибка.

Журнал ошибок также должен содержать сообщение, подтверждающее характер ошибки, чтобы подтвердить первоначальное предположение, основанное на коде ошибки.

Например, такое сообщение об ошибке [ABC-XYZ-DATA] All-But-Crazy failed to submit recipe to Xtra-Yummy-Zinger на простом английском подтверждает, что компонент не может обработать данные, возвращаемые зависимостью.

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

Итак, полезный журнал ошибок действительно выглядит так:

2022-05-31T15:11:25.349Z [ABC-XYZ-DATA] All-But-Crazy failed to submit recipe to Xtra-Yummy-Zinger.
Inputs:
{
  "ingredient1": "chocolate",
  "ingredient2": "sand",
  ...
}
Outputs:
{
  "message": "The value for ingredient2 is not supported: 'sand'"
}

Отслеживаются ли ошибки?

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

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

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

Оцените состояние своей системы с помощью этих подробных аналитических данных. Настройте его и определитесь со следующим шагом.

И последнее, но не менее важное: кто вы?

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

«Привет, я совсем-но-сумасшедший. Рад встрече с вами."

Спасибо за прочтение :)