審查程序

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

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

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

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

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

開會時的一些建議項目如下:

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

雖然審查完成後,其價值所在自然明朗,但您可能會發現新的團隊起初可能會有所抗拒。經由對團隊教育審查的益處,可解決下列幾項反對說法:

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