Поделиться через

Анализ режима сбоя для приложений Azure

Анализ режимов сбоя (FMA) — это процесс реализации устойчивости в системе за счет определения возможных точек сбоя в системе. FMA должна быть частью архитектуры и выполняться на этапе разработки, чтобы вы могли включить функцию восстановления после сбоев в систему с самого начала.

Ниже описана общая процедура для выполнения FMA:

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

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

  3. Оценивайте каждый режим сбоя в соответствии с его общим уровнем риска. Учитывайте следующие факторы:

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

  4. Для каждого режима сбоя определите, как приложение будет реагировать на эти сбои и восстанавливаться после них. Оцените компромиссы в цене и сложности приложения.

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

Примечание.

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

Служба приложений

Приложение службы приложений завершает работу.

Обнаружение. Возможные причины:

  • Ожидаемое завершение работы

    • Оператор завершает работу приложения, например, с помощью портала Azure.
    • Приложение было выгружено, так как оно бездействовало. (Только если параметр Always On отключен.)

  • Непредвиденное завершение работы

    • Приложение аварийно завершает работу.
    • Экземпляр виртуальной машины службы приложений становится недоступным.

Метод Application_End в журнале зафиксирует прекращение работы домена приложения (нефатальный сбой). Это единственный способ зафиксировать прекращение работы доменов приложения.

Выздоровление:

  • Если завершение работы ожидалось, корректно завершите работу с помощью события завершения приложения. Например, в ASP.NET используйте метод Application_End.
  • Если приложение было выгружено из-за бездействия, оно будет автоматически перезагружено при следующем запросе. Однако вы будете нести стоимость "холодного запуска".
  • Чтобы избежать выгрузки приложения, когда оно бездействует, включите параметр Always On в веб-приложении. См . статью "Настройка веб-приложений" в Службе приложений Azure.
  • Чтобы оператор не завершал работу приложения, установите блокировку ресурсов с уровнем ReadOnly. См. раздел "Блокировка ресурсов" с помощью Azure Resource Manager.
  • Если происходит сбой приложения или виртуальная машина службы приложений становится недоступной, служба приложений автоматически перезагружает приложение.

Диагностика. Журналы приложений и веб-сервера. См. раздел "Включение ведения журнала диагностики для веб-приложений" в Службе приложений Azure.

Конкретный пользователь многократно выполняет неправильные запросы или перегружает систему.

Обнаружение. Выполните проверку подлинности пользователей и включите идентификаторы пользователей в журналы приложений.

Выздоровление:

Диагностика. Регистрируйте все запросы проверки подлинности.

Развернуто неправильное обновление.

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

Восстановление:. Используйте несколько слотов развертывания и вернитесь к последнему известному удачному развертыванию. Дополнительные сведения см. в разделе "Базовый веб-приложение".

Microsoft Entra ID

Проверка подлинности OpenID Connect завершается ошибкой.

Обнаружение. К возможным режимам сбоев относится следующее:

  1. Идентификатор Microsoft Entra недоступен или не может быть достигнут из-за проблемы с сетью. Перенаправление к точке входа проверки подлинности завершается сбоем, и промежуточное ПО OpenID Connect вызывает исключение.
  2. Клиент Microsoft Entra не существует. Перенаправление на конечную точку проверки подлинности возвращает код ошибки HTTP, а ПО промежуточного слоя OpenID Connect выдает исключение.
  3. Пользователь не может пройти проверку подлинности. Стратегия обнаружения не требуется; Идентификатор Microsoft Entra обрабатывает сбои входа.

Выздоровление:

  1. Перехватывать необработанные исключения из ПО промежуточного слоя.
  2. Обработка событий AuthenticationFailed.
  3. Перенаправление пользователя на страницу ошибки.
  4. Повторные попытки пользователя.

Запись данных в ИИ-поиск Azure не удаётся.

Обнаружение. Перехватите ошибки Microsoft.Rest.Azure.CloudException.

