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

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

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

 AWS Well-Architected 架構與內部審核系統和服務的方式 AWS 一致。它以影響架構方法的一組設計原則為基礎，以及驗證人員不會忽略根本原因分析 （RCA） 中經常出現的區域的問題。每當內部系統、 AWS 服務或客戶發生重大問題時，我們會查看 RCA，看看我們是否可以改善我們使用的審核程序。

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

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

 開會時的一些建議項目如下：
+  有白板的會議室 
+  任何圖或設計備註的列印紙本 
+  需要 out-of-band研究才能回答的問題動作清單 （例如，「我們是否啟動加密？」） 

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

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

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