# 改進程序
<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 成本和用量報告來協助識別熱點。使用此 [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％。實作新的演算法是一種不費力的替代方案，而涉及的風險很低。

# 確定改進的優先順序和規劃改進
<a name="prioritize-and-plan-improvements"></a>

 根據成本最低且風險可接受的最大預期影響，確定您所識別之改進的優先順序。

 決定最初要專注哪些改進，並將其包括在您的資源規劃和開發藍圖中。

 將此步驟套用至[範例藍本](improvement-process.md#example-scenario)，您可以確定目標改進的優先順序，如下所示：


|  **優先順序**  |  **改進**  |  **潛在**  |  **成本**  |  **風險**  | 
| --- | --- | --- | --- | --- | 
|  1  |  實作更有效的壓縮機制  |  高  |  低  |  低  | 
|  2  |  實作預測性擴展  |  中  |  低  |  低  | 

 更新檔案壓縮的高潛力、低成本和風險，讓其成為貴公司的高價值目標，且優先於實作預測性擴展。您確定實作具有中等潛在影響、低成本和低風險的預測性擴展，應該是在檔案壓縮完成之後的優先改善。

 您指派團隊成員，以實作改進的檔案壓縮，並將預測性擴展新增至您的待處理項目。

# 測試和驗證改進
<a name="test-and-validate-improvements"></a>

 執行最小投資的小型測試，以降低大規模工作的風險。

 在測試環境中實作工作負載的代表性副本，以限制執行測試和驗證的成本和風險。執行一組預先定義的測試交易、測量佈建的資源，並確定每工作單位使用的資源來建立測試基準。

 在測試環境中實作目標改進，並在相同條件下使用相同的方法重複測試。然後，透過適當的改進來測量佈建的資源和每工作單位使用的資源。

 從每工作單位佈建的資源基準計算百分比變化，並確定預期定量減少生產環境中佈建的資源。針對預期值比較這些值。確定結果是否為可接受的改進等級。評估耗用的其他資源中的任何權衡是否使得改進的淨收益不可接受。

 確定改進是否成功，以及是否應投入資源，實作生產環境中的變更。如果此時更改被評估為不成功，請重定導向您的資源，來測試並驗證您的下一個目標，並繼續您的改進週期。


|  **每個工作單位佈建的資源中的 % 減少**  |  **所佈建資源中的定量減少**  |  **Action**  | 
| --- | --- | --- | 
|  已符合期望  |  已符合期望  |  繼續改進  | 
|  不符合期望  |  已符合期望  |  繼續改進  | 
|  已符合期望  |  不符合期望  |  追求替代改進  | 
|  不符合期望  |  不符合期望  |  追求替代改進  | 

 將此步驟套用至[範例藍本](improvement-process.md#example-scenario)後，您可以執行測試來驗證成功。

在您對改進的壓縮演算法執行測試之後，每個工作單元所佈建資源 (原始影像和修改後影像所需的儲存空間) 中的減少百分比已符合期望，佈建的儲存空間平均減少 30%，而增加的運算負載可忽略不計。

您確定將改進的壓縮演算法套用至生產環境中現有檔案所需的額外運算資源，相比於所實現的儲存空間減少微不足道。您已確認成功減少所需資源 （TBs 儲存體），且已核准生產部署的改進。

# 將變更部署至生產環境
<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 有益減少。這些改進歸功於高度最佳化的程式碼。

 您建立一個內部開放原始碼專案，您可以在其中分享您的程式碼、相關聯的成品、有關如何實作變更的指引，以及實作結果。內部開放原始碼專案可讓您的團隊輕鬆地針對其所有持續的檔案儲存使用案例採用程式碼。您的團隊會採用改進作為標準。內部開放原始碼專案的次要好處是，採用解決方案的每個人都可以從對解決方案的改進中獲益，而且任何人都可以為專案的改進做出貢獻。

 您發布您的成功並在您的整個組織中分享開放原始碼專案。採用解決方案的每個團隊都以最少的投資複製收益，並將其新增至從您的投資中獲得的淨收益。您將此資料發布為持續成功案例。

 您將繼續監控改進在一段時間後的影響，並視需要對內部開放原始碼專案進行變更。