# 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，Key Performance Indicator）。评估 KPI 以便确定运营是否成功。 **常见反模式：** + 业务领导会问您，运营在完成业务目标方面成效如何，但却没有确定成功的参考框架。 + 您无法确定维护时段是否会对业务成果产生影响。 **建立此最佳实践的好处：** 通过识别识别关键性能指标，您可以将业务成果的实现情况作为对运营运行状况和是否成功的测试。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 识别关键性能指标：根据所需的业务成果和客户成果识别关键性能指标（KPI，Key Performance Indicator）。评估 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/)通过与 AWS Glue 的原生集成，可用于分析您的日志数据，并使用标准 SQL 进行查询。使用像 [Quick](https://aws.amazon.com/quicksight/) 这样的商业智能工具，您可以直观显示、浏览和分析您的数据。 **常见反模式：** + 一个识别关键性能指标是始终如一地交付新功能。您没有衡量部署频率的方法。 + 您记录部署、回滚部署、安装补丁和回滚补丁，以跟踪您的运营活动，但是没有人审核指标。 + 您有一个恢复时间目标，要在十五分钟内将丢失的数据库恢复，这是在部署系统且还没有用户时定义的。现在，您有成千上万的用户，并且已经运营了两年。最近一次恢复花费了两个多小时。没有对此进行记录，也没有人知道。 **建立此最佳实践的好处：** 通过收集和分析运营指标，您可以了解运营活动的运行状况，并可以洞察可能影响运营或业务成果完成情况的趋势。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 收集和分析运营指标：定期主动检查各种指标，以便发现趋势并确定哪里需要做出适当响应。 + [使用 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 代理从 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 代理从 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 建立运营指标基准 建立指标基准以便提供预期值，作为比较和识别运营活动执行不足和运营活动执行过度的依据。 **常见反模式：** + 您被问及预期的部署时长。您尚未测量部署所需的时间，也无法确定预期时间。 + 您被问及从应用程序服务器问题中恢复所需的时间。您不知道从首次联系客户到恢复完成的时长。您不知道从首次通过监控发现问题到恢复完成的时长。 + 您被问及周末需要多少支持人员。您不知道周末通常有多少支持案例，无法估算。 + 您有一个恢复时间目标，要在十五分钟内将丢失的数据库恢复，这是在部署系统且还没有用户时定义的。现在，您有成千上万的用户，并且已经运营了两年。您不知道数据库的还原时间是如何变化的。 **建立此最佳实践的好处：** 通过定义基准指标值，您可以评估当前指标值和指标趋势，从而确定是否需要采取措施。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 了解运营的预期活动模式：建立运营活动模式以便确定行为何时不符合预期值，从而根据需要做出适当响应。 # OPS09-BP05 了解运营的预期活动模式 建立运营活动的模式来识别异常行为，以便您在必要时做出适当响应。 **常见反模式：** + 最近，您的部署失败率大幅增加。您单独处理每个故障。您没有发现，故障是由对部署管理系统不熟悉的新员工所执行的部署引发的。 **建立此最佳实践的好处：** 通过学习行为模式，您可以识别意外行为并在必要时采取措施。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 了解运营的预期活动模式：建立运营活动模式以便确定行为何时不符合预期值，从而根据需要做出适当响应。 # OPS09-BP06 在运营成果面临风险时发出提醒 任何时候，只要运营成果存在风险，就必须引发警报并采取操作。运营成果是为生产工作负载提供支持的任意活动。其范围极广，从开发应用程序新版本到从中断中恢复，无所不包。需要像重视业务成果一样重视运营成果。 软件团队应确定关键运营指标和活动，并为其设定警报。警报必须及时并且内容可付诸行动。引发警报时，必须附带对相应运行手册或行动手册的引用。没有相应操作的警报会导致用户疲于应对警报。 **期望的结果：** 运营活动存在风险时，发送警报来督促采取行动。警报应包含引发警报的背景信息，并指向行动手册（提供调查方法）或运行手册（提供防范方法）。在可能时，运行手册应自动运行并发送通知。 **常见反模式：** + 您在调查一起事件并建立了支持案例。支持案例指明违反了服务等级协议（SLA，Service Level Agreement），但没有引发警报。 + 原本计划在午夜进行生产环境部署，但由于最后时刻进行代码更改而延迟。没有引发警报，部署挂起。 + 出现生产中断，但没有发送警报。 + 您的部署时间始终落后于预计时间。没有采取任何调查操作。 **建立此最佳实践的好处：** + 在运营成果存在风险时引发警报有助于防患于未然，提升支持工作负载的能力。 + 由于实现了积极的运营成果，业务成果得到改善。 + 对运营问题的检测和修复能力得到改进。 + 整体的运营健康状况得以提升。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 您必须先定义运营成果，然后才能在运营成果上设置警报。这个过程首先要定义哪些运营活动对您的组织来说最重要。是需要在两个小时内部署到生产环境，还是在设定的时间内响应支持案例？ 您的组织必须定义关键运营活动以及衡量方式，这样才能对其进行监控、改进和设定警报。您需要一个集中位置来存储和分析工作负载及运营遥测数据。应该能够使用同一套机制，在运营成果存在风险时引发警报。 **客户示例** 在 AnyCompany Retail 的例行部署期间触发了 CloudWatch 警报。已经超过了部署的准备时间。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 管理和监管工具研讨会 – Operations 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) 可通过事件关联、日志分析并应用机器学习来分析工作负载遥测数据，用于确定异常行为。所获得的 [见解](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）支持第三方日志分析系统和商业智能工具。 **常见反模式：** + 随着开发团队数量的增加，部署的频率也随之增加。您定义的预期部署频率是每周一次。而您现在已定期每日部署。如果您的部署系统出现问题，无法进行部署，那么几天之内都不会被发现。 + 之前，您的业务仅在星期一至星期五的核心业务时间提供支持。您针对事件建立了下一工作日响应时间目标。您最近开始提供 24x7 全天候支持，响应时间目标为 2 小时。您的夜班员工不堪重负，客户也不满意。没有迹象表明事件响应时间有问题，因为您在针对下一工作日目标进行报告。 **建立此最佳实践的好处：** 通过审核和修订 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/)