Рекомендации по анализу режима сбоя
Применяется к этой рекомендации по контрольным спискам надежности платформы Azure Well-Architected:
| RE:03 | Используйте анализ режима сбоя (FMA) для выявления и определения приоритетов потенциальных сбоев в компонентах решения. Выполните FMA, чтобы оценить риск и влияние каждого режима сбоя. Определите, как рабочая нагрузка реагирует и восстанавливается. |
|---|
В этом руководстве описаны рекомендации по выполнению анализа режима сбоя (FMA) для рабочей нагрузки. FMA — это практика выявления потенциальных точек сбоя в рабочей нагрузке и связанных с ними потоков и соответствующего планирования действий по устранению рисков. На каждом этапе потока определяется радиус взрыва нескольких типов сбоев, что помогает спроектировать новую рабочую нагрузку или рефакторинг существующей рабочей нагрузки, чтобы свести к минимуму широко распространенные последствия сбоев.
Ключевым принципом FMA является то, что сбои происходят независимо от того, сколько уровней устойчивости вы применяете. Более сложные среды подвержены сбоям большего числа типов. Учитывая такую реальность, FMA позволяет спроектировать рабочую нагрузку, чтобы выдержать большинство типов сбоев и корректно восстанавливаться при сбое.
Если пропустить FMA полностью или выполнить неполный анализ, рабочая нагрузка будет подвержена риску непредсказуемого поведения и возможных сбоев, вызванных неоптимальной структурой.
Определения
| Термин | Определение |
|---|---|
| Режим сбоя | Тип проблемы, которая может привести к ухудшению работы одного или нескольких компонентов рабочей нагрузки или серьезному влиянию на их недоступность. |
| Меры по снижению риска | Действия, которые вы определили для решения проблем упреждающим или реактивным способом. |
| Обнаружение | Процессы и процедуры мониторинга инфраструктуры, данных и приложений и оповещений. |
Ключевые стратегии проектирования
Предварительные требования
Просмотрите и реализуйте рекомендации по определению потоков. Предполагается, что вы определили и приоритете потоки пользователей и систем на основе важности.
Собранные данные и артефакты, созданные в ходе работы, предоставляют конкретное описание путей к данным, участвующих в потоках. Для успешной работы FMA очень важна точность и тщательность работы с артефактами.
Подход FMA
Определив критические потоки, можно спланировать необходимые компоненты. Затем следуйте каждому потоку шаг за шагом, чтобы определить зависимости, включая сторонние службы и потенциальные точки сбоя, и спланировать стратегии устранения рисков.
Декомпилировать рабочую нагрузку
При переходе от идей к проектированию необходимо определить типы компонентов, необходимые для поддержки рабочей нагрузки. Рабочая нагрузка определяет необходимые компоненты, которые необходимо планировать. Как правило, необходимо планировать управление входящего трафика, сетью, вычислениями, данными, хранилищем, вспомогательными службами (такими как проверка подлинности, обмен сообщениями, управление секретами или ключами) и управление исходящим трафиком. На этом этапе разработки вы можете не знать конкретные технологии, которые вы будете развертывать, поэтому ваш проект может выглядеть так, как показано в следующем примере.
После создания начальной архитектуры можно наложить потоки, чтобы определить дискретные компоненты, используемые в этих потоках, и создать списки или схемы рабочих процессов, описывающие потоки и их компоненты. Чтобы понять важность компонентов, используйте определения критичности, назначенные потокам. Рассмотрим влияние неисправности компонента на потоки.
Определение зависимостей
Определите зависимости рабочей нагрузки для выполнения анализа единой точки отказа. Разложение рабочей нагрузки и наложение потоков позволяет получить представление о зависимостях, которые являются внутренними и внешними по сравнению с рабочей нагрузкой.
Внутренние зависимости — это компоненты в область рабочей нагрузки, необходимые для функционирования рабочей нагрузки. Типичные внутренние зависимости включают API или решения для управления секретами и ключами, такие как Azure Key Vault. Для этих зависимостей запишите данные о надежности, такие как соглашения об уровне обслуживания о доступности и ограничения масштабирования. Внешние зависимости — это обязательные компоненты за пределами область рабочей нагрузки, например другое приложение или сторонняя служба. К типичным внешним зависимостям относятся решения проверки подлинности, такие как Microsoft Entra ID, и решения для подключения к облаку, такие как Azure ExpressRoute.
Определите и задокументируйте зависимости в рабочей нагрузке и включите их в артефакты документации по потоку.
Точки сбоя
В критических потоках рабочей нагрузки рассмотрите каждый компонент и определите, как на этот компонент и его зависимости может повлиять режим сбоя. Помните, что существует множество режимов сбоя, которые следует учитывать при планировании устойчивости и восстановления. На любой компонент может повлиять несколько режимов сбоя в любой момент времени. К этим режимам сбоя относятся:
Региональный сбой. Весь регион Azure недоступен.
Сбой зоны доступности. Зона доступности Azure недоступна.
Сбой службы. Одна или несколько служб Azure недоступны.
Распределенная атака типа "отказ в обслуживании" (DDoS) или другая вредоносная атака.
Неправильная настройка приложения или компонента.
Ошибка оператора.
Сбой планового обслуживания.
Перегрузка компонента.
Анализ всегда должен находиться в контексте потока, который вы пытаетесь проанализировать, поэтому обязательно задокументируйте влияние на пользователя и ожидаемый результат этого потока. Например, если у вас есть приложение электронной коммерции и вы анализируете поток клиентов, то влияние определенного режима сбоя на один или несколько компонентов может заключаться в том, что все клиенты не могут завершить оформления заказа.
Учитывайте вероятность каждого типа режима сбоя. Некоторые из них очень маловероятны, например сбои в нескольких зонах или нескольких регионах, и добавление планирования мер по устранению рисков, помимо избыточности, не является хорошим использованием ресурсов и времени.
Меры по снижению риска
Стратегии устранения рисков делятся на две широкие категории: повышение устойчивости и проектирование для снижения производительности.
Повышение устойчивости включает в себя избыточность компонентов, таких как инфраструктура, данные и сеть, и обеспечение соответствия архитектуры приложений рекомендациям по обеспечению устойчивости, например разделение монолитных приложений на изолированные приложения и микрослужбы. Дополнительные сведения см. в разделах Рекомендации по избыточности и Рекомендации по самосохранении.
Чтобы спроектировать снижение производительности, определите потенциальные точки сбоя, которые могут отключить один или несколько компонентов потока, но не полностью отключить этот поток. Чтобы обеспечить функциональность сквозного потока, может потребоваться перенаправить один или несколько шагов на другие компоненты или принять, что компонент, завершив ошибку, запускает функцию, поэтому функция больше не доступна в пользовательском интерфейсе. Чтобы вернуться к примеру приложения электронной коммерции, сбой компонента, такого как микрослужба, может привести к недоступности подсистемы рекомендаций, но клиенты по-прежнему могут искать продукты и завершать свою транзакцию.
Кроме того, необходимо спланировать устранение зависимостей. Сильные зависимости играют решающую роль в функционировании и доступности приложений. Если они отсутствуют или возникают неполадки, это может привести к значительному эффекту. Отсутствие слабых зависимостей может повлиять только на определенные функции и не повлиять на общую доступность. Это различие отражает затраты на поддержание связи высокого уровня доступности между службой и ее зависимостями. Классифицируйте зависимости как сильные или слабые, чтобы определить, какие компоненты необходимы для приложения.
Если приложение имеет сильные зависимости, без которых оно не может работать, целевые показатели доступности и восстановления этих зависимостей должны соответствовать целевым объектам самого приложения. Сведите к минимуму зависимости, чтобы обеспечить контроль над надежностью приложения. Дополнительные сведения см. в статье Минимизация координации между службами приложений для достижения масштабируемости.
Если жизненный цикл приложения тесно связан с жизненным циклом его зависимостей, операционная гибкость приложения может быть ограничена, особенно для новых выпусков.
Обнаружение
Обнаружение сбоев важно для правильного определения точек сбоя в анализе и правильного планирования стратегий устранения рисков. Обнаружение в этом контексте означает мониторинг инфраструктуры, данных и приложений, а также оповещение при возникновении проблем. Максимально автоматизируйте обнаружение и создайте избыточность в операционных процессах, чтобы оповещения всегда перехватывались и реагировали на них достаточно быстро в соответствии с бизнес-требованиями. Дополнительные сведения см. в статье Рекомендации по мониторингу.
Результат
Для результатов анализа создайте набор документов, которые эффективно сообщают результаты, принятые вами решения относительно компонентов потока и их устранения, а также влияние сбоя на рабочую нагрузку.
При анализе определите приоритеты режимов сбоев и стратегий устранения рисков, которые вы определили на основе серьезности и вероятности. Используйте это определение приоритетов, чтобы сосредоточиться в документации на тех режимах сбоя, которые являются распространенным и достаточно серьезными, чтобы оправдывать затраты времени, усилий и ресурсов на разработку стратегий устранения рисков. Например, могут быть некоторые режимы сбоя, которые очень редки при возникновении или обнаружении. Разработка стратегий устранения рисков не стоит затрат.
Отправную точку документации см. в приведенном ниже примере таблицы .
Во время первоначального упражнения 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 экземплярах с 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 | Сбой в регионе | Очень низкий | Отработка отказа группы автоматической отработки отказа в дополнительный регион. Потенциальный сбой во время отработки отказа. Целевые значения времени восстановления (RTO) и целевые точки восстановления (RPO), которые необходимо определить во время тестирования надежности. | Потенциальный полный |
| Azure SQL | Сбой зоны доступности | Низкий | Не влияет | Нет |
| Azure SQL | Злонамеренная атака (внедрение) | Средний | Минимальный риск. Все экземпляры Azure SQL привязаны к виртуальной сети через частные конечные точки, а группы безопасности сети (NSG) добавляют дополнительную защиту внутри виртуальной сети. | Потенциальный низкий риск |
| Служба приложений | Простой службы | Низкий | Полный сбой рабочей нагрузки. Зависит от корпорации Майкрософт для исправления. | Полное |
| Служба приложений | Сбой в регионе | Очень низкий | Минимальный эффект. Задержка для пользователей в затронутых регионах. Azure Front Door автоматически направляет трафик в неисправные регионы. | Нет |
| Служба приложений | Сбой зоны доступности | Низкий | Не влияет. Службы приложений были развернуты как избыточные между зонами. Без избыточности между зонами существует потенциал для эффекта. | Нет |
| Служба приложений | Атака DDoS | Средний | Минимальный эффект. Входящий трафик защищен Azure Front Door и Azure Брандмауэр веб-приложений. | Нет |
Связанные ссылки
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по