用于响应实时性能问题的体系结构策略

适用于此 Azure Well-Architected 框架性能效率清单建议：

本指南介绍响应实时性能问题的最佳做法。 实时性能问题是指实时挑战和瓶颈，这些挑战和瓶颈可能会阻碍工作负荷的最佳运行。 及时解决这些问题不仅有助于立即检测和纠正性能问题，而且还可确保工作负荷始终满足其性能基准。 未能解决这些问题可能会导致复杂性，包括减速、崩溃和系统无响应，并降低用户体验。 他们还可以防止用户有效地完成任务，反过来又会玷污组织的声誉。

定义

遇到实时性能问题时，需要准备好正确的数据和响应问题的计划。 此计划应包括明确的沟通和责任线。 主要目标是实现有助于快速返回常规作并提供事件见解的解决方案。 将预防措施集成到工作流中是一项关键策略。 目标是防止同一问题再次发生，或者如果无法预防，则降低其对性能的影响。

准备问题

对实时站点性能问题的理想响应是精确而快速的。 性能修正的精度和速度需要准备。 为了有效响应实时性能问题，监视关键性能指标、确定问题的根本原因并实施适当的解决方案或优化至关重要。 若要执行这些步骤，可能需要分析工作负荷日志、执行性能测试、优化代码或配置以及缩放资源。 以下示例概述了一些关键准备领域：

• 具有准确的体系结构关系图。 体系结构关系图应包括所有组件并显示它们如何交互。 视觉表示有助于识别可能导致性能下降或不可用的瓶颈和单一故障点。 理想情况下，可以在这些问题导致问题之前捕获和删除这些问题，但有一个 up-to日期关系图可以帮助你找出高压力时刻的问题。

• 检查数据访问。 监视过程中的数据和日志对于实时响应性能问题并执行根本原因分析至关重要。 但是，必须保持数据的完整性和机密性。 响应实时站点性能问题通常需要访问可能无法正常访问的基础数据。 你需要确保人员有权访问出现问题时所需的数据。 但是，应仅授予时间限制、最低特权访问权限，并且应限制对已授权人员的访问权限。

• 设置自动警报。 警报可帮助你识别并解决问题。 当工作负荷性能偏离性能基线时，警报应生成通知。 随着时间的推移，应调整警报配置，以避免生成过多或太少的通知。 使用监视解决方案需要收集足够的数据来生成警报。 这些警报应与性能目标和已建立的基线保持一致。 应避免针对与目标相关的问题生成警报。 警报示例包括 CPU 使用率、内存、响应时间和数据库性能下降。

创建会审计划

创建会审计划涉及设计结构化方法来识别、升级、分析、确定优先级并传达实时站点性能问题。 会审计划是响应实时性能问题的策略。 它可确保通过明确的角色和过程及时有效地解决性能中断。 大多数性能问题不值得灾难恢复协议，但它们可能会影响足以要求会审规划的工作负荷功能。 记录良好的会审计划可确保所有团队成员保持一致，并且可以迅速采取行动，最大限度地减少对用户和工作负载的影响。 会审计划应包括以下组件：

• 识别和监视：实现系统来实时识别和监视性能问题。 你应该有一个列表，其中列出了能够做出决策或将问题提升到更高级别的人员的联系信息。 该计划还应确定角色和责任。 它需要记录哪些帐户有权访问受保护信息，以及访问多长时间。

• 升级过程：定义明确的升级过程，以确保及时将性能问题升级到相应的团队或个人。 流程定义应包括联系信息和升级问题的指南。

• 根本原因分析：制定用于执行根本原因分析的过程，以确定每个性能问题的根本原因。 此过程应涉及分析日志和性能指标，并执行诊断测试来查明每个问题的来源。

• 优先级：建立优先顺序框架，确定性能问题的严重性，并根据他们对工作负荷和用户的影响确定优先级。

• 沟通：创建沟通计划，让利益干系人了解性能问题和解决进度。 请考虑定期更新、状态报告和明确的通信渠道。

• 文档：记录会审计划，包括其所有步骤、流程和最佳做法。 参与应对性能问题的团队成员可以轻松访问本文档。

开发用于识别和解决问题的方法

