# 操作
**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 之类的工具执行指标分析。Amazon CloudWatch 异常检测和 Amazon DevOps Guru 之类的 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/)来清楚地了解指标分布，这有助于定义 SLA 和理解异常值。
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 DevOps Guru：**加入 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)，以便利用其机器学习增强的异常检测功能，识别无服务器应用程序操作问题的早期迹象，并在对客户造成影响之前将其修复。
1. **根据洞察进行优化**：根据指标分析作出明智的决策，以便调整和改进工作负载。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
**相关文档：**
+ [The Wheel b博客 – 强调持续审查指标的重要性](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [Percentile are important](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)
**相关视频：**
+ [Enable Cross-Account Observability in Amazon CloudWatch](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [Introduction to Amazon DevOps Guru](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [Continuously Analyze Metrics using AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [Gaining operation insights with AIOps using Amazon DevOps Guru](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 Logs**：配置应用程序和服务，以便将日志发送到 CloudWatch Logs。
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 比较（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 Logs 指标筛选条件**：配置 [CloudWatch Logs 指标筛选条件](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)
**相关文档：**
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Using CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [Creating and Managing CloudWatch Log Metric Filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**相关视频：**
+ [Analyze Log Data with CloudWatch Logs Insights](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [Use CloudWatch Contributor Insights to Analyze High-Cardinality Data](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**相关示例：**
+ [CloudWatch Logs Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [One Observability 讲习会](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 DevOps Guru 等功能，可增强从跟踪数据中获得的可行洞察的深度。
### 实施步骤
以下步骤提供了一种结构化方法，以便使用 AWS 服务有效地实施跟踪数据分析：
1. **集成 AWS X-Ray**：确保 X-Ray 已与应用程序集成，以便捕获跟踪数据。
1. **分析 X-Ray 指标**：使用[服务地图](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view)深入研究从 X-Ray 跟踪数据中得出的指标，例如延迟、请求率、故障率和响应时间分布等，以便监控应用程序的运行状况。
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. 查阅洞察时间表，按时间顺序分析检测到的问题。
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 DevOps Guru**：利用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 从机器学习模型中受益，查明跟踪数据中的操作异常。
1. **使用 CloudWatch Synthetics**：使用 [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) 创建用于持续监控端点和工作流程的金丝雀。这些金丝雀可以与 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)
**相关文档：**
+ [Using ServiceLens to Monitor Application Health](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [Exploring Trace Data with X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [Detecting Anomalies in Traces with X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [Continuous Monitoring with CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**相关视频：**
+ [Analyze and Debug Applications Using Amazon CloudWatch Synthetics & AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [使用 AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 AWS Lambda 实施 X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [CloudWatch Synthetics Canary Templates](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 创建可操作的警报
及时检测和响应应用程序行为的偏差至关重要。尤其重要的是，认识到基于关键绩效指标（KPI）的结果何时面临风险或何时出现意外异常。基于 KPI 的警报可确保收到的信号与业务或运营影响直接相关。这种可操作警报的方法可促进主动响应，并有助于维护系统性能和可靠性。
**期望结果：**接收及时、相关且可操作的警报，以便快速发现和缓解潜在问题，尤其是在 KPI 结果面临风险时。
**常见反模式：**
+ 设置过多非关键警报，导致警报疲劳。
+ 不根据 KPI 对警报进行优先级排序，因此很难了解问题对业务的影响。
+ 忽视解决根本原因，导致针对同一问题出现重复警报。
**建立此最佳实践的好处：**
+ 关注可操作的相关警报，减少警报疲劳。
+ 主动检测和缓解问题，增加系统的正常运行时间并提高可靠性。
+ 与常用的警报和通信工具集成，增强团队协作并更快解决问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要创建有效的警报机制，必须使用指标、日志和跟踪数据来标记基于 KPI 的结果何时存在风险，或何时检测到异常情况。
### 实施步骤
1. **确定关键绩效指标（KPI）**：确定应用程序的 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 开发者版**：集成[聊天应用程序中的 Amazon Q 开发者版](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)
+ [Create a composite alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Create a CloudWatch alarm based on anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [DevOps Guru Notifications](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [X-ray insights notifications](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 Integration Guide \$1 PagerDuty](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [Integrate Opsgenie with Amazon CloudWatch](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**相关视频：**
+ [Create Composite Alarms in Amazon CloudWatch](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [Amazon Q Developer in chat applications Overview](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS On Air ft. Mutative Commands in Amazon Q Developer in chat applications](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**相关示例：**
+ [Alarms, incident management, and remediation in the cloud with Amazon CloudWatch](https://aws.amazon.com/bloarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [Tutorial: Creating an Amazon EventBridge rule that sends notifications to Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [One Observability 讲习会](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. **日志洞察查询：**利用 [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) 从日志中获取可操作的指标，并在控制面板上显示这些洞察。
1. **设置警报：**将 [CloudWatch Alarms](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 Dashboard](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/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**相关视频：**
+ [Create Cross Account & Cross Region CloudWatch Dashboards](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with AWS 云 operation dashboards)](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 Amazon CloudWatch 进行应用程序监控](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
+ [AWS Health Events Intelligence Dashboards and Insights](https://aws.amazon.com/blogs/mt/aws-health-events-intelligence-dashboards-insights/)
+ [Visualize AWS Health events using Amazon Managed Grafana](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，并确定指标可反映这些目标和 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/)
+ [How to track your cost optimization KPIs with KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [AWS DevOps Guidance ](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
**相关示例：**
+ [ Monitor the performance of your software delivery using native AWS monitoring and observability tools ](https://catalog.us-east-1.prod.workshops.aws/workshops/3b7f3d77-c6ef-44b2-aa29-d2719b8be897/en-US)
+ [ Balance deployment speed and stability with DORA metrics ](https://aws.amazon.com/blogs/devops/balance-deployment-speed-and-stability-with-dora-metrics/)
+ [ Example MLOps operational metrics in the financial services industry ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-unlock-value-data-financial-services/operational-metrics.html)
+ [How to track your cost optimization KPIs with the KPI Dashboard](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)
**相关文档：**
+ [Measure Progress](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/)
**相关示例：**
+ [Data Operations](https://aws.amazon.com/solutions/app-development/data-operations)
+ [How to track your cost optimization KPIs with KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [The Importance of Key Performance Indicators (KPIs) for Large-Scale Cloud Migrations](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
# OPS09-BP03 审查运营指标并确定改进优先顺序
留出专门的时间和资源来审查运营状况，可确保为日常业务提供服务始终是优先事项。召集运营主管和利益相关方，定期审查指标，重申或修改长期和短期目标，并确定改进的优先顺序。
**期望结果：**
+ 运营主管和员工定期开会，审查给定报告期内的指标。交流挑战，庆祝胜利，分享经验教训。
+ 定期向利益相关方和业务领导者通报运营状况，并征求他们对目标、KPI 和未来举措的意见。结合相关背景，讨论服务交付、运营和维护之间的权衡。
**常见反模式：**
+ 推出了一款新产品，但一级和二级运营团队没有接受充分培训，无法为其提供支持，或者没有相应地增加人手。领导者看不到表明工单解决时间缩短和意外事件量增加的指标。几周后，心怀不满的用户离开平台，订阅数量开始下降，此时才采取行动。
+ 对工作负载进行维护的手动流程已经存在很长时间。尽管人们一直想要实现自动化，但考虑到该系统的重要性较低，自动化并未得到足够的重视。然而，随着时间的推移，该系统的重要性与日俱增，现在这些手动流程耗费了运营团队的大部分时间。没有安排资源为运营团队提供更多工具，这导致随着工作负载的增加，员工疲惫不堪。有人报告员工离职去了其他竞争对手那里时，领导层才意识到这一点。
**建立此最佳实践的好处：**在一些组织中，如何将同样的时间和精力用于提供新产品或新服务，可能是一项挑战。一旦出现这种情况，预期的服务水平会慢慢降低，业务线就会受到影响。这是因为运营团队没有随着业务的增长而做出改变和发展，很快就跟不上业务的节奏。如果不定期审查运营团队收集的洞察，等到发现业务面临的风险时，可能为时已晚。通过花时间与运营人员和领导层一起审查指标和程序，运营团队所发挥的关键作用将显而易见，并且能在风险达到临界水平之前及早发现。运营团队可以更好地洞察即将发生的业务变化和即将实施的计划，从而积极主动地开展工作。领导层对运营指标的了解展示了这些团队在客户满意度（包括内部和外部客户满意度）方面所发挥的作用，让他们能够更好地权衡选择的优先事项，或确保运营团队有足够的时间和资源随着新业务和工作负载计划的变化而做出改变和发展。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
花时间与利益相关方和运营团队一起审查运营指标和报告数据。结合组织的长期和短期目标来审查这些报告，以便确定是否实现了这些目标。在目标不明确的地方，或在要求的东西和给予的东西之间可能存在冲突的地方，找出含糊不清的根源。
确定时间、人员和工具可以在哪些方面推动实现运营成果。确定这将影响哪些 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 代理收集 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 使用流程来管理事件、意外事件和问题
要想维持工作负载的运行状况和性能，对事件、意外事件和问题的高效管理能力非常关键。因此务必要认识和理解这些要素之间的不同，这样才能制定有效的响应和解决策略。针对各个方面确立并遵循明确的流程，有助于团队快速有效地应对出现的任何运营挑战。
**期望结果：**组织通过记录详实且集中存储的流程，高效地管理运营事件、意外事件和问题。这些流程会不断更新来反映变更，并简化处理过程，保持出色的服务可靠性和工作负载性能。
**常见反模式：**
+ 被动而不是主动地响应事件。
+ 面对不同类型的事件或意外事件，采取不一致的方法。
+ 组织没有分析意外事件并从中吸取教训，以防将来再次发生。
**建立此最佳实践的好处：**
+ 简化响应流程并使之标准化。
+ 降低意外事件对服务和客户的影响。
+ 加快问题解决速度。
+ 持续改进运营流程。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
实施这种最佳实践意味着您正在跟踪工作负载事件。建立用于处理意外事件和问题的流程。记录、分享并经常更新这些流程。发现问题，确定问题优先级并加以解决。
**了解事件、意外事件和问题**
+ **事件：***事件*是观察到的动作、事件或状态变化。事件可以是预先计划的，也可以是计划外的，可以源自工作负载内部，也可以源自工作负载外部。
+ **意外事件：***意外事件*是需要响应的事件，例如计划外的中断或服务质量下降。意外事件表示出现了中断，需要立即采取行动才能恢复工作负载正常运行。
+ **问题：***问题*是一起或多起意外事件的根本原因。发现和解决问题需要对意外事件进行更深入的研究，以防将来再次发生。
### 实施步骤
**Events**
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 开发者版](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 Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 等 AWS 支持资源，获取主动指导和优化建议。
+ 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 Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》
+ [AWS Incident Detection and Response](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)
+ [AWS Cloud Adoption Framework: Operations Perspective - Incident and problem management ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [Incident Management in the Age of DevOps and SRE](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - What is Incident Management?](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**相关视频：**
+ [Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [AWS re:Invent 2022 - The Amazon Builders' Library: 25 yrs of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - AWS Incident Detection and Response (SUP201)](https://www.youtube.com/watch?v=IbSgM4IP9IE)
+ [Introducing Incident Manager from AWS Systems Manager](https://www.youtube.com/watch?v=I6lScgh4qds)
**相关示例：**
+ [AWS Proactive Services – Incident Management 讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [How to Automate Incident Response with PagerDuty and AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/how-to-automate-incident-response-with-pagerduty-and-aws-systems-manager-incident-manager/)
+ [Engage Incident Responders with the On-Call Schedules in 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/)
+ [Improve the Visibility and Collaboration during Incident Handling in 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/)
+ [Incident reports and service requests in 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 开发者版，上报计划和联系方式，运行手册流入响应计划，响应计划流入意外事件和分析。Amazon CloudWatch 也将流入响应计划。\]](http://docs.aws.amazon.com/zh_cn/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，请启用 [organization view for 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)。
+ 通过 [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/incident-manager/latest/userguide/chat.html) 建立聊天频道，连接到 Incident Manager 中的响应计划，在发生事件时，协调 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: Operations Perspective - Incident and problem management ](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)
+ [Setting up AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/setting-up.html)
+ [Preparing for incidents in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-response.html)
**相关视频：**
+ [Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [ re:Invent 2,023 \$1 Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相关示例：**
+ [AWS 讲习会 – AWS Systems Manager Incident Manager – Automate incident response to security events](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_cn/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_cn/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **创建优先级矩阵：**
+ 使用矩阵来交叉参考影响力和紧急程度，向不同的组合分配优先级。
+ 确保负责运营事件响应的所有团队成员都能访问并且理解矩阵。
+ 以下示例矩阵根据紧急程度和影响力显示意外事件的严重性：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **培训和沟通：**培训响应团队，让其了解优先级矩阵以及在发生事件时遵循矩阵的重要性。与所有利益相关方沟通优先次序流程，并设定明确的期望。
1. **与意外事件响应集成：**
+ 将优先级矩阵纳入意外事件响应计划和工具中。
+ 尽可能自动对事件进行分类和优先级排序，以便加快响应速度。
+ Enterprise Support 客户可以使用 [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 - Understanding incident severity levels](https://www.atlassian.com/incident-management/kpis/severity-levels)
+ [IT Process Map - Checklist Incident Priority](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. **针对上报计划进行培训和演习：**针对上报流程对团队进行培训，并定期进行意外事件响应演习或 GameDay 活动。Enterprise Support 客户可以申请[事件管理讲习会](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 Escalation Plans](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
+ [Working with on-call schedules in 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)
+ [Temporary elevated access management with AWS IAM Identity Center](https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/)
+ [Atlassian - Escalation policies for effective incident management](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 开发者版等工具进行团队协调和沟通。使用 CloudWatch 控制面板来传达状态信息。
1. **使用专用工具和服务来协调沟通：**
+ 将 AWS Systems Manager Incident Manager 与聊天应用程序中的 Amazon Q 开发者版结合使用来设置专用的聊天频道，以便在发生事件时进行实时内部沟通和协调。
+ 发生意外事件时，使用 AWS Systems Manager Incident Manager 运行手册，通过 Amazon Pinpoint、Amazon SNS 或社交媒体平台等第三方工具，自动通知客户。
+ 将审批工作流程纳入运行手册，以便在所有外部通信渠道发送信息之前，进行审核和授权（如需要）。
1. **练习和改进：**
+ 开展有关使用沟通工具和策略的培训。增强团队能力，以便在发生意外事件时及时作出决策。
+ 通过定期演习或 GameDay 活动来测试沟通计划。使用这些测试来完善消息传递流程，并评估渠道的有效性。
+ 实施反馈机制来评测发生意外事件时的沟通有效性。根据反馈和不断变化的需求，不断改进沟通计划。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [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 - Incident communication best practices](https://www.atlassian.com/incident-management/incident-communication)
+ [Atlassian - How to write a good status update](https://www.atlassian.com/blog/statuspage/how-to-write-a-good-status-update)
+ [PagerDuty - A Guide to Incident Communications](https://www.pagerduty.com/resources/learn/a-guide-to-incident-communications/)
**相关视频：**
+ [Atlassian - Create your own incident communication plan: Incident templates](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 Dashboard](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) 或 [AWS Health events on Amazon EventBridge](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/)
+ [Using Amazon CloudWatch Dashboards](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)
**相关示例：**
+ [One Observability 讲习会 – Dashboards](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 运行手册来简化维护、部署和修复任务。
+ [在 Incident Manager 中创建意外事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)，自动收集并添加与意外事件相关的 AWS 资源的详细信息。
+ 使用[适用于 AWS 的配额监控程序](https://aws.amazon.com/solutions/implementations/quota-monitor/)主动监控配额。
+ 使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 自动调整容量，维持可用性和性能。
+ 使用 [Amazon CodeCatalyst](https://codecatalyst.aws/explore) 实现开发管道自动化。
+ 使用[综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)进行烟雾测试或持续监控端点和 API。
1. **通过自动化功能执行风险缓解：**
+ 实施[自动安全响应](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)，以便快速应对风险。
+ 使用 [AWS Systems Manager State 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)
**相关文档：**
+ [Using Systems Manager Automation runbooks with Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/tutorials-runbooks.html)
+ [Creating incidents in 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)
+ [Monitor resource usage and send notifications when approaching quotas](https://docs.aws.amazon.com/solutions/latest/quota-monitor-for-aws/solution-overview.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [What is 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)
+ [Remediating Noncompliant Resources with AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [Creating metrics from log events using filters](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)
**相关视频：**
+ [Create Automation Runbooks with AWS Systems Manager](https://www.youtube.com/watch?v=fQ_KahCPBeU)
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Security Hub CSPM automation rules](https://www.youtube.com/watch?v=XaMfO_MERH8)
+ [Start your software project fast with Amazon CodeCatalyst blueprints](https://www.youtube.com/watch?v=rp7roaoPzFE)
**相关示例：**
+ [Amazon CodeCatalyst Tutorial: Creating a project with the Modern three-tier web application blueprint](https://docs.aws.amazon.com/codecatalyst/latest/userguide/getting-started-template-project.html)
+ [One Observability 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US)
+ [Respond to incidents using Incident Manager](https://catalog.workshops.aws/getting-started-with-com/en-US/operations-management/incident-manager)