

# OPS 9. 如何了解自己的运营状况？
<a name="ops-09"></a>

 定义、记录和分析运营指标以便了解运营事件，从而采取适当的行动。

**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
<a name="ops_operations_health_measure_ops_goals_kpis"></a>

 从组织获取定义运营成功的目标和 KPI，并确定指标可反映这些目标和 KPI。将基线设置为参考点，并定期重新评估。制定机制，从团队收集这些指标以供评估。[DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) 指标提供了一种常用的方法来衡量软件交付 DevOps 实践的进展。

 **期望结果：**
+ 组织发布并分享运营团队的目标和 KPI。
+ 您建立反映这些 KPI 的指标。示例可能包括：
  +  工单队列深度或平均工单时长 
  +  按问题类型分组的工单数量 
  +  使用或不使用标准化操作程序（SOP）时处理问题所花费的时间 
  +  从失败的代码推送中恢复所花费的时间 
  +  呼叫量 

 **常见反模式：**
+  由于开发人员被抽调去执行故障排除任务，而错过部署截止日期。开发团队主张增加人手，但由于无法衡量所占用的时间，因此无法量化他们需要多少人手。
+  设置了 1 级服务台来处理用户呼叫。随着时间的推移，工作负载越来越多，但没有为 1 级服务台分配人手。随着呼叫次数的增加以及问题解决时间的延长，客户满意度下降，但管理层看不到此类问题的任何指标，因此未采取任何行动。
+  有问题的工作负载已移交给单独的运营团队进行处理。与其他工作负载不同，这种新的工作负载没有提供适当的文档和运行手册。因此，团队需要花费更长的时间排除和解决故障。但是，没有任何指标记录这一点，这使得问责制变得难以实施。

 **建立此最佳实践的好处：**工作负载监控可以显示应用程序和服务的状态，而监控运营团队则可以让所有者深入了解这些工作负载使用者之间的变化，例如不断变化的业务需求。通过创建能够反映运营状态的指标，可衡量这些团队的效率，并根据业务目标对其进行评估。指标可以突出显示支持问题，或确定何时出现偏离服务水平目标的情况。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

安排时间与业务主管和利益相关方商谈，来确定服务的总体目标。确定各个运营团队的任务，以及他们可能应对哪些挑战。利用这些信息，针对可能反映这些运营目标的关键绩效指标（KPI）进行集思广益。这些指标可能是客户满意度、从功能构思到部署所花的时间、平均问题解决时间或成本效益。

 根据 KPI，确定最能反映这些目标的指标和数据来源。客户满意度可能是各种指标的组合，例如呼叫等待或回复时间、满意度得分和提出的问题类型。部署时间可能是测试和部署所需的时间，加上需要添加的所有部署后修复的总和。统计数据显示了不同类型问题所花费的时间（或这些问题的数量），其可以提供一个窗口，便于了解需要在哪些方面开展有针对性的工作。

## 资源
<a name="resources"></a>

 **相关文档：**
