应对实时性能问题的建议
适用于此 Power Platform Well-Architected 性能效率检查表建议：
| PE：09 | 响应实时性能问题。 通过纳入明确的沟通渠道和职责来规划如何解决绩效问题。 当出现问题时，使用您学到的知识来确定预防措施并将其纳入您的工作负载中。 实施方法，以便在发生类似情况时更快地恢复正常操作。 |
|---|
本指南介绍了响应实时性能问题的最佳实践。 实时性能问题是指可能阻碍工作负载最佳运行的实时挑战和瓶颈。 及时解决这些问题不仅有助于立即检测和纠正性能问题，还可以确保工作负载始终满足其性能基准。 如果不解决这些问题，可能会导致复杂情况，包括速度变慢、崩溃和系统无响应，并降低用户体验。 它们还会阻止用户有效地完成任务，进而损害组织的声誉。
定义
| 术语 | 定义 |
|---|---|
| 数据关联 | 调整工作负载各个部分的日志、指标和事件，以查明根本原因。 |
| 根本原因分析 | 用于确定导致问题的基础因素的过程。 |
| 自我修复 | 无需人工干预即可自动修复问题的能力。 |
| 自我预防 | 工作负载中的实现，以防止潜在问题和故障。 |
关键设计策略
当您遇到实时性能问题时，您需要准备好正确的数据和应对该问题的计划。 该计划应包括明确的沟通渠道和责任。 主要目标是确定性能问题是暂时的还是孤立的，确定性能问题的根本原因，并实施有助于快速恢复正常运营并提供事件洞察的解决方案。 将预防措施集成到您的工作流程中是一项关键策略。 目标是防止同一问题再次发生，或者在无法预防的情况下减轻其对性能的影响。
为问题做好准备
对实时站点性能问题的理想回复是精确和快速的。 性能修复的精度和速度需要做好准备。 为了有效响应实时性能问题，监控关键性能指标、确定问题的根本原因并实施适当的解决方案或优化至关重要。 要执行这些步骤，您可能需要分析工作负载日志、执行性能测试并优化代码或配置。
以下示例概述了准备的几个关键领域：
拥有准确的架构图。 您的架构图应包括所有组件并显示它们如何交互。 可视化表示有助于识别可能导致性能下降或不可用的瓶颈和单点故障。 理想情况下，您可以在这些问题导致问题之前发现并消除这些问题，但拥有最新的图表可以帮助您在高压力时刻查明问题。
检查数据访问权限。 来自监控流程的数据和日志对于实时响应性能问题和进行根本原因分析至关重要。 但维护数据的完整性和机密性很重要。 响应实时站点性能问题通常需要访问通常可能无法访问的基础数据。 您需要确保员工在出现问题时能够访问他们需要的数据。 但是，您应该只授予有时间限制的最低权限访问权限，并且您应该将该访问权限限制为授权人员。
设置自动警报。 警报可以帮助您在问题发生时立即识别和解决问题。 当工作负载性能偏离性能基准时，警报应生成通知。 随着时间的推移，您应该调整警报配置，以避免生成过多或过少的通知。 您使用的监控解决方案需要收集足够的数据来生成警报。 这些警报应与性能目标和已建立的基线对齐。 您应该避免在与您的目标无关的问题上生成提醒。 警报的示例包括回复时间下降、API 调用或插件的性能 Dataverse 以及页面加载。
创建分类计划
创建分类计划涉及设计一种结构化方法来识别、上报、分析、确定优先级和传达实时站点性能问题。 分类计划是一种用于响应实时性能问题的策略。 它确保通过明确的角色和程序及时有效地解决性能中断。 大多数性能问题不需要使用灾难恢复协议，但它们可能会影响工作负载功能，以至于需要分类计划。 有据可查的分类计划可确保所有团队成员保持一致并能够迅速采取行动，从而最大限度地减少对用户和工作负载的影响。 分类计划应包括以下组件：
识别和监控：实施一个系统来实时识别和监控性能问题。 您应该有一个能够做出决策或将问题升级到更高级别的人的联系信息列表。 该计划还应确定角色和职责。 它需要记录哪些账户可以访问受保护的信息以及访问时间。
上报流程：定义明确的上报流程，以确保及时将性能问题上报给适当的团队或个人。 流程定义应包括联系信息和上报问题的指南。
根本原因分析：制定一个流程来执行根本原因分析，以确定每个性能问题的根本原因。 该过程应包括分析日志和性能指标，并执行诊断测试以查明每个问题的根源。
优先级排序：建立优先级框架以确定性能问题的严重性，并根据它们对工作负载和用户的影响确定问题的优先级。
沟通：制定沟通计划，让利益干系人了解性能问题的状态及其解决进度。 考虑定期更新、状态报告和清晰的沟通渠道。
文档：记录分类计划，包括其所有步骤、流程和最佳实践。 参与响应性能问题的团队成员应该可以轻松访问此文档。
开发识别和解决问题的方法
解决实时性能问题涉及识别和解决可能导致实时工作负载性能下降或效率低下的任何因素。 您在监控期间收集的数据对于调查和解决与性能相关的事件非常宝贵。 此数据提供了性能指标的历史记录。 当您有可用的监控数据时，您可以分析根本原因并确定影响因素。 您应该使用所有相关的监控数据来了解和修复每个性能问题。 监控您检测到的瞬态峰值数量，并相应地调整阈值。
使用根本原因分析
根本原因分析需要假设检验。 查看监控数据后，您应该列出性能问题的潜在原因并对其进行测试。
要对实时性能问题进行根本原因分析，跟随以下步骤操作：
收集信息。 收集尽可能多的有关性能问题的信息。 示例包括错误消息、日志、性能指标和任何其他相关数据。 此外，还包括有关报告问题的用户的信息，例如他们的设备、网络和位置。
定义问题。 通过识别症状以及问题对工作负载或用户的影响来明确定义问题。
调查潜在原因。 通过确定出现性能问题的工作负载的特定组件或区域来缩小分析范围。 根据收集的信息确定性能问题的潜在原因。 此过程可能涉及分析代码、配置设置、基础架构或外部依赖项。
关联数据。 更深入地研究收集的数据，以识别可能导致性能问题的模式、异常或相关性。 数据关联是识别性能问题和原因的关键。 它可能涉及查看日志、分析性能指标和执行测试。
检验假设。 根据您确定的潜在原因制定假设。 进行测试以验证或反驳您的假设。 您应该使用测试环境来查看是否可以复制错误。
实施解决方案。 确定根本原因后，制定并实施解决方案以解决性能问题。
监控和验证。 实施解决方案后，请持续监控工作负载以确保性能问题得到解决。 通过监控性能指标和用户反馈来验证解决方案的有效性。
权衡：根本原因分析的步骤（例如确定可能的原因、测试假设和记录分析）可能非常耗时。 要关联性能问题，您还需要收集和存储数据。 所需的时间和基础设施可能会给运营团队增加大量工作，并增加工作负载成本。
风险：如果您在没有适当的安全护栏的情况下执行根本原因分析，则在提供对日志和数据的访问权限时，存在暴露敏感信息的风险。
联系 Microsoft 支持
请联系 Microsoft 支持部门 以帮助解决持续的性能问题。 Microsoft 支持代表不仅拥有解决问题所需的专业知识、工具、资源和经验，而且他们可能还了解可能影响您的工作负载的任何当前全球性能问题或中断。 您的支持协议决定了所提供的支持级别。
通常最好与 Microsoft Support 并行工作。 例如，考虑一种策略，其中一些团队成员与支持人员协作 Microsoft ，而其他团队成员继续分类和修复性能问题。
向团队提供支持联系信息非常重要。 请记住， Microsoft 支持团队可能还需要访问数据才能有效地解决问题。
有关详细信息，请参阅 获取帮助 + 支持 Power Platform。
从调查结果中学习
修复实时站点性能问题后，您需要查看发生的情况。 目标是从性能问题中学习，而不仅仅是发现问题。 最好的学习方式是通过文档。 记录每个问题并说明如何修复它。 如果供应商提供帮助，请与供应商合作以增强您的文档、培训您的团队并相应地修改您的工作负载。
文档应说明如何防止每个问题再次发生。 除了文档之外，您还可以创建精细的警报，以帮助您及早响应性能问题指标。
Power Platform 便利化
Power Platform 和 Azure 提供了多种工具来帮助你应对实时性能问题：
Azure Monitor 是一个全面的监视解决方案，可让您深入了解应用程序和基础结构的性能以及 health。 Azure Monitor 提供指标、日志、警报和仪表板等功能，可帮助你监视和诊断性能问题。 Power Platform 应用和自动化可以使用该功能 Application Insights 与 Azure Monitor 集成。 可以 记录和分析标准遥测以及自定义跟踪事件。
Application Insights 是一项应用程序性能管理（APM）服务，可帮助开发人员和 DevOps 专业人员监控实时应用程序。 它会自动检测性能异常，收集应用程序级日志和事件，并提供分析工具来诊断问题。 Power Platform 集成 Application Insights。
Log Analytics 是一项服务，用于从各种来源（包括应用程序、虚拟机和 Azure 资源）收集和分析日志数据。 使用 Log Analytics 时，您可以查询和分析日志数据，以深入了解应用程序的性能和行为。 如果您的工作负载使用 Azure 资源，请考虑使用 Log Analytics。
Solution Checker 根据一组最佳实践规则对您的解决方案执行丰富的静态分析，并识别有问题的模式。 在将解决方案部署到生产环境之前解决任何与性能相关的问题，以避免实时站点性能问题。
性能效率清单
请参考整套建议。