去哪儿如何实现故障率降低 65%？技术 + 管理的数字化度量体系实践

一分钟精华速览

如何全面把握系统现状，以便在关键时刻做出明智的决策？这是很多负责全局稳定性的管理者深感关切的问题。基于这一背景，同时也为了寻求提升研发工作效率提升，去哪儿网构建了一套数字化质量度量体系，以此来更精确地度量、管理并提升系统稳定性。

本文将详细解读这套质量度量体系，阐述如何在 100 多个指标中筛选出关键的度量标准，并进行有效的优化。同时，也将探讨如何借助这个指标模型理论，衡量系统复杂度并进行系统防腐化治理。这套数字化度量体系让去哪儿网的管理决策更有依据，改进方向更明确，结果也更可控，实现了系统运行状态的可视化。

作者介绍

去哪儿网基础研发产品总监——陈靖贤

TakinTalks 稳定性社区专家团成员，去哪儿网基础研发产品总监。2013 年加入去哪儿网，曾任职于摩托罗拉、索尼移动通信。多年来深耕于 DevOps、研发效能领域，致力于公司内部 DevOps 实践的落地实施，研发与交付流程的优化，工程效率平台工具的建设与推广，覆盖开发、测试、交付、运维研发生命周期全流程。 全面系统提升研发效能，助力业务发展。

温馨提醒：本文约 7000 字，预计花费 10 分钟阅读。

「TakinTalks 稳定性社区」公众号后台回复 “交流” 进入读者交流群；回复“1123”获取课件；

背景

去哪儿网采取了一系列技术手段来确保系统稳定性，包括监控告警日志、分布式链路跟踪等可观测性实践，以及混沌工程全链路压测等稳定性治理方法。尽管如此，依然还是会出现各种问题。

故障频发问题是很多企业内部的重点议题。其实单靠技术手段是无法做到全面提升的，需要结合技术和管理手段。去哪儿实施数字化度量之前，各团队进行的度量更多的是为了评估自己系统的某个特性，而且对于相同的特性，不同的部门有各自的度量口径，这就导致了指标的混乱。一方面管理者无法全面了解现状，另一方面，管理者的管理和重要决策也会缺乏抓手和依据。因此，数字化度量成为了赋能管理，提升系统稳定性的重要工具。

我将在本文详细介绍去哪儿网在数字化度量方面的实践，以及如何通过数字化度量提升研发管理的可观测性，并以系统腐化治理为例，详述其在稳定性提升方向的成效。希望这能对大家有所帮助，促进共同进步。

一、如何建设质量度量体系？

1.1 数字化度量的目标与实施路径

我们希望通过建设统一的数字化度量体系，实现研发团队的全面度量和管理。

那么，如何实现这个目标呢？在去哪儿网，我们采用了下图的模型来制定实施路径。这个模型分为五个步骤：指标定义、数据采集、数据处理、评估分析，并通过持续运营和改进来实现度量效果的落地。

指标的定义并不是一蹴而就的，当执行中遇到问题，我们会重新进行指标的定义和数据采集等，不断循环优化，这是一个逐步提升的过程。

1.2 指标模型的创建

在开始数字化度量之前，需要明确要度量什么，为谁度量，以及如何进行度量。这个步骤是非常重要的，因为它决定了后续的工作方向和重点。

1.2.1 确定度量对象和指标（度量什么）

在整个研发过程中，主要涉及到四个元素：产品、项目、应用和人。产品是向用户提供和交付价值的载体，而这个价值是通过项目的一系列迭代来实现的。项目中涉及到的应用变更和代码发布，是项目实现价值交付的关键环节。而在这整个流程中，人扮演着重要的角色，他们是整个流程的操作者和操纵者。因此，度量主要针对这四个对象。

但是，有一点需要特别注意，那就是度量人的问题。如果直接对每一个人进行度量，可能会引起被度量者的反感，从而导致度量无法达到预期的效果。此外，我们的目标是了解公司整体的状况，而不是关注特定个体的情况。因此，我们将人的度量转换为对团队的度量。这是我们在刚开始进行度量时进行的一项重要考虑。

明确了度量对象之后，需要进一步明确每个对象下的具体度量指标。

创建度量指标并非易事，因为涉及到的人和团队众多，需要找出一个能让所有人达成共识的指标，这是一个挑战。在此过程中，涵盖了多个领域，如项目管理、应用开发和质量管理等，我们需要找到各领域的专家，共同进行头脑风暴，确定需要从哪些指标进行度量。

