本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 階段 3：檢查、調整和重複
<a name="inspect-adapt-iterate"></a>

實作可觀測性系統之後，建議您持續檢閱、評估、學習、調整和改善實作。您可以使用[AWS 可觀測性成熟度模型](https://aws-observability.github.io/observability-best-practices/guides/observability-maturity-model/)作為工具，以評估實作的成熟度，並識別需要改進的領域並排定其優先順序。

## 實作定期檢閱
<a name="reviews"></a>

可觀測性是一種反覆程序。它需要定期稽核和評估現有元件，以及變更和增強功能，以推動持續改進。我們建議您執行定期審查，以重新評估 SLOs、警示閾值、儀表板、指標精細程度、保留政策、抽樣策略等，以確保這些都為您的團隊和業務帶來價值。透過將可觀測性成本連接到特定團隊和服務，您可以啟用有關涵蓋範圍和資源配置的資料驅動型決策。

在 Amazon，我們會每週執行[營運準備度審查 (ORRs)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)，根據最佳實務稽核團隊的程序和可觀測性狀態。這是一個非封鎖練習，符合 Amazon 的服務數量和發行頻率。

根據您的組織大小，您也可以擁有照常營運 (BAU) 名單，其中每個團隊中的一位成員負責報告異常和趨勢、發現未知情況、移除不需要的檢測和提醒、改善儀表板，並確保可觀測性解決方案繼續為團隊工作，並與團隊的目標和成功指標保持一致。這也有機會重新評估警示策略，使其更具回應性、主動性且更接近使用者。這些檢閱的目標是建立良性循環，如下圖所示，並改善可觀測性姿勢成熟度的成熟度，如[AWS 可觀測性成熟度模型](https://aws-observability.github.io/observability-best-practices/guides/observability-maturity-model)中所述。

![反覆觀察性程序中的意見回饋和檢閱週期。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerate-observability-outcomes/images/review-cycle.png)


識別最常存取的手冊，並考慮改善您的應用程式或新增更多檢測。識別最常執行的 Runbook，並考慮自動化這些 Runbook。

這些檢閱的學習也會與可觀測性小組和專家分享，以強調集中計劃和可觀測性平台的改善。例如，根據部署觸發事件的頻率，您可以決定優先改善部署管道，而不是其他元件。如果 MTTR 因為監控差距而較高，您可以優先改善可觀測性平台及其組態。

## 慶祝勝利
<a name="wins"></a>

分享來自使用可觀測性工具之團隊的成功案例。例如，強調使用可觀測性指標來實作替代解決方案的團隊成功，該解決方案更有效率，並降低延遲或成本。傳達此成功強調可觀測性的重要性，並鼓勵其他團隊改善可觀測性狀態，並努力取得類似的成功。

## 從事件中學習
<a name="learnings"></a>

進行與 Amazon [錯誤校正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 程序類似的無責事後練習，以識別需要改進的領域並防止未來發生問題。與獲勝一樣，本練習的學習可以與其他團隊廣泛分享，以強化可觀測性和最佳實務的價值。