如何執行 Well-Architected Framework Review - 準備階段

WAFR 的目的是演進系統的架構設計。使系統能夠更有效地支持任務需求、協助組織達到預設目標。在架構設計改進過程中，首先檢核當下的架構設計細節，並與最佳實踐的建議方法進行比較。

熟悉系統任務及技術細節的成員需要通過回答問題的方式來完成「量測（Measure）」。每個支柱的每一組問題都被設計成針對特定領域的最佳實踐，並提出最佳實踐的實作方式。這些問題用以驗證您的系統架構設計是否明確地實做了對應的最佳實踐。根據您的答案，在 AWS Well-Architected Tool（AWS WA Tool）的操作介面上，會顯示相對應的檢核結果。您可以清楚地瞭解每一個題目所涵蓋的項目內容，並且得知目前架構設計是否曝露在高、中或低風險之中。

下一步，則是確定這些風險是否可能對系統或任務造成不良的影響。並將所有被列出的風險項目，基於優先順序的方法制定解決清單，再參考系統所提供的改善計逐步地解決這些問題。接下來，我們將詳細介紹每個階段的步驟。

WAFR 分為三個階段：準備階段、執行審查和改善架構。以下我們將深入探討每個階段，並為您提供最有效的實作方法。

在 WAFR 的準備階段， 大多建議從實際審查日（Review Day）之前的約 3 周開始。當然，這取決於組織審查團隊的時間、要進行審查的支柱數量，或完成審查的優先順序等因素。在此階段，您將決定邀請加入評審會議的團隊成員、要討論的系統服務範圍，以及評審的對話格式。您還需要事先收集有關系統架構的必要資訊、系統觀測數據，或是架構圖，以期審查討論能夠順利進行。在此，我們明確列出五個細項∶

1. 定義工作負載
2. 定義核心團隊
3. 決定檢核範圍
4. 決定進行方式
5. 收集必要資訊

接下來，讓我們更深入地瞭解每一個細項。

準備 WAFR 的第一步是確定哪些工作負載（Workload）是這次進行檢核討論的範圍。

工作負載可以視為在組織中的一群組合元件，其中包括了相對應的系統技術、承包人員，以及工作流程；最終組合出一個可為組織提供任務或產生價值的運作單位。過去有很多客戶認為工作負載即為由  AWS 帳號中的資源、服務與系統構成，但這不是一個恰當的解釋。工作負載範圍可以只對應到系統中的某個子集合，再配合上專屬的功能（Function）以及承包的工作團隊。舉例來說，一個提供客戶在線上購物下單，同時又能夠追蹤訂單狀態的網站，加上支援其後端工作的的基礎架構（Infrastructure）以及開發、佈署、維運與相關服務流程，這才是一個完整的工作負載。

成功的 WAFR，其必要的關鍵組成是從一開始就邀請合適的人進入核心團隊。

確定要進行審查討論的工作負載範圍後，首先需要確定此一工作負載的擁有者或負責人。我們有時稱他們為主辦者（Sponsor）。主辦者在組織內的角色是對工作負載的最終成功或失敗負責的個人或小組。主辦者需要具有足夠的決策級別，用來決定並採取後續行動，解決在審查過程中，被最優先列出的系統架構風險。例如需要有足夠的決策能力來調整團隊的優先工作順序、僱用外部第三方進行系統改善，或其他方面的決策權限。

另外，您還需要確認每個支柱有該支柱的主答人（Pillar Sponsor）。

根據組織的結構和規模，您可能有一個人負責多個支柱，或多個團隊負責同一支柱，或兩者兼而有之。這裡的目標是確保您有合適的人來回答每個支柱的審查問題。支柱的主答者通常是對該工作負載範圍內的技術、業務、流程細節最清楚的成員，或是瞭解技術與資源分配的成員。例如安全性支柱的主答者，可由團隊內的資安專家來擔任。而該支柱的主答者還必須有能力對於範圍內被標識出的風險項目進行解讀，並且評估後續的改進建議及實施方式。

所以，您可以需要邀請來自不同團隊的人員，用更全面地角度來瞭解要審查的支柱。例如∶

• 若要檢核可靠性支柱（Reliability Pillar），需要包括在以下方面的成員及工作內容者一例如：資料庫、網路、安全性和系統維運。
• 若要檢核卓越運營支柱（Performance Efficiency），需要包括企業架構師和應用開發工程師，或業務/財務團隊等。

決定檢核範圍是指在進行細部討論之前，要先決定涵蓋哪些支柱（Pillar）和聚焦（Lens）內容。