Выздоровление:

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

Политика повтора по умолчанию использует стратегию экспоненциальной отсрочки. Чтобы использовать другую политику повтора, вызовите SetRetryPolicy в классе SearchIndexClient или SearchServiceClient. Дополнительные сведения см. в разделе Автоматические повторные попытки.

Диагностика. Используйте аналитику трафика поиска.

Сбой чтения данных из поиска ИИ Azure.

Обнаружение. Перехватите ошибки Microsoft.Rest.Azure.CloudException.

Выздоровление:

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

Политика повтора по умолчанию использует стратегию экспоненциальной отсрочки. Чтобы использовать другую политику повтора, вызовите SetRetryPolicy в классе SearchIndexClient или SearchServiceClient. Дополнительные сведения см. в разделе Автоматические повторные попытки.

Диагностика. Используйте аналитику трафика поиска.

Кассандра

Чтение из узла или запись в узел завершается сбоем.

Обнаружение. Перехватите исключение. Для клиентов .NET это, как правило, будет System.Web.HttpException. Другой клиент может иметь другие типы исключений. Дополнительные сведения см. в разделе Правильная обработка ошибок в Cassandra.

Выздоровление:

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

Диагностика. Журналы приложений

Azure Cosmos DB (облачная база данных)

Сбой при считывании данных.

Обнаружение. Перехватите System.Net.Http.HttpRequestException или Microsoft.Azure.Documents.DocumentClientException.

Выздоровление:

  • Пакет SDK автоматически осуществляет новую попытку после сбоя. Чтобы задать количество повторных попыток и максимальное время ожидания, настройте свойство ConnectionPolicy.RetryOptions. Исключения клиента находятся за пределами действия политики повтора или не являются временными ошибками.
  • Если Azure Cosmos DB ограничивает клиента, он возвращает ошибку HTTP 429. Проверьте код состояния в DocumentClientException. Если вы постоянно получаете ошибку 429, рассмотрите возможность увеличения пропускной способности коллекции.
    • Если вы используете API MongoDB, служба возвращает код ошибки 16500 при ограничении скорости.
  • Включите резервирование зоны при работе с регионом, поддерживающим зоны доступности. При использовании избыточности зоны Azure Cosmos DB автоматически переключается на резерв в случае сбоя зоны. Дополнительные сведения см. в статье "Обеспечение высокого уровня доступности с помощью Azure Cosmos DB".
  • Если вы разрабатываете решение с несколькими регионами, реплицируйте базу данных Azure Cosmos DB в двух или нескольких регионах. Все реплики читабельны. Укажите параметр PreferredLocations с помощью клиентских SDK. Это упорядоченный список регионов Azure. Все операции чтения будут отправляться в первый доступный регион из списка. Если запрос не удаётся, клиент попытается обратиться к другим регионам в списке, в указанном порядке. Дополнительные сведения см. в статье о настройке глобального распространения в Azure Cosmos DB для NoSQL.

Диагностика. Регистрируйте все ошибки на стороне клиента.

Запись данных не удаётся.

Обнаружение. Перехватите System.Net.Http.HttpRequestException или Microsoft.Azure.Documents.DocumentClientException.

