【.com快译】近日，我们对一些企业的各个运营团队和工程师进行了调查。我们发现：约70%的受访者将MTTA（MeanTimeToAnswer，平均响应时间）和MTTR（MeantimetoRepair，平均响应时间）作为运营能力的主要指标之一；20%的受访者关注计划内和计划外工作的比例；10%的受访者表示他们没有既定的衡量标准。当然，在实际操作中，单靠MTTA和MTTR是远远不够的。随着系统复杂性的增加，我们需要更全面地了解每个服务的健康状况。下面，我们将与大家分享健康运营过程中的挑战、痛点和需要衡量的关键指标。在此基础上，我们将进一步给出一个标准的成熟度模型和相应的实际案例。针对痛点，在打造实用标准时，为了避免在运营过程中陷入海量无用信息的陷阱，需要提前设计精准的仪表盘和监控指标。以下是运营和基础架构团队经常遇到的各种痛点和挑战。数据不足：我们的APM（ApplicationPlatformManagement）、派单、运营聊天工具等平台都会产生不同类型的数据，数据分散。同时，由于不同团队各司其职，各自为政，数据孤岛现象在企业中并不少见。缺乏反馈：已经发生或正在发生的各种事件无法相互联系和关联，无法反馈到后续行动。运营团队因计划外事件而不知所措。缺乏标准：传统的APM和分析工具虽然功能强大，但由于缺乏针对目标系统的具体标准和规范，运维团队很难使用这些工具达到预期的效果。放之四海而皆准：有时对一个团队有用的数据不一定对另一个团队有用。所以我们需要在不同的场景下监控不同的数据指标，不能相同。那么基于上述痛点，我们应该制定哪些关键的运营标准呢？健康运行的关键指标显然不仅仅是监控系统产生的各类数据。我们需要确保在充分了解他们所处环境的基础上做出合理选择，并根据需要进行调整，以提高运营团队的能力和效率。以下是各企业，尤其是实施了DevOps的企业最常用的一些监控指标。大家可以根据实际情况选择：速度是最常用、最常见、最值得监控和衡量的指标之一。对应的KPI包括：冲刺能力的规划，以及团队将新功能推入生产环境的速度。可用性在给定时间启动并运行的系统的百分比。相应的KPI包括：了解系统和团队从事件或中断中恢复的能力。工程时间由于系统不稳定，团队耗费大量时间进行低效操作。相应的KPI包括：减少拥堵和提高自动化程度。产品质量和客户满意度了解客户满意度。对应的KPI包括：了解用户的关键服务水平对象（ServiceLevelObject，SLO）状态、反应性事件响应（reactiveincidentresponse）等。值得注意的是，如果单独考虑上述指标之一，我们可能会被误导.例如，表面上看起来部署能力高的团队比部署效率低的团队更成功。但是，如果一个高效的团队本身也有很高的失败率或高错误率，那么就不能简单地认为它是成功的。因此，我们需要花一些时间来弄清楚与每个指标相关联的上下文。然后，在此基础上，为每个团队或组织建立不同的标准成熟度模型等级。标准成熟度模型我们可以用下面的成熟度模型来描述从弱势群体到成为该领域领先者的持续成长和改进的过程。以下是每个级别的不同关键特征：脆弱：目前大多数企业和团队都处于这个成熟度级别。虽然他们在操作上有一定的反应能力，但也会时不时感到压力。在这个脱离上下文的阶段，团队主要关注事件或派遣的数量。例如：单位时间内产生的50个事件似乎大于40个事件的绝对数量。但是，如果团队能够对这50起事件中的大部分事件有一个预案，并且能够快速解决，那么这50起事件的实际影响其实并没有那么大。此外，由于没有明确的参考和分级标准，团队可能会将大部分事件定义为高危事件，这会消耗大量的人力、物力甚至时间来处理。统一：在这个层次上，团队可以根据类型和建立的标签对事件进行分类，从而有针对性地处理各种事件。同时，随着这些突发事件的可见度提高，团队可以不断完善现有的事件分类和处理能力，并可以集中精力解决那些计划外的严重事件（通常占30-50%）。优势：这个成熟度级别的团队有更先进的SLO和相关指标，可以主动预防各种事件的影响。为了平衡数据驱动器所要求的服务质量，他们需要在系统流畅地提供各种功能的同时保证整体的可靠性。其中，更成熟的团队可以通过更小更频繁的变更，更好地定位和限制事故的影响半径，使计划外处理工作的比例低于30%。领队：目前只有不到1%的企业达到这个成熟度。它的特点是各种先进的做法，比如：通过适当的服务降级，或者自身的容错功能，来应对那些大规模突发事件的影响。因此，他们能够集中精力解决占计划外事件不到20%的严重事件。可见，领导者的水平不是一蹴而就的。运营团队需要从目标系统的细微处着手，逐步建立合适的监控和处置标准。下面，我们一起来研究一个典型案例。CaseStudy2019年初，某全球电商运营团队开始从最基础的关键指标入手，包括：事件处理时间、事件严重程度划分、计划工作的区分等。（即功能性），什么是计划外工作（例如，事件和错误）等。通过半年的时间，他们建立了坚实的基准指标，并了解了每个指标数据的发展趋势和改进机会。由此，他们发现团队总工程时间的45%花在了计划外工作上，这相当于每月额外花费200,000美元。其中，主要事件集中在产品页面的每个处理流程中，包括：页面加载时间和故障排除时间等。有了这些数据，他们开始深入分流，找出导致用户订单流的原因出错。经过进一步调查，他们确定错误与第三方反欺诈服务以及支付提供商的数据库标签和API有关。2020年第一季度，运营团队主要做了以下改进：重写数据库查询和索引，提升数据质量和系统性能。改进了API的连接处理和错误处理。更换了其中一家反欺诈服务提供商。修改了CDN的提供者，提高了动态对象的加载速度，增加了静态对象的TTL。2020年第一季度后，团队再次评估测量。他们发现产品页面和支付结账流程等用户参与流程的事件数量减少了76%；花在计划外事件上的总工程时间减少了40%。虽然这不是他们健康运行的结束，但这是一个好的开始。原标题：这是了解运营健康所需的指标，作者：HannahCulver
