# 操作
**Topics**
+ [OPS 8. 如何在組織中利用工作負載可觀測性？](ops-08.md)
+ [OPS 9. 如何了解營運狀況？](ops-09.md)
+ [OPS 10. 如何管理工作負載和營運事件？](ops-10.md)
# OPS 8. 如何在組織中利用工作負載可觀測性？
利用可觀測性確保最佳的工作負載運作狀況。利用相關指標、日誌和追蹤，全面掌握工作負載效能並有效解決問題。
**Topics**
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作負載日誌](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作負載追蹤](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 建立儀表板](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 分析工作負載指標
實作應用程式遙測之後，請定期分析收集到的指標。雖然延遲、請求、錯誤和容量 (或配額) 可提供深入了解系統效能的洞見，但務必將檢閱業務成果指標視為優先事項。這樣做可確保您所做的資料驅動決策符合您的業務目標。
**預期成果：**獲得深入工作負載效能的精確洞見，有助於做出資料驅動的決策，確保與業務目標保持一致。
**常見的反模式：**
+ 單獨分析指標，未能考慮到其對業務目標的影響。
+ 過度依賴技術指標，而輕忽業務指標。
+ 未能時常檢閱指標，而錯失即時決策的機會。
**建立此最佳實務的優勢：**
+ 增進對於技術表現與業務成果之間相互關聯的了解。
+ 透過即時資料改善了決策過程。
+ 主動識別並緩解問題，不讓問題影響業務成果。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
利用 Amazon 等工具 CloudWatch 執行指標分析。 CloudWatch 異常偵測和 Amazon DevOpsGuru 等 AWS 服務可用來偵測異常，特別是靜態閾值未知或行為模式更適合異常偵測時。
### 實作步驟
1. **分析與檢閱：**定期檢閱和解讀您的工作負載指標。
1. 將業務成果指標視為優先於純粹技術指標的事項。
1. 了解資料中峰值、下降或模式的重要性。
1. **使用 Amazon CloudWatch：**使用 Amazon CloudWatch 進行集中式檢視和深入分析。
1. 設定 CloudWatch 儀表板以視覺化您的指標，並隨時間進行比較。
1. 使用 [中的百分位數 CloudWatch](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)來取得指標分佈的清晰檢視，這有助於定義SLAs和了解異常值。
1. 設定[CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)以識別異常模式，而不必依賴靜態閾值。
1. 實作[CloudWatch 跨帳戶可觀測性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)，以監控和疑難排解跨區域內多個帳戶的應用程式。
1. 使用 [CloudWatch Metric Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) 查詢和分析帳戶和區域的指標資料，識別趨勢和異常。
1. 套用[CloudWatch 指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)來轉換、彙總或執行指標的計算，以取得更深入的洞見。
1. **使用 Amazon DevOpsGuru：**將 [Amazon DevOpsGuru](https://aws.amazon.com/devops-guru/) 納入其機器學習增強型異常偵測，以識別無伺服器應用程式的早期操作問題跡象，並在影響客戶之前對其進行修復。
1. **根據洞見最佳化：**根據您的指標分析做出明智的決策，以調整和改善您的工作負載。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
**相關文件：**
+ [The Wheel 部落格 - 強調持續檢閱指標的重要性](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [百分位數很重要](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [ 使用 AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch 跨帳戶可觀測性 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ 使用 CloudWatch Metrics Insights 查詢您的指標 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**相關影片：**
+ [ 在 Amazon 中啟用跨帳戶可觀測性 CloudWatch ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Amazon DevOpsGuru 簡介 ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [ 使用 持續分析指標 AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
+ [ AIOps使用 Amazon DevOpsGuru 取得操作洞見 ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 分析工作負載日誌
定期分析工作負載日誌對於深入了解應用程式的操作層面至關重要。藉由有效率地篩選、視覺化和解讀日誌資料，可持續最佳化應用程式效能和安全。
**預期成果：**從徹底的日誌分析中獲得深入應用程式行為和操作的豐富洞見，以確保主動偵測和緩解問題。
**常見的反模式：**
+ 忽略日誌分析，直到出現嚴重問題。
+ 沒有使用可用於日誌分析的完整工具套件，錯過了關鍵洞見。
+ 只倚賴手動檢閱日誌，而未利用自動化和查詢功能。
**建立此最佳實務的優勢：**
+ 主動找出操作瓶頸、安全威脅及其他潛在問題。
+ 有效利用日誌資料，以實現持續的應用程式最佳化。
+ 加強對應用程式行為的理解，幫助偵錯和疑難排解。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 是日誌分析的強大工具。 CloudWatch Logs Insights 和 Contributor Insights 等整合功能，讓從日誌中擷取有意義的資訊的過程變得直覺且有效。
### 實作步驟
1. **設定 CloudWatch 日誌 **：設定應用程式和服務將日誌傳送至 CloudWatch 日誌。
1. **使用日誌異常偵測：**利用 [Amazon CloudWatch Logs 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)自動識別並提醒異常日誌模式。此工具可協助您主動管理日誌中的異常，並儘早偵測潛在問題。
1. **設定 CloudWatch Logs Insights **：使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 以互動方式搜尋和分析您的日誌資料。
1. 製作查詢以找出模式、視覺化日誌資料，並產生可付諸行動的洞見。
1. 使用 [CloudWatch Logs Insights 模式分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Patterns.html)來分析和視覺化常用日誌模式。此功能可協助您了解日誌資料中常見的操作趨勢和潛在的異常值。
1. 使用 [CloudWatch Logs compare （diff）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Compare.html) 在不同時段或不同日誌群組之間執行差異分析。使用此功能可精確找出變更，並評估其對系統效能或行為的影響。
1. **使用 Live Tail 即時監控日誌：**使用 [Amazon CloudWatch Logs Live Tail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_LiveTail.html) 即時檢視日誌資料。您可以在應用程式的操作活動發生時進行主動監控，以便立即掌握系統效能和潛在問題。
1. **利用 Contributor Insights **：使用 [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) 來識別 IP 地址或使用者代理等高基度維度的熱門發言者。
1. **實作 CloudWatch 日誌指標篩選條件 **：設定[CloudWatch 日誌指標篩選條件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)，將日誌資料轉換為可操作的指標。如此您就能設定警報或進一步分析模式。
1. **實作[CloudWatch跨帳戶可觀測性 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)：**監控和疑難排解跨區域內多個帳戶的應用程式。
1. **定期檢閱和改進**：定期檢閱您的日誌分析策略，以擷取所有相關資訊並持續最佳化應用程式效能。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
**相關文件：**
+ [使用 Logs Insights 分析 CloudWatch 日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [使用 CloudWatch 貢獻者洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [建立和管理 CloudWatch 日誌指標篩選條件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**相關影片：**
+ [使用 Logs Insights 分析 CloudWatch 日誌資料](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [使用 CloudWatch 貢獻者洞察分析高基數資料](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**相關範例：**
+ [CloudWatch 記錄範例查詢](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 分析工作負載追蹤
分析追蹤資料對於實現應用程式營運歷程的全面檢視至關重要。透過視覺化和了解各種不同元件之間的互動，就能微調效能、找出瓶頸，並且增強使用者體驗。
**預期成果：**清楚掌握應用程式的分散式操作，就能更快解決問題並增強使用者體驗。
**常見的反模式：**
+ 忽略追蹤資料，只依賴日誌和指標。
+ 不會將追蹤資料與相關日誌建立關聯。
+ 忽略從追蹤產生的指標，如延遲和故障率。
**建立此最佳實務的優勢：**
+ 改善故障診斷並減少解決的平均時間 （MTTR）。
+ 深入了解依賴性及其影響。
+ 快速識別和糾正效能問題。
+ 利用追蹤衍生的指標制定明智的決策。
+ 透過最佳化元件互動改善使用者體驗。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
[AWS X-Ray](https://www.docs.aws.com/xray/latest/devguide/aws-xray.html) 提供了全方位的追蹤資料分析套件，能讓您深入了解服務互動的各個層面、監控使用者活動，以及偵測效能問題。 ServiceLens、X-Ray Insights、X-Ray Analytics 和 Amazon DevOpsGuru 等功能可增強從追蹤資料衍生的可操作洞察深度。
### 實作步驟
下列步驟提供結構化方法，可有效使用 AWS 服務實作追蹤資料分析：
1. **整合 AWS X-Ray**：確保 X-Ray 與您的應用程式整合，以擷取追蹤資料。
1. **分析 X-Ray 指標**：深入研究 X-Ray 追蹤衍生的指標，例如延遲、請求率、錯誤率和回應時間分佈，使用[服務地圖](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view)來監控應用程式運作狀態。
1. **使用 ServiceLens**：利用[ServiceLens地圖](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html)增強服務和應用程式的可觀測性。如此就能將追蹤、指標、日誌、警報和其他運作狀況資訊整合在一起檢視。
1. **啟用 X-Ray Insights**：
1. 開啟 [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html)，以自動偵測追蹤中的異常。
1. 檢查洞見以找出明確的模式並確定根本原因，例如故障率或延遲增加。
1. 請參考 Insights 時間軸，依時間順序查看所偵測到問題的分析。
1. **使用 X-Ray Analytics**：[X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) 可讓您徹底探索追蹤資料、精確定位模式並擷取洞見。
1. **使用 X-Ray 中的群組**：在 X-Ray 中建立群組，即可根據如高延遲等條件篩選追蹤，以進行更針對性的分析。
1. **合併 Amazon DevOpsGuru **：讓 [Amazon DevOpsGuru](https://aws.amazon.com/devops-guru/) 受益於機器學習模型，以找出追蹤中的操作異常。
1. **使用 CloudWatch Synthetics **：使用 [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) 建立 Canary，以持續監控您的端點和工作流程。這些 Canary 可與 X-Ray 整合，以提供追蹤資料，用來對要測試的應用程式進行深入分析。
1. **使用實際使用者監控 （RUM）**：使用 [AWS X-Ray 和 CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)，您可以從應用程式的最終使用者開始透過下游 AWS 受管服務分析和偵錯請求路徑。這樣做有助於找出影響最終使用者的延遲趨勢和錯誤。
1. **與日誌建立關聯**：將[追蹤資料與 X-Ray 追蹤檢視中的相關日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs)建立關聯，以深入了解應用程式行為。如此可讓您檢視與追蹤的交易直接相關的日誌事件。
1. **實作[CloudWatch跨帳戶可觀測性 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)：**監控和疑難排解跨區域內多個帳戶的應用程式。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作負載日誌](ops_workload_observability_analyze_workload_logs.md)
**相關文件：**
+ [使用 ServiceLens 監控應用程式運作狀態](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [使用 X-Ray Analytics 探索追蹤資料](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [使用 X-Ray Insights 偵測追蹤中的異常狀況](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [使用 CloudWatch Synthetics 持續監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**相關影片：**
+ [使用 Amazon CloudWatch Synthetics & 分析和偵錯應用程式 AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [使用 AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 實作 X-Ray AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [CloudWatch Synthetics Canary 範本](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 建立可執行的提醒
及時偵測並回應您的應用程式行為中的偏差至關重要。尤其重要的是要了解基於關鍵績效指標 (KPI) 的結果何時處於危險之中，或者何時出現意外異常。以 KPI 為基礎的提醒可確保您收到的訊號直接與業務或營運影響產生關係。這種可採取動作的提醒方法可促進主動回應，並有助於維持系統效能與可靠性。
**預期成果：**接收及時、相關且可行的提醒，以便快速識別和緩解潛在問題，尤其是在 KPI 結果面臨風險時。
**常見的反模式：**
+ 設定太多非嚴重性提醒會導致提醒疲勞。
+ 不會根據 KPI 來排定提醒的優先順序，因此難以了解問題的業務影響。
+ 忽視解決根本原因導致同一問題的重複提醒。
**建立此最佳實務的優勢：**
+ 透過專注於可操作且相關的提醒來減少提醒疲勞。
+ 透過主動偵測和緩解問題，改善系統運作時間和可靠性。
+ 透過與熱門的提醒和通訊工具整合，強化團隊協同作業並加快解決問題的速度。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若要建立有效的提醒機制，使用指標、日誌和追蹤資料至關重要，其會在基於 KPI 的結果出現風險或偵測到異常時進行標記。
### 實作步驟
1. **確定關鍵績效指標 (KPI)**：確定應用程式的 KPI。提醒應與這些關鍵績效指標相關聯，以準確反映業務影響。
1. **實作異常偵測**：
+ **使用 Amazon CloudWatch 異常偵測**：設定 [Amazon CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)以自動偵測異常模式，這可協助您僅針對真正的異常產生提醒。
+ **使用 AWS X-Ray Insights**：
1. 設定 [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) 以偵測追蹤資料中的異常。
1. 設定 [X-Ray Insights 的通知](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)，以便在偵測到問題時收到提醒。
+ **與 Amazon DevOps Guru 整合**：
1. 利用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 的機器學習功能，偵測現有資料的操作異常情況。
1. 導覽至 DevOps Guru 中的[通知設定](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings)，以設定異常提醒。
1. **實作可執行的提醒**：設計提醒，為立即採取行動提供足夠資訊。
1. [使用 Amazon EventBridge 規則監控 AWS Health 事件](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)，或以程式設計方式與 AWS Health API 整合，以便在您收到 AWS Health 事件時自動執行動作。這些動作可以是一般動作 (例如將所有規劃的生命週期事件訊息傳送至聊天介面) 或是特定動作 (例如在 IT 服務管理工具中啟動工作流程)。
1. **減少提醒疲勞**：將非嚴重性提醒降至最低。當團隊對眾多微不足道的提醒感到不知所措時，他們可能會失去對重大問題的監督，從而降低提醒機制的整體有效性。
1. **設定複合警示**：使用 [Amazon CloudWatch 複合警示](https://aws.amazon.com/bloprove-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/)來合併多個警示。
1. **與提醒工具整合**：整合諸如 [Ops Genie](https://www.atlassian.com/software/opsgenie) 和 [PagerDuty](https://www.pagerduty.com/) 等工具。
1. **採用聊天應用程式中的 Amazon Q Developer**：整合[聊天應用程式中的 Amazon Q Developer](https://aws.amazon.com/chatbot/)，以便將警示轉送至 Amazon Chime、Microsoft Teams 和 Slack。
1. **基於日誌的提醒**：使用 CloudWatch 中的[日誌指標篩選器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)，根據特定的日誌事件建立警示。
1. **審查並反覆**：定期重新檢視並調整提醒組態。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS04-BP03 實作使用者體驗遙測](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 實作分散式追蹤](ops_observability_dist_trace.md)
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作負載日誌](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作負載追蹤](ops_workload_observability_analyze_workload_traces.md)
**相關文件：**
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [建立複合警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [根據異常偵測建立 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [DevOps Guru 通知](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [X-ray Insights 通知](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [透過互動式 ChatOps 監控和操作您的 AWS 資源並進行疑難排解](https://aws.amazon.com/chatbot/)
+ [Amazon CloudWatch 整合指南 \$1 PagerDuty](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [整合 Opsgenie 與 Amazon CloudWatch](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**相關影片：**
+ [在 Amazon CloudWatch 中建立複合警示](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [聊天應用程式中的 Amazon Q Developer 概觀](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [聊天應用程式中的 Amazon Q Developer 中的 AWS On Air ft. 可變命令](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**相關範例：**
+ [使用 Amazon CloudWatch 在雲端進行警示、事件管理和修復](https://aws.amazon.com/bloarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [教學課程：建立將通知傳送至聊天應用程式中的 Amazon Q Developer 的 Amazon EventBridge 規則](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 建立儀表板
儀表板是以人為本的工作負載遙測資料檢視。雖然它們提供了重要的視覺介面，但它們不應該取代警報機制，而是補充它們。經過精心打造的儀表板不僅能提供快速了解系統運作狀況和效能的洞見，還能對利益相關者呈現有關業務成果和問題影響層面的即時資訊。
**預期成果：**
使用視覺呈現的方式，提供清楚、深入系統與業務運作狀況且可付諸行動的洞見。
**常見的反模式：**
+ 包含太多指標、過於複雜的儀表板。
+ 仰賴沒有異常偵測提醒的儀表板。
+ 儀表板未隨著工作負載發展而更新。
**建立此最佳實務的優勢：**
+ 立即掌握關鍵系統指標和 KPI。
+ 增強利益相關者的溝通和理解。
+ 快速深入洞察操作問題的影響層面。
**未建立此最佳實務時的風險等級：**中
## 實作指引
**以業務為中心的儀表板**
專為業務 KPI 量身打造的儀表板，可與更廣泛的利益相關者進行互動。儘管這些人可能對系統指標不感興趣，但他們熱衷於了解這些數字的業務含義。以業務為中心的儀表板可確保所有受監控和分析的技術和營運指標都與總體業務目標保持同步。這種一致性提供了清晰度，確保每個人在什麼重要以及什麼不重要的問題上意見一致。此外，突出顯示業務 KPI 的儀表板往往更具可操作性。利益相關者可以快速了解營運的運作狀態、需要注意的領域以及對業務成果的潛在影響。
考慮到這一點，在建立儀表板時，請確保技術指標和業務 KPI 之間保持平衡。兩者都至關重要，但兩者迎合不同的受眾。在理想情況下，您應有能夠提供全方位視角儀表板，以便深入掌握系統運作狀況與效能，同時也要強調關鍵業務成果及其影響。
Amazon CloudWatch 儀表板是 CloudWatch 主控台中可自訂的首頁，可讓您在單一檢視中監控資源，甚至是分散在不同的 AWS 區域 和帳戶中的那些資源。
### 實作步驟
1. **建立基本儀表板：**[在 CloudWatch 中建立新儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)，並為其提供描述性名稱。
1. **使用 Markdown 小工具:**在深入研究指標之前，請[使用 Markdown 小工具](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html)在儀表板頂端新增文字內容。此內容應說明儀表板涵蓋的內容、所呈現指標的重要性，還可以包含其他儀表板和疑難排解工具的連結。
1. **建立儀表板變數：**在適當位置[合併儀表板變數](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)，以允許動態且靈活的儀表板檢視。
1. **建立儀表板小工具：**[新增儀表板小工具](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html)以便將應用程式產生的各種不同指標視覺化，並調整這些小工具以便有效呈現系統運作狀況和業務成果。
1. **Log Insights 查詢：**利用 [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) 從日誌中導出可操作的指標，並在儀表板上顯示這些洞見。
1. **設定警示：**將 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html)整合到儀表板中，以便快速查看違反其閾值的任何指標。
1. **使用 Contributor Insights：**整合 [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) 以分析高基數欄位，並更清楚地了解資源的主要貢獻者。
1. **設計自訂小工具：**對於標準小工具未滿足的特定需求，請考慮建立[自訂小工具](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)。這些小工具可從各種資料來源中提取資料，或以獨特的方式呈現資料。
1. **使用 AWS Health：** AWS Health 是 AWS 雲端 資源運作狀態的權威資訊來源。使用現成的 [AWS Health 儀板表](https://health.aws.amazon.com/health/status)，或使用您自己的儀表板和工具中的 AWS Health 資料，以便擁有正確的資訊來做出明智的決策。
1. **反覆執行並改進：**隨著應用程式發展，請定期重新檢視您的儀表板，以確保其相關性。
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作負載日誌](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作負載追蹤](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
**相關文件：**
+ [建置用於檢視營運狀況的儀表板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**相關影片：**
+ [建立跨帳戶和跨區域 CloudWatch 儀表板](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - 透過 AWS 雲端 了解企業 (營運儀表板)](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 Amazon CloudWatch 監控應用程式](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
+ [AWS Health 事件智慧儀表板和洞見](https://aws.amazon.com/blogs/mt/aws-health-events-intelligence-dashboards-insights/)
+ [使用 Amazon Managed Grafana 視覺化 AWS Health 事件](https://aws.amazon.com/blogs/mt/visualize-aws-health-events-using-amazon-managed-grafana/)
# OPS 9. 如何了解營運狀況？
定義、擷取和分析營運指標，掌握營運事件，以便採取適當行動。
**Topics**
+ [OPS09-BP01 使用指標衡量營運目標與 KPI](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 傳達狀態和趨勢以確實掌控營運狀況](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 審核營運指標並優先改進](ops_operations_health_review_ops_metrics_prioritize_improvement.md)
# OPS09-BP01 使用指標衡量營運目標與 KPI
從您的組織取得定義營運成功的目標和 KPI，並決定反映這些目標的指標。設定基準做為參考點，並定期重新評估。制定機制以便從團隊收集這些指標以進行評估。[DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) 指標提供了衡量軟體交付的 DevOps 實務進度的常用方法。
**預期成果：**
+ 組織會發布並分享營運團隊的目標和 KPI。
+ 您負責建立反映這些 KPI 的指標。範例可能包括：
+ 票證佇列深度或票證平均存留時間
+ 依問題類型分組的票證計數
+ 處理問題所花的時間，無論是否有標準作業程序 (SOP)
+ 從失敗的程式碼推送復原所花的時間長度
+ 通話音量
**常見的反模式：**
+ 錯過部署期限，因為開發人員須分心處理疑難排解工作。開發團隊要求更多人力，但無法提出確切需要的人力數量，因為無法衡量被佔用的時間。
+ 設立了 1 級服務台來處理使用者通話。經過一段時間後，加入了更多工作負載，但並沒有分配更多人員給 1 級服務台。客戶滿意度受到通話時間增加及問題未解決的時間拉長影響而下降，但管理層看不到這些現象的指標，未能採取任何行動。
+ 有問題的工作負載已交由另一個營運團隊進行維護。與其他工作負載不同的是，並未針對這個新工作負載提供適當的文件和執行手冊。因此，團隊花費更長的時間進行疑難排解和解決失敗情況。然而，沒有任何指標記載此情況，因此無法明確究責。
**建立此最佳實務的優勢：**只要工作負載監控顯示我們應用程式和服務的狀態，監控營運團隊就可讓擁有者深入了解這些工作負載取用者之間的變化，例如業務需求轉變。藉由建立能夠反映營運狀態的指標來衡量這些團隊的效用，並依據業務目標進行評估。指標可突顯支援問題，或識別何時發生偏離服務層級目標的情形。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
安排時間與企業領導者和利害關係人一起確定服務未來的整體目標。確定各個不同營運團隊應負責的任務，以及能夠應對哪些挑戰。使用這些來集思廣益，找出能夠反映這些營運目標的關鍵績效指標 (KPI)。這些目標可能包括客戶滿意度、從形成功能概念到部署的時間、平均問題解決時間，以及成本效率。
從 KPI 中找出最能反映這些目標的資料指標和來源。客戶滿意度可能由各種不同的指標組合而成，例如通話等待或回應時間、滿意度分數，以及提出的問題類型。部署時間可能是測試和部署，加上任何需要新增的部署後修正所需時間的總和。顯示不同類型的問題所花費時間 (或是這些問題的計數) 的統計資料，可提供一個切入視角，以了解需要針對性處理的地方。
## 資源
**相關文件：**
+ [Quick - 使用 KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [Amazon CloudWatch - 使用指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [建置儀表板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [如何使用 KPI 儀表板追蹤成本最佳化 KPI](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [AWS DevOps 指引](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
**相關範例：**
+ [使用原生 AWS 監控和可觀測性工具來監控軟體交付的效能](https://catalog.us-east-1.prod.workshops.aws/workshops/3b7f3d77-c6ef-44b2-aa29-d2719b8be897/en-US)
+ [利用 DORA 指標在部署速度與穩定性之間取得平衡](https://aws.amazon.com/blogs/devops/balance-deployment-speed-and-stability-with-dora-metrics/)
+ [金融服務產業中的 MLOps 營運指標範例](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-unlock-value-data-financial-services/operational-metrics.html)
+ [如何使用 KPI 儀表板追蹤成本最佳化 KPI](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
# OPS09-BP02 傳達狀態和趨勢以確實掌控營運狀況
您須了解營運狀態及趨勢方向，以確定成果何時可能存在風險、是否可支援新增的工作，或是變更對您的團隊造成的影響。營運事件發生時，有提供使用者和營運團隊參考資訊的狀態頁面，就能減輕溝通管道的壓力，並有效傳播資訊。
**預期成果：**
+ 主管對團隊處理的通話量類型和正在進行的工作 (例如部署) 可以一目瞭然。
+ 發生影響擴及正常營運的情況時，利益相關者和使用者社群就會收到警示。
+ 組織領導階層和利益相關者可查看狀態頁面以便回應警示或影響，並且獲得有關營運事件的資訊，例如聯絡窗口、票證資訊及預估的復原時間。
+ 領導階層和其他利益相關者會收到報告，報告中會顯示營運統計資料，例如某一段時間內的通話量、使用者滿意度分數、待處理票證數量及其存留時間。
**常見的反模式：**
+ 工作負載停擺，造成服務無法使用。通話量暴增，因為使用者要求得知發生什麼情況。主管也要求得知誰在處理問題，因而增加了通話量。不同的營運團隊重複投入嘗試調查的工作。
+ 由於需要新功能，因而轉派數名人員進行工程工作。但未回補空缺，使得解決問題的時間大幅拉長。領導階層並未獲得這些資訊，而是在經過數週且收到使用者不滿意的意見回饋後才察覺此問題。
**建立此最佳實務的優勢：**在業務受到影響的營運事件中，各個團隊可能會浪費大量時間和精力來查詢資訊，以試圖了解情況。透過建立廣泛傳播的狀態頁面和儀表板，利益相關者就能迅速獲得資訊，例如是否偵測到問題、誰負責處理問題，或是預計何時恢復正常營運。如此一來，團隊成員就不需花太多時間與其他人溝通狀態，因而有更多時間解決問題。
此外，儀表板和報告可以為決策者和利益相關者提供洞見，以了解營運團隊如何能夠回應業務需求以及如何分配其資源。這對於確定是否有足夠的資源來支援業務至關重要。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建置儀表板，以顯示營運團隊目前的關鍵指標，並且讓營運主管和管理層隨時可存取這些資訊。
建置可快速更新的狀態頁面，以顯示事故或事件何時發生、負責人是誰，以及誰負責協調回應。在此頁面上分享使用者應考量的任何步驟或因應措施，並廣泛傳播位置。鼓勵使用者遇到未知的問題時，先查看此位置。
收集並提供報告，以顯示長時間的營運狀況，並將此資訊傳達給主管和決策者，以說明運營工作及挑戰和需求。
在團隊之間共用這些最能反映目標和 KPI 的指標和報告，以及這些資訊在推動變革方面的影響力。花時間進行這些活動，以在團隊內部和團隊之間提高營運的重要性。
使用 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 搭配您擁有的儀表板，或將 AWS Health 事件整合到其中，讓您的團隊能夠找出應用程式問題與 AWS 服務狀態之間的相互關聯。
## 資源
**相關的最佳實務：**
+ [OPS09-BP01 使用指標衡量營運目標與 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
**相關文件：**
+ [測量進度](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [建置用於檢視營運狀況的儀表板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
**相關範例：**
+ [資料操作](https://aws.amazon.com/solutions/app-development/data-operations)
+ [如何使用 KPI 儀表板追蹤成本最佳化 KPI](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [大規模雲端遷移關鍵績效指標 (KPI) 的重要性](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
# OPS09-BP03 審核營運指標並優先改進
預留審核營運狀態的專屬時間和資源，以確保依舊優先處理日常業務線所需的服務。召集營運主管和利益相關者定期審核指標、重新確認或修改各項目標，並優先改進。
**預期成果：**
+ 營運主管和員工定期開會，以審核一段特定報告期間的指標。說明挑戰、一同慶祝成就，並分享學到的經驗。
+ 利益相關者與企業領導者會定期收到營運狀態的簡報，並徵求有關目標、KPI 和未來計畫的意見。討論服務交付、營運和維護之間的權衡，並納入相關環境中。
**常見的反模式：**
+ 新產品已推出，但 1 級和 2 級營運團隊未接受足夠的培訓來提供支援，或未配置額外的人員。領導者未看見指出支援單解決次數減少且事故量增加的指標。訂閱數量隨著不滿的使用者離開平台而開始減少，但數週後才採取行動。
+ 長久以來一直採用手動程序來執行工作負載維護工作。雖然渴望自動化，但由於系統的重要性較低，因此優先順序較低。然而經過一段時間後，系統的重要性已提高，而現在這些手動程序佔用了大多數營運時間。未安排資源來提供更多營運工具，導致員工隨著工作負載增加而倦怠。等到有員工離職並加入其他競爭對手，領導階層才察覺到此情況。
**建立此最佳實務的優勢：**在某些組織中，將相同的時間和注意力分配給服務交付和新產品或方案可能會是一項挑戰。發生這種情況時，業務線可能會因為預期的服務層級逐漸惡化而受到影響。這是因為營運未隨著業務成長而改變和發展，並且可能很快就會落後。假如未定期審核營運收集的洞見，那麼察覺到業務風險時，便可能為時已晚。透過分配時間與營運員工和領導階層一起審核指標和程序，就能持續掌握營運所扮演的重要角色，並且能夠在風險達到嚴重等級之前發現。營運團隊能夠更深入洞察即將發生的業務變化與計畫，進而採取積極的行動。領導階層對於營運指標的掌握程度，展現了這些團隊在內部和外部的客戶滿意度方面所扮演的角色，並讓他們在各種選擇當中權衡出更適當的優先順序，或確保營運團隊有時間和資源能夠隨著新的業務和工作負載計畫做出改變與發展。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
花時間與利益相關者和營運團隊一起審核營運指標，並審核報告資料。將這些報告與組織的目標相互比對，以確定是否符合這些目標。找出目標不明確，或者要求與付出之間存在衝突的模糊地帶來源。
找出時間、人員和工具能夠協助實現營運成果的地方。確定哪些 KPI 會受到影響，以及哪些應是成功的目標。定期重新檢視，以確保營運資源充足，可支援業務線。
## 資源
**相關文件：**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [使用 Amazon 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)
# 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 使用程序進行事件、事故和問題管理
有效管理事件、事故和問題的能力是維持工作負載運作狀態和效能的關鍵。識別和理解這些元素之間的差異，以制定有效的回應和解決策略至關重要。為每個方面建立並遵循明確定義的流程，有助於您的團隊迅速且有效地處理出現的任何運營挑戰。
**預期成果：**您的組織透過詳細記錄且集中儲存的流程，有效地管理營運事件、事故和問題。這些流程會持續更新以反映變更，簡化處理並維持高服務可靠性和工作負載效能。
**常見的反模式：**
+ 您會反應性地 (而非主動) 回應事件。
+ 對不同類型的事件或事故採取不一致的方法。
+ 您的組織不會分析事件並從中學習，以防止未來再次發生。
**建立此最佳實務的優勢：**
+ 簡化且標準化的回應流程。
+ 減少事件對服務和客戶的影響。
+ 加速解決問題。
+ 持續改善營運流程。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
實作此最佳實務表示您正在追蹤工作負載事件。您有處理事件和問題的程序。會經常記錄、共用和更新這些程序。問題經識別後會定出優先順序，然後獲得修正。
**了解事件、事故和問題**
+ **事件：***事件*是對動作、狀況或狀態變化的觀察。事件可以經過計劃或未計劃，並且事情可以在工作負載內部或外部產生。
+ **事故：***事故*是指需要回應的事件，例如意外中斷或服務品質下降。它們表示需要立即注意以恢復正常工作負載操作的中斷。
+ **問題：***問題*是一個或多個事故的根本原因。識別和解決問題涉及更深入地研究事故，以防止將未來再次發生。
### 實作步驟
**事件**
1. **監控事件：**
+ [實作可觀測性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)並[利用工作負載可觀測性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)。
+ 使用者、角色或 AWS 服務所採取的監控動作會記錄為 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 中的事件。
+ 使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 即時對應用程式中的操作變更進行回應。
+ 使用 [AWS Config](https://aws.amazon.com/config/) 持續評估、監控和記錄資源組態變更。
1. **建立程序：**
+ 制定一個程序來評估哪些事件重要並需要監控。這涉及設定正常和異常活動的閾值和參數。
+ 確定將事件升級為事故的條件。這可以基於嚴重性、對使用者的影響或與預期行為的偏差。
+ 定期審核事件監控和回應程序。這包括分析過去的事件、調整閾值以及完善警示機制。
**事故**
1. **回應事故：**
+ 使用可觀測性工具的洞察力，快速識別並回應事故。
+ 實作 [AWS Systems Manager Ops Center](https://aws.amazon.com/systems-manager/features/#OpsCenter) 以彙總、組織營運項目和事故，並排定優先順序。
+ 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 等服務，進行更深入的分析和疑難排解。
+ 考慮使用 [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) 來加強事件管理，利用其主動、預防性和偵測功能。AMS 透過監控、事故偵測和回應以及安全管理等服務擴展了營運支援。
+ Enterprise Support 客戶可利用 [AWS 事件偵測與回應](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)功能，為生產工作負載提供持續的主動監控和事件管理。
1. **建立事件管理程序：**
+ 建立結構化的事件管理流程，包括清晰的角色、通訊協定和解決步驟。
+ 將事件管理與[聊天應用程式中的 Amazon Q Developer](https://aws.amazon.com/chatbot/) 這類工具整合，以實現有效率的回應和協調。
+ 依嚴重性將事件分類，並針對每個類別預先定義[事件回應計劃](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)。
1. **學習和改進：**
+ 進行[事件後分析](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)以了解根本原因和解決方案有效性。
+ 根據審查和不斷發展的實務，持續更新和改進回應計劃。
+ 記錄並分享跨團隊所學到的經驗教訓，以增強營運彈性。
+ Enterprise Support 客戶可向其技術客戶經理請求參加[事件管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)。這個指導性研討會可測試您現有的事件回應計畫，並協助您找出需要改進的領域。
**問題**
1. **識別問題：**
+ 使用先前事件的資料來識別可能指出更深層次系統性問題的週期性模式。
+ 運用諸如 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 和 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 等工具來分析趨勢並發現潛在問題。
+ 與包括營運、開發和業務單位在內的跨職能團隊合作，以獲得有關根本原因的不同觀點。
1. **建立問題管理程序：**
+ 制定問題管理的結構化程序，專注於長期解決方案，而不是快速修復。
+ 整合根本原因分析 (RCA) 技術，以調查並了解事件的根本原因。
+ 根據調查結果更新營運政策、程序和基礎設施，以防止重複發生。
1. **持續改善：**
+ 培養不斷學習和改進的文化，鼓勵團隊積極識別和解決潛在問題。
+ 定期審查和修訂問題管理程序和工具，以配合不斷發展的業務和技術環境。
+ 在整個組織中分享見解和最佳實務，以建立更具彈性且更有效率的營運環境。
1. **聯絡 AWS 支援：**
+ 使用 AWS 支援資源，例如 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，取得主動式指引和最佳化建議。
+ Enterprise Support 客戶可以在重大事件期間存取 [AWS Countdown](https://aws.amazon.com/premiumsupport/aws-countdown/) 等專業計畫以取得支援。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)
+ [OPS08-BP01 分析工作負載指標](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md)
**相關文件：**
+ [AWS 安全事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS 事件偵測與回應](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)
+ [AWS Cloud Adoption Framework：營運角度 - 事件與問題管理](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [DevOps 和 SRE 時代的事件管理](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - 什麼是事件管理？](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**相關影片：**
+ [來自 AWS 的重要事件回應秘訣](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [AWS re:Invent 2022 - Amazon 建置者資料中心：25 年 Amazon 卓越營運](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - AWS 事故偵測與回應 (SUP201)](https://www.youtube.com/watch?v=IbSgM4IP9IE)
+ [介紹 AWS Systems Manager 中的 Incident Manager](https://www.youtube.com/watch?v=I6lScgh4qds)
**相關範例：**
+ [AWS 主動服務 – 事件管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [如何使用 PagerDuty 和 AWS Systems Manager Incident Manager 來自動化事故回應](https://aws.amazon.com/blogs/mt/how-to-automate-incident-response-with-pagerduty-and-aws-systems-manager-incident-manager/)
+ [使用 AWS Systems Manager Incident Manager 中的隨時待命的時間表與事故回應人員互動](https://aws.amazon.com/blogs/mt/engage-incident-responders-with-the-on-call-schedules-in-aws-systems-manager-incident-manager/)
+ [改善 AWS Systems Manager Incident Manager 中事故處理期間的可見性和協作](https://aws.amazon.com/blogs/mt/improve-the-visibility-and-collaboration-during-incident-handling-in-aws-systems-manager-incident-manager/)
+ [AMS 中的事故報告和服務請求](https://docs.aws.amazon.com/managedservices/latest/userguide/support-experience.html)
**相關服務：**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
# OPS10-BP02 每個提醒建立一個程序
為系統中的每個提醒建立清晰明確的程序，對於有效且高效的事件管理至關重要。此做法可確保每個提醒都能產生特定且可行的回應，從而改善操作的可靠性和回應能力。
**預期成果：**每個提醒都會啟動特定且明確定義的回應計劃。在可能的情況下，回應會自動化，具有明確的擁有權和定義的呈報路徑。提醒會連結至最新的知識庫，以便任何操作員都能一致且有效地回應。回應迅速且全面一致，可提升營運效率和可靠性。
**常見的反模式：**
+ 提醒沒有預定義的回應流程，導致臨時和延遲的解決方案。
+ 提醒過載會導致重要提醒被忽略。
+ 由於缺乏明確的擁有權和責任，提醒的處理不一致。
**建立此最佳實務的優勢：**
+ 透過僅提高可操作的提醒來減少提醒疲勞。
+ 減少操作問題的平均解決時間 (MTTR)。
+ 減少平均調查時間 (MTTI)，有助於降低 MTTR。
+ 增強擴展操作回應的能力。
+ 提高了處理操作事件中的一致性和可靠性。
例如，您已有既定流程來處理重要帳戶的 AWS Health 事件，包括應用程式警示、營運問題及規劃的生命週期事件 (例如，在叢集自動更新之前更新 Amazon EKS 版本)，而且您為團隊提供主動監控、溝通和回應這些事件的能力。這些動作有助於防止 AWS 端變更造成的服務中斷，或是在發生非預期的問題時更快緩解。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
為每個提醒制定一個流程，包括：為每個提醒建立清晰的回應計劃；在可能的情況下自動化回應；並根據營運意見回饋和不斷發展的需求持續完善這些流程。
### 實作步驟
下圖說明 [AWS Systems Manager Incident Manager](https://aws.amazon.com/systems-manager/features/incident-manager/) 中的事件管理工作流程。它的設計目的是透過自動建立事件來回應 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 或 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 中的特定事件，迅速回應營運問題。自動或手動建立事件時，Incident Manager 會集中管理事件，組織相關的 AWS 資源資訊，並啟動預先定義的回應計劃。這包括執行 Systems Manager Automation 執行手冊以立即採取行動，以及在 OpsCenter 中建立父作業工作項目以追蹤相關任務和分析。此簡化的流程可加速並協調整個 AWS 環境中的事件回應。
![\[描述 Incident Manager 如何運作的流程圖 - 聊天應用程式中的 Amazon Q Developer、呈報計畫和聯絡人，並且執行手冊會流入回應計畫，回應計畫會流入事件和分析。Amazon CloudWatch 也會流入回應計劃。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/incident-manager-how-it-works.png)
1. **使用複合警示：**在 CloudWatch 中建立[複合警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)，將相關警示分組，從而降低噪音並允許更有意義的回應。
1. **利用 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 隨時掌握新知：**AWS Health 是 AWS 雲端 資源運作狀態的權威資訊來源。使用 AWS Health 視覺化並接收有關任何目前服務事件和近期變更的通知 (例如規劃的生命週期事件)，如此您就能採取行動來緩解衝擊。
1. 透過 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) [建立符合用途的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，以利用電子郵件和聊天管道傳送，並[透過 Amazon EventBridge 或 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 以程式設計方式與您的監控和警示工具整合](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)。
1. 透過 Amazon EventBridge 或 AWS Health API 整合變更管理或您可能已在使用的 ITSM 工具 (如 [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 或 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html))，以規劃並追蹤需要採取行動的運作狀態事件進度。
1. 如果您使用 AWS Organizations，請啟用 [AWS Health 的組織檢視](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html)，以彙總帳戶之間的 AWS Health 事件。
1. **整合 Amazon CloudWatch 警示與 Incident Manager** 設定 CloudWatch 警示，以便在 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html) 中自動建立事件。
1. **整合 Amazon EventBridge 與 Incident Manager：**建立 [EventBridge 規則](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)以回應事件並使用定義的回應計劃建立事件。
1. **為 Incident Manager 中的事件做好準備：**
+ 在 Incident Manager 中針對每種提醒類型建立詳細的[回應計劃](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)。
+ 透過與 Incident Manager 中回應計劃相連的[聊天應用程式中的 Amazon Q Developer](https://docs.aws.amazon.com/incident-manager/latest/userguide/chat.html) 來建立聊天頻道，以便在 Slack、Microsoft Teams 和 Amazon Chime 等平台的事件期間進行即時通訊。
+ 將 [Systems Manager Automation 執行手冊](https://docs.aws.amazon.com/incident-manager/latest/userguide/runbooks.html)納入 Incident Manager 中，以推動對事件的自動回應。
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
**相關文件：**
+ [AWS Cloud Adoption Framework：營運角度 - 事件與問題管理](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [設定 AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/setting-up.html)
+ [為 Incident Manager 中的事件做好準備](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-response.html)
**相關影片：**
+ [來自 AWS 的重要事件回應秘訣](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [ re:Invent 2023 \$1 使用 AWS Health 大規模管理資源生命週期事件](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相關範例：**
+ [AWS 研討會 - AWS Systems Manager Incident Manager - 自動化對安全事件的事件回應](https://catalog.workshops.aws/automate-incident-response/en-US/settingupim/onboarding)
# OPS10-BP03 根據業務影響確定營運事件的優先順序
及時回應操作事件至關重要，但並非所有事件都是平等的。當您根據業務影響排定優先順序時，也可以優先處理可能產生重大後果的事件，例如安全、財務損失、違反法規或聲譽損害。
**預期成果：**根據對業務營運和目標的潛在影響，對營運事件的回應進行優先級排序。這使得回應高效且有效。
**常見的反模式：**
+ 每個事件都按相同的緊急程度處理，會導致解決關鍵問題時出現混亂和延遲。
+ 您無法區分高影響和低影響事件，導致資源分配錯誤。
+ 您的組織缺乏明確的優先順序排定架構，導致對營運事件的回應不一致。
+ 事件的優先級基於其報告的順序，而不是其對業務成果的影響。
**建立此最佳實務的優勢：**
+ 確保關鍵業務功能首先獲得關注，將潛在損害降至最低。
+ 改善多個並行事件期間的資源配置。
+ 增強組織維持信任並遵守法規要求的能力。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
當面對多個營運事件時，根據影響和緊迫性來確定優先順序的結構化方法至關重要。這種方法可幫助您做出明智的決策，直接在最需要的地方做出努力，並降低業務持續性的風險。
### 實作步驟
1. **評估影響：**制定分類系統，根據事件對業務營運和目標的潛在影響來評估事件的嚴重性。下列範例顯示了影響類別：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **評估緊迫性：**定義事件需要回應的速度之緊急程度，考慮安全、財務影響和服務水準協議 (SLA) 等因素。下列範例示範緊急類別：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **建立一個優先級矩陣：**
+ 使用矩陣來交叉參考影響和緊迫性，將優先級別分配給不同的組合。
+ 讓負責營運事件回應的所有團隊成員都能存取和理解矩陣。
+ 下列範例矩陣會根據緊急性和影響來顯示事件嚴重性：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **培訓與溝通：**對回應團隊進行優先級矩陣的培訓，並強調在事件期間遵循該矩陣的重要性。向所有利益相關者傳達優先級排序過程，以設定明確的期望。
1. **與事件回應整合：**
+ 將優先級矩陣整合到您的事件回應計畫和工具中。
+ 盡可能自動化事件的分類和優先順序，以加快回應時間。
+ 企業支援客戶可利用 [AWS 事件偵測與回應](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)功能，為生產工作負載提供全年無休的主動監控和事件管理。
1. **審查和調整：**定期審查優先順序排定程序的有效性，並根據業務環境中的意見回饋和變化進行調整。
## 資源
**相關的最佳實務：**
+ [鼓勵 OPS03-BP03 升級](ops_org_culture_team_enc_escalation.md)
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
+ [OPS09-BP01 使用指標衡量營運目標與 KPI](ops_operations_health_measure_ops_goals_kpis.md)
**相關文件：**
+ [Atlassian - 了解事件嚴重性層級](https://www.atlassian.com/incident-management/kpis/severity-levels)
+ [IT 流程圖 - 檢查清單事件優先順序](https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority)
# OPS10-BP04 定義呈報路徑
在您的事件回應協定中建立明確的呈報路徑，以促進及時且有效的活動。這包括指定呈報提示、詳細說明呈報流程，以及預先核准動作，以加速決策並縮短平均解決時間 (MTTR)。
**預期成果：**結構化且有效率的流程，可將事件呈報給適當的人員，將回應時間和影響降到最低。
**常見的反模式：**
+ 復原程序不明確會導致在關鍵事件期間採取臨時應對措施。
+ 當需要緊急行動時，缺少已定義的權限和擁有權會導致延遲。
+ 利益相關者和客戶沒有按照預期得到通知。
+ 重要決策被推遲。
**建立此最佳實務的優勢：**
+ 透過預先定義的呈報程序來簡化事件回應。
+ 透過預先核准的動作和明確的擁有權，減少停機時間。
+ 根據事件嚴重性來改善資源配置和支援層級調整。
+ 改善與利益相關者和客戶的溝通。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
正確定義的呈報路徑對於快速事件回應至關重要。AWS Systems Manager Incident Manager 支援設定結構化呈報計畫和隨時待命的排程，它們會提醒合適人員，以便他們在事件發生時做好行動準備。
### 實作步驟
1. **設定呈報提示：**設定 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)以在 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com//incident-manager/latest/userguide/incident-creation.html) 中建立事件。
1. **設定隨時待命的排程：**在 Incident Manager 中建立與您的呈報路徑保持一致的[隨時待命的排程](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule-create.html)。為隨時待命的人員提供必要的權限和工具，以迅速採取行動。
1. **詳細說明呈報程序：**
+ 確定應在哪些特定條件下呈報事件。
+ 在 Incident Manager 中建立[呈報計劃](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)。
+ 呈報渠道應包括聯絡人或隨時待命的時間表。
+ 定義團隊在每個呈報級別的角色和職責。
1. **預先核准的緩解措施：**與決策者協同合作，針對預期情況預先核准動作。使用與 Incident Manager 整合的 [Systems Manager Automation 執行手冊](https://docs.aws.amazon.com//incident-manager/latest/userguide/tutorials-runbooks.html)，加快事件解決速度。
1. **指定擁有權：**針對呈報路徑的每個步驟，清楚識別內部擁有者。
1. **詳細說明第三方呈報：**
+ 記錄第三方服務水準協議 (SLA)，並使其與內部目標保持一致。
+ 為事件期間的供應商溝通制定明確的協定。
+ 將供應商聯絡資訊整合至事件管理工具，以便直接存取。
+ 定期進行演練，包括第三方回應方案。
+ 保持供應商呈報資訊有據可查且易於存取。
1. **培訓和演練呈報計劃：**對您的團隊進行呈報流程培訓，並定期進行事件回應演習或練習。企業支援客戶可申請[事件管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)。
1. **持續改善：**定期審核呈報路徑的有效性。根據事件發生後的經驗教訓和持續回饋來更新您的流程。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md)
**相關文件：**
+ [AWS Systems Manager Incident Manager 呈報計劃](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
+ [在 Incident Manager 中使用隨時待命的時間表](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule.html)
+ [建立和管理執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [使用 AWS IAM Identity Center 進行臨時提升的存取管理](https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/)
+ [Atlassian - 有效事件管理的呈報政策](https://www.atlassian.com/incident-management/on-call/escalation-policies)
# OPS10-BP05 為影響服務的事件定義客戶溝通計劃
在影響服務的事件中，有效的溝通對於維護與客戶的信任和透明度至關重要。明確定義的溝通計劃可協助您的組織在事件發生期間快速且清楚地分享資訊，包括內部和外部。
**預期成果：**
+ 強大的溝通計劃可在影響服務的事件中有效地通知客戶和利益相關者。
+ 溝通中的透明度可建立信任並減少客戶焦慮。
+ 盡量減少服務影響事件對客戶體驗和業務運營的影響。
**常見的反模式：**
+ 溝通不充分或延遲會導致客戶困惑和不滿。
+ 過於技術化或模糊的消息傳遞無法傳達對使用者的實際影響。
+ 沒有預先定義的溝通策略，導致不一致且被動的消息傳遞。
**建立此最佳實務的優勢：**
+ 透過主動和清晰的溝通，增強客戶的信任和滿意度。
+ 透過搶先解決客戶問題，減輕支援團隊的負擔。
+ 改善有效管理事件並從中復原的能力。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
為影響服務的事件制定全面的溝通計劃涉及多個方面，從選擇正確的渠道到精心製作消息和基調。該計劃應具有適應性、可擴展性，並適應不同的停機情況。
### 實作步驟
1. **定義角色和責任：**
+ 指派一名主要事件管理者來監督事件回應活動。
+ 指定一名溝通管理者，其負責協調所有外部與內部溝通。
+ 包括支援管理者，以透過支援票證提供一致的溝通。
1. **確定溝通渠道：**選取諸如工作場所聊天、電子郵件、簡訊、社交媒體、應用程式內通知和狀態頁面等渠道。這些渠道應具有彈性，並且能夠在影響服務的事件期間獨立運作。
1. **快速、清晰、定期地與客戶溝通：**
+ 為各種服務損害場景開發模板，強調簡單性和基本細節。包括有關服務損害、預期解決時間和影響等資訊。
+ 透過推播通知、應用程式內通知、電子郵件、文字訊息、語音訊息和自訂渠道上的訊息，使用 Amazon Pinpoint 來提醒客戶。
+ 使用 Amazon Simple Notification Service (Amazon SNS) 以程式設計方式或透過電子郵件、行動推送通知和文字訊息來提醒訂閱用戶。
+ 透過公開共用 Amazon CloudWatch 儀表板，使用儀表板溝通狀態。
+ 鼓勵社交媒體參與：
+ 積極監控社交媒體以了解客戶情緒。
+ 在社交媒體平台上發布公共更新和社區參與情況。
+ 準備範本以進行一致且清晰的社交媒體溝通。
1. **協調內部溝通：**使用如聊天應用程式中的 Amazon Q Developer 等工具實作內部通訊協定，以進行團隊協調和溝通。使用 CloudWatch 儀表板來溝通狀態。
1. **使用專用工具和服務協調溝通：**
+ 搭配使用 AWS Systems Manager Incident Manager 和聊天應用程式中的 Amazon Q Developer 即可設定專屬的聊天頻道，以便在事件發生時進行即時內部溝通和協調。
+ 在事件發生期間，透過 Amazon Pinpoint、Amazon SNS 或第三方工具 (例如社交媒體平台)，使用 AWS Systems Manager Incident Manager 執行手冊將客戶通知自動化。
+ 在執行手冊中合併核准工作流程，以便在傳送前選擇性地審核和授權所有外部通訊。
1. **實踐和改善：**
+ 針對溝通工具和策略的使用進行培訓。讓團隊能夠在事件發生時及時做出決策。
+ 透過定期演習或演練日測試溝通計劃。使用這些測試來精簡消息傳遞並評估渠道的有效性。
+ 實作意見回餽機制，以評估事件期間的溝通效率。根據意見回饋和不斷變化的需求不斷發展溝通計劃。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS10-BP06 透過儀表板傳達狀態](ops_event_response_dashboards.md)
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md)
**相關文件：**
+ [Atlassian - 事件溝通最佳實務](https://www.atlassian.com/incident-management/incident-communication)
+ [Atlassian - 如何編寫良好的狀態更新](https://www.atlassian.com/blog/statuspage/how-to-write-a-good-status-update)
+ [PagerDuty - 事件溝通指南](https://www.pagerduty.com/resources/learn/a-guide-to-incident-communications/)
**相關影片：**
+ [Atlassian - 建立您自己的事件溝通計劃：事件範本](https://www.youtube.com/watch?v=ZROVn6-K2qU)
**相關範例：**
+ [AWS Health 儀表板](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
# OPS10-BP06 透過儀表板傳達狀態
使用儀表板作為戰略工具，將即時營運狀態和關鍵指標傳達給不同的受眾，包括內部技術團隊、領導層和客戶。這些儀表板提供系統運作狀態和業務績效的集中式視覺化呈現，從而提高透明度和決策效率。
**預期成果：**
+ 儀表板提供與不同利益相關者相關的系統和業務指標的全面檢視。
+ 利益相關者可以主動存取營運資訊，減少頻繁的狀態請求。
+ 在正常操作和事件期間增強實時決策。
**常見的反模式：**
+ 加入事件管理通話的工程師要求更新狀態以加快速度。
+ 依靠手動報告進行管理，這會導致延遲和潛在的不准確性。
+ 事件發生期間，營運團隊經常因為狀態更新而受到干擾。
**建立此最佳實務的優勢：**
+ 使利益相關者能夠立即存取關鍵資訊，有助於制定明智決策。
+ 透過最大限度地減少手動報告和頻繁狀態查詢，減少操作效率低下問題。
+ 透過即時掌握系統效能和業務指標，提高透明度和信任度。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
儀表板可有效地傳達系統和業務指標的狀態，並可根據不同受眾群體的需求進行量身打造。Amazon CloudWatch 儀表板和 Amazon Quick 等工具可協助您建立用於系統監控和商業智慧的互動式即時儀表板。
### 實作步驟
1. **確定利益相關者的需求：**確定不同受眾群體的特定資訊需求，例如技術團隊、領導層和客戶。
1. **選擇正確的工具：**選取適當的工具，例如，使用 [Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)進行系統監控，以及使用 [Amazon Quick](https://aws.amazon.com/quicksight/) 獲得互動式商業情報。[AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 在 [AWS Health 儀板表](https://health.aws.amazon.com/health/home) 中提供了立即可用的體驗，您也可以使用 Amazon EventBridge 中的運作狀態事件或透過 AWS Health API 來擴增您的儀表板。
1. **設計高效儀表板：**
+ 設計儀表板以清楚呈現相關指標和 KPI，確保其易於理解和操作。
+ 視需要整合系統層級與企業層級檢視。
+ 包括高階 (用於廣泛概述) 和低階 (用於詳細分析) 儀表板。
+ 在儀表板中整合自動警示，以突顯重大問題。
+ 使用重要指標閾值和目標為儀表板加上註釋，以實現即時可見性。
1. **整合資料來源：**
+ 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 彙總和顯示來自各種 AWS 服務的指標，並[查詢其他資料來源的指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)，建立系統運作狀態和商業指標的統一檢視。
+ 使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 等功能，查詢並視覺化來自不同應用程式和服務的日誌資料。
+ 使用 AWS Health 事件透過 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 或 [Amazon EventBridge 上的 AWS Health 事件](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)，隨時掌握 AWS 服務的操作狀態和已確認的操作問題。
1. **提供自助服務存取：**
+ 與相關利益相關者共用 CloudWatch 儀表板，以使用[儀表板共用功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)進行自助式資訊存取。
+ 確保儀表板易於存取，並提供即時、最新的資訊。
1. **定期更新和完善：**
+ 持續更新和完善儀表板，以滿足不斷變化的業務需求和利益相關者的意見回饋。
+ 定期審核儀表板，使其保持相關性並可有效傳達必要資訊。
## 資源
**相關的最佳實務：**
+ [OPS08-BP05 建立儀表板](ops_workload_observability_create_dashboards.md)
**相關文件：**
+ [建置用於檢視營運狀況的儀表板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用儀表板變數建立彈性儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)
+ [共享 CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)
+ [從其他資料來源中查詢指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)
+ [將自訂小工具新增至 CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)
**相關範例：**
+ [一個可觀測性研討會 - 儀表板](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/aws-native/dashboards)
# OPS10-BP07 自動化對事件的回應
自動化事件回應是快速、一致且無誤操作處理的關鍵。建立簡化的流程，並使用工具自動管理和回應事件，將手動干預降至最低，並提高營運效率。
**預期成果：**
+ 透過自動化減少人為錯誤並縮短解決時間。
+ 一致且可靠的操作事件處理。
+ 提高運營效率和系統可靠性。
**常見的反模式：**
+ 手動事件處理會導致延遲和錯誤。
+ 在重複的關鍵任務中，自動化被忽略。
+ 重複的手動任務會導致警示疲勞，並遺漏重大問題。
**建立此最佳實務的優勢：**
+ 加速事件回應，減少系統停機時間。
+ 可靠的操作，自動化且一致的事件處理。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
整合自動化以建立有效的操作工作流程，並將手動干預降至最低。
### 實作步驟
1. **識別自動化機會：**確定自動化的重複性任務，例如問題修復、工單擴充、容量管理、擴展、部署和測試。
1. **識別自動化提示：**
+ 使用 [Amazon CloudWatch 警示動作 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)來評估和定義啟動自動回應的特定條件或指標。
+ 使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 來回應 AWS 服務、自訂工作負載和 SaaS 應用程式中的事件。
+ 考慮啟動事件，例如[特定日誌項目 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)、[效能指標閾值 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)或 AWS 資源[的狀態變更](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)。
1. **實作事件驅動型自動化：**
+ 使用 AWS Systems Manager Automation Runbook 簡化維護、部署和修復任務。
+ 在 [Incident Manager 中建立事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)會自動收集有關事件所涉及 AWS 資源的詳細資訊，並將其新增至事件。
+ 使用 [Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) 主動監控配額。
+ 使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 自動調整容量，以維持可用性和效能。
+ 使用 [Amazon CodeCatalyst](https://codecatalyst.aws/explore)將開發管道自動化。
+ 煙霧測試或持續監控端點，APIs[並使用合成監控 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)。
1. **透過自動化執行風險緩解：**
+ 實作[自動化安全回應](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)，迅速解決風險。
+ 使用 [AWS Systems Manager狀態管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)來減少組態偏差。
+ [使用 修復不合規資源 AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS08-BP04 建立可執行的提醒](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)
**相關文件：**
+ [搭配 Incident Manager 使用 Systems Manager Automation 執行手冊](https://docs.aws.amazon.com/incident-manager/latest/userguide/tutorials-runbooks.html)
+ [在 Incident Manager 中建立事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)
+ [AWS 服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [監控資源使用情況並在接近配額時傳送通知](https://docs.aws.amazon.com/solutions/latest/quota-monitor-for-aws/solution-overview.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [什麼是 Amazon CodeCatalyst？](https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html)
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon CloudWatch 警示動作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)
+ [使用 修復不合規資源 AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [使用篩選條件從日誌事件建立指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
**相關影片：**
+ [ 使用 建立 Automation Runbook AWS Systems Manager](https://www.youtube.com/watch?v=fQ_KahCPBeU)
+ [ 如何在 上自動化 IT 操作 AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Security Hub CSPM 自動化規則 ](https://www.youtube.com/watch?v=XaMfO_MERH8)
+ [ 使用 Amazon CodeCatalyst 藍圖快速啟動軟體專案 ](https://www.youtube.com/watch?v=rp7roaoPzFE)
**相關範例：**
+ [ Amazon CodeCatalyst 教學課程：使用現代三層式 Web 應用程式藍圖建立專案 ](https://docs.aws.amazon.com/codecatalyst/latest/userguide/getting-started-template-project.html)
+ [一個可觀測性研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US)
+ [使用 Incident Manager 回應事件](https://catalog.workshops.aws/getting-started-with-com/en-US/operations-management/incident-manager)