+ [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 通报状态和趋势，确保了解运营情况
<a name="ops_operations_health_communicate_status_trends"></a>

 了解运营状况及其趋势非常有必要，这样才能确定结果何时可能面临风险、是否可以支持新增的工作，或者变更对团队的影响。在运营事件期间，用户和运营团队可通过状态页面获取信息，从而减轻通信渠道的压力并主动传播信息。

 **期望结果：**
+  运营主管可以一目了然地了解其团队正在处理的呼叫量，以及可能正在开展的工作（如部署）。
+  当正常运营受到影响时，会向利益相关方和用户群体发出警报。
+  组织领导层和利益相关方可以查看状态页面，以响应警报或影响，并获取与运营事件相关的信息，如联系人、工单信息和预计恢复时间。
+  向领导层和其他利益相关方提供报告，以便显示运营统计数据，例如一段时间内的呼叫量、用户满意度分数、未处理工单的数量及其时长。

 **常见反模式：**
+  工作负载出现故障，导致服务不可用。用户想知道发生了什么情况，呼叫量激增。管理人员想知道谁在处理问题，从而进一步增加了呼叫量。各个运营团队都加倍努力调查问题。
+  由于人们都想获得新功能，导致几名人员被重新分配到工程工作中。没有提供候补人员，问题解决时间激增。没有记录这些信息，几周后，在收到用户表达不满的反馈时，领导层才意识到这个问题。

 **建立此最佳实践的好处：**在业务受到影响的运营事件中，为了解情况而向不同团队查询信息可能会浪费大量时间和精力。通过建立广泛传播的状态页面和控制面板，利益相关方可以快速获得相关信息，例如是否检测到了问题、谁在负责处理问题，或者预计何时可以恢复正常运营。这样，团队成员就不必花太多时间与他人沟通状态，而是可以将更多时间花在解决问题上。

 此外，控制面板和报告可以为决策者和利益相关方提供洞察，以便了解运营团队响应业务需求以及分配资源的方式。这对于确定是否有足够的资源来支持业务至关重要。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 构建控制面板，显示运营团队当前的关键指标，并让运营主管和管理层都能随时访问这些指标。

 构建可以快速更新的状态页面，显示意外事件或事件何时发生、由谁负责以及谁在协调响应。在此页面上分享用户应考虑的任何步骤或解决方法，并广泛告知该位置。鼓励用户在遇到未知问题时先查看此位置。

 收集并提供显示一段时间内运营状况的报告，并将其分发给领导者和决策者，以便说明运营工作以及挑战和需求。

 在团队之间分享这些指标和报告，这些指标和报告最能反映目标和 KPI，以及在推动变革方面的影响力。投入时间开展这些活动，提升运营在团队内部和团队之间的重要性。

 将 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 与您自己的控制面板一起使用，或者将 AWS Health 事件集成到控制面板中，这样您的团队就可以将应用程序问题与 AWS 服务状态相关联。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+ [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 审查运营指标并确定改进优先顺序
<a name="ops_operations_health_review_ops_metrics_prioritize_improvement"></a>

 留出专门的时间和资源来审查运营状况，可确保为日常业务提供服务始终是优先事项。召集运营主管和利益相关方，定期审查指标，重申或修改长期和短期目标，并确定改进的优先顺序。

 **期望结果：**
+  运营主管和员工定期开会，审查给定报告期内的指标。交流挑战，庆祝胜利，分享经验教训。
+  定期向利益相关方和业务领导者通报运营状况，并征求他们对目标、KPI 和未来举措的意见。结合相关背景，讨论服务交付、运营和维护之间的权衡。

 **常见反模式：**
+  推出了一款新产品，但一级和二级运营团队没有接受充分培训，无法为其提供支持，或者没有相应地增加人手。领导者看不到表明工单解决时间缩短和意外事件量增加的指标。几周后，心怀不满的用户离开平台，订阅数量开始下降，此时才采取行动。
+  对工作负载进行维护的手动流程已经存在很长时间。尽管人们一直想要实现自动化，但考虑到该系统的重要性较低，自动化并未得到足够的重视。然而，随着时间的推移，该系统的重要性与日俱增，现在这些手动流程耗费了运营团队的大部分时间。没有安排资源为运营团队提供更多工具，这导致随着工作负载的增加，员工疲惫不堪。有人报告员工离职去了其他竞争对手那里时，领导层才意识到这一点。

 **建立此最佳实践的好处：**在一些组织中，如何将同样的时间和精力用于提供新产品或新服务，可能是一项挑战。一旦出现这种情况，预期的服务水平会慢慢降低，业务线就会受到影响。这是因为运营团队没有随着业务的增长而做出改变和发展，很快就跟不上业务的节奏。如果不定期审查运营团队收集的洞察，等到发现业务面临的风险时，可能为时已晚。通过花时间与运营人员和领导层一起审查指标和程序，运营团队所发挥的关键作用将显而易见，并且能在风险达到临界水平之前及早发现。运营团队可以更好地洞察即将发生的业务变化和即将实施的计划，从而积极主动地开展工作。领导层对运营指标的了解展示了这些团队在客户满意度（包括内部和外部客户满意度）方面所发挥的作用，让他们能够更好地权衡选择的优先事项，或确保运营团队有足够的时间和资源随着新业务和工作负载计划的变化而做出改变和发展。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 花时间与利益相关方和运营团队一起审查运营指标和报告数据。结合组织的长期和短期目标来审查这些报告，以便确定是否实现了这些目标。在目标不明确的地方，或在要求的东西和给予的东西之间可能存在冲突的地方，找出含糊不清的根源。

 确定时间、人员和工具可以在哪些方面推动实现运营成果。确定这将影响哪些 KPI 以及成功的目标应该是什么。定期重新审视，确保运营团队有足够的资源来支持业务线。

## 资源
<a name="resources"></a>

 **相关文档：**
+ [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)