Выздоровление:

  • Пакет SDK автоматически осуществляет новую попытку после сбоя. Чтобы задать количество повторных попыток и максимальное время ожидания, настройте свойство ConnectionPolicy.RetryOptions. Исключения клиента находятся за пределами действия политики повтора или не являются временными ошибками.
  • Если Azure Cosmos DB ограничивает клиента, он возвращает ошибку HTTP 429. Проверьте код состояния в DocumentClientException. Если вы постоянно получаете ошибку 429, рассмотрите возможность увеличения пропускной способности коллекции.
  • Включите резервирование зоны при работе с регионом, поддерживающим зоны доступности. При использовании зональной избыточности в Azure Cosmos DB все записи синхронно реплицируются в зонах доступности. Дополнительные сведения см. в статье "Обеспечение высокого уровня доступности с помощью Azure Cosmos DB".
  • Если вы разрабатываете решение с несколькими регионами, реплицируйте базу данных Azure Cosmos DB в двух или нескольких регионах. В случае сбоя основного региона будет назначен другой регион на выполнение записи. Вы также можете вручную активировать аварийное переключение. Пакет SDK выполняет автоматическое обнаружение и маршрутизацию, поэтому код приложения продолжает работать после переключения на резерв. Во время переключения при отказе (обычно это занимает несколько минут) операции записи будут выполняться дольше, так как SDK ищет новый регион записи. Дополнительные сведения см. в статье о настройке глобального распространения в Azure Cosmos DB для NoSQL.
  • В качестве резерва сохраните документ в резервной очереди и обработайте очередь позже.

Диагностика. Регистрируйте все ошибки на стороне клиента.

Хранилище очередей

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

Обнаружение. После попыток повтора N операция записи по-прежнему завершается ошибкой.

Выздоровление:

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

Диагностика. Используйте метрики хранилища.

Приложение не может обработать конкретное сообщение из очереди.

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

Выздоровление:

Переместите сообщение в отдельную очередь. Запустите отдельный процесс для проверки сообщений в этой очереди.

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

Примечание.

Если вы используете очереди хранилища с веб-заданиями, пакет SDK для веб-заданий предоставляет встроенную функцию обработки ядовитых сообщений. Узнайте , как использовать хранилище очередей Azure с пакетом SDK для веб-заданий.

Диагностика. Используйте ведение журнала приложений

Кэш Azure для Redis

Чтение из кэша завершается сбоем.

Обнаружение. Поймайте StackExchange.Redis.RedisConnectionException.

Выздоровление:

  1. Повторите попытки в случае кратковременного сбоя. Кэш Azure для Redis поддерживает встроенную повторную попытку.
  2. Обрабатывайте непостоянные сбои как промах кэша и возвращайтесь к исходному источнику данных.

Диагностика. Используйте диагностику кэша Azure для Redis.

Сбой при записи в кэш.

Обнаружение. Поймайте StackExchange.Redis.RedisConnectionException.

Выздоровление:

  1. Повторите попытки в случае кратковременного сбоя. Кэш Azure для Redis поддерживает встроенную повторную попытку.
  2. Если ошибка не является нетранслируемой, пропустить ее и разрешить другим транзакциям записывать в кэш позже.

Диагностика. Используйте диагностику кэша Azure для Redis.

База данных SQL

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

Обнаружение. Сбой подключения.

Выздоровление:

  • Включите зоновую избыточность. При включении зональной избыточности база данных Azure SQL автоматически реплицирует ваши записи в нескольких зонах доступности Azure в поддерживаемых регионах. Дополнительные сведения см. в разделе "Избыточность между зонами".

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

    Необходимое условие. База данных должна быть настроена для активной георепликации. См. раздел "Активная георепликация базы данных SQL".

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

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

Обнаружение. Перехватите ошибки System.InvalidOperationException.

Выздоровление:

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

Диагностика. Журналы приложений.

Достигнут предел для числа подключений к базе данных.

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

Чтобы обнаружить эти ошибки, перехватите System.Data.SqlClient.SqlException и проверьте значение SqlException.Number, чтобы определить код ошибки SQL. Список соответствующих кодов ошибок см. в разделе "Коды ошибок SQL" для клиентских приложений базы данных SQL: ошибка подключения к базе данных и другие проблемы.

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

Диагностика. — запрос sys.event_log возвращает успешные подключения к базе данных, сбои подключения и взаимоблокировки.

Обмен сообщениями через служебную шину

Чтение сообщения из очереди служебной шины завершается сбоем.

Обнаружение. Перехватите исключения из клиентского SDK. Базовый класс исключений служебной шины — MessagingException. Если это временная ошибка, свойство IsTransient имеет значение true.