当时头脑风暴后，我们识别出了 100 多个初步指标，我在这里列出的只是其中的一部分。之后，经过一轮又一轮的筛选和精简，最终确定了大约 60 个指标。确定了这些指标之后，在实际使用过程中，又不断对指标进行了迭代和优化。这个指标识别和确认的过程，实际上也是与各相关方共建的过程。

1.2.2 定义服务对象（为谁度量）

明确用户是谁，并识别出他们的关注点，这样才能更好地满足不同对象的需求。我们根据角色将服务对象分为三类：中高层管理者、一线团队领导（TL）和基层员工。

不同角色的关注层次有所不同，这是在设计度量方式时需要注意的。需要设计出能满足各角色在不同维度上需求的度量方式。

对于中高层管理者来说，他们关注的是公司整体以及大的团队或部门之间的质量情况，中层管理者可能更关心自己管理的大部门的整体情况以及部门内部各小团队的情况。一线 TL 则更关注他们所带领的团队以及团队内各个度量对象的情况。而对于基层员工，他们主要关注自己负责的度量对象。

1.2.3 确定指标模型（怎样度量）

前文提到我们有 60 个指标，这是一个相当大的数量。因此，我们对这些指标进行了分级。分级的方法主要有三种：指标层级的划分、指标级别的划分以及指标的分类。

指标层级：我们采用了结构性思维，通过类似金字塔的结构，从总体到局部进行划分，形成了三层结构。每个层级有其特定的名称，例如“维度”是指度量对象某一方向的度量，可以按照不同的度量对象划分维度。在维度下面，每个度量对象会有自己的分类，分类下面则对应具体的指标项。这样，从整体到部分，形成了层层分解的结构。

指标级别：根据指标对度量对象的直接影响和表明状态的关系，对指标进行重要等级的划分，分为 P1、P2 和 P3 三个级别。例如，P1 级别的指标是直接影响和直接表明度量对象状态的指标。此外，还需要一个评价标准来判断数据好坏。为了更好地呈现指标水平，我们对指标进行了评价标准的划分，将每个级别分为几个等级，比如好、中、差、极差等。不同的等级会对应不同的评分，最终通过一个得分率来展现指标的情况。

指标分类：根据角色的不同，我们还对指标进行了分类，比如产品指标、开发指标和 QA 指标，不同的角色可以通过筛选条件选择自己关注的指标。

这个模型是通用的，不仅适用于质量度量，也可以适用于任何维度的度量。下面我将介绍在质量指标中，如何套用这个指标模型。

1.2.4 质量指标模型

这里画了一个简单的图来展示去哪儿网目前的质量指标模型概况，整体分为结果指标、过程指标两部分。但这个模型并不是一次性就形成的，而是经历了许多迭代改进。

比如，起初我们并没有结果指标这个层级的划分。原来的度量直接按照应用维度、项目维度和业务维度进行划分。在业务团队维度中，之前包含了一些故障的情况，比如故障率、团队的故障主动发现率和处理时长的超时率等。但当时每次发生故障后，对于质量分数的影响非常大，起伏也很大，对于线上故障的整体情况并不能很好地呈现出来。

为了更客观地度量整体的故障情况，我们决定将大家更关注的结果指标单独拆出来，形成了现在的结果指标和过程指标。

1.3 质量度量的数字化落地

接下来就要对这个模型进行落地，将其运用到平台上，然后对业务进行数字化度量。

1.3.1 质量度量平台架构模型

数字化度量平台架构模型包含几个层级。底层是数据源层，这里的数据来自各种系统，含有各类度量指标。由于不同系统的数据各异，直接度量有困难。因此，我们设定了数据标准，以特定格式采集数据，然后将其集成到平台上。

这些数据覆盖了各个维度，形成了一个数据湖。基于预设的质量度量模型，我们计算每个指标的得分。有了这些得分，就可以根据评价模型进行级别划分，角色达标和指标归属等操作。我们还会添加标签，方便后续管理。根据评价对象，会得到各个维度不同的得分。

在此基础上，我们可以将应用和项目的评价汇总到产品评价中。同样，团队的评价也会反映在产品线的稳定性上，因为团队的表现会影响到产品线的稳定性。

最后的展示层以多种方式如趋势分析、对比分析、聚类分析和下钻分析等展现数据，以满足不同用户的需求。我们还设计了分层面板，包括全局面板、项目面板和应用面板等，用户可以根据自己的关注点，选择相应的视图。

1.3.2 度量结果和看板

1）全局看板

全局看板下，首先可以看到一个整体的趋势图，展示了各个团队的整体变化。在这个趋势图里，可以明显看到某一条线有特别明显的变化，无论是上涨还是下降，或者是持续在一个低位的状态，都可以一目了然地看出来。