解决实时性能问题涉及识别和解决任何可能导致实时工作负荷性能下降或效率低下的因素。 调查和解决与性能相关的事件时，监视期间收集的数据非常有用。 此数据提供性能指标的历史记录。 如果监视数据可用，可以分析根本原因并确定贡献因素。 应使用所有相关监视数据来了解和修复每个性能问题。

使用根本原因分析

根本原因分析需要假设测试。 查看监视数据后，应列出性能问题的潜在原因并对其进行测试。 若要对实时性能问题进行根本原因分析，可以按照以下步骤作：

1. 收集信息。 收集有关性能问题的尽可能多的信息。 示例包括错误消息、日志、性能指标和任何其他相关数据。

2. 定义问题。 通过识别问题对工作负荷或用户产生的症状和效果来明确定义问题。

3. 调查潜在原因。 通过确定发生性能问题的工作负荷的特定组件或区域来缩小分析范围。 根据收集的信息确定性能问题的潜在原因。 此过程可以涉及分析代码、配置设置、基础结构或外部依赖项。

4. 关联数据。 深入了解收集的数据，以确定可能导致性能问题的模式、异常或相关性。 数据关联是识别性能问题和原因的关键。 它可能涉及查看日志、分析性能指标和执行测试。

5. 测试假设。 根据你确定的潜在原因制定假设。 执行测试来验证或驳斥假设。 应使用测试环境来查看是否可以复制错误。

6. 实现解决方案。 确定根本原因后，开发和实现解决性能问题的解决方案。

7. 监视和验证。 实现解决方案后，请持续监视工作负荷，以确保性能问题得到解决。 通过监视性能指标和用户反馈来验证解决方案的有效性。

权衡：根本原因分析的步骤（例如识别可能的原因、测试假设和记录分析）可能很耗时。 若要关联性能问题，还需要收集和存储数据。 所需的时间和基础结构可以为运营团队增加大量工作，并为工作负荷带来成本。

风险：如果在没有适当的安全防护措施的情况下执行根本原因分析，则提供对日志和数据的访问权限时，可能会公开敏感信息。

参与供应商支持

处理正在进行的性能问题时，供应商支持可能是一个重要步骤。 供应商具有专业知识、工具、资源和经验，可帮助解决其产品的问题。 与供应商的支持协议决定了供应商提供的支持级别。

最好与供应商并行工作。 你应该创建一个计划，让一些团队成员与供应商支持人员协作，而另一些团队成员则继续会审并修复性能问题。 供应商支持团队还可以就如何帮助防止和自动响应类似事件提出建议。

你需要为你的人员提供联系信息。 供应商可能还需要访问数据，以有效地参与解决问题。 你需要制定一个计划，以便对外部帐户或来宾帐户进行身份验证和授权以访问监视数据。

从发现中学习

修复实时站点性能问题后，需要查看所发生的情况。 目标是从性能问题中吸取教训，而不仅仅是识别问题。 学习的最佳方法是通过文档。 记录每个问题，并说明如何修复此问题。 如果供应商有所帮助，请与供应商合作，以增强文档、培训团队并相应地修改工作负荷。

文档应指示如何防止每个问题再次发生。 避免重复问题的一种方法是引入自动化来响应常见问题。 自动化应将自我修复和自我预防质量添加到工作负荷。 除了自动化之外，还可以创建优化警报，帮助你尽早响应性能问题指标。

Azure 便利化

开发用于识别和解决问题的方法：Azure 提供了多种工具来帮助你响应实时性能问题：

• Azure Monitor 是一种全面的监视解决方案，可深入了解应用程序和基础结构的性能和运行状况。 监视提供指标、日志、警报和仪表板等功能，以帮助监视和诊断性能问题。

• Application Insights 是一项应用程序性能管理（APM）服务，可帮助开发人员和 DevOps 专业人员监视实时应用程序。 它会自动检测性能异常、收集应用程序级日志和事件，并提供用于诊断问题的分析工具。

• Log Analytics 是一项服务，它从各种源（包括应用程序、虚拟机和 Azure 资源）收集和分析日志数据。 使用 Log Analytics 时，可以查询和分析日志数据，以便深入了解应用程序的性能和行为。

相关链接

• 自我修复和自我保护的建议

性能效率清单

请参阅完整的建议集。