Рекомендации по выполнению анализа видов отказа
Применимо к этой рекомендации Power Platform контрольного списка надежности, хорошо продуманной архитектуры:
| РЕ:03 | Используйте анализ типов отказов (FMA) для выявления и определения приоритетности потенциальных сбоев в компонентах вашего решения. Выполните анализ типов отказов, чтобы оценить риск и влияние каждого типа отказа. Определите, как рабочая нагрузка реагирует и восстанавливается. |
|---|
В этом руководстве описаны передовые методики выполнения анализа видов отказа (FMA) для вашей рабочей нагрузки. Анализ видов отказа (FMA) — это методика определения потенциальных точек отказа в рабочей нагрузке и связанных с ней потоках и планирование соответствующих действий по их устранению. На каждом этапе потока вы определяете радиус поражения нескольких типов сбоев, что помогает вам разработать новую рабочую нагрузку или реорганизовать существующую, чтобы минимизировать распространенное влияние сбоев.
Ключевой принцип FMA заключается в том, что сбои случаются независимо от того, сколько уровней устойчивости вы применяете. Более сложные среды подвержены большему количеству типов сбоев. Учитывая эту реальность, FMA позволяет вам спроектировать рабочую нагрузку так, чтобы она выдерживала большинство типов сбоев и корректно восстанавливалась в случае возникновения сбоя.
Если вы пропустите анализ FMA полностью или выполните неполный анализ, ваша рабочая нагрузка подвергнется риску непредсказуемого поведения и потенциальных сбоев, вызванных субоптимальным проектированием.
Определения
| Термин | Определение |
|---|---|
| Вид отказа | Тип проблемы, которая может привести к ухудшению качества или серьезному повреждению одного или нескольких компонентов рабочей нагрузки до такой степени, что они станут недоступными. |
| Устранение | Действия, которые вы определили для решения проблем в режиме упреждения или реагирования. |
| Обнаружение | Процессы и процедуры мониторинга ваших данных и приложений, а также оповещения. |
Ключевые стратегии проектирования
В контексте анализа FMA понимание предварительных условий имеет решающее значение. Начните с рассмотрения и реализации рекомендаций по выявлению потоков, расстановке их приоритетности на основе критичности. Артефакты данных играют ключевую роль в описании путей данных в этих потоках. Применяя подход FMA, сосредоточьтесь на планировании компонентов критических потоков, выявлении зависимостей (как внутренних, так и внешних) и разработке стратегий устранения рисков.
Предварительные условия
Просмотрите и внедрите рекомендации по выявлению и оценке потоков. Предполагается, что вы определили пользовательские и системные потоки и расставили приоритеты на основе критичности.
Данные, которые вы собрали, и артефакты, которые вы создали в своей работе, дают вам конкретное описание ваших путей данных, участвующих в потоках. Для достижения успешности FMA точность и тщательность ваших артефактов имеют решающее значение.
Подход FMA
После определения критических потоков можно спланировать их необходимые компоненты. Затем шаг за шагом проверяйте каждый поток, чтобы определить зависимости, включая сторонние службы и потенциальные точки сбоя, и спланируйте стратегии устранения рисков.
Разделение рабочей нагрузки на составные части
По мере перехода от идеи к проектированию вам необходимо определить типы компонентов, которые необходимы для поддержки вашей рабочей нагрузки. Ваша рабочая нагрузка определяет необходимые компоненты, которые вы должны запланировать.
После создания первоначального проекта архитектуры вы можете накладывать потоки, чтобы идентифицировать отдельные компоненты, которые используются в этих потоках, и создавать списки или диаграммы рабочих процессов, описывающие потоки и их компоненты. Чтобы понять критичность компонентов, используйте определения критичности, которые вы назначили потокам. Учитывайте влияние неисправности компонента на ваши потоки.
Определение зависимостей
Определите зависимости рабочей нагрузки, чтобы выполнить анализ единой точки отказа. Разделение вашей рабочей нагрузки на составные части и наложение потоков позволяет понять зависимости, которые являются внутренними и внешними по отношению к рабочей нагрузке.
Внутренние зависимости — это компоненты в области рабочей нагрузки, необходимые для функционирования рабочей нагрузки. Типичные внутренние зависимости включают API или решения для управления секретами и ключами, такие как Azure Key Vault. Для этих зависимостей нужно собрать данные о надежности, такие как соглашения об уровнях обслуживания (SLA) и ограничения масштабирования. Внешние зависимости — это требуемые компоненты, выходящие за рамки рабочей нагрузки, например другое приложение или сторонняя служба. Типичные внешние зависимости включают решения для аутентификации, такие как Microsoft Entra ID и инфраструктура Power Platform.
Определите и задокументируйте зависимости в вашей рабочей нагрузке и включите их в артефакты документации по потоку.
Точки отказа
В критических потоках вашей рабочей нагрузки рассмотрите каждый компонент и определите, как на этот компонент и его зависимости может повлиять вид отказа. Помните, что существует множество видов отказов, которые следует учитывать при планировании устойчивости и восстановления. Любой компонент может быть подвержен воздействию более чем одного вида отказа в любой момент времени. К этим видам отказа относятся:
- Региональный сбой: недоступна вся платформа Power Platform или регион Azure
- Сбой службы: одна или несколько служб Power Platform или Azure недоступны
- Распределённая атака "отказ в обслуживании" (DDoS) или другая вредоносная атака
- Неправильная конфигурация приложения или компонента
- Ошибка оператора
- Сбой планового обслуживания
- Перегрузка компонента
Изучите вероятность каждого вида отказа. Некоторые из них очень маловероятны, например, сбои в нескольких зонах или регионах, а добавление планирования действий для устранения рисков помимо резервирования не является эффективным использованием ресурсов и времени.
Устранение
Стратегии по устранению рисков делятся на две большие категории: повышение устойчивости и разработка решений для снижения производительности.
Повышение отказоустойчивости означает, что проект вашего приложения соответствует лучшим практикам обеспечения надежности. К ним относятся разделение монолитных приложения на изолированные приложения и микрослужбы и использование предоставляемых платформой конфигураций устойчивости, включая политики повторных попыток. Для получения дополнительной информации см. Рекомендации по резервированию и Рекомендации по самосохранению.
Чтобы спроектировать решение для снижения производительности, определите потенциальные точки отказов, которые могут отключить один или несколько компонентов вашего потока, но не отключают этот поток полностью. Чтобы сохранить функциональность сквозного потока, вам может потребоваться перенаправить один или несколько шагов на другие компоненты или признать, что неисправный компонент запускает функцию, поэтому функция больше не доступна в пользовательском интерфейсе. Возвращаясь к примеру приложения электронной коммерции: неисправный компонент, такой как микрослужба, может привести к тому, что ваша служба рекомендаций станет недоступна, но клиенты все равно смогут искать продукты и совершать транзакции.
Вам также необходимо спланировать устранение рисков зависимостей. Сильные зависимости играют решающую роль в функционировании и доступности приложения. Если они отсутствуют или работают неправильно, это может иметь серьезные последствия. Отсутствие слабых зависимостей может повлиять только на отдельные функции и не влиять на общую доступность. Это различие отражает затраты на поддержание отношений высокого уровня доступности между службой и ее зависимостями. Классифицируйте зависимости как сильные или слабые, чтобы определить, какие компоненты важны для приложения.
Если приложение имеет сильные зависимости, без которых оно не может работать, цели доступности и восстановления этих зависимостей должны соответствовать целям самого приложения. Если жизненный цикл приложения тесно связан с жизненным циклом его зависимостей, операционная гибкость приложения может быть ограничена, особенно для новых выпусков.
Обнаружение
Обнаружение отказов необходимо для того, чтобы вы правильно определили точки отказов в своем анализе и правильно спланировали стратегии их устранения. В этом контексте обнаружение означает мониторинг вашей инфраструктуры, данных и приложений, а также отправка оповещений при возникновении проблем. Максимально автоматизируйте процесс обнаружения и обеспечьте резервирование своих рабочих процессов, чтобы гарантировать, что оповещения всегда доставляются и на них реагируют достаточно быстро, чтобы удовлетворить ваши бизнес-требования. Дополнительные сведения см. в разделе Рекомендации для мониторинга.
Результат
В качестве результата анализа создайте набор документов, в которых будут эффективно отражены ваши выводы, решения, которые вы приняли в отношении компонентов потока и мер по их устранению, а также влияние сбоя на вашу рабочую нагрузку.
В своем анализе расставьте приоритеты видов отказов и стратегий их устранения, которые вы определили, исходя из серьезности и вероятности. Используйте эту расстановку приоритетов, чтобы ваша документации отражала те виды отказов, которые являются распространенными и достаточно серьезными, чтобы оправдать трату времени, усилий и ресурсов на разработку стратегий устранения рисков. Например, могут существовать некоторые виды отказов, которые возникают или обнаруживаются очень редко. Разработка стратегий устранения рисков на их основе не стоит понесенных затрат.
Обратитесь к примеру таблицы, чтобы использовать ее как отправную точку для составления документации.
Во время первоначального применения анализа FMA документы, которые вы создаете, будут в основном представлять собой теоретическое планирование. Документы FMA следует регулярно пересматривать и обновлять, чтобы они соответствовали вашей рабочей нагрузке. Тестирование в условиях хаоса и реальный опыт помогут вам со временем усовершенствовать анализ.
Пример
В следующей таблице показан пример FMA для приложения учета расходов, размещенного как приложение Power Apps на основе холста с серверной частью Microsoft Dataverse и API-интерфейсами, размещенными в APIM, для взаимодействия со сторонней системой.
Поток пользователя: вход пользователя в систему, подача заявки на расходы и взаимодействие с отчетом о расходах
| Компонент | Риск | Вероятность | Последствие/смягчение/примечание | Сбой |
|---|---|---|---|---|
| ИД Microsoft Entra | Сбой службы | Низкая | Полный сбой рабочей нагрузки. Зависит от Microsoft исправления. | Полный |
| ИД Microsoft Entra | Неправильная конфигурация | Средняя | Пользователи не могут войти в систему. Нет последствий для последующих процессов. Служба поддержки сообщает о проблеме с конфигурацией команде по идентификации. | None |
| Power Apps | Сбой службы | Низкая | Полный сбой для внешних пользователей. Зависит от Microsoft исправления. | Полный |
| Power Apps | Региональный сбой | Очень низкое | Полный сбой для внешних пользователей. Зависит от Microsoft исправления. | Полный |
| Power Apps | DDoS-атака | Средняя | Возможность прерывания работы. Microsoft управляет защитой от DDoS-атак (L3 и L4). | Возможность частичного сбоя |
| Dataverse | Сбой службы | Низкая | Полный сбой рабочей нагрузки. Зависит от Microsoft исправления. | Полный |
| Dataverse | Региональный сбой | Очень низкое | Группа автоматической отработки отказа переключается на дополнительный регион. Возможный сбой во время аварийного переключения. Целевые значения времени восстановления (RTO) и целевые точки восстановления (RPO) должны быть определены в ходе тестирования надежности. | Полный потенциал |
| Dataverse | Вредоносная атака (внедрение) | Средняя | Минимальный риск. | Потенциальный низкий риск |
| Управление API | Сбой службы | Низкая | Полный сбой для внешних пользователей. Зависит от Microsoft исправления. | Полный |
| Управление API | Региональный сбой | Очень низкое | Полный сбой для внешних пользователей. Зависит от Microsoft исправления. | Полный |
| Управление API | DDoS-атака | Средняя | Возможность прерывания работы. Microsoft управляет защитой от DDoS-атак (L3 и L4). | Возможность частичного сбоя |
| Ваше решение Power Platform | Неправильная конфигурация | Средняя | Неправильные конфигурации должны быть обнаружены во время развертывания. Если это происходит во время обновления конфигурации, администраторы должны отменить изменения. Обновление конфигурации вызывает кратковременный внешний сбой. | Возможность полного сбоя |
Возможности в Power Platform
Power Platform интегрируется с Application Insights, которая является частью экосистемы Azure Monitor. Вы можете использовать эту интеграцию следующим образом:
Подписаться на получение телеметрии, полученной платформой Dataverse в Application Insights по диагностике, производительности и операциям, которые приложения выполняют на вашей базе данных Dataverse и в приложениях на основе модели. Эта телеметрия предоставляет информацию, которую можно использовать для диагностики и устранения проблем, связанных с ошибками и производительностью.
Подключите свои приложения на основе холста к Application Insights, чтобы использовать эту аналитику для диагностики проблем, изучения действий пользователей в ваших приложениях, принятия более эффективных бизнес-решений и улучшения качества приложений.
Настройте Power Automate телеметрию для передачи в Application Insights. Вы можете использовать эту телеметрию для мониторинга выполнения облачных потоков и создания оповещений о сбоях этого выполнения.
Собирайте данные телеметрии от вашего Microsoft Copilot Studio второго пилота для использования в Azure Application Insights. Вы можете использовать эту телеметрию для мониторинга зарегистрированных сообщений и событий, отправляемых вашему второму пилоту и получаемых от него, тем, которые будут запускаться во время разговоров пользователей, а также пользовательских событий телеметрии, которые могут отправляться из ваших тем.
Power Platform ресурсы регистрируют действия на Microsoft портале соответствия требованиям Purview. Большинство событий доступны в течение 24 часов после их наступления. Не используйте эту информацию для мониторинга в реальном времени. Дополнительную информацию о регистрации действий в Power Platform см. в разделе:
- Power Apps
- Power Automate
- Copilot Studio
- Power Pages
- Power Platform разъемы
- Предотвращение потери данных
- Power Platform административные журналы
- Dataverse аудит
Контрольный список надежности
Обратитесь к полному набору рекомендаций.