Для получения дополнительной информации см. статью об исключениях обмена сообщениями служебной шины.

Выздоровление:

  1. Повторите попытки в случае кратковременного сбоя.
  2. Сообщения, которые не могут быть доставлены любому получателю, помещаются в очередь недоставленных писем. Используйте эту очередь, чтобы узнать, какие сообщения не удалось получить. Автоматическая очистка очереди недоставленных писем отсутствует. Сообщения остаются там, пока вы намеренно не извлечете их. Обзор очередей недоставленных сообщений в Service Bus.

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

Обнаружение. Перехватите исключения из клиентского SDK. Базовый класс исключений служебной шины — MessagingException. Если это временная ошибка, свойство IsTransient имеет значение true.

Для получения дополнительной информации см. статью об исключениях обмена сообщениями служебной шины.

Выздоровление:

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

  • Если превышена квота очереди, клиент выбрасывает QuotaExceededException. Сообщение об исключении содержит более подробные сведения. Удалите некоторые сообщения из очереди перед повторной попыткой и рассмотрите возможность использовать шаблон Circuit Breaker, чтобы избежать постоянных повторных попыток, когда квота превышена. Кроме того, убедитесь, что свойство BrokeredMessage.TimeToLive не задано слишком высоким.

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

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

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

    • Активная репликация. Клиент отправляет каждое сообщение в обе очереди. Получатель прослушивает обе очереди. Отметьте сообщения уникальным идентификатором, чтобы клиент мог удалять повторяющиеся сообщения.
    • Пассивная репликация. Клиент отправляет сообщение в одну очередь. Если возникла ошибка, клиент возвращается в другую очередь. Получатель прослушивает обе очереди. При таком подходе уменьшается число отправляемых повторяющихся сообщений. Тем не менее получатель должен по-прежнему обрабатывать повторяющиеся сообщения.

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

Повторяющиеся сообщения.

Обнаружение. Изучите свойства MessageId и DeliveryCount сообщения.

Выздоровление:

  • По возможности спроектируйте операции обработки сообщений идемпотентными. В противном случае сохраните идентификаторы уже обработанных сообщений и проверьте их перед обработкой сообщений.

  • Включите поиск повторяющихся сообщений, создав очередь с параметром RequiresDuplicateDetection, которому присвоено значение true. С помощью этого параметра служебная шина автоматически удаляет любое сообщение, отправленное с тем же MessageId, что и предыдущее. Обратите внимание на следующее:

    • Этот параметр предотвращает помещение в очередь повторяющихся сообщений. Он не предотвращает повторную обработку одного и того же сообщения пользователем.
    • Функция обнаружения дубликатов имеет временное окно. Если дубликат отправляется за пределами этого окна, он не будет обнаружен.

Диагностика. Регистрируйте повторяющиеся сообщения.

Приложение не может обработать конкретное сообщение из очереди.

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

Выздоровление:

Существует два режима сбоя, которые следует учитывать.

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

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

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

Хранилище

Запись данных в службу хранилища Azure завершается сбоем.

Обнаружение. Клиент получает ошибки при записи.

Выздоровление:

  1. Повторите операцию, чтобы восстановить данные после временных сбоев. Политика повторных попыток в клиентском пакете SDK обрабатывает это автоматически.

  2. Реализуйте паттерн прерывания цепи, чтобы избежать перегрузки хранилища.

  3. Если N попыток повторного выполнения неудачны, выполните корректный переход. Например:

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

Диагностика. Используйте метрики хранилища.

Считывание данных из службы хранилища Azure завершается сбоем.

Обнаружение. Клиент получает ошибки при считывании данных.

