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

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

RE:03	Используйте анализ режима сбоя (FMA) для выявления потенциальных сбоев в рабочей нагрузке. Определение зависимостей и точек сбоя и разработка стратегий устранения рисков для этих сбоев.

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

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

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

определения

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

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

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

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

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

Разделите рабочую нагрузку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смягчение

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

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

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

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

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

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

Обнаружение

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

Результат

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

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

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

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

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

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

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

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

Пример

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

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

Компонент	Риск	Вероятность	Эффект/устранение/примечание	Отключение
Microsoft Entra ID	Сбой службы	Низкий	Полный сбой рабочей нагрузки. Зависит от корпорации Майкрософт для исправления.	Полный
Microsoft Entra ID	Неправильная настройка	Средний	Пользователи не могут войти. Нет эффекта нижестоящего потока. Служба технической поддержки сообщает о проблеме с конфигурацией команде по идентификации.	Нет
Azure Front Door	Сбой службы	Низкий	Полный сбой для внешних пользователей. Зависит от корпорации Майкрософт для исправления.	Только внешний
Azure Front Door	Региональный сбой	Очень низкий	Минимальный эффект. Azure Front Door — это глобальная служба, поэтому глобальная маршрутизация трафика направляет трафик через неисправные регионы Azure.	Нет
Azure Front Door	Неправильная настройка	Средний	Во время развертывания должны быть обнаружены ошибки конфигурации. Если эти ситуации происходят во время обновления конфигурации, администраторы должны откатить изменения. Обновление конфигурации приводит к краткому внешнему сбою.	Исключительно внешний
Azure Front Door	Атака DDoS	Средний	Потенциальная возможность нарушений. Корпорация Майкрософт управляет защитой от атак DDoS (L3 и L4), а брандмауэр веб-приложений Azure блокирует большинство угроз. Потенциальный риск воздействия атак L7.	Потенциал для частичного сбоя
Azure SQL	Сбой службы	Низкий	Полный сбой рабочей нагрузки. Зависит от корпорации Майкрософт для исправления.	Полный
Azure SQL	Региональный сбой	Очень низкий	Группа автоматического переключения переключается на вторичный регион. Потенциальный сбой при переключении на резерв. Цели времени восстановления (ОСРВ) и цели точки восстановления (ТРВ) должны быть определены во время тестирования надежности.	Возможный потенциал
Azure SQL	Сбой в зоне доступности	Низкий уровень	Нет эффекта	Никакой
Azure SQL	Вредоносные атаки (внедрение)	Средний	Минимальный риск. Все экземпляры SQL Azure привязаны к виртуальной сети через частные конечные точки и группы безопасности сети (NSG) добавляют дополнительную защиту внутри виртуальной сети.	Низкий риск, потенциал для частичного сбоя
Служба приложений	Сбой службы	Низкий	Полный сбой рабочей нагрузки. Зависит от Майкрософт в устранении проблемы.	Полный
Служба приложений	Региональный сбой	Очень низкий	Минимальный эффект. Задержка для пользователей в затронутых регионах. Azure Front Door автоматически направляет трафик в неэфектированные регионы.	Нет
Служба приложений	Сбой в зоне доступности	Низкий	Нет эффекта. Службы приложений развернуты с избыточностью на уровне зон. Без избыточности зон существует потенциал для влияния.	Никакой
Служба приложений	Атака DDoS	Средний	Минимальный эффект. Входящий трафик защищен Azure Front Door и Брандмауэром веб-приложений Azure.	Нет

Связанные ссылки

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

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

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

список проверки надежности