# 審查程序
<a name="the-review-process"></a>

 架構審查的執行方式必須一致，採行鼓勵深入探索的無譴責作法。應為輕量程序 (數小時而非數日)，屬於一種對話而非稽核。就架構進行審查的目的是找出可能需要解決的重要問題，或是有改進空間之處。審查的結果是一套行動，應能提升客戶使用工作負載得到的體驗。

 如同「論架構」一節所討論，建議由各團隊成員對其架構的品質負起責任。我們建議建置架構的團隊成員使用 Well-Architected 架構以持續審查其架構，而非舉行正式審查會議。採取持續作法可讓您的團隊成員隨著架構演進更新答案，並隨著您遞送功能而提升架構。 

 AWS Well-Architected Framework 符合 AWS 於內部審查系統與服務的方式。其所根據的前提為能影響架構方針的一套設計原則，並提出問題，確保人員不致於忽略根本原因分析 (RCA) 中經常列為重點的領域。每當內部系統、AWS 服務或客戶有明顯問題，我們都會查看 RCA，了解是否能提升所使用的審查程序。 

 審查應在產品生命週期的重要里程碑，並於設計階段早期實施，以免成為 *單向門戶* 難以變更，而且需趕在正式運作日期之前。(許多決定為可逆的雙向門戶。這些決定可採用輕量程序。單向門戶難以、甚至無法逆轉，實施之前需要更多檢查工作。) 進入生產環境之後，您的工作負載可隨著新增功能和變更技術實作而繼續演進。工作負載的架構會隨時間而變化。您需要遵守良好的衛生實務，以阻止您推動演進的同時，其架構上的特性隨之衰退。在您作出重要的架構變更時，應遵照一套衛生程序，包括 Well-Architected 審查。 

 若您想以審查作為一次性的快照或獨立測量，建議確定在對話中包含所有適當人員。我們經常發現，到審查時團隊才初次真正了解實作了些什麼。審查另一個團隊的工作負載時，一種效果良好的方式是就其架構進行一連串非正式對話，能探詢出大多數問題的答案。接著您即可透過一兩次會議進行追蹤，釐清或深入探索模稜兩可或看出有風險的領域。 

 開會時的一些建議項目如下： 
+  有白板的會議室 
+  任何圖或設計備註的列印紙本 
+  需要另外研究答案的問題動議清單 (例如「我們有無啟用加密？」) 

 在您完成審查之後，應列有問題清單，可根據業務環境排列優先順序。也建議考量這些問題對於您的團隊之日常工作有何影響。若您及早解決這些問題，即可空出時間創造商業價值，不必忙於解決重複發生的問題。當您解決問題時，可以更新審查，了解架構改良的情形。 

 雖然審查完成後，其價值所在自然明朗，但您可能會發現新的團隊起初可能會有所抗拒。經由對團隊教育審查的益處，可解決下列幾項反對說法： 
+  「我們太忙了\$1」(團隊預備進行盛大推出時，往往會這麼說。) 
  +  既然預備進行盛大推出，一定希望過程能夠順利。審查可讓您了解可能漏掉的任何問題。 
  +  建議您在產品生命週期之中及早實施審查，以發現風險並開發配合功能遞送藍圖的減緩計劃。 
+  「我們沒有時間處理結果！」(往往在作為目標的活動無法挪動，例如超級盃時會這麼說。) 
  +  這些活動無法挪動。您是否真的想在對於架構所具風險不知情的情況下迎接活動？ 就算無法解決所有的問題，仍然可在發生狀況時握有處理問題的程序手冊。 
+  「我們不想讓解決方案實作的秘密外流！」 
  +  如果您向團隊指出 Well-Architected Framework 中的疑問，他們就能看出這些疑問完全不會顯露商業或技術專屬資訊。 

 在您與組織內的團隊實施多重審查之時，可能會找出主題上的問題。例如，可能會發現一群團隊的問題集中在特定支柱或主題上。建議以全面方式審視所有的審查，並找出有助於解決這些主題問題的任何機制、培訓或首席工程設計對談。