# 改进流程
<a name="improvement-process"></a>

 架构改进流程包括了解您拥有什么以及您可以采取哪些改进措施，选择改进目标，测试改进，采用成功的改进，量化您取得的成功并分享您学到的经验，以便可以在其他地方复制，然后重复该流程。

 改进目标可以是：
+  消除浪费、利用率低以及闲置或未使用的资源 
+  最大程度发挥所消耗资源的价值 

**注意**  
使用预置的所有资源，以最少的资源完成同样的工作。

 在优化的早期阶段，首先解决浪费或低利用率问题，然后转向适合特定工作负载的更有针对性的优化项。

 监控资源消耗情况随时间的变化。确定累积变化导致资源消耗效率低下或显著增加的地方。确定要进行哪些改进来应对消耗变化情况，再按优先顺序实施改进。

 以下步骤旨在构成一个迭代流程，可针对以可持续性为重点的云工作负载改进进行评估、优先顺序确定、测试和部署。

1.  **确定改进目标：**根据本文档中确定的可持续性最佳实践审核工作负载，确定需要改进的目标。

1.  **评估具体改进：**对潜在改进的具体变更、预计成本和业务风险进行评估。

1.  **确定改进的优先顺序并制定计划：**优先考虑能以最低的成本和风险带来最大改进的变更，并制定测试和实施计划。

1.  **测试并验证改进：**在测试环境中实施变更，验证变更的改进潜力。

1.  **将变更部署到生产环境：**在生产环境中实施变更。

1.  **衡量结果并复制成功：**寻找能在工作负载之间复制成功案例的机会，如遇不可接受的结果，则还原所做的变更。

## 示例方案
<a name="example-scenario"></a>

 本文档会在后文引用以下示例场景，用以说明改进流程的每个步骤。

 贵公司的工作负载在 Amazon EC2 实例上执行复杂的图像处理，将修改后的文件和原始文件存储起来供用户访问。处理活动会占用大量 CPU 资源，输出文件也非常大。

# 确定改进目标
<a name="identify-targets-for-improvement"></a>

 了解有助于实现可持续性目标的最佳实践。您可以在本文档的后文找到这些[最佳实践](best-practices-for-sustainability-in-the-cloud.md)的详细描述和改进建议。

 审核工作负载及其所用资源。确定大型部署和常用资源这样的*热点*。评估这些热点，从中寻找机会来提高资源的有效利用率，从而减少实现业务成果所需的总资源。

 根据最佳实践审核工作负载，确定需要改进的候选项。

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可将以下最佳实践确定为可能的改进目标：
+  使用最少的硬件来满足需求 
+  使用最能支持数据访问和存储模式的技术 

