那些与健康运营密切相关的衡量标准

下面，我们将和您在健康运营的过程中，企业所面临的各项挑战、痛点、以及需要衡量的各项关键指标。在此基础上，我们会进一步给出一个标准成熟度模型，以及对应的实践案例。

根据痛点，创建实用标准

在运营时，为了避免陷入海量却有无用的信息陷阱中，我们需要事先设计好准确的仪表板和监控指标。以下便是运营与基础架构团队经常遇到各种痛点和挑战。

• 数据不足：我们的APM(应用平台管理)、派单、运营聊天工具等平台，都会分散地产生不同类型的数据。同时，由于不同团队各司其职、各自为政，因此数据孤岛的现象在企业中屡见不鲜。
• 缺乏反馈：各种发生过或正在发生的事件，无法相互联系与关联，无法反馈给后续的行动。运营团队疲于应付各种计划外的事故。
• 标准缺失：传统的APM和分析工具虽然功能强大，但是由于缺乏针对目标系统所制定的具体标准与规范，因此运营团队难以使用这些工具，达到预期的效果。
• 千篇一律：有时候，某些数据能够对一个团队非常实用，并不一定对另一个团队也有用。因此，我们需要在不同的场景中监控不同的数据指标，不可千篇一律。

那么基于上述痛点，我们该制定哪些关键性运营标准呢?

健康运营的关键指标

显然对于由系统产生的纷繁复杂的各类数据，我们并非只是为了监控而进行获取。我们需要确保在充分了解其所处上下文环境的基础上，合理进行选择，按需进行调整，以提高运营团队的能力与效率。如下是各个企业，特别是落地了DevOps的企业最常用的一些监控指标，您可以根据实际情况酌情进行选择：

• 速度
  • 它是最常用、最普遍且值得监控和衡量的指标之一。
  • 对应的KPI包括：冲刺能力的规划，以及团队将新功能推入生产环境的速度。
• 可用性
  • 系统在给定时间内正常运行的占比。
  • 对应的KPI包括：了解本系统和团队能够从事故或中断中恢复正常的能力。
• 工程时间
  • 由于系统的不稳定性，导致团队运营效率低下的耗时。
  • 对应的KPI包括：减少拥塞，提高自动化。
• 产品质量和客户满意度
  • 了解客户的满意水平。
  • 对应的KPI包括：了解用户的关键服务水平目标(Service Level Object，SLO)状态，反应式事件响应(reactive incident response)等。

值得注意的是，如果单独地去考量上述指标中的某一项，我们可能会被误导。例如，表面上看，那些部署能力高的团队似乎会比部署效率低下的团队更成功。但是，如果效率高的团队自身反而失败率或错误率也高的话，那就不能简单地将其认定为成功了。因此，我们需要花一些时间，弄清楚与每项指标相关的上下文环境。进而在此基础上，为每个团队或组织建立不同的标准成熟度模型级别。

标准成熟度模型

我们可以通过如下成熟度模型，来描述从脆弱到该领域的领导者，这种不断成长和提升的变化过程。下面是每个档次的不同关键特征：

• 脆弱(Fragile)：目前，大多数企业和团队都处于该成熟度层次上，他们虽然在运营中有一定的响应能力，但是也时常倍感压力。在这个脱离了上下文环境的阶段中，团队主要着眼于事件数量、或派单数量。例如：在单位时间内产生的50个事件，看似比40个事件的绝对数量要大。但是，如果团队对于那50个事件中的绝大多数都能够拥有预案，而且可以快速解决，那么这50个事件实际所造成的影响其实并不大。此外，由于没有明确的参考与分级标准，团队可能会将大多数事件都界定为高严重等级，进而动辄耗费大量的人力、物力、乃至于时间去处理。
• 统一(Unified)：在该级别上，团队可能会按照类型和既定的标签对事件进行分类，从而有的放矢地对各类事件予以处置。同时，随着那些突发事件的可见度增加，团队既能够不断地改进既有的事件分类和处置能力，又能够集中精力去解决那些计划外的严重事故(通常占比为30-50%)。
• 优势(Advantage)：处于该成熟度级别的团队，拥有更高级的SLO和相关指标，能够前摄性地预防各类事故所带来的影响。为了权衡数据驱动所要求的服务质量，他们需要让系统平稳地提供各项功能的同时，确保整体的可靠性。其中，更加成熟的团队还能够通过更小、更频繁的变更，更好地定位和限制事故的影响半径，进而让那些计划外的处理工作的占比少于30%。
• 领导者(Leader)：目前，只有不到1%的企业能够达到这种成熟度水平。其特点在于拥有各项高级实践，例如：通过适当的服务降级、或自身容错功能，以应对那些大规模的意外事件所造成的影响。因此，他们能够将主要精力专注于解决那些占比少于20%计划外的严重事故上。

可见，领导者级别是无法一蹴而就的，运营团队需要从目标系统的细微处入手，循序渐进地建立恰当的监控与处置标准。下面，我们来共同研究一个典型案例。

案例研究

2019年初，一家全球性电商公司的运营团队开始从那些最基础的关键性指标入手，其中包括：花费在事件处理上的时间，事件严重性级别的划分，以及区分何为计划内的工作(即功能性的)、何为计划外的工作(如：事件与错误)等。

通过半年的时间，他们建立了坚实的基准性指标，并从中了解到各项指标数据的发展趋势和改进机会。据此，他们发现：整个团队总工程时间的45%被花费在了计划外的工作上，这相当于每月额外消耗了20万美元。其中，主要事件都集中在产品页面上的各个处理流程中，包括：页面加载时间和故障排查时间等。

有了这些数据，他们开始进行深入分类，以分析出到底是什么导致了用户订单流程出现了问题。通过进一步的调查，他们认定这些错误与某个第三者反欺诈服务，以及支付商的数据库标签和API有关。

2020年第一季度，该运营团队进行了如下重点改进：

• 重写了数据库的查询和索引，以提高数据质量和系统性能。
• 改进了API的连接处理和错误处理方式。
• 替换了其中的一个反欺诈服务提供商。
• 修改了CDN的提供程序，以提高动态对象的加载速度，并增加静态对象的TTL。