为了更好地度量，我们对指标进行了等级划分，比如某一个团队，它当前的水平是达标、优秀或是卓越，这样可以对整个团队的度量有一个评价划分。

还通过指标维度的整体趋势图，可以看到某一个特定指标的突出变化趋势。对于特别显著的指标，可以进行下钻分析。

（质量看板-全局趋势图）

2）数据洞察

如果想看更细节的情况，我们提供了数据洞察的能力，可以对各个团队的得分情况进行排名，看到每一个团队基于选定的某一个基准，它是涨了还是降了。如果降了，可以点击分析，看到具体指标的变化和数值，然后再进行进一步的下钻分析。

（质量看板-详情数据）

我们还提供了更详细的数据，比如故障处理超时的个数，具体是什么故障，用了多长时间等详细数据。这样，就可以从全局到细节，逐步进行分析。我们还进行了指标的排行榜和应用的排行榜。在指标排行榜中，可以看到哪个指标的得分变化最大，哪个最差，哪个最好等。

1.3.3 指标运营

仅仅有平台是不够的，更重要的是要对指标进行运营，让大家持续关注并改进。指标运营主要包含两个部分，一是团队的协作，二是运营的流程。

1）团队协作：因为整个质量的数字化度量是公司高层管理者比较重视的，各级团队的管理者也非常积极地支持，数字化运营是组织级的持续的 OKR。每个季度，我们都会根据公司的情况设定一些改进目标，采取一些改进措施。为了能让组织和团队高效配合，推进指标和改进的情况，我们成立了一个数字化治理委员会。对于质量维度，我们有质量治理委员会，成员包括基础研发部门的同学和来自其他业务研发团队的专家，大家会一起做一些讨论，制定计划，推进并度量效果。为了鼓励大家完成，还制定了一些奖励和激励机制，比如在年终的时候，会对在数字化度量方面改进提升效果比较突出的个人和团队进行奖励。

除了协作外，还有一个汇报机制，让大家及时知道治理的情况。我们会月度对数据进行报告，包括大家的改进动作对哪些指标产生影响，哪些指标提升或恶化，以及具体原因等。也会向公司的高层管理者汇报，比如这个季度的 OKR 目标及其完成情况，哪些团队在治理过程中产生了好的经验，还存在哪些问题等。

2）运营流程：主要按照 PDCA 环来进行，即制定计划，执行行动，检查效果，进行改进。数字化委员会的同学会共同参与制定计划，各个团队的对接同学会负责在团队内部执行行动。然后会定期评估治理效果，得到效果反馈，这是正向的激励。在最后一个阶段，会把治理过程中好的做法进行标准化和推广，总结未解决的问题，进入下一循环。这样就能持续不断地进行指标运营。

1.4 实践效果

故障率从 0.57%下降到 0.2%左右；

质量门禁百分百开启；（以前，虽然在发布过程中有质量拦截机制，但并不是所有团队都开启了这些门禁，所以并没有完全发挥出它的作用。但当我们把这个机制纳入到度量体系中以后，大家对这个问题的重视度提升了，所有团队都开启了质量门禁。）

核心业务系统压测覆盖率 100%；

核心业务系统故障演练 100%；

二、如何度量系统复杂度并防止腐化？

2.1 防腐化治理的背景

2022 年去哪儿落地了一个公司级的代码瘦身项目，我们做到了代码精简 50%，应用精简 50%。然而，如果后期不继续进行干预，随着功能的迭代和人员的更替，应用数量和代码量还会增加，系统会逐渐腐化。如果我们不能保持代码瘦身成果，那么我们之前花费的精力就会完全白费。因此，我们将如何巩固瘦身成果的问题转化为如何防止系统腐化的问题。

2.2 系统腐化指标模型建设

在进行系统腐化治理的过程中，我们实际上是在进行一个数字化的过程，这与质量度量的思路基本一致。我们需要定义腐化，测量腐化，然后进行腐化治理。这个过程主要分为三个阶段：定义阶段、度量阶段、治理阶段。在定义阶段，我们需要首先定义什么是腐化，确定好模型，这是最重要的一步。然后，基于数字化平台，我们开始进行数据的采集和分析，最后通过运营机制，进行腐化的治理和持续的运营。

2.2.1 指标识别（度量什么）

系统腐化，指的是系统性能或功能逐渐下降或恶化的现象。比如无用代码变多，无效配置多，代码覆盖率低，发布依赖太多，内外部调用不合理……这些都是系统腐化的表现。但看起来，这些更像是一个系统复杂度的度量。因此，我们将系统腐化的度量最终转换成了系统复杂度的度量。

