Стратегии архитектуры для выполнения анализа режима сбоя

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

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

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

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

определения

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

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

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

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

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

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

Определение зависимостей рабочей нагрузки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование стратегий устранения рисков

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

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

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

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

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

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

Реализация обнаружения сбоев

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

Задокументируйте выводы FMA

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

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

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

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

мониторинг Azure

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

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

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

Пример

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

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

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

• устойчивость и зависимости

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

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