# 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/)