那么具体要度量什么呢？一个单独的系统不能直接对外提供服务，我们需要考虑的因素包括业务域、系统内的应用、应用内部的代码、配置和接口等等。这些都是我们的度量对象。

2.2.2 模型建设（怎么度量）

在确定了度量对象之后，就需要考虑如何进行度量，这就涉及到模型建设的问题。在这个过程中，我们采取了"专业的人做专业的事"的原则，因为对于复杂度这一块，业务研发同学可能是最有话语权的。因此，模型的建设是由公司的业务研发技术专家共同完成的，他们共同研究大家共性的问题，解决研发上的难点，共建模型。

（参考模型一：The Open Group Conference 2015 复杂度评估模型）

（参考模型二：国防科技大学学报 41 卷第 1 期-系统复杂性及度量）

由于业内对于复杂度的度量并没有一个特别成熟的标准和模型，我们查阅并找到了一些参考。参考模型一给我们的启示是，可以按照指标分层进行度量。这种分层的逻辑与我们自己定义的模型有着相似性，因此，我们在建立自己的度量模型时，也采取了这种分层的逻辑。参考模型二的启示是，需要对复杂性概念进行分类，这实际上也是一个维度的划分。

由于不同的业务线对复杂度有自己的理解，可能存在认知差异，所以最后大家坐到一起进行共同讨论，进行头脑风暴，来确定了具体的指标。在这个过程中，一开始总计提出了 29 个指标，经过讨论和筛选，最终确定了 8 个核心指标。

2.2.3 复杂度度量模型

这个模型包含 8 个指标项，每个指标项对应一个特定的维度，分别用来度量复杂度和相关性。例如，即使一个系统复杂，但与重点 OKR 和核心链路的关联度不强，那就很可能在精简中被剔除。

我们将复杂度分为两类：一类是系统的静态属性，另一类是系统的调用属性。静态属性度量应用，包括代码量、代码圈复杂度和有效代码量。调用属性度量应用接口，包括外部依赖、内部链路复杂度和外部链路复杂度。这里的内部和外部是指系统内部的应用之间的调用和系统与其他系统之间的应用的调用。

因为每一个指标对应的度量数据的量级和量纲都大不相同，例如代码行可能是几千行、几万行或者十几万行，而圈复杂度可能只有一位数或者两位数，所以我们采取归一规则，将所有数据都统一到 0 到 10 之间。此外，不同的指标在整个度量中所占的权重可能会不一样，我们为每个指标分配了一个系数。这个系数也是在不断实验中调整，以确保其最终值能真实反映系统情况。

2.3 系统腐化数字化落地

2.3.1 平台架构

为了复杂度模型落地，我们也建立的一个平台来落地。这个平台的架构相对较简单，主要分为三层，数据源、模型层和展示层。

2.3.2 效果展示

1）元数据管理 在元数据管理中，需要构建业务域、链路入口、系统和应用之间的关系，因为在度量过程中涉及到相关性和调用关系的度量。在这个页面中，采用了分层的结构，即业务域下面包含了不同的系统，又对应了不同的入口，比如在客户端，前端页面访问的服务的入口，这个是我们维护的服务的列表，系统下面又分为应用。这样就通过元数据管理建立了基本的数据关系。

（元数据管理：业务域 -> 链路入口 -> 系统 -> 应用）

2）系统复杂度面板 在系统复杂度面板中，我们能看到同一个系统在不同的业务域中，复杂度的分值是不一样的，这是因为在不同的业务域中，调用关系会存在一些差异，所以会导致复杂度分值上的差异。通过这个差异，可以看到某一个系统在哪个业务域中可能存在较复杂的调用关系，是否需要进行一些治理，这个面板能提供一些参考。

对于某一系统，在特定业务域中，它的复杂度变化状态是怎样的，能在详情分析中看到它的整体复杂度和相关性的变化趋势，以及具体某一项指标的变化趋势。在具体的详情中，还能看到它的代码行数等具体数据，这些数据为我们提供了一个参考。

3）应用腐化治理面板 在应用腐化治理面板中，我们主要针对的是应用的治理。这个过程主要针对的是静态复杂度的部分。对于接口调用这块，我们并没有把它归到团队这里，因为在不同的业务域里，这个复杂度是不一样的，我们目前还没有找到一个合理的方式去进行这个整合，所以这部分可以作为一个参考。

另外一个原因是，在之前的元数据梳理过程中，这个过程是靠业务线来梳理的，他们录入元数据时，有一些可能没有纳入进来。所以如果我们对这部分进行统一的复杂度评分，可能就不够客观。因此，我们对统一的部分进行了腐化的治理。