Выздоровление:

  1. Повторите операцию, чтобы восстановить данные после временных сбоев. Политика повторных попыток в клиентском пакете SDK обрабатывает это автоматически.
  2. Для хранилища RA-GRS, если произошел сбой при чтении из основной конечной точки, переключитесь на чтение из вторичной конечной точки. Клиентский пакет SDK может обрабатывать это автоматически. См. статью репликации службы хранилища Azure.
  3. Если N повторных попыток завершаются неудачей, выполните альтернативное действие, чтобы обеспечить плавное снижение производительности. Например, если изображение продукта нельзя извлечь из хранилища, используйте универсальное изображение-заполнитель.

Диагностика. Используйте метрики хранилища.

Виртуальная машина

Подключение к серверной виртуальной машине завершается сбоем.

Обнаружение. Ошибки сетевого подключения.

Выздоровление:

  • Разверните как минимум две серверные виртуальные машины в группе доступности за балансировщиком нагрузки.
  • Если ошибка подключения временная, иногда протокол TCP будет успешно выполнять повторную отправку сообщения.
  • Реализуйте политику повтора в приложении.
  • Для постоянных или непостоянных ошибок реализуйте шаблон Circuit Breaker.
  • Если вызывающая виртуальная машина превышает предел исходящего сетевого трафика, очередь исходящего трафика будет заполнена. Если очередь исходящих сообщений постоянно заполнена, попробуйте масштабировать систему.

Диагностика. Регистрируйте события в границах служб.

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

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

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

Диагностика. — Используйте log analytics Load Balancer.

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

Оператор случайно завершает работу виртуальной машины.

Обнаружение. Н/П

Восстановление. Установите блокировку ресурса на уровне ReadOnly. См. раздел "Блокировка ресурсов" с помощью Azure Resource Manager.

Диагностика. Используйте журналы действий Azure.

ВебДжобс

Выполнение непрерывного задания останавливается, когда узел управления исходным кодом неактивен.

Обнаружение. Передайте токен отмены в функцию веб-задания. Дополнительные сведения см. в разделе "Корректное завершение работы".

Восстановление. Включите параметр Always On в веб-приложении. Дополнительные сведения см. в разделе "Выполнение фоновых задач с помощью веб-заданий".

Проектирование приложений

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

Обнаружение. Зависит от приложения. Обычные симптомы:

  • Веб-сайт начинает возвращать коды ошибок HTTP 5xx.
  • Зависимые службы, такие как системы базы данных или хранения данных, начинают регулировать запросы. Найдите ошибки HTTP, такие как HTTP 429 (слишком много запросов), в зависимости от службы.
  • Длина очереди HTTP увеличивается.

Выздоровление:

  • Масштабируйте систему для обработки увеличенной нагрузки.

  • Устраните ошибки, чтобы предотвратить каскадные сбои во всем приложении. Стратегии устранения рисков включают следующее:

Диагностика. Используйте ведение журнала диагностики службы приложений. Используйте службу, например Azure Log Analytics, Application Insights или New Relic , чтобы понять журналы диагностики.

Пример доступен здесь. В нем используется Polly для этих исключений:

  • 429 — ограничение скорости
  • 408 — истекло время ожидания
  • 401 — Unauthorized (Не авторизовано)
  • 503 или 5xx — служба недоступна

Одна из операций в рабочем процессе или распределенная транзакция завершается сбоем.

Обнаружение. После повторных попыток N он все еще завершается ошибкой.

Выздоровление:

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

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

Вызов удаленной службы завершается сбоем.

Обнаружение. Код ошибки HTTP.

Выздоровление:

  1. Повторите попытки в случае кратковременного сбоя.
  2. Если вызов завершается ошибкой после попыток N , выполните резервное действие. (Зависит от приложения.)
  3. Реализуйте шаблон разбиения цепи , чтобы избежать каскадных сбоев.

Диагностика. Регистрируйте все ошибки удаленных вызовов.

Следующие шаги

См. статью "Устойчивость и зависимости " в Azure Well-Architected Framework. Встроенная возможность восстановления системы после сбоя должна быть частью архитектуры и этапов проектирования с самого начала, чтобы избежать риска сбоя.