# 改善您的工作負載
<a name="improving-your-workload"></a>

 此時，您已準備好執行 WAFR、完成審查，並根據 AWS 最佳實務評估工作負載。

 WAFR 的輸出將根據審查期間擷取的答案來識別架構風險。這些風險分類為*高風險問題 (HRI)* 和*中等風險問題 (MRI)*。

 在最後一個階段，您將建立改進計畫，其中包括建立風險清單、了解風險對您業務的影響、找出解決方案，以及根據組織的優先事項實作這些解決方案。

 下列各節提供工作負載改進程序的詳細指引：
+  識別並了解風險 
+  確定規範解決方案 
+  排定改善的優先順序 
+  實作並追蹤改進 

 下列週期顯示 WAFR *改進*階段中包含的主要步驟。

![\[改進週期\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/userguide/images/improvement_cycle.png)


# 識別並了解風險
<a name="identify-and-understand-risks"></a>

 將識別出的風險視為改善機會。

 WAFR 環境中有兩種風險類別：*高風險問題 (HRI)* 和*中等風險問題 (MRI)*。
+  **高風險問題 (HRI)**：可能會對業務造成重大負面影響的架構和操作選擇。高風險最佳實務視為支柱內必須實施的基礎實務。這些可能會影響組織營運、資產和個人。安全支柱的 HRI 範例：沒有保護好您的 AWS 帳戶。
+  **中等風險問題 (MRI)**：同樣可能對您的業務造成負面影響，但程度低於 HRI 的選擇。中等風險最佳實務代表可實質改善工作負載的可行實務。安全支柱的 MRI 範例：沒有定期稽核和輪換憑證。

## 產生報告
<a name="generating-a-report"></a>

 目視找出 HRI 和 MRI 的第一步是產生報告，以顯示您檢閱的每個工作負載的風險。

 [AWS Well-Architected Tool (AWS WA Tool )儀表板](https://docs.aws.amazon.com/wellarchitected/latest/userguide/dashboard.html)可讓您存取工作負載及其相關聯的 HRI 和 MRI。您也可以包含已與您共用的工作負載。您可以使用儀表板，依工作負載、支柱或嚴重性 (高或中等) 篩選問題。

 在儀表板頁面中，您可以查看依支柱或嚴重性篩選的 HRI 和 MRI 清單。選取改善項目後，您便會從 Well-Architected Framework 直接前往與其相關聯的最佳實務。在該處，您可以閱讀有關補救問題所需的建議動作，以及必要的資源。

 您可以從 WA Tool 儀表板選擇[產生報告](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-report.html)，將所有調查結果合併在一份報告中。

 我們建議您將回顧電子郵件與報告一起傳送給 WAFR 出席者，並摘要說明重要的調查結果和建議的改進計畫，幫助他們準備進行下一步。

## 管理風險
<a name="managing-risks"></a>

 為了有效管理風險，務必定義風險及其可接受層級。透過風險分析，探索有哪些潛在問題，以及如何判斷這些是否為問題。

 有兩種主要方法可以進行風險評估：
+  **量化：**使用加權目標資料來評估風險在成本超支、資源消耗和排程延遲方面的影響。
+  **質性：**使用與成本或效益的實際價值無關的主觀資料來評量機率和整體影響。

 在某些情況下，您可能最終會使用結合兩種方法優點的混合方法，來評估風險的影響。

 根據 HRI 和 MRI 定義評估風險層級時，請考慮提出下列問題：
+  風險造成影響的可能性為何？ 
+  客戶會受到什麼影響？ 
+  可能造成什麼樣的業務影響？ 
+  可完全排除或只能緩解風險？ 
+  誰有此風險？ 
+  誰負責消除或緩解的改善工作？ 
+  此結果再次發生的機率是多少？ 是否可能造成相同的影響？ 
+  是否能找出結果的可能性與週期模式之間的關係？ 

 請主要利害關係人或業務負責人回答這些問題，這樣將有助於建立一份需要關注的最重要風險清單，以及解決這些風險預計的時間。

## 風險程度
<a name="risk-magnitude"></a>

 您可以使用下表來協助您判斷風險程度：


|  可能性 x 影響  |  可忽略 (1)  |  輕微 (2)  |  中等 (3)  |  重大 (4)  |  嚴重 (5)  | 
| --- | --- | --- | --- | --- | --- | 
|  幾乎確定 (5)  |  5  |  10  |  15  |  20  |  25  | 
|  很可能 (4)  |  4  |  8  |  12  |  26  |  20  | 
|  可能 (3)  |  3  |  6  |  9  |  12  |  15  | 
|  不太可能 (2)  |  2  |  4  |  6  |  8  |  10  | 
|  少見 (1)  |  1  |  2  |  3  |  4  |  5  | 

 彼此合作，一起探討 HRI 和 MRI，以及兩者對業務帶來的風險。建立需要解決的 HRI 清單。根據業務重要性將風險排名，以建立優先順序。

# 確定規範解決方案
<a name="determine-prescriptive-solutions"></a>

 了解組織環境中的風險和改善機會後，請與團隊合作找出緩解措施。在此階段，每個團隊都需要處理在其領域中找到的 HRI，並確定解決 HRI 的規範解決方案。

 此步驟可能需要額外進行研究、討論，或建立概念驗證。在此階段中，務必不要花太多時間投入解決方案的實作詳細資訊。如果您確定須優先處理所述 HRI，稍後將會進一步深入探討。

 此步驟的目的是了解解決方案的複雜性以及所需的資源，讓您可以在根據時間、複雜性和影響來排定任務的優先順序時，將其納入考量。

 彼此合作，一起收集可行的 HRI 解決方案清單。保持關注大範圍的資訊，且不要深入實作詳細資訊。

# 排定改善的優先順序
<a name="prioritize-improvements"></a>

 組織的時間和資源都有限。一次解決所有識別出的 HRI 和 MRI，可能不是充分利用 WAFR 的適當方式。

 從可能對業務造成最大影響且較容易實作的幾個精選問題開始著手。處理解決方案。追蹤改進，然後反覆執行該方法。

## 排定實作的優先順序
<a name="prioritize-for-implementation"></a>

 有一種可協助您視覺化解決方案優先順序的方法，那就是 [Eisenhower 樣式圖](https://www.eisenhower.me/eisenhower-matrix/)。有不同的方式可使用此工具。評估時，請考慮改進的重要性 (可為業務帶來多少價值) 以及實作改進的工作 (所需時間、實作複雜性或人數)。

![\[Eisenhower 圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/userguide/images/eisenhower.png)


 此分析的輸出提供一組對您的業務影響最大的風險，但不會太複雜而無法實作。這些都是在第一次迭代中開始實作的良好選擇。

## 解決方案特性
<a name="solution-characteristics"></a>

 針對識別出的風險選取解決方案時，請考慮下列事項：
+  [https://www.forbes.com/advisor/business/smart-goals/](https://www.forbes.com/advisor/business/smart-goals/)考慮具體、可衡量、可實現、相關且有時效性 (SMART) 的目標。
+  **擁有者：**確定每個解決方案的擁有者。
+  **簡單優先於複雜：**雖然複雜的解決方案可以運作，但會使得改進更難以實作，而且可能需要更長的時間才能建立。除非複雜解決方案是不可妥協的需求，否則選擇單純，而非複雜。
+  [https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/)解決方案應可擴展，並旨在隨時間改進和演進。可能的話，請避免無法隨架構發展而調整的靜態解決方案。
+  **目標模式型解決方案：**考慮可編碼、重複使用和重新共用的解決方案。切勿浪費時間做重複的事情。如需範例，請前往 [AWS 架構中心](https://aws.amazon.com/architecture/)。
+  **以團隊形式持續運作：**彼此合作，以建立 HRI 的解決方案清單。在 Eisenhower 矩陣中優先處理這份清單。

# 實作並追蹤改進
<a name="implement-and-track-improvements"></a>

 理想的成功實作結果是減少 HRI 和 MRI，進而改善工作負載的架構運作狀態。

 使用 WA Tool 中記錄工作負載在特定時間點之狀態的里程碑，反覆實作補救措施。每次進行檢閱工作階段，或完成改進項目時，請儲存里程碑以隨時衡量進度。

## 敏捷的 WAFR
<a name="wafr-in-agile"></a>

 WAFR 優先順序練習的輸出，可用來安排開發團隊的衝刺和待辦項目票證的優先順序。開發人員應該能夠了解實作的影響，並擁有改善架構運作狀態的貢獻。WAFR 改進和追蹤可以整合在敏捷回顧會議中。

 回顧會議是在迭代或衝刺結束時舉行的會議。在回顧會議期間，團隊會回顧迭代中發生的情況，並找出未來改進的動作。這是一個理想的機制，可納入 WAFR 審查進行討論，並讓成員具備架構運作狀態方面的能力。

## 時間軸
<a name="timeline"></a>

 這些步驟的時間表隨每個組織而異，因為每個組織皆不同且擁有獨特的挑戰。不過，許多 AWS 的客戶成功執行 WAFR 之後，我們建議此階段需要 90 到 180 天。

 如果您的 HRI 和 MRI 清單需要更長的時間，請重新安排其優先順序，並設法縮短清單，以便您可以開始實施程序以獲得一些改善。然後對其餘項目重複進行。

## WAFR 之後的時間表
<a name="timeline-after-the-wafr"></a>

 **WAFR 後一天：**

1. 建立改進計畫的回顧電子郵件，並摘要：
   + 審查對象
   + 重要的調查結果
   + 後續步驟的時間表

1. 附加改進計畫

1. 引導團隊進行規劃

 **WAFR 後兩到三天：**

1. 建立 HRI 優先順序會議，並優先處理 HRI：
   + 依努力
   + 依影響
   + 與負責工作負載的團隊合作

1. 對業務真正重要的事項進行協作

 **WAFR 後一週：**

1. 展開改進計畫

1. 請考慮下列建議：
   + **持續時間：**90 或 180 天
   + 確定 HRI 優先順序
   + 針對每一項擬定緩解措施
   + 嘗試充分利用計劃來解決多個 HRI

 **例行任務：**

1. 定調有關改進計畫的後續會議

1. 檢閱改進工作負載所要採取的動作

1. 請考慮下列建議：
   + 訂下出席者期望
   + 傳送 WA 問題連結給出席者
   + 進行後續審查