使團隊能夠根據成本進行架構

Well-Architected 架構的成本優化支柱。它可以防止開發人員和工程團隊事後無法在早期決策點解決環境中出現的問題而造成成本浪費時必須優化工作負載的情況。

有能力根據成本進行架構的團隊可以快速迭代，並隨著時間推移而進行學習，以便將最佳實務納入到日常營運中。以下實務有助於團隊根據成本進行架構：

• 透過建立透明度和使用工具促進一致的報告、衡量和問責能力，促進和達成可見性。

• 在採取正確的行動時，透過建立積極的獎勵措施來推動正確的行為類型 (例如，來自管理層的電子郵件強調優化成功)。

• 建立控制策略，同時保持敏捷性 (例如，制定程序識別和解決超大資源、制定非生產資源在工作時間以外關閉的選擇退出政策)。

以下是一些有助於您促進成本優化行為的想法：

• 獎勵措施 – 其中包括指標的視覺化和遊戲化，以及基於結果的領導層積極溝通。他們鼓勵團隊瞭解效率和節儉樸實是重要的，並協助開發人員和工程師考慮本身決策的成本影響。他們也提供防止效率不彰的方法。

• 對使用者進行成本退款 – 退款能夠獎勵企業使用者關注 IT 效率。這會導致將 IT 視為企業使用和付費的資源，而不是成本中心。

• 消除程序障礙 – 有時會出現限制開發人員和工程師進行優化的障礙。例如，政策可能要求對環境所做的任何變更都必須經過變更審查程序。這將妨礙促進適當規模調整和彈性的舉措。修改此類政策可以簡化優化工作。

• 敏捷的工作方法 – 如果設計迭代週期包含成本作為衡量指標，貴組織以較低的成本交付相同或更好成果的能力將隨著時間推移而提高。

• 訓練和到職 – 個人通常使用本身熟悉的工具和技術解決問題。這可以透過訓練和到職來解決這個問題，這些訓練和到職將結合最新實務以盡可能提高效率 (例如，使用無伺服器架構、使用 Amazon CloudFront 降低運算需求)。

以下方法也可能有效，但如果不小心執行，就會對敏捷性造成風險：

• 主管支援/壓力 – 由於最佳實務對工作人員滿意度產生積極影響，因此優先支援最佳實務，而不支援解除成本壓力。成本壓力會產生隱藏效率不彰的誘因，並可能導致預算限制，導致喪失敏捷性和創新能力。

• 架構審查 – 通常在沒有架構審查 (或選用審查) 和強制性審查之間保持合理的平衡。過多的強制性審查可能會造成瓶頸。重大成果和高成本的專案可能需要審查，其界限由每個組織確定。

• 協同運作控制 – 專案和資源的核准工作流程為了保護財務和預算，而造成導致敏捷性和創新出現風險。平衡控制和敏捷性的一種方法是減少 (或不) 對創造營收服務進行成本控制。您可以透過為這些服務設定進階指標來消除這種情況。