本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 階段 4：操作
完成[階段 3：評估和測試](stage-3.md)後，您就可以將應用程式部署到生產環境。在*操作*階段，您將應用程式部署到生產環境，並管理客戶的體驗。 應用程式的設計和實作會決定許多彈性結果，但此階段著重於系統用來維護和改善彈性的操作實務。建立卓越營運的文化有助於在這些實務中建立標準和一致性。
## 可觀測性
了解客戶體驗最重要的部分是透過監控和警示。您需要檢測應用程式以了解其狀態，而且您需要不同的觀點，這表示您需要從伺服器端和用戶端測量，通常使用 Canary。您的指標應包含應用程式與其相依性和維[度互動的資料，以符合您的故障隔離界限](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/multi-az-observability.html)。您也應該產生日誌，提供應用程式所執行每個工作單位的其他詳細資訊。您可以考慮使用 [Amazon CloudWatch 內嵌指標格式等解決方案來結合指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)和日誌。您可能會發現您總是想要更多的可觀測性，因此請考慮實作所需檢測層級所需的成本、精力和複雜性權衡。
下列連結提供檢測應用程式和建立警示的最佳實務：
+ [監控 Amazon 的生產服務](https://youtu.be/hnPcf_Czbvw) (AWS re：Invent 2020 簡報）
+ [Amazon Builders' Library：Amazon 的卓越營運](https://youtu.be/7MrD4VSLC_w) (AWS re：Invent 2021 簡報）
+ [Amazon 的可觀測性最佳實務](https://youtu.be/zZPzXEBW4P8) (AWS re：Invent 2022 簡報）
+ [檢測分散式系統以實現操作可見性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) (Amazon Builders' Library 文章）
+ [建立儀表板以實現營運可見性 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)(Amazon Builders' Library 文章）
## 事件管理
當您的警示 （或更糟糕的客戶） 告訴您發生問題時，您應該有適當的事件管理程序來處理損害。此程序應包括與待命操作員互動、呈報問題，以及建立 Runbook 以取得一致的故障診斷方法，以協助消除人為錯誤。不過，損害通常不會單獨發生；單一應用程式可能會影響依賴它的其他多個應用程式。您可以透過了解所有受影響的應用程式，並在單一電話會議上將來自多個團隊的運算子集合在一起，快速解決問題。不過，視您組織的大小和結構而定，此程序可能需要集中式操作團隊。
除了設定事件管理程序之外，您應該定期透過儀表板檢閱指標。定期審查可協助您了解客戶體驗和應用程式效能的長期趨勢。這可協助您在造成重大生產影響之前識別問題和瓶頸。以一致、標準化的方式檢閱指標可提供顯著的好處，但需要由上而下的支持和時間投資。
下列連結提供建置儀表板和操作指標檢閱的最佳實務：
+ [建立儀表板以實現營運可見性 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)(Amazon Builders' Library 文章）
+ [Amazon 成功失敗的方法 ](https://youtu.be/yQiRli2ZPxU)(AWS re：Invent 2019 簡報）
## 持續彈性
在[階段 2：設計和實作](stage-2.md)以及[階段 3：評估和測試](stage-3.md)期間，您會在將應用程式部署到生產環境之前啟動檢閱和測試活動。在*操作*階段期間，您應該繼續在生產環境中反覆執行這些活動。您應該透過 [AWS Well-Architected Framework Reviews](https://aws.amazon.com/architecture/well-architected/)、[Operational Readiness Reviews (ORRs)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 和彈性[分析架構，定期檢閱應用程式的彈性](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)狀態。這有助於確保您的應用程式不會偏離已建立的基準和標準，並讓您隨時掌握最新或更新的指導方針。這些持續彈性活動可協助您發現先前未預期的中斷，並協助您提出新的緩解措施。
在生產前環境中成功執行遊戲後，您可能也想要考慮在生產環境中執行[遊戲日](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html)和[混沌工程](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)實驗。遊戲日模擬您已建置可緩解的彈性機制的已知事件。例如，遊戲日可能會模擬 AWS 區域服務受損，並實作多區域容錯移轉。雖然實作這些活動可能需要大量精力，但這兩個實務都可協助您建立信心，讓您的系統能夠適應您設計為承受的故障模式。
透過操作您的應用程式、遇到操作事件、檢閱指標和測試應用程式，您將遇到許多回應和學習的機會。