## 资源
<a name="resources-1"></a>
+  [优化您的 AWS 基础设施以实现可持续性，第 I 部分：计算](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/) 
+  [优化您的 AWS 基础设施以实现可持续性，第 II 部分：存储](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) 
+  [优化您的 AWS 基础设施以实现可持续性，第 III 部分：联网](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 

# 评估具体改进
<a name="evaluate-specific-improvements"></a>

 了解工作负载为完成工作单元而预置的资源。评估潜在改进，并预估这些改进的潜在影响、实施成本以及相关风险。

 要衡量一段时间内的改进，首先要了解已在 AWS 中预置的资源以及这些资源的消耗情况。

 从全面概述您的 AWS 使用情况开始，再使用 AWS 成本和使用情况报告来帮助确定热点。若采用了 Amazon Athena，此 [AWS 示例代码](https://github.com/aws-samples/aws-usage-queries)有助于您查看和分析自己的报告。

## 代理指标
<a name="proxy-metrics"></a>

 在评估具体变更时，还必须评估哪些指标最能量化该变更对关联资源的影响。这些指标即被称为*代理指标*。选择最能反映您正在评估的改进类型和改进所针对的资源的代理指标。这些指标可能会随时间发生变化。

 为支持工作负载而预置的资源包括计算、存储及网络资源。使用代理指标评估预置资源，了解这些资源的消耗情况。

 使用代理指标来衡量为实现业务成果而预置的资源。


|  **资源**  |  **代理指标示例**  |  **改进目标**  | 
| --- | --- | --- | 
|  计算  |  vCPU 分钟数  |  最大程度提高预置资源的利用率  | 
|  存储  |  预置的 GB 数  |  减少预置的总量  | 
|  网络  |  传输的 GB 数或传输的数据包数  |  缩短传输总距离和传输距离  | 

## 业务指标
<a name="business-metrics"></a>

 选择业务指标，量化业务成果的实现情况。业务指标应反映工作负载提供的价值，例如：并发活跃用户数、已处理的 API 调用数或已完成的事务数。这些指标可能会随时间发生变化。在评估基于财务的业务指标时要谨慎，因为事务值不一致会导致比较无效。

## 关键绩效指标
<a name="key-performance-indicators"></a>

 使用以下公式，将预置的资源除以实现的业务成果，由此确定每个工作单元的预置资源。

![\[图中显示了公式：每个工作单元的预置资源 = 预置资源的代理指标/成果的业务指标\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/sustainability-pillar/images/key-performance-indicators-formula.png)


 将每个工作单元的资源用作 KPI。根据预置资源建立基准，作为比较的基础。


|  **资源**  |  **KPI 示例**  |  **改进目标**  | 
| --- | --- | --- | 
|  计算  |  每个事务的 vCPU 分钟数  |  最大程度提高预置资源的利用率  | 
|  存储  |  每个事务的 GB 数  |  减少预置的总量  | 
|  网络  |  每个事务传输的 GB 数或每个事务传输的数据包数  |  缩短传输总距离和传输距离  | 

## 预估改进
<a name="estimate-improvement"></a>

 根据预置资源的减少数量（如代理指标所示），以及每个工作单元的预置基准资源的百分比变化情况，预估改进的情况。


|  **资源**  |  **KPI 示例**  |  **改进目标**  | 
| --- | --- | --- | 
|  计算  |  每个事务 vCPU 分钟数降幅（%）  |  最大程度提高利用率  | 
|  存储  |  每个事务 GB 数降幅（%）  |  减少预置的总量  | 
|  网络  |  每个事务传输的 GB 数或每个事务传输的数据包数降幅（%）  |  缩短传输总距离和传输距离  | 

## 评估改进
<a name="evaluate-improvements"></a>

 根据预期的净效益评估潜在改进。评估实施与维护的时间、成本和工作量以及业务风险，例如意外影响。

 有针对性的改进通常表示所消耗资源类型之间的权衡。例如，为了减少计算消耗量，可以将结果存储起来；为了限制数据传输量，可以在将结果发送给客户端之前处理数据。稍后将进一步讨论这些[权衡](sustainability-as-a-non-functional-requirement.md)。

 在评估工作负载风险时，还应考虑非功能性要求，包括安全性、可靠性、性能效率、成本优化以及改进对运营工作负载的能力的影响。

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可评估目标改进，结果如下：


|  **最佳实践**  |  **有针对性的改进**  |  **潜力**  |  **成本**  |  **风险**  | 
| --- | --- | --- | --- | --- | 
|  使用最少的硬件来满足需求  |  实施预测性扩展来缩短利用率低的期限  |  中  |  低  |  低  | 
|  使用最能支持数据访问和存储模式的技术  |  实施更有效的压缩机制来减少总存储空间和实现该目标的时间  |  高  |  低  |  低  | 

 实施预测性扩展可以减少未充分利用或未使用的实例消耗的 vCPU 小时数。与现有扩展机制相比，预测性扩展机制确有一定优势，消耗的资源量预计降低了 11%。所涉及的成本很低，涵盖了云资源的配置和 Amazon EC2 Auto Scaling 的预测性扩展操作。当需求超出预测时，被动地执行横向扩展会导致性能受限，这便是风险所在。

 实施更有效的压缩会产生显著影响，大幅减少所有原始图像和处理后图像的文件大小，生产中的存储需求预计会降低 25%。实施新算法是一种工作量极小的替代方案，涉及的风险很低。

# 确定改进的优先顺序并制定计划
<a name="prioritize-and-plan-improvements"></a>

 根据最大的预期影响、最低的成本和可接受的风险，确定已确定改进的优先顺序。

 决定最初要重点关注的改进，并将这些改进纳入资源规划和开发路线图中。

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可按以下方式确定目标改进的优先顺序：


|  **优先级**  |  **改进**  |  **潜力**  |  **成本**  |  **风险**  | 
| --- | --- | --- | --- | --- | 
|  1  |  实施更有效的压缩机制  |  高  |  低  |  低  | 
|  2  |  实施预测性扩展  |  中  |  低  |  低  | 

 更新文件压缩机制的高潜力、低成本和风险使其成为贵公司的高价值目标，优先顺序高于实施预测性扩展。在文件压缩完成后，您确定应优先实施具有中等潜在影响、低成本和低风险的预测性扩展。

 您可以指派一名团队成员来实施改进后的文件压缩，为积压工作添加预测性扩展功能。

# 测试并验证改进
<a name="test-and-validate-improvements"></a>

 以最少的投资进行小规模测试，借此降低大规模工作伴随的风险。

 在测试环境中实施工作负载的代表性副本，可限制执行测试和验证工作的成本和风险。执行一组预定义的测试事务、测量预置资源并确定每个工作单元的所用资源，由此建立测试基准。

 在测试环境中实现目标改进，再在相同条件下使用相同方法重复执行测试。然后，根据改进情况，衡量预置资源和每个工作单元的所用资源。

 计算每个工作单元的预置资源相对于基准资源的百分比变化，确定生产环境中预置资源的预期减少数量。将这些值与预期值进行对比。判定结果是否达到可接受的改进水平。评估所耗额外资源的权衡是否会令改进带来的净效益变得不可接受。

 判定改进是否成功，以及是否应投入资源来实施生产变更。如果此时变更被评估为不成功，请重定向资源来测试并验证下一个目标，然后继续推行改进周期。


|  **每个工作单元的预置资源降幅（%）**  |  **预置资源减少数量**  |  **操作**  | 
| --- | --- | --- | 
|  达到期望  |  达到期望  |  继续进行改进  | 
|  未达到预期  |  达到期望  |  继续进行改进  | 
|  达到期望  |  未达到预期  |  寻求替代改进  | 
|  未达到预期  |  未达到预期  |  寻求替代改进  | 

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可执行测试来验证是否成功。

在对改进后的压缩算法进行测试后，每个工作单元的预置资源（原始图像和修改后的图像所需的存储空间）的百分比降幅达到了预期，预置存储空间的平均降幅达到 30%，计算负载的增幅可以忽略不计。

与存储空间实现的降幅相比，您确定将改进后的压缩算法应用于生产环境中的现有文件所需的额外计算资源微不足道。您确认所需资源（存储空间 TB 数）在减少数量方面取得了成功，并且改进也获准用于生产部署。

# 将变更部署到生产
<a name="deploy-changes-to-production"></a>

 实施经过测试、验证和批准的生产改进。使用有限部署进行实施，确认工作负载的功能，测试在有限部署中预置资源和每个工作单元消耗资源的实际减少情况，并检查变更是否会产生意外后果。测试成功后，继续全面部署。

 如果测试失败或者变更造成不可接受的后果，则还原所做的变更。

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可执行以下操作。

 通过蓝绿部署方法，您可以使用有限部署在生产环境中实施变更。针对新部署实例执行的功能测试已成功。原始图像文件和处理后的图像文件的预置存储空间的平均降幅达到 26%。并无任何证据表明压缩新文件会增加计算负载。

 压缩图像文件所花费的时间大幅缩短，这是因为新压缩算法采用了高度优化的代码。

 继续全面部署新版本。

# 衡量结果并复制成功
<a name="measure-results-and-replicate-successes"></a>

按以下方式衡量结果并复制成功：
+ 衡量每个工作单元的预置资源的初步改进情况和预置资源数量减少情况。
+  将初步估计值和测试结果与生产测量值进行比较。确定可能造成差异的因素，并视情况更新估算和测试方法。
+  确定成功和成功度，并与利益相关方分享结果。
+  如因测试失败或变更造成意料外的负面后果而必须还原所做的变更，请确定成因。在可行之时进行迭代，或者评估可实现变更目标的新方法。
+  利用汲取经验，建立标准，并将成功的改进应用于其他同样可以受益的系统。跨团队和组织收集并共享方法、相关构件以及净效益，以便其他人员可以采用您的标准并复制您的成功。
+ 监控每个工作单元的预置资源，跟踪一段时间内的变化情况和总体影响。工作负载的变化或客户使用工作负载的方式都可能会对改进的效果产生影响。如果改进的效果在短期内显著降低，或者随着时间的推移效果累积降低，则重新评估改进机会。
+ 量化一段时间内从您的改进中获得的净效益，包括应用您改进的其他团队获得的效益（若有），以此显示您的改进活动带来的投资回报。

 将此步骤应用于 [示例方案](improvement-process.md#example-scenario)，即可测量以下结果。

 在将新的压缩算法部署并应用于现有图像文件后，工作负载显示存储需求的降幅达到了 23%。

 测量值与初步估计值（25%）基本一致，与测试值（30%）之间的明显差异则是因为测试中使用的图像文件不能代表生产中存在的图像文件。您可以修改测试图像集，更准确地反映生产中的图像。

 该改进被视作完全成功的改进。预置存储空间的总降幅比估计的 25% 少了 2%，但 23% 仍然是可持续性影响方面的巨大改进，同时还实现了同等的成本节省效果。

 变更带来的唯一的意外结果是缩短了执行压缩所需的时间，并相应减少了 vCPU 消耗量。之所以会有这些改进，是因为采用了高度优化的代码。

 您可以建立一个内部开源项目，在其中共享自己的代码、关联的构件、实施变更的指导以及实施结果。内部开源项目让团队可以轻松地将代码用于其所有持久性文件存储应用场景。您的团队可将改进作为标准。内部开源项目的另一好处是，采用该解决方案的每个人都能从解决方案的改进中受益，并且任何人都可以为项目做出改进。

 您可以发布成功案例，在整个组织中共享开源项目。采用该解决方案的每个团队都能以最少的投资复制效益，增加从您的投资中获得的净效益。您将此类资料作为持续的成功案例发布。

 您可以继续监控改进随时间推移产生的影响，也可以根据需要对内部开源项目进行更改。