# 營運
**Topics**
+ [OPS 8 您如何了解工作負載的運作狀態？](w2aac19b5b9b5.md)
+ [OPS 9 您如何了解營運狀況？](w2aac19b5b9b7.md)
+ [OPS 10 您如何管理工作負載和營運事件？](w2aac19b5b9b9.md)
# OPS 8 您如何了解工作負載的運作狀態？
定義、擷取和分析工作負載指標，掌握工作負載事件，以便採取適當行動。
**Topics**
+ [OPS08-BP01 識別關鍵績效指標](ops_workload_health_define_workload_kpis.md)
+ [OPS08-BP02 定義工作負載指標](ops_workload_health_design_workload_metrics.md)
+ [OPS08-BP03 收集和分析工作負載指標](ops_workload_health_collect_analyze_workload_metrics.md)
+ [OPS08-BP04 建立工作負載指標基準](ops_workload_health_workload_metric_baselines.md)
+ [OPS08-BP05 了解工作負載的預期活動模式](ops_workload_health_learn_workload_usage_patterns.md)
+ [OPS08-BP06 在工作負載結果有風險時發出提醒](ops_workload_health_workload_outcome_alerts.md)
+ [OPS08-BP07 在偵測到工作負載異常時發出提醒](ops_workload_health_workload_anomaly_alerts.md)
+ [OPS08-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_workload_health_biz_level_view_workload.md)
# OPS08-BP01 識別關鍵績效指標
根據所需的業務成果 (例如，訂單率、客戶保留率以及獲利與營運支出的對比) 與客戶成果 (例如，客戶滿意度)，識別關鍵績效指標 (KPI)。評估 KPI 以確定工作負載是否成功。
**常用的反模式：**
+ 企業領導階層會詢問您工作負載如何成功滿足業務需求，但您卻沒有可判斷成功與否的參考框架。
+ 您無法判斷為組織營運的商用現成應用程式是否具成本效益。
**建立此最佳實務的優勢：** 藉由識別關鍵績效指標，您可以實現業務成果，做為對工作負載運作狀態和成功的測試。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 識別關鍵績效指標：根據所需的業務和客戶成果識別關鍵績效指標 (KPI)。評估 KPI 以確定工作負載是否成功。
# OPS08-BP02 定義工作負載指標
定義工作負載指標以衡量 KPI 的實現情況 (例如，捨棄的購物車、下單的訂單、成本、價格和分配的工作負載支出)。定義工作負載指標以衡量工作負載的運作狀態 (例如，界面回應時間、錯誤率、提出的請求、完成的請求和使用率)。評估指標以判斷工作負載是否取得了預期的成果，並了解工作負載的運作狀態。
您應該將日誌資料傳送到 CloudWatch Logs 這類服務，並從必要日誌內容的觀察中產生指標。
CloudWatch 擁有專業功能，例如 [適用於 .NET 和 SQL Server 的 Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-what-is.html) 和 [Container Insights，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 這些功能可協助您在各個特定支援應用程式資源和技術堆疊之間識別並設定關鍵指標、日誌和警示。
**常用的反模式：**
+ 您已定義與任何 KPI 無關或針對任何工作負載量身打造的標準指標。
+ 您的指標計算中有錯誤，這會產生無效的結果。
+ 您尚未為工作負載定義任何指標。
+ 您只衡量了可用性。
**建立此最佳實務的優勢：** 透過定義和評估工作負載指標，您可以判斷工作負載的運作狀態，並衡量業務成果的實現情況。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 定義工作負載指標：定義工作負載指標以衡量 KPI 的實現情況。定義工作負載指標，以衡量工作負載及其各個元件的運作狀態。評估指標以確定工作負載是否取得了預期的成果，並了解工作負載的運作狀態。
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
# OPS08-BP03 收集和分析工作負載指標
定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。
您應該將應用程式、工作負載元件、服務和 API 呼叫的日誌資料彙總至像是 CloudWatch Logs 等服務中。從必要日誌內容的觀察中產生指標，以深入了解營運活動的效能。
在 AWS 上，您可以分析工作負載指標並識別操作問題，方法為使用 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)機器學習功能。AWS DevOps Guru 會提供操作問題的通知，隨附 [針對性和主動](https://docs.aws.amazon.com/devops-guru/latest/userguide/view-insights.html) 建議，以解決問題並維護應用程式運作狀態。
在 AWS 共同責任模式中，監控部分可透過下列項目提供給您： [AWS Health 儀板表](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)。此儀表板會在 AWS 發生可能影響您的事件時，提供提醒與修補指導。商業和企業支援訂閱客戶還可存取 [AWS Health API](https://docs.aws.amazon.com/health/latest/ug/getting-started-api.html)，進而可以整合至其事件管理系統。
在 AWS 上，您可以 [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 或者 [直接傳送日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 至 [Amazon S3](https://aws.amazon.com/s3/) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/)，在 Amazon S3 中探索和準備日誌資料，以進行分析並將關聯的中繼資料儲存在 [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena](https://aws.amazon.com/athena/)Amazon Athena，透過與 AWS Glue 的原生整合，可用來分析日誌資料，並使用標準 SQL 進行查詢。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料。
另一個 [解決方案](https://aws.amazon.com/solutions/centralized-logging/?did=sl_card&trk=sl_card) 是使用 [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) 和 [OpenSearch 儀表板](https://aws.amazon.com/elasticsearch-service/the-elk-stack/kibana/) 跨多個帳戶和 AWS 區域 收集、分析和顯示 AWS 上的日誌。
**常用的反模式：**
+ 網路設計團隊會詢問您目前的網路頻寬使用率。您提供目前的指標，網路使用率為 35%。由於時間點測量並未反映使用率趨勢，因此它們降低電路容量，以作為節省成本的措施，這導致廣泛的連線問題。
+ 您的路由器失敗。它一直在記錄非關鍵的記憶體錯誤，隨著頻率越來越大，直到完全失敗。您未偵測到此趨勢，因此在路由器造成服務中斷之前，並未取代出錯的記憶體。
**建立此最佳實務的優勢：** 透過收集和分析工作負載指標，您可以了解工作負載的運作狀態，並深入了解可能影響工作負載或達成業務成果的趨勢。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 收集和分析工作負載指標：定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## 資源
**相關文件：**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/)
+ [AWS Health 儀板表](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS08-BP04 建立工作負載指標基準
為指標建立基準，以提供期望值，做為比較和識別效能欠佳和過剩的元件的基礎。識別用於改善、調查和介入的閾值。
**常用的反模式：**
+ 伺服器在 95% 的 CPU 使用率下執行，系統會詢問您情況是好或壞。該伺服器的 CPU 使用率尚未進行基準比較，因此您不知道這是好或壞。
**建立此最佳實務的優勢：** 透過定義基準指標值，您可以評估目前的指標值和指標趨勢，以判斷是否需要採取動作。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 為工作負載指標建立基準：為工作負載指標建立基準，以提供期望值做為比較的基礎。
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 資源
**相關文件：**
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
# OPS08-BP05 了解工作負載的預期活動模式
建立工作負載活動模式以識別異常行為，以便您可以在需要時做出適當回應。
CloudWatch 透過 [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能套用統計和機器學習演算法，以產生代表一般指標行的預期值範圍。
[Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 可以用來透過事件關聯性、日誌分析和套用機器學習分析您的工作負載遙測來識別異常行為。當偵測到非預期行為時，它會提供 [相關的指標和事件，](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 隨附處理行為的建議。
**常用的反模式：**
+ 您正在檢閱網路使用率日誌，並看到網路使用率在上午 11:30 到下午 1:30 之間增加，然後在下午 4:30 到下午 6:00 之間再次增加。您不知道這是否應該視為正常。
+ 您的 Web 伺服器每天凌晨 3:00 重新開機。您不知道這是否是預期的行為。
**建立此最佳實務的優勢：** 透過學習行為模式，您可以識別意外行為，並在必要時採取動作。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 了解工作負載的預期活動模式：建立工作負載活動模式，以確定行為何時超出預期值，以便您在需要時做出適當的回應。
## 資源
**相關文件：**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
# OPS08-BP06 在工作負載結果有風險時發出提醒
當工作負載結果有風險時發出提醒，以便您可以在必要時做出適當的回應。
理想情況下，您先前已識別可對其發出警示的指標閾值，或已識別可用來觸發自動回應的事件。
在 AWS 上，您可以使用 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 建立 Canary 指令碼，來監控您的端點和 API，方法為執行與客戶相同的動作。產生的遙測和 [取得的洞見](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) 可讓您在客戶受到影響之前識別問題。
您也可以使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) ，透過專門打造的查詢語言，以互動的方式搜尋並分析日誌資料。CloudWatch Logs Insights 會自動 [探索 AWS 服務日誌中的欄位，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) 以及 JSON 中的自訂日誌事件。它可以隨日誌量和查詢複雜性進行擴展，並在幾秒鐘內提供答案，以協助您搜尋事件的影響因素。
**常用的反模式：**
+ 您沒有網路連線能力。沒有人注意到。沒有人嘗試找出原因，或採取動作來恢復連線。
+ 套用修補程式之後，您的持久性執行個體不可用，從而中斷使用者。您的使用者已開啟支援案例。沒有人收到通知。沒有人採取動作。
**建立此最佳實務的優勢：** 透過識別業務成果已產生風險，並提醒採取動作，您就有機會防止或緩解事件的影響。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 在工作負載結果有風險時發出提醒：當工作負載結果有風險時發出提醒，以便您在需要時做出適當的回應。
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP07 在偵測到工作負載異常時發出提醒
當偵測到工作負載異常時發出提醒，以便您可以在必要時做出適當的回應。
透過長時間分析工作負載指標能夠建立可充分量化的行為模式，以定義事件或發出警示來回應。
經過訓練後， [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能可用於對偵測到的異常發出 [警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) ，或提供重疊的預期值至指標資料 [圖形](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 上，以便進行持續比較。
**常用的反模式：**
+ 您的零售網站銷售額突然大幅增加。沒有人注意到。沒有人試圖找出導致此激增的原因。沒有人採取動作，以確保額外負載下的優質客戶體驗。
+ 應用程式套用修補程式之後，您的持久性伺服器會經常重新啟動，從而中斷使用者。您的伺服器通常重新開機最多三次，但不會更多次。沒有人注意到。沒有人試圖找出發生此問題的原因。
**建立此最佳實務的優勢：** 透過了解工作負載行為的模式，您可以識別意外行為，並在必要時採取動作。
**若未建立此最佳實務，暴露的風險等級為：** 低
## 實作指引
+ 在偵測到工作負載異常時發出提醒：當偵測到工作負載異常時發出提醒，以便您在需要時做出適當的回應。
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## 資源
**相關文件：**
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP08 驗證結果的實現以及 KPI 和指標的有效性
建立工作負載營運的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。
AWS 還可透過 AWS 服務 API 和 SDK (例如 Grafana、Kibana 和 Logstash) 支援第三方日誌分析系統和商業智慧工具。
**常用的反模式：**
+ 頁面回應時間從來未被視為有助於提高客戶滿意度的因素。您從未建立頁面回應時間的指標或閾值。您的客戶對於緩慢問題抱怨不已。
+ 您尚未達到最低回應時間目標。為改善回應時間，您已擴展應用程式伺服器。您現在已大幅超出回應時間目標，而且已付費容量中還有大量未使用。
**建立此最佳實務的優勢：** 透過審查和修訂 KPI 和指標，您可以了解工作負載如何支援業務成果的達成，並找出達成業務目標需要改善的地方。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 驗證結果的實現以及 KPI 和指標的有效性：建立工作負載營運的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
## 資源
**相關文件：**
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
# OPS 9 您如何了解營運狀況？
定義、擷取和分析營運指標，掌握營運事件，以便採取適當行動。
**Topics**
+ [OPS09-BP01 識別關鍵績效指標](ops_operations_health_define_ops_kpis.md)
+ [OPS09-BP02 定義營運指標](ops_operations_health_design_ops_metrics.md)
+ [OPS09-BP03 收集和分析營運指標](ops_operations_health_collect_analyze_ops_metrics.md)
+ [OPS09-BP04 建立營運指標基準](ops_operations_health_ops_metric_baselines.md)
+ [OPS09-BP05 了解營運活動的預期模式](ops_operations_health_learn_ops_usage_patterns.md)
+ [OPS09-BP06 在營運成果有風險時發出警示](ops_operations_health_ops_outcome_alerts.md)
+ [OPS09-BP07 在偵測到營運異常時發出提醒](ops_operations_health_ops_anomaly_alerts.md)
+ [OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_operations_health_biz_level_view_ops.md)
# OPS09-BP01 識別關鍵績效指標
根據所需的業務成果 (例如，交付的新功能) 和客戶成果 (例如，客戶支援案例)，識別關鍵績效指標 (KPI)。評估 KPI 以確定營運是否成功。
**常用的反模式：**
+ 企業領導階層會詢問您是否成功完成業務目標，但您卻沒有可判斷成功與否的參考框架。
+ 您無法判斷您的維護時段是否會影響業務成果。
**建立此最佳實務的優勢：** 藉由識別關鍵績效指標，您可以實現業務成果，做為對營運運作狀態和成功的測試。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 識別關鍵績效指標：根據所需的業務和客戶成果識別關鍵績效指標 (KPI)。評估 KPI 以確定營運是否成功。
# OPS09-BP02 定義營運指標
定義營運指標以衡量 KPI 的實現情況 (例如，成功部署和失敗部署)。定義營運指標以衡量營運活動的運作狀態 (例如，偵測事件所需的平均時間 (MTTD)，以及從事件中復原所需的平均時間 (MTTR))。評估指標以判斷營運是否取得理想成果，並了解您的營運活動的運作狀態。
**常用的反模式：**
+ 您的運營指標是以團隊認為合理的內容為基礎。
+ 您的指標計算中有錯誤，這會產生不正確的結果。
+ 您尚未為營運活動定義任何指標。
**建立此最佳實務的優勢：** 透過定義和評估營運指標，您可以判斷營運活動的運作狀態，並衡量業務成果的實現情況。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 定義營運指標：定義營運指標以衡量 KPI 的實現情況。定義營運指標以衡量營運及其活動的狀況。評估指標以確定營運是否取得理想成果，並了解營運狀況。
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## 資源
**相關文件：**
+ [AWS Answers：集中式記錄](https://aws.amazon.com/answers/logging/centralized-logging/)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [使用 Amazon CloudWatch Events 偵測管道狀態中的變更並做出反應](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**相關影片：**
+ 制定監控計劃
# OPS09-BP03 收集和分析營運指標
定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。
您應該將執行營運活動和操作 API 呼叫的日誌資料彙總至 CloudWatch Logs 這類服務中。從必要日誌內容的觀察中產生指標，以深入了解營運活動的效能。
在 AWS 上，您可以 [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 或者 [直接傳送日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 至 [Amazon S3](https://aws.amazon.com/s3/) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/)，在 Amazon S3 中探索和準備日誌資料，以進行分析並將關聯的中繼資料儲存在 [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena](https://aws.amazon.com/athena/)Amazon Athena，透過與 AWS Glue 的原生整合，可用來分析日誌資料，並使用標準 SQL 進行查詢。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料。
**常用的反模式：**
+ 我們將新功能的一致交付視為關鍵績效指標。您無法測量部署發生的頻率。
+ 您記錄部署、復原的部署、修補程式和復原的修補程式，以追蹤您的營運活動，但沒有人審查指標。
+ 您的復原時間目標為可在 15 分鐘內還原遺失的資料庫，該目標設定於系統已部署且沒有使用者時。您現在有一萬名使用者，並已營運兩年。最近的還原時間花費超過兩小時。未記錄此項目，也沒有人知道。
**建立此最佳實務的優勢：** 透過收集和分析營運指標，您可以了解營運的運作狀態，並深入了解可能影響營運或達成業務成果的趨勢。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 收集和分析營運指標：定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## 資源
**相關文件：**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS09-BP04 建立營運指標基準
為指標建立基準，以提供期望值，做為比較和識別效能欠佳和過剩的營運活動的基礎。
**常用的反模式：**
+ 您需告知預計部署的時間為何。您尚未測量部署所需的時間，也無法判斷預期的時間。
+ 您需告知從應用程式伺服器問題中復原需要多長時間。對於從第一次聯絡客戶起計算的所需復原時間，您沒有相關資訊。對於從監控得知的第一次識別問題起計算的所需復原時間，您沒有相關資訊。
+ 您需告知您在週末需要多少名支援人員。您不知道週末有多少個典型支援案例，且無法提供預估值。
+ 您的復原時間目標為可在 15 分鐘內還原遺失的資料庫，該目標設定於系統已部署且沒有使用者時。您現在有一萬個使用者，並已營運兩年。對於資料庫還原時間為什麼變更的原因，您沒有相關資訊。
**建立此最佳實務的優勢：** 透過定義基準指標值，您可以評估目前的指標值和指標趨勢，以判斷是否需要採取動作。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 了解營運活動的預期模式：建立營運活動模式，以確定行為何時超出預期值，以便您可以在需要時做出適當的回應。
# OPS09-BP05 了解營運活動的預期模式
建立營運活動模式以識別異常活動，以便您可以在必要時做出適當的回應。
**常用的反模式：**
+ 最近，您的部署失敗率大幅增加。您獨立解決每次失敗。您不知道失敗源於不熟悉部署管理系統的新員工執行的部署。
**建立此最佳實務的優勢：** 透過學習行為模式，您可以識別意外行為，並在必要時採取動作。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 了解營運活動的預期模式：建立營運活動模式，以確定行為何時超出預期值，以便您可以在需要時做出適當的回應。
# OPS09-BP06 在營運成果有風險時發出警示
每當營運成果有風險時，就必須發出警示並據以行動。營運成果是可支援生產中工作負載的任何活動。其中包含從部署新版應用程式到從中斷復原的所有作業。您必須以與業務成果一樣的重要性來看待營運成果。
軟體團隊應找出關鍵的營運指標和活動，並為其建立警示。警示必須及時且可據以採取行動。發出警示時，應包含相應執行手冊或程序手冊的參考。發出警示，但未提供相應的動作可能會導致警示疲勞。
**預期成果：** 當營運活動有風險時，就會傳送警示來促進行動。警示包含為何發出警示的背景資訊，並指向要調查的程序手冊和要採取緩解措施的執行手冊。盡可能自動化執行手冊並傳送通知。
**常見的反模式：**
+ 您正在調查事件，以及正在將支援案例歸檔。支援案例違反服務水準協議 (SLA)，但未發出任何警示。
+ 由於最後一刻的程式碼變更，預定於午夜進行的生產部署遭到延遲。未發出任何警示，而部署發生懸置。
+ 發生生產中斷，但未傳送任何警示。
+ 您的部署時間一直落後於預估值。未採取任何調查動作。
**建立此最佳實務的優勢：**
+ 當營運成果有風險時，發出警示可以協助您透過預先發現問題來支援工作負載。
+ 營運成果的運作狀態良好，業務成果因而獲得改善。
+ 營運問題的偵測和修復也獲得改善。
+ 整體營運運作狀態也有所改善。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
必須先定義營運成果，才能針對這些成果發出警示。透過定義哪些營運活動對貴組織最重要來開始。是否要在兩小時內將其部署至生產，或是在固定的時間內回應支援案例？ 貴組織必須定義關鍵營運活動，以及如何衡量這些活動，如此才能夠監控、改善這些活動，並據以發出警示。您需要一個中心位置，來存放和分析工作負載及營運遙測。相同的機制應能夠在營運成果有風險時發出警示。
**客戶範例**
CloudWatch 警示會在 AnyCompany Retail 的例行部署期間觸發。超過部署的前置時間。Amazon EventBridge 已在 AWS Systems Manager OpsCenter 中建立 OpsItem。雲端營運團隊使用程序手冊來調查問題，並發現結構描述的變更花費的時間比預期更長。他們向待命的開發人員發出警示，並持續監控部署。在部署完成後，雲端營運團隊就會解析 OpsItem。該團隊會在事後分析事件。
## 實作步驟
1. 如果您還沒有確定營運 KPI、指標和活動，請著手實作先前所述的此問題的最佳實務 (OPS09-BP01 至 OPS09-BP05)。
+ 使用 [企業支援的 支援 客戶](https://aws.amazon.com/premiumsupport/plans/enterprise/) 可以要求 [營運 KPI 研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) (透過其技術客戶經理)。此協作研討會可協助您定義與業務目標一致的營運 KPI 和指標，而不需額外費用。聯絡技術客戶經理來進一步了解。
1. 在您建立營運活動、KPI 和指標後，請在可觀察性平台設定警示。警示應具備與其關聯的動作，例如程序手冊或執行手冊。應避免發出不含動作的警示。
1. 經過一段時間後，您應能評估營運指標、KPI 和活動來找出待改善的地方。擷取執行手冊和程序手冊中來自操作人員的回饋，找出在回應警示時待改善的地方。
1. 警示應包含將待改善地方標示為誤判的機制。這會導致對指標閾值的審查。
**實作計劃的工作量：** 中。在實作此最佳實務前，必須實作幾個最佳實務。在確定營運活動與建立營運 KPI 後，也應建立警示。
## 資源
**相關的最佳實務：**
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md)：每個營運活動和成果都應有確定的負責擁有者。當成果有風險時，該擁有者就應收到警示。
+ [OPS03-BP02 授權團隊成員在成果有風險時採取動作](ops_org_culture_team_emp_take_action.md)：發出警示時，團隊中應有專員採取行動來修復此問題。
+ [OPS09-BP01 識別關鍵績效指標](ops_operations_health_define_ops_kpis.md)：針對營運成果發出警示，從確定營運 KPI 開始。
+ [OPS09-BP02 定義營運指標](ops_operations_health_design_ops_metrics.md)：先建立此最佳實務，再開始產生警示。
+ [OPS09-BP03 收集和分析營運指標](ops_operations_health_collect_analyze_ops_metrics.md)：您必須集中收集營運指標，才能建立警示。
+ [OPS09-BP04 建立營運指標基準](ops_operations_health_ops_metric_baselines.md)：營運指標基準讓您能夠調整警示並避免警示疲勞。
+ [OPS09-BP05 了解營運活動的預期模式](ops_operations_health_learn_ops_usage_patterns.md)：您可以透過了解營運事件的活動模式，來改善警示的準確性。
+ [OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_operations_health_biz_level_view_ops.md)：評估營運成果的達成情形，來確保 KPI 和指標是有效的。
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：每個警示應具備相關的執行手冊或程序手冊，並為收到警示的人員提供背景資訊。
+ [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md)：在收到警示後執行事件後分析，來找出待改善的地方。
**相關文件：**
+ [AWS 部署管道參考架構：應用程式管道架構](https://pipelines.devops.aws.dev/application-pipeline/)
+ [GitLab：開始使用敏捷 / DevOps 指標](https://about.gitlab.com/handbook/marketing/strategic-marketing/devops-metrics/)
**相關影片：**
+ [使用 AWS Systems Manager OpsCenter 彙總和解決營運問題](https://www.youtube.com/watch?v=r6ilQdxLcqY)
+ [將 AWS Systems Manager OpsCenter 與 Amazon CloudWatch 警示整合](https://www.youtube.com/watch?v=Gpc7a5kVakI)
+ [使用 Amazon EventBridge 將資料來源整合至 AWS Systems Manager OpsCenter](https://www.youtube.com/watch?v=Xmmu5mMsq3c)
**相關範例：**
+ [使用 Amazon EC2 Systems Manager Automation 和 AWS Health 自動化 Amazon EC2 通知及其他方面的修復動作](https://aws.amazon.com/blogs/mt/automate-remediation-actions-for-amazon-ec2-notifications-and-beyond-using-ec2-systems-manager-automation-and-aws-health/)
+ [AWS 管理與管控工具研討會 - 2022 年營運 ](https://mng.workshop.aws/operations-2022.html)
+ [在 AWS 上使用 DevOps 監控儀表板來擷取、分析和視覺化指標](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/welcome.html)
**相關服務：**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [支援 主動服務 - 營運 KPI 研討會 ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [AWS Systems Manager OpsCenter，](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [CloudWatch 事件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP07 在偵測到營運異常時發出提醒
在偵測到營運異常時發出提醒，以便您可以在必要時做出適當的回應。
透過長時間分析營運指標能夠建立可充分量化的行為模式，以定義事件或發出警示來回應。
經過訓練後， [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能可用於對偵測到的異常發出 [警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) ，或提供重疊的預期值至指標資料 [圖形](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 上，以便進行持續比較。
[Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 可以用來透過事件關聯性、日誌分析和套用機器學習分析您的工作負載遙測來識別異常行為。AWS Well-Architected [洞見](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 會呈現出來，隨附相關資訊和建議。
**常用的反模式：**
+ 您正將修補程式套用到您的執行個體機群。您已在測試環境中成功測試修補程式。對於機群中的大部分執行個體，修補程式失敗。您不採取任何動作。
+ 您注意到，有部署動作從週五結束日開始。您的組織已預先定義星期二和星期四的維護時段。您不採取任何動作。
**建立此最佳實務的優勢：** 透過了解營運行為的模式，您可以識別意外行為，並在必要時採取動作。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 在偵測到營運異常時發出提醒：在偵測到營運異常時發出提醒，以便您可以在需要時做出適當的回應。
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## 資源
**相關文件：**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon CloudWatch Events 偵測管道狀態中的變更並做出反應](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性
建立營運活動的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。
AWS 還可透過 AWS 服務 API 和 SDK (例如 Grafana、Kibana 和 Logstash) 支援第三方日誌分析系統和商業智慧工具。
**常用的反模式：**
+ 部署頻率已隨著開發團隊數量的成長而增加。您定義的預期部署數量為每週一次。您一直每天定期部署。當您的部署系統有問題，而無法部署時，數天都不會偵測到該問題。
+ 當您的公司先前只在週一至週五的核心上班時間提供支援時。您已針對事件建立下個工作日回應時間目標。您最近開始提供全年無休支援涵蓋範圍，並隨附兩小時回應時間的目標。您的夜班員工不堪重負，客戶也不滿意。沒有事件回應時間發生問題的跡象，原因是您的通報違背下個工作日目標。
**建立此最佳實務的優勢：** 透過審查和修訂 KPI 和指標，您可以了解工作負載如何支援業務成果的達成，並找出達成業務目標需要改善的地方。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 驗證結果的實現以及 KPI 和指標的有效性：建立營運活動的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
## 資源
**相關文件：**
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
# OPS 10 您如何管理工作負載和營運事件？
準備和驗證回應事件的程序，大幅降低工作負載中斷情形。
**Topics**
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 根據業務影響確定營運事件的優先順序](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 定義向上呈報路徑](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 啟用推送通知](ops_event_response_push_notify.md)
+ [OPS10-BP06 透過儀表板傳達狀態](ops_event_response_dashboards.md)
+ [OPS10-BP07 自動回應事件](ops_event_response_auto_event_response.md)
# OPS10-BP01 使用程序進行事件、事故和問題管理
您的組織具有處理事件、事故和問題的程序。*事件* 是發生於工作負載、但可能無需由您介入的事項。*事故* 是需要介入的事件。 *問題* 是重複發生而需要介入或無法解決的事件。您需要相關程序來減輕這些事件對業務的影響，並確保您能夠適當因應。
當工作負載發生事故和問題時，您需要有相關程序來加以處理。您如何讓利害關係人得知事件的狀態？ 應變由誰監控？ 您使用哪些工具來減輕事件的影響? 在此舉例說明一些您為了獲得可靠的應變程序而有待解答的問題。
程序必須集中記載，並且提供給涉及工作負載的每個人使用。如果您沒有集中的 Wiki 或文件存放區，可以使用版本控制儲存庫。您將隨著程序的演進而保有最新計劃。
問題是可以自動化的。這些事件佔據的時間會影響到您的創新能力。請開始建置可重複的程序，以減輕問題。經過一段時間後，您將著重於緩解措施的自動化或修正基礎問題。如此您即有時間投入於工作負載的改進。
**預期成果：** 您的組織具有處理事件、事故和問題的程序。這些程序會集中記載並存放。這些文件會隨著程序的變更而更新。
**常見的反模式：**
+ 週末發生了事故，而值班工程師不知該如何處理。
+ 客戶傳送電子郵件給您，指出應用程式已關閉。您將伺服器重新開機，試著修正問題。此狀況頻繁地發生。
+ 有一項事故讓多個團隊各自獨立試著加以解決。
+ 您的工作負載中發生了部署，但並未記錄。
**建立此最佳實務的優勢：**
+ 您的工作負載中有事件的稽核軌跡。
+ 您的事故中復原的時間減少了。
+ 團隊成員可用一致的方式解決事故和問題。
+ 調查事故的人力會更加整合。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
實作此最佳實務，意味著您會追蹤工作負載事件。您具有處理事故和問題的程序。這些程序會經常記載、共用及更新。問題經識別後會定出優先順序，然後獲得修正。
**客戶範例**
AnyCompany Retail 有某部分的內部 Wiki 專門用來處理事件、事故和問題管理。所有事件都會傳送至 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)。問題會在 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 中識別為 OpsItems，並定出修正的優先順序，以減少無特殊專長人力。程序變更後，會隨即在其內部 Wiki 中更新。他們使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來管理事故及協調緩解工作。
## 實作步驟
1. 事件
+ 追蹤發生在工作負載中的事件，即使無需人為介入亦然。
+ 與工作負載利害關係人共同擬定應追蹤的事件清單。範例包括已完成的部署或成功的修補。
+ 您可以使用諸如 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 或者 [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 等服務來產生要追蹤的自訂事件。
1. 事故
+ 首先請定義事故的溝通計劃。哪些利害關係人必須獲得通知？ 您如何維繫其參與度? 協調工作由誰監控？ 我們建議建立內部交談管道，以利溝通和協調。
+ 為支援工作負載的團隊定義呈報路徑，尤其是團隊未設置當班輪值時。根據您的支援等級，您也可以向 支援 申請立案。
+ 建立用來調查事件的程序手冊。其中應包含溝通計劃和詳細的調查步驟。在您的調查中納入對 [AWS Health 儀板表](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 的檢查。
+ 記載您的事故應變計劃。傳達事故管理計劃，讓內部與外部客戶都了解互動的規則及其應有的預期。對您的團隊成員進行其使用訓練。
+ 客戶可使用 [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來設定及管理其事故應變計劃。
+ Enterprise Support 客戶可以要求 [事件管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) (透過其技術客戶經理)。這個指導研討會將測試您現有的事故應變計劃，並協助您識別改善的領域。
1. 問題
+ 問題必須在 ITSM 系統中受到識別及追蹤。
+ 識別所有已知問題，並按照修正的工作量以及對工作負載的影響定出優先順序。
![\[用來排定問題優先順序的動作優先順序矩陣\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/impact-effort-chart.png)
+ 先解決高影響、低工作量的問題。這些問題解決後，再接著解決位於低影響、低工作量象限的問題。
+ 您可以使用 [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) 來識別這些問題、將執行手冊連結至問題，並加以追蹤。
**實作計劃的工作量：** 中。必須同時具備程序和工具，才能實作此最佳實務。記載您的程序，並且讓工作負載的任何相關人員都可加以使用。經常加以更新。您具有管理問題和加以緩解或修正的程序。
## 資源
**相關的最佳實務：**
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)：已知問題需要相關聯的執行手冊，讓緩解工作保有一致性。
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)：事件需使用程序手冊來調查。
+ [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md)：從事故復原後務必要執行事後檢討。
**相關文件：**
+ [Atlassian - DevOps 時代的事故管理](https://www.atlassian.com/incident-management/devops)
+ [AWS 安全事故應變指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [DevOps 和 SRE 時代的事故管理](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - 什麼是事故管理？](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**相關影片：**
+ [AWS re:Invent 2020：分散式組織中的事故管理](https://www.youtube.com/watch?v=tyS1YDhMVos)
+ [AWS re:Invent 2021 - 使用事件驅動架構建置新一代的應用程式](https://www.youtube.com/watch?v=U5GZNt0iMZY)
+ [AWS 為您提供支援 \$1 探索事故管理桌上模擬演練](https://www.youtube.com/watch?v=0m8sGDx-pRM)
+ [AWS Systems Manager Incident Manager - AWS 虛擬研討會](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS 下一步 ft. Incident Manager \$1 AWS 事件](https://www.youtube.com/watch?v=uZL-z7cII3k)
**相關範例：**
+ [AWS 管理與管控工具研討會 - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html)
+ [AWS 主動服務 – 事故管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [使用 Amazon EventBridge 建置事件驅動應用程式](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [在 AWS 上建置事件驅動架構](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
**相關服務：**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [AWS Health 儀板表](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS10-BP02 每個提醒建立一個程序
對於引發提醒的任何事件，建立明確定義的回應 (執行手冊或程序手冊)，並指明。此舉可確保對營運事件的有效而迅速的回應，並防止需採取動作的事件被無價值的通知所淹沒。
**常用的反模式：**
+ 您的監控系統會將核准的連線串流以及其他訊息一起提供給您。訊息數量如此龐大，以至於您錯過需要您介入的定期錯誤訊息。
+ 您收到提醒，指出網站運作中斷。發生這種情況時沒有已定義的程序。您必須採取臨機操作方法來診斷和解決問題。隨需開發此程序會延長復原時間。
**建立此最佳實務的優勢：** 只有在需要採取動作時才發出提醒，可防止低值提醒隱藏高值提醒。透過讓每個可採取動作的提醒都具有一個程序，您可針對環境中的事件實現一致且迅速的回應。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 每個提醒建立一個程序：對於引發提醒的任何事件，都應建立明確定義的回應 (執行手冊或程序手冊)，並指明負責人 (例如，個人、團隊或角色) 來對成功完成的程序負責。回應的執行可以自動化，也可以由另一個團隊完成，但負責人要對確保流程交付預期結果負責。透過建立這些程序，您可以確保對營運事件做出迅速有效的回應，並防止需採取行動的事件被無價值的通知所淹沒。例如，自動調整規模功能可能應用於調整 Web 前端規模，但營運團隊可能需負責確保自動調整規模規則和限制符合工作負載需求。
## 資源
**相關文件：**
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**相關影片：**
+ [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU)
# OPS10-BP03 根據業務影響確定營運事件的優先順序
確保在有多個事件需要介入時，首先解決對業務最重要的事件。影響可能包括人員傷亡、經濟損失或聲譽或信用受損。
**常用的反模式：**
+ 您收到為使用者新增印表機組態的支援請求。處理此問題時，您收到支援請求，而其指出您的零售網站運作中斷。為使用者完成印表機組態後，您便開始處理網站問題。
+ 您收到零售網站和薪資系統運作中斷的通知。您不知道應該優先處理哪一個。
**建立此最佳實務的優勢：** 將對業務影響最大的事件回應排定優先順序，讓您能夠管理該影響。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 根據業務影響，排定操作事件的優先順序：確保在有多個事件需要介入時，首先解決對業務最重要的事件。影響可能包括人員傷亡、經濟損失、違反法規或聲譽或信用受損。
# OPS10-BP04 定義向上呈報路徑
在您的執行手冊和程序手冊中定義向上呈報路徑，包括觸發向上呈報的條件以及向上呈報的程序。明確確定每個動作的擁有者，以確保對營運事件做出迅速有效的回應。
在採取行動之前，確定何時需要人為決策。與決策者合作，事先做出該決策，並預先核准行動，如此就不會延長 MTTR 等待回應的時間。
**常用的反模式：**
+ 您的零售網站已運作中斷。您不了解用於恢復網站的執行手冊。您開始打電話給同事，希望有人能夠幫助您。
+ 您收到應用程式無法連線的支援案例。您沒有管理系統的許可。您不知道誰有這個許可。您嘗試聯絡開立此案例的系統擁有者，但沒有回應。您沒有此系統的聯絡人，而且您的同事對此不熟悉。
**建立此最佳實務的優勢：** 透過定義向上呈報、向上呈報觸發條件和向上呈報程序，您可以針對影響以適當的速率將資源系統性地新增到事件中。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 定義向上呈報路徑：在您的執行手冊和程序手冊中定義向上呈報路徑，包括觸發向上呈報的條件以及向上呈報的程序。例如，當執行手冊無法解決問題或經過預定時間，將問題從支援工程師向上呈報給資深支援工程師。適當的向上呈報途徑還有，當程序手冊無法確定工作負載的補救途徑或經過預定時間，從高級支援工程師向上呈報給開發團隊。明確確定每個動作的擁有者，以確保對營運事件做出迅速有效的回應。向上呈報可以包括第三方。例如，網路連接提供商或軟體供應商。向上呈報可以包括受影響系統的指定授權決策者。
# OPS10-BP05 啟用推送通知
就您的使用者所用之服務受到影響以及服務再次恢復正常，直接與使用者溝通 (例如，透過電子郵件或簡訊)，以便使用者能夠採取適當動作。
**常用的反模式：**
+ 您的應用程式正遭遇分散式阻斷服務事故，且已數天沒有回應。沒有錯誤訊息。您尚未傳送通知電子郵件。您尚未傳送文字通知。您尚未在社交媒體上分享資訊。您的客戶感到沮喪，正在尋找能夠支援他們的其他廠商。
+ 週一，您的應用程式在進行修補之後發生問題，並中斷運作了幾個小時。週二，您的應用程式在程式碼部署之後發生問題，且效能不可靠的情況持續數小時。週三，您的應用程式在進行程式碼部署 (以減輕與失敗修補相關之安全性弱點的影響) 後出現問題，且無法使用的情況持續數小時。週四，沮喪的客戶開始尋找可以支援他們的其他廠商。
+ 這個週末您的應用程式將會中斷運作以進行維護。您沒有通知客戶。您的部分客戶已排定會用到您應用程式的活動。他們在發現您的應用程式無法使用時感到非常沮喪。
**建立此最佳實務的優勢：** 透過定義通知、通知觸發條件和通知程序，讓您的客戶可以在工作負載的問題影響他們時，收到通知和回應。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 啟用推送通知：就服務受到影響以及服務恢復正常，直接與您的使用者溝通 (例如，透過電子郵件或 SMS)，以便使用者能夠採取適當措施。
+ [Amazon SES 功能](https://aws.amazon.com/ses/details/)
+ [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
## 資源
**相關文件：**
+ [Amazon SES 功能](https://aws.amazon.com/ses/details/)
+ [設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
# OPS10-BP06 透過儀表板傳達狀態
提供針對其目標受眾 (例如，內部技術團隊、領導和客戶) 量身定制的儀表板，以傳達業務的當前營運狀態，並提供感興趣的指標。
您可以使用 [Amazon CloudWatch 儀表板](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 建立儀表板，它位於 CloudWatch 主控台中的自訂首頁上。您可以使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧服務，建立和發佈工作負載和營運運作狀態 (例如，下單率、連線的使用者和交易時間) 的互動式儀表板。建立儀表板，以顯示指標的系統和業務等級檢視。
**常用的反模式：**
+ 根據要求，您執行應用程式目前使用率的報告來進行管理。
+ 在事故期間，相關系統擁有者每 20 分鐘就會聯絡您一次，想知道問題是否已修正。
**建立此最佳實務的優勢：** 透過建立儀表板，您可以自助存取資訊，讓您的客戶能夠自行獲得相關資訊並自行判斷是否需要採取動作。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 透過儀表板溝通狀態：提供針對其目標受眾 (例如，內部技術團隊、領導階層和客戶) 量身定制的儀表板，以傳達企業的當前營運狀況，並提供感興趣的指標。提供自助獲取狀態資訊選項，減少因回應營運團隊狀態請求而造成的干擾。範例包括 Amazon CloudWatch 儀表板和 AWS Health 儀板表。
+ [CloudWatch 儀表板建立和使用自訂指標檢視](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
## 資源
**相關文件：**
+ [Quick](https://aws.amazon.com/quicksight/)
+ [CloudWatch 儀表板建立和使用自訂指標檢視](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
# OPS10-BP07 自動回應事件
自動對事件進行回應，以減少由手動程序引起的錯誤，並確保快速一致的回應。
有多種方式可以在 AWS 上將執行手冊和程序手冊動作自動化。若要回應來自 AWS 資源狀態變更的事件，或您自己的自訂事件，您應建立 [CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 透過 CloudWatch 目標觸發回應 (例如，Lambda 函數、Amazon Simple Notification Service (Amazon SNS) 主題、Amazon ECS 任務，以及 AWS Systems Manager Automation)。
要回應超過資源臨界值的指標 (例如，等待時間)，您應使用建立 [CloudWatch 警示，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 來執行一個或多個動作，方法為使用 Amazon EC2 動作、Auto Scaling 動作，或將通知傳送至 Amazon SNS 主題。如果您需要執行自訂動作來回應警示，則請透過 Amazon SNS 通知叫用 Lambda。使用 Amazon SNS 發佈事件通知和向上呈報訊息，以使人們了解情況。
AWS 還可透過 AWS 服務 API 和 SDK 支援第三方系統。AWS 合作夥伴和第三方提供了許多監控工具，可用於監控、通知和回應。其中一些工具包含 New Relic、Splunk、Loggly、SumoLogic 和 Datadog。
當自動化程序失敗時，您應保留重要的手動程序以供使用
**常用的反模式：**
+ 開發人員檢查其程式碼。此事件原本可能用於啟動建置，然後執行測試，不過沒有發生任何情況。
+ 您的應用程式會在停止運作之前記錄特定錯誤。您應非常了解重新啟動應用程式的程序，且可以編寫此程序的指令碼。您可以使用日誌事件來叫用指令碼，並重新啟動應用程式。相反地，當星期日凌晨 3 點發生錯誤時，您做為負責修正系統的待命資源將被喚醒。
**建立此最佳實務的優勢：** 透過對事件使用自動回應，您可以縮短回應時間，並限制手動活動引入錯誤。
**若未建立此最佳實務，暴露的風險等級為：** 低
## 實作指引
+ 將事件的回應自動化：自動對事件進行回應，以減少由手動流程引起的錯誤，並確保快速、一致的回應。
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [建立隨事件觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [使用 AWS CloudTrail 建立隨 AWS API 呼叫觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [來自所支援服務的 CloudWatch Events 事件範例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [來自所支援服務的 CloudWatch Events 事件範例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
+ [使用 AWS CloudTrail 建立隨 AWS API 呼叫觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [建立隨事件觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**相關影片：**
+ [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU)
**相關範例：**