# 评估具体改进
<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%。实施新算法是一种工作量极小的替代方案，涉及的风险很低。