Рекомендации по выполнению анализа режима сбоя

Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:

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

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

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

Определения

Основные стратегии проектирования

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

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

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

Распакуйте рабочую нагрузку

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

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

Определение зависимостей

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

Внутренние зависимости — это компоненты в области рабочей нагрузки, необходимые для работы рабочей нагрузки. Типичные внутренние зависимости включают API или решения для управления секретами и ключами, такие как Azure Key Vault. Для этих зависимостей фиксируйте данные надежности, такие как соглашения об уровне обслуживания доступности и ограничения масштабирования. Внешние зависимости являются обязательными компонентами за пределами рабочей нагрузки, такими как другое приложение или сторонняя служба. Типичные внешние зависимости включают решения проверки подлинности, такие как Идентификатор Microsoft Entra, и решения для подключения к облаку, такие как Azure ExpressRoute.

Определите и задокументируйте зависимости в рабочей нагрузке и включите их в артефакты документации по потоку.

Оценка точек сбоя

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

• Региональный сбой. Весь регион Azure недоступен.

• Сбой зоны доступности. Зона доступности Azure недоступна.

• Сбой службы. Одна или несколько служб Azure недоступны.

• Распределенная атака типа "отказ в обслуживании" (DDoS) или другая вредоносная атака.

• Неправильное настройка приложения или компонента.

• Ошибка оператора.

• Сбой планового обслуживания.

• Перегрузка компонентов.

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

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

Исправление

Стратегии устранения рисков делятся на две широкие категории: создание более устойчивости и проектирование для снижения производительности.

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

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

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

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

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

Detection

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

Результат

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

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

Ознакомьтесь со следующей таблицей для начальной точки документации.

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

Упрощение функций Azure

Используйте Azure Monitor и Log Analytics для обнаружения проблем в рабочей нагрузке. Дополнительные сведения о проблемах, связанных с инфраструктурой, приложениями и базами данных, используйте такие средства, как Application Insights, Container Insights, Network Insights, VM Insights и SQL Insights.

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

Сведения о применении принципов FMA к общим службам Azure см. в статье "Анализ режима сбоя" для приложений Azure.

Пример

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

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

Дополнительные ссылки

• Анализ режима сбоя для приложений Azure
• Устойчивость и зависимости

Контрольный список надежности

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