最理想的作法是從六大支柱的角度全面瞭解工作負載。建議您遵循 Well-Architected 的框架中列出的支柱順序。從卓越運營支柱開始，繼而安全性、可靠性、性能效率、成本最佳化到永續發展支柱結束。但是，團隊組織因為商業目標的不同，對於服務要求的優先順序也會有所不同。在此階段，決定要審查的支柱順序會需要與組織目標作正確的對應。另外，瞭解支柱的優先次序也有其必要性；例如：大幅改善安全性、可靠性，可能會造成基礎建設的花費增加；而有效且正確地進行資源效能改善，可以明顯地消除過度預估（Over-Provision）進而降低花費成本。

有時，不適當的檢核順序，例如在執行可靠性改善之前即先進行成本最佳化改善，往往無法有效的改善系統架構的穩定性與完整性。又在某些情況下，您可以只關注特定的支柱。例如您更改了部分安全性相關的設定，希望這些改動仍然符合最佳實踐，在這種情況下，您可以選擇僅針對安全性相關問題進行審查討論。

接下來，則要決定是否針對於架構聚焦（AWS Well-Architected Lenses）進行深入討論。

聚焦（Lens）內容提供對於特定的行業和技術領域的最佳實踐。例如，若系統架構主要使用無伺服器（Serverless）技術，則可根據無伺服器聚焦（Serverless Lens）進行討論。如果運行數據分析工作負載，則可在審核中包含數據分析聚焦（Data Analytics Lens）。

在 AWS Well-Architected 的頁面可以看到最新的白皮書清單。而 WA Tool 也在 2023 年末宣布支持內建功能聚焦目錄（Lens Catalog），所有最佳實踐以及問題都可以直接在 WA Tool 中呈現。

根據所選擇支柱的討論範圍以及團隊時間，您需要決定審查的討論方式。您可以將六大支柱的討論安排在同一天，或將選定的支柱分散在多天的多次會議。持續一整天的會議通常很難安排，但它是最有價值的，因為所有利益相關者都聚在一起討論最佳實踐。在討論的過程中，儘量聚焦在較高層級且能夠與任務目標連結的實際狀態，避免深入非常細部的系統設置，這將最有助於發現流程或架構相關的改進機會。

如果您有分散在不同的地理或時區上的團隊，則進行多個會議討論是個不錯的選擇。但需要您做一些額外的工作來更新各個團隊的不同里程碑 (Milestone)。

在審查期間，團隊之間的溝通是關鍵，因為它將有助於回答問題並共同發現異狀。因此，建議將 WAFR 作為即時會話來討論，讓團隊在 AWS WA Tool 中同步回答問題，並且儘速在會後共享資訊以供改善使用。

在審查討論之前，建議收集相關工作負載的詳細資訊。例如系統主要元件、後端及負責操作系統的主要流程，團隊的工作方針或標準流程文件（Standard Operation Procedure-SOP），以及任何架構圖（Architecture Diagram）、流程圖（Flow Diagram）、執行指南及腳本（Playbook & Runbook）。

對於更複雜的工作負載，您可以利用 AWS Trusted Advisor 提供的自動化檢查項目；根據成本優化、性能、安全容錯和服務限制等方面的最佳實踐進行自動評估。啟用 AWS Trusted Advisor 亦可以協助理解 AWS Organization 中的所有帳戶的狀況。然後，您可以使用 Trusted Advisor 推薦的建議來更好地優化您對某些最佳實踐的遵守情況，並將這些詳細資訊納入您的討論中，並在以後制定改善計劃時納入這些優化建議。

★ 延伸閱讀：介紹如何將 AWS Well-Architected 的架構與 AWS Trusted Advisor 結合使用，以實現數據驅動的成本最佳化

在這篇技術文章中，我們深入探討了 Well-Architected 的框架審查的第一階段：準備階段，與您分享了我們從與客戶進行架構審查與風險評估中學到的步驟和經驗。這些建議將使您的審查更加順利，並將使您能充分利用每個參與者的時間。這些步驟包括「定義需要審查的工作負載」、「定義正確的核心團隊和主答人」、「選擇支柱和會話類型」，最後，「提前收集所需的數據」。這些步驟將使您為日後的高效審核做好準備。在後續第二階段：執行審查與第三階段：改善架構將更深入地探討這些重點。

本文同時也提及了 AWS WA Tool 中的新功能--聚焦目錄 (AWS Well-Architected Lens Catalog)。此功能擴展了針對特定行業和以技術為重點的廣度和深度，因此客戶可以更好地客製他們的評估作業，以專注於對其業務最重要的部分。您可以經由使用 AWS WA Tool 及 Lens Catalog 提供的知識來評估工作負載的運行狀況。如需後續協助或意見，歡迎向 AWS 業務與架構團隊洽詢，或加入我們的線上技術社群 AWS re:Post。