# 評估特定改進
<a name="evaluate-specific-improvements"></a>

 了解您的工作負載佈建以完成工作單位的資源。評估潛在的改進，並估計其潛在影響、實作成本，以及關聯的風險。

 若要測量隨著時間的改進，請先了解您已佈建的內容， AWS 以及這些資源的取用方式。

 從 AWS 用量的完整概觀開始，並使用 AWS 成本和用量報告來協助識別熱點。使用此 [AWS 範例程式碼](https://github.com/aws-samples/aws-usage-queries)，藉助 Amazon Athena 來協助您審查並分析您的報告。

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

 當評估特定的變更時，您還必須評估哪些指標最能量化該變更對關聯資源的影響。這些指標稱為*代理指標*。選取代理指標，最能反映您評估的改進類型，以及作為改進目標的資源。這些指標可能會隨著時間而演進。

 佈建以支援工作負載的資源包括運算、儲存和網路資源。使用您的代理指標評估佈建的資源，以查看如何耗用這些資源。

 使用您的代理指標來測量為了實現業務成果而佈建的資源。


|  **Resource**  |  **範例代理指標**  |  **改進目標**  | 
| --- | --- | --- | 
|  運算  |  vCPU 分鐘  |  所佈建資源的最大使用率  | 
|  儲存  |  佈建的 GB  |  減少總佈建量  | 
|  網路  |  傳輸的 GB 或傳輸的封包  |  減少總傳輸量和傳輸距離  | 

## 業務指標
<a name="business-metrics"></a>

 選取業務指標來量化業務成果的實現程度。您的業務指標應反映工作負載提供的值，例如同時作用中使用者的數量、服務的API呼叫數量或完成的交易數量。這些指標可能會隨著時間而演進。在評估財務型業務指標時要謹慎，因為交易價值的不一致性會使比較無效。

## 關鍵績效指標
<a name="key-performance-indicators"></a>

 使用下列公式，將佈建的資源除以所實現的業務成果，以確定每工作單位的佈建資源。

![\[顯示此公式的圖表：每個工作單位佈建的資源 = 所佈建資源的代理指標 / 成果的業務指標\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/sustainability-pillar/images/key-performance-indicators-formula.png)


 使用每個工作單位的資源作為 KPIs。根據佈建的資源建立基準，作為比較基礎。


|  **Resource**  |  **範例 KPIs**  |  **改進目標**  | 
| --- | --- | --- | 
|  運算  |  每筆交易 vCPU 分鐘  |  所佈建資源的最大使用率  | 
|  儲存  |  每筆交易 GB  |  減少總佈建量  | 
|  網路  |  每筆交易傳輸的 GB 或每筆交易傳輸的封包  |  減少總傳輸量和傳輸距離  | 

## 估計改進
<a name="estimate-improvement"></a>

 將改進同時估計為所佈建資源的定量減少 (如您的代理指標所示)，以及每個工作單位佈建的基準資源的變更百分比。


|  **Resource**  |  **範例 KPIs**  |  **改進目標**  | 
| --- | --- | --- | 
|  運算  |  每次交易減少 % vCPUs 分鐘  |  最大化使用率  | 
|  儲存  |  每筆交易 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％。實作新的演算法是一種不費力的替代方案，而涉及的風險很低。