你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

有关响应实时性能问题的建议

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

PE:11 响应实时性能问题。 通过纳入明确的沟通和职责,规划如何解决性能问题。 当出现问题时,请使用所学知识来确定预防措施,并将其纳入工作负载。 实现方法,在发生类似情况时更快地恢复正常操作。

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

定义

术语 定义
数据关联 协调工作负载各个部分的日志、指标和事件,找出根本原因。
根本原因分析 用于识别导致问题的根本因素的过程。
自我修复 无需人工干预即可自动修复问题。
自我预防 工作负载中的实现,以防止潜在的问题和故障。

关键设计策略

遇到实时性能问题时,需要准备好正确的数据和计划来响应问题。 此计划应包括明确的沟通和责任。 主要目标是实现有助于快速恢复常规操作并提供事件见解的解决方案。 将预防措施集成到工作流中是一项关键策略。 目标是防止同一问题再次发生,或者减少对性能的影响(如果不可预防)。

为问题做好准备

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

  • 具有准确的体系结构关系图。 体系结构关系图应包含所有组件,并显示它们如何交互。 可视化表示有助于识别可能导致性能下降或不可用的瓶颈和单一故障点。 理想情况下,可以在这些问题导致问题之前捕获并删除这些问题,但拥有最新的图表可以帮助你在高压力时刻查明问题。

  • 检查数据访问。 监视过程中的数据和日志对于实时响应性能问题和进行根本原因分析至关重要。 但维护数据的完整性和机密性非常重要。 响应实时站点性能问题通常需要访问通常无法访问的基础数据。 你需要确保人员在出现问题时能够访问他们所需的数据。 但应仅授予时间限制的最小特权访问权限,并且应将访问权限限制为授权人员。

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

创建会审计划

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

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

  • 升级过程:定义明确的升级过程,以确保性能问题及时上报给相应的团队或个人。 流程定义应包括有关上报问题的联系信息和指南。

  • 根本原因分析:开发用于执行根本原因分析的过程,以确定每个性能问题的根本原因。 此过程应包括分析日志和性能指标,并执行诊断测试以查明每个问题的根源。

  • 优先级:建立优先级框架以确定性能问题的严重性,并根据性能问题对工作负载和用户的影响确定其优先级。

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

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

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

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

使用根本原因分析

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

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

  2. 定义问题。 通过识别症状和问题对工作负载或用户的影响来明确定义问题。

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

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

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

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

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

权衡:根本原因分析的步骤(例如确定可能的原因、测试假设和记录分析)可能很耗时。 若要关联性能问题,还需要收集和存储数据。 所需的时间和基础结构可能会为运营团队增加大量工作,并增加工作负荷的成本。

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

联系供应商支持

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

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

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

从发现中吸取教训

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

文档应说明如何防止每个问题再次发生。 避免反复出现的问题的一种方法是引入自动化来响应常见问题。 自动化应为工作负荷添加自我修复和自我预防品质。 除了自动化,还可以创建优化警报,帮助你及早响应性能问题指标。

Azure 简化

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

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

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

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

性能效率清单

请参阅完整的建议集。