首先选择正确的组件并建立性能目标，然后继续测量和监视工作负荷的行为。 成熟后，你将整合真正的用户反馈来优化方法，利用生产见解进行有针对性的改进，并最终通过试验和自动化实现高级优化。 每个阶段都基于上一阶段，将性能策略从被动故障排除转变为主动效率工程。
建立明确的性能预期，并选择与要求相符的适当大小的组件。
成熟度模型的级别 1 侧重于收集性能预期，并选择有助于满足这些期望的云服务。 在此级别，你将分析这些资源和组件，以找到最合适的。 确定仅提供必要性能功能的服务的优先级。 此方法有助于控制成本和维护开发速度。
关键策略
请与利益干系人合作，了解工作负荷性能的一般预期。 这些期望可能包括 Web 应用的页面加载时间或交互式系统的响应时间的目标。 在工作负荷开发的这一阶段，将这些目标视为指导方针而不是硬性要求，因为你的重点还不是衡量性能指标。 收集工作负荷预期后，开始调查可能适合工作负荷的资源类型。
• 选择适当的网络资源
评估网络需求，以确定适合工作负荷的适当服务和配置。 考虑网络流量、带宽、延迟和吞吐量，确保网络有效支持工作负荷。 使用专用虚拟网络和主干网络来降低延迟。
确保网络流量均匀分布，以防止服务器过载并减少响应时间。 评估云提供商提供的不同 负载均衡服务 。 考虑流量类型、全局或区域路由、服务级别目标以及站点加速和低延迟负载均衡等特定功能。
风险： 花时间来全面调查和了解 基础网络的不同选项。 在此区域中的后续更改可能需要完全重新设计和重新部署。
• 选择适当的计算资源
评估工作负荷的计算需求，包括实例类型、可伸缩性和服务层。 考虑容器化，通过隔离、资源效率、快速启动时间和可移植性来实现性能提升。
选择可满足需求的 计算服务 ，同时允许随着工作负荷的发展而轻松缩放。 构建工作负荷是一个迭代过程。 可以通过使用性能较低的 SKU 和更少的实例从小规模开始。 稍后在工作负荷的生命周期中升级这些组件。
折衷： 根据预算权衡你的即时需求。 查找在不使用计算资源时关闭或解除分配计算资源的机会。
• 选择适当的数据存储服务
确定工作负荷存储、检索和管理数据的需求。 考虑以下特征：
根据这些问题的解答，为每个工作负荷的用例 选择最佳数据服务 。
由于云环境中数据服务的各种选项，可以定制设计，以使用不同的服务来最好地匹配工作负荷中每个组件的功能。 此方法可帮助你优化每个组件的性能。
权衡：不要因使用多个数据服务而使您的数据组件过度设计，而应将可以合并的组件整合到单一数据存储中。 在性能与成本和复杂性之间取得平衡。
实现全面的性能监视，以便深入了解工作负荷的行为并确定优化机会。
性能效率支柱的第 2 级侧重于如何使用有关工作负载的信息来指导性能优化。 第一步是从性能角度确定关键工作负荷流。 接下来，将工作负荷分解为其组件，并设置可衡量的目标和指标，以便捕获和分析将来的优化。 最后，应调查有助于提高性能效率并执行初始容量规划练习的设计模式。 这些活动可帮助你为工作负荷的短期建立计划。 此方法可确保工作负荷的发展时性能不会受到影响。
关键策略
对工作负荷流进行排名和分类是每个 Well-Architected 框架支柱中的重要策略。 从每个支柱的角度分析流有助于确定需要优化的领域。 可以比较这些优化，以帮助确定投资位置。 例如，在某些情况下，安全考虑可能优先于性能考虑。 在对流量进行分类和排序后，重点关注您认定为关键的流，以开始优化规划。 可帮助你识别关键流的与性能相关的条件包括：
频率： 执行流的次数，例如搜索产品。
关键性：某个流程对应用程序整体成功的重要程度，例如用户资料查找。
风险： 流在总体性能上存在的风险级别，例如生成复杂的报表。
数据密集型： 流对数据层施加的压力量。
体系结构密集型： 流在整个工作负荷中与组件交互的程度。
• 为工作负载资源和组件建立关键指标，帮助你实现目标
根据市场研究、竞争分析和调查为工作负荷组件和资源设置性能目标。 专注于关键指标，例如响应时间、吞吐量和延迟。 为不同的组件、用户流、工作流、数据流、外部依赖项和总体工作负荷性能建立目标。
为每个指标设置实际且可衡量的目标，同时牢记客户期望。 使用 P99、P95 和 P50 等百分位来全面了解情况。 执行测试以建立基线性能，但不要过度强调优化。
记录开发和运营团队可访问的集中位置中的所有性能目标。 使用仪表板和报表使目标可见且可作。
容量规划是一个迭代过程，应在工作负荷的生命周期内定期执行。 在此阶段，你可能尚未完全熟悉使用的所有技术，或者可能仍在评估不同的选项。 这种不确定性可以限制你全面规划未来需求的能力。 对于此初始容量规划练习，目标是从被动容量管理转变，其中包括添加资源以满足即时需求。 相反，重点在于主动规划，可在其中预测定义的时间段所需的容量。 若要实现有效的容量规划，请收集和分析有关资源使用情况的数据，包括现有工作负荷的历史模式。 使用统计分析、趋势分析和预测建模来预测未来需求。 确保这些预测符合工作负荷目标。
风险： 在传统的基于数据中心的环境中，过度预配是容量规划的常见方法。 在云环境中，过度预配可能会浪费资金。 仔细考虑业务预期，制定一个时间线，以满足性能需求的方式添加容量，而不会对预算产生负面影响。
有许多常见的应用程序设计模式可以帮助你优化工作负荷的性能。 可以通过添加缓存或开发分片策略来实现性能提升。 有关可能有助于增强工作负荷的模式的综合列表，请参阅 云设计模式。
折衷： 某些设计模式可能会为工作负荷增加一定程度的复杂性。 将额外的管理负担与效率提升进行比较，以确定特定模式是否值得实施。
代码优化使整个工作负荷更高效。 应用程序任务运行速度更快，使用更少的计算资源，以便最大程度地提高基础结构的性能。 请考虑以下代码优化方法：
检测代码。 为代码添加检测功能有助于您通过运行时收集遥测数据识别性能问题。 此过程有助于在开发周期的早期识别和解决问题。
确定关键路径。 为代码添加检测功能有助于您识别关键路径。 热路径是需要高性能和低延迟的程序的基本或高使用率部分。
优化代码逻辑。 查找简化代码逻辑以提高效率的方法。 删除不必要的函数调用和数据处理作。 最大程度地减少日志记录作、网络请求和内存分配。 寻找使用更高性能 SDK 和库的机会。
使用并发和并行。 使用并发和并行性可以通过有效管理多个任务来提高应用程序的效率。 并发通过在多个任务之间切换来处理，而并行则同时处理多个任务。
收集应用程序性能数据，例如吞吐量、延迟和完成时间，以确定瓶颈并提高用户体验。 使用分布式跟踪和结构化日志记录来简化分析。 收集所有资源的指标和日志。 使用 Azure Monitor Insights 等工具进行性能监视。 收集数据库和存储数据，并收集虚拟机的性能指标。 将所有收集的数据存储在一个位置，以便轻松访问和分析。
风险： 确保设置日志轮换和保留策略，因为收集和存储的数据量可能会迅速增长，成本可能会意外增加。
利用真正的用户见解和系统反馈来推动增强用户体验的目标性能改进。
性能效率支柱级别 3 侧重于整合内部和外部信号，以优化性能目标、工作负荷设计和配置以及相关的作实践。 在早期的成熟度级别中，可能已根据开发速度需求和内部测试设置性能目标和配置。 随着工作负荷的发展，结合内部和外部用户及利益相关者的反馈，有助于确保生产工作负荷的实际性能目标。 此方法允许你满足这些目标，而不会影响其他支柱的要求。
关键策略
迁移到生产意味着必须准备好立即响应性能问题。 可靠的性能监视和有用的可作警报有助于确保正确的团队收到问题通知，并且可以快速开始调查和故障排除活动。 以下策略可帮助你定义性能问题响应活动：
作为性能监控策略的一部分，确保您能专门监控各个流程的性能。 了解每个流对工作负荷性能的影响。 对于流，请通过用户行为见解识别潜在问题。 跟踪响应时间、错误和其他指标以优化关键流。 分析日志以跟踪流性能并识别问题。
定期查看内部和外部用户对性能的反馈，以评估目标是否符合预期。 请考虑使用客户满意度轮询、评论系统和目标用户测试来收集有用的反馈。
在适用于您的工作负载的情况下，考虑使用真实用户监控（RUM）方法。 此方法可帮助你确定用户体验是否满足你对性能的期望。 Application Insights 和 Azure 流量管理器 提供用于捕获网站的 RUM 数据的功能。
使用与您的目标和指标一致的度量来跟踪应用的性能。 将这些指标与用户和业务利益干系人反馈进行比较，以确保收集正确的数据。 使与业务相关的指标与性能数据分开，以便于分析，即使存在某些重叠也是如此。 此方法使数据更加清晰，并帮助团队做出明智的决策。
分析趋势有助于规划容量要求。 更新预测以匹配工作负荷目标和用户需求，以便始终有足够的资源。 定期查看云提供商的服务级别协议，以确保可以根据需要添加资源，而不会遇到服务限制。
随着容量规划的发展，请与业务决策者密切合作，以保持与业务目标一致。
折衷： 通过可靠性和预算要求平衡性能容量规划。 与利益干系人合作，在要求冲突时找到实际妥协。
✓ 优化缩放策略
采用高级缩放技术来优化资源使用情况。 根据内部和外部反馈调整用于缩放操作的阈值。 构建自动化方案，以对缺乏原生自动扩缩能力的组件执行扩缩操作。 对那些在每日、每周或每月中有可预测的轻负载或空闲时间的组件使用计划扩缩。 持续评估缩放配置并进行优化，以更好地满足工作负荷的波动需求。
• 优化数据管理
数据管理效率低下可能会导致工作负荷的性能问题。 使用以下策略优化数据资产：
将大型数据集或工作负荷划分为较小的部分，称为 分区，用于单独的存储或处理。 此方法可实现并行处理、减少争用，并提高资源使用和处理时间。 它还在多个存储设备之间分配数据，从而减少单个负载并提高整体性能。 将分区类型与特定用例对齐。 分区可以是水平、垂直或功能，具体取决于系统的需求。 有关使用分区的设计模式的详细信息，请参阅 性能效率设计模式。
使用 Azure SQL 数据库的查询性能见解等功能优化查询。
考虑规范化、索引和分区等因素，确保数据模型非常适合工作负荷。
通过优化缓冲区大小和缓存等设置，使存储基础结构符合工作负载要求。
设计性能测试，可帮助你了解工作负载在不同生产方案中的表现。 根据条件和指标采用各种测试，例如负载、压力、浸泡、峰值和兼容性测试。 测量每个测试如何影响工作负荷性能。 指标应包括响应时间、吞吐量、内存和 CPU 使用率等性能方面。 定义与目标一致的验收条件。 有关详细信息，请参阅性能测试的建议。
性能测试应在专用环境中作为总体测试策略的一部分进行。 此方法包括可靠性和安全测试。
查看测试结果以查明瓶颈和效率低下。 将结果与目标、预定义条件或以前的运行进行比较。
折衷： 测试环境可能是主要成本驱动因素。 仅设计具有必要资源的测试环境，以准确模拟要测试的特定方案。 若要最大程度地降低使用成本，请确保在测试后关闭或删除资源。
风险： 如果需要使用生产数据，请确保在将数据复制到测试环境之前删除敏感数据。 在实际情况下使用合成数据。
另一个关键测试函数是生成性能基线。 基线提供参考点，用于比较一段时间内的性能。 确定性能指标并将其用作基线指标。 根据这些基线评估将来的性能，以确定改进或降级。 定期查看和更新基线以捕获更新的设计元素和功能。 随着工作负载的成熟和新功能的添加，过时的基线可能会导致不切实际且无法实现的目标。
培养持续改进的环境，让团队从生产中学习，倾听内部和外部反馈。 为工作负荷团队配备必要的技能和思维模式，以优化性能并处理需求波动。 分配用于监视和解决性能问题的时间。 使用可见的性能目标、基线和可接受的偏差阈值设置明确的预期。
通过数据驱动的决策和主动优化将生产见解转换为系统性能增强功能。
成熟度模型的级别 4 假设工作负荷处于生产阶段，并且已足够长时间运行，以便收集有关其通常如何运行的有用见解。 在此级别，应使用此信息进行必要的更新和进一步改进。
使用遥测和反馈机制确定性能问题（如瓶颈）并制定改进计划。 使用成熟的变更管理做法来确保在对环境进行更改时不会无意中引起更多问题。
请记住，迭代改进达到减少回报点。 需要确定何时达到满足要求的运行状态。 可接受的状态是，修复效率低下的成本和负担不会超过你获得的轻微性能改进。
请记住，您为提高性能而对环境所做的任何更改都会直接影响 Well-Architected 框架的其他支柱。 成本优化是最常见的折中方案。 在进行性能改进之前，请仔细评估对其他支柱的影响，以保持对需求的适当平衡。
关键策略
在第 4 级，您应该监视和测试生产环境中的性能。 你应该已经制定了良好的测试计划和方案和测试数据。 测试的目标是在生产环境中出现潜在性能问题之前捕获它们。 因此，监视和测试应严格、规范和全面记录。 请考虑以下建议：
持续地重新评估基线。 应用从性能监视中学到的内容，以确保基线反映实际性能指标。 请务必维护基线，因为针对该基线运行测试以确保功能更新等部署不会对性能产生负面影响。
将测试前移。 在开发周期早期进行测试，以便在问题进入生产环境之前发现潜在问题。
将测试后移。 在生产环境中进行测试。 若要确保测试不会造成干扰，请使用蓝绿部署和 A/B 测试等策略。
在测试中使用模拟事务。 合成事务允许你稳定地测试真实世界的用户体验。 这些测试有助于在用户受到影响之前识别问题和潜在改进。
自动监视和测试。 使用业界验证过的工具，对照基线进行监控与告警自动化，以及性能测试。 自动化可减少手动步骤并确保一致性。
折衷： 在生产环境中进行测试可能非常复杂，通常需要 DevOps 团队做出大量努力。 这些要求可能会影响开发速度和其他作功能。 蓝绿部署和 A/B 测试还可以在测试时使用重复资源向工作负荷添加成本。 在预算和开发规划中包括这些注意事项。
• 实现高级数据管理优化
在级别 4 中，应已实施许多数据管理优化策略。 结合生产环境的经验，进一步优化和调整数据管理，确保工作负载在持续演进中高效运行。
使用无损和有损的数据压缩来降低数据占用。 此方法有助于节省存储空间和带宽使用量，并可能导致更快的数据传输和访问时间。
为很少使用或不再使用的数据开发和实现存档和删除策略。 将数据移到单独的、成本较低的存储或将其完全删除，以帮助节省存储空间和带宽使用量。
根据生产体验微调缓存和分片策略。
将数据复制到靠近用户的区域，以减少延迟。 某些数据库技术（如 Azure Cosmos DB）提供跨多个区域的可读和可写副本。 在跨区域部署工作负荷时，副本会进一步降低延迟。
在工作负荷监视解决方案中包含存储性能监视。 违反存储限制时，性能问题可能会很快出现。 当超过阈值时，许多云存储服务会施加限制，这会导致影响下游应用程序功能的瓶颈。 监视存储性能和监视趋势有助于主动避免限制。
• 通过隔离优化关键流
在实际情况下，隔离关键流以防止资源争用并简化管理。 请考虑以下策略：
折衷： 通过专用资源隔离流比跨流共享资源更昂贵。 在实现此方法之前执行成本效益分析，以确保它是用例的最佳方法。
✓ 扩展从生产经验中获得的代码优化
重新访问之前在工作负荷开发中所做的代码优化，以查找需要进一步增强的区域。 例如，现在应该有来自生产环境的遥测数据，有助于查找内存泄漏等低效问题。 还可以确认使用生产运行时数据标识的热路径，或者找到意外的热路径。
优化操作任务
病毒扫描、机密轮换、备份、索引优化（如重组或重新生成）和部署等作任务都会影响工作负荷的性能。 优化其效率可让工作负荷平稳运行。 请考虑以下策略来优化这些类型的任务：
调查并测试可用于确定它们是否可以帮助你提高效率的新平台功能。 持续监控这些新增内容的反馈和性能指标，以改进您的方案。
折衷： 请注意云平台如何将功能打包到 SKU 中。 某些为当前用例提供更高的性能的 SKU 可能会过度预配，但它们可能会节省将来迁移的时间和精力。
折衷： 采用某些类型的服务可能意味着迁移应用程序或数据，这可能会导致停机才能完成迁移。 作为评估的一部分，确定是否可以容忍成功迁移所需的停机时间。
• 确定优化工作的优先级
主动优化性能意味着在出现问题之前通过识别瓶颈并实施优化来提高工作负荷的效率。 根据分析，通过代码更改、基础结构调整或配置更新进行特定改进。
通过试验、自动化和尖端优化技术实现最佳性能，从而提供可衡量的业务价值。
成熟度模型的级别 5 侧重于确定在工作负载中做出有价值的性能优化的机会。 采用基于试验的方法进行优化。 重新审视工作负载设计领域，例如部署实践、监视和调试，以及运营自动化，以寻求进一步改进。 通过定期评审工作负荷设计和作实践，采用持续改进思维模式。 使用既定的变更管理流程来确保安全高效地实施改进。
关键策略
采取主动方法来通过试验提高效率。 首先提出一个关于工作负载更新的假设，该假设应能够根据观察到的性能数据——这些数据已识别出瓶颈或效率低下——来实现预期的可衡量的性能提升。 构建一个测试环境，以尽可能多地模拟实际条件来验证或驳斥假设。 证明假设后，评估更改的回报（ROI），以确定它是否值得实施。 在 ROI 评估中包括所有 Azure Well-Architected 框架支柱。 如果为了其他支柱而进行的权衡是可以接受的，那么这些变更通常值得推进。
• 优化部署和功能发布
在级别 5 中，应具有可靠的标准化升级过程。 在此级别，重新评估流程以确定当前策略是否最适合运营效率。 评估蓝绿、Canary 或其他部署模型是否符合组织的需求。 考虑使用功能标志，以便更轻松地向特定用户组推出和回滚功能。 确保备份策略支持快速恢复到已知良好状态。
• 优化监视和调试过程
从组件收集日志和遥测数据本质上会影响性能。 测量监视平台对工作负荷的影响，包括日志记录、遥测、检测和远程调试等元素。 确定优化机会。 如果其中任一进程比提高可观测性更降低性能，请考虑重新配置或禁用它们。 作为持续改进实践的一部分，请定期查看收集的监视数据，以确保仅收集所需的性能见解最有价值的信息。
重新评估性能警报，以确定是否只收到有价值的警报。 删除不可操作的警报，并重新配置那些没有提供足够信息以清楚了解性能问题和受影响组件性质的警报。
扩展运营自动化
寻找扩大作任务的自动化以提高效率的机会。 应在第5级中自动化许多重复的操作任务，因此请全面审视操作情况，以确定其他有价值的自动化目标。 请考虑以下与性能相关的任务：
性能测试： 使用成熟的行业标准工具来模拟工作负荷。
部署： 实现持续集成和持续部署工具，以实现一致且高效的部署。
事件管理： 自动执行警报路由、票证创建和分配。
补救措施： 自动执行重启服务和调整资源分配等操作。
自我修复机制： 生成功能以自动修复已知性能问题。