在这个治理页面里，会展示公司整体的复杂度变化情况，以及每一个指标的变化情况。也会对各个团队的腐化情况进行展示。比如，有各个不同级别的部门，如三级团队和四级团队，我们会让业务线关注腐化的情况。

在腐化的详情里，可以看到在某一个时间周期内，复杂度的变化趋势，对于不同指标的变化趋势，都可以在这里看到。这个治理面板还包括了团队内部所负责的应用在各个维度上的变化值。业务线在治理时，可以看到某一个维度上的增长，然后根据我们提供的治理建议进行治理。

2.4 长效治理机制

我们要如何有效地进行治理呢？这需要通过一系列运营流程和长效管理机制来实现。主要包含四个阶段：

首先，第一个阶段是设定控制目标。因为我们是基于代码瘦身成果来治理，所以这一阶段以瘦身结束后的数据作为初始基准。每年会更新一次这个基准，然后设定了一个总的年度增长上限是 10%。这个上限是根据代码的自然年增长率来的。为了避免年度目标跟踪存在的风险，我们把这个目标拆解到每个月，每个月的增长上限设定为 0.85%。如果超过了这个上限，就会认为它存在腐化，需要人工干预去进行治理。

第二，设定完这个指标后，通过数字化委员会与各个成员达成一致。有了这个目标，每天会定时取数据计算，检测复杂度的增长率是否超标。对于腐化部门，会自动进行识别，识别出腐化的原因，并给出腐化治理的建议。

第三，识别出来之后，会通过公司内部的即时通信工具，及时通知到这个腐化部门的 TL 以及负责腐化应用的负责人。通知中，会提供相关的腐化详情，比如当前状况，阈值，超标详情和治理建议等。

最后，会对腐化治理的过程进行跟踪。业务线开始治理后，需要在系统内创建治理计划。这个治理计划会在项目管理系统中自动生成治理任务。我们会通过检测腐化值的变化和任务完成情况，来判断治理效果。如果没有按时创建计划或进行治理，腐化指标就会变差。如果对腐化没有任何干预动作，会在数字化系统中的度量直接评价为差。我们也会跟质量一起，进行周期性的汇报。

2.5 实践效果

年度复杂度增长率：9%<10%

2.5 实践效果 年度复杂度增长率：9%<10%

腐化团队 6 次个，治理完成 4 次个（值得注意的是，有的团队可能会出现多次腐化，例如在一个月内腐化，治理完后，可能在下个月又再次出现腐化）

建立了系统复杂度度量的标准和长效治理机制；

为研发团队系统复杂度提供了依据；

提高业务研发对系统复杂度的重视；

驱动业务研发持续关注与治理系统复杂度，降低系统稳定性隐患。

三、总结和展望

未来，我们还是会继续从人、流程和平台三个方面进行系统稳定性提升。

首先，我们会在公司内部组织主题培训，分享各个团队的优秀经验，提炼并标准化流程，提升每一个人对质量的意识和对系统稳定性的重视程度。我们将在流程中加入常态化演练，以持续提升在处理故障和问题时的整体能力。

其次，对于平台方面，将进行更多的赋能。例如，我们公司正在研究 AI 结合，准备从这个方向深入结合，提高平台的能力，从而提升问题处理能力。例如，可以利用 AI 进行预测，进行数据分析，提早发现故障。通过 AI 可以快速定位故障，并对预案进行梳理，然后根据定位出来的原因，进行智能预案的推荐。

最后，在故障演练系统方面，会支持流程中的常态化演练。这包括预案演练，可以通过这个平台来验证预案是否有效。还包括对人的演练，例如通过攻防演练来提高快速处理问题的能力。同时，还会进行服务依赖的演练，识别服务接口的强弱依赖，并对这些依赖进行治理。（全文完）

Q&A：

1、能讲一下为什么考虑做这个系统的?前期做了什么评估？

2、研发效能和质量这块在运营上如何平衡？这两块应该都有数字化度量，际运行中是否有两边指标的对比？

3、如何处理和避免度量过程中的一些技术难题，例如数据倾斜、数据缺失等问题？

4、对于一些难以直接度量的指标，我们如何通过其他指标进行间接度量？

5、业务看到度量指标变差后的改造实践，具体怎么修复的？

6、如何调整和优化指标模型，然后来适应业务的变化和团队的一些发展？

以上问题答案，欢迎点击“阅读全文”，观看完整版解答！

本文由博客一文多发平台 OpenWrite 发布！