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

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

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

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

• Выполните регулирование запросов от пользователя с помощью службы управления API 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 для веб-заданий предоставляет встроенную обработку сообщений о сбое. Ознакомьтесь со статьей об использовании пакета SDK веб-заданий для работы с хранилищем очередей Azure.

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

Кэш Azure для Redis

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

Обнаружение. Перехватите StackExchange.Redis.RedisConnectionException.

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

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

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

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

Обнаружение. Перехватите StackExchange.Redis.RedisConnectionException.

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

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

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

База данных SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обмен сообщениями с помощью служебной шины

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранилище

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

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

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

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

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

3. При сбое N повторных попыток выполните корректный переход. Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Восстановление. Установите блокировку ресурсов с уровнем ReadOnly. Ознакомьтесь со статьей Блокировка ресурсов для предотвращения непредвиденных изменений.

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

веб-задания;

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

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

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

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

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

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

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