Анализ режима сбоя для приложений 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.

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

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

Восстановление:

• Используйте службу управления API Azure для ограничения скорости запросов от пользователя. Ознакомьтесь со статьей Расширенное регулирование запросов с помощью Azure API Management.
• Заблокируйте пользователя.

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

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

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

Восстановление. Используйте несколько слотов развертывания и выполните откат до последнего успешного развертывания. Дополнительные сведения см. в статье Basic web application (Базовое веб-приложение).

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

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

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

Восстановление:

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

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

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

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

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

Восстановление:

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

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

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

Cassandra

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

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

Восстановление:

• У каждого клиента Cassandra свои политики повтора и возможности. Для получения дополнительной информации см. Cassandra error handling done right (Правильная обработка ошибок Cassandra).
• Используйте развертывание с распределением нагрузки, с узлами данных, распределенными между доменами сбоя.
• Выполните развертывание в несколько регионов, используя согласованность локального кворума. Если происходит непереходящий сбой, переключение на другой регион.

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

Облачные службы

Веб-роли или роли рабочих неожиданно отключаются.

Обнаружение. Срабатывает событие RoleEnvironment.Stopping.

Восстановление. Переопределите метод RoleEntryPoint.OnStop, чтобы выполнить корректную очистку. Дополнительные сведения см. в записи блога The Right Way to Handle Azure OnStop Events (Правильный способ обработки событий Azure OnStop).

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 Queue Storage с SDK WebJobs.

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

Кэш 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.

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

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

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

Обнаружение. Улавливайте ошибки System.InvalidOperationException.

Восстановление:

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

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

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

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

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

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

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

• Создайте правило генерации оповещений для неудачных подключений.
• Включите аудит базы данных SQL и проверьте неудачные попытки входа.

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

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

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

Дополнительные сведения см. в статье Исключения обмена сообщениями сервисной шины.

Восстановление:

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

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

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

Дополнительные сведения см. в статье Исключения обмена сообщениями сервисной шины.

Восстановление:

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

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

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

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

• Если вы разрабатываете решение с несколькими регионами, создайте два пространства имен 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 паттерн.
• Если вызывающая виртуальная машина превышает предел исходящего сетевого трафика, очередь исходящего трафика будет заполнена. Если очередь исходящих сообщений постоянно заполнена, попробуйте масштабировать систему.

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

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

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

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

Диагностика. Используйте балансировщик нагрузки Log Analytics.

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

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

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

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

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

WebJobs

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

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

Восстановление. Включите параметр 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. Встроенная возможность восстановления системы после сбоя должна быть частью архитектуры и этапов проектирования с самого начала, чтобы избежать риска сбоя.