每一位被故障折磨的稳定性负责人，都或多或少面临自证的困境：如何证明今年的稳定性工作是出色的？在无法完全避免故障发生的前提下，如何证明稳定性保障工作的价值？在团队和工具尚不完备时，如何高效率推进稳定性建设工作？本期邀请货拉拉稳定性负责人，从全局视角分享如何在2年内从0-1建立稳定性度量体系建设的经验，系统介绍稳定性指标度量的价值、落地方法及成效。作者介绍
TakinTalks社区特邀讲师。2021年加入货拉拉，现任货拉拉技术稳定性团队负责人，主导了公司技术稳定性体系从0到1的建设，也曾作为核心成员深度参与了阿里本地生活技术风险体系建设，在应急响应、变更管控、大促保障等稳定性领域有丰富经验。
温馨提醒：本文约5500字，预计花费11分钟阅读。
后台回复 “交流” 进入读者交流群；回复“0607”获取课件资料；
“拉货就找货拉拉”，相信很多人都听过这句slogan，也有不少人使用过货拉拉的搬家服务。货拉拉除了有大家熟知的同城货运、搬家等业务，还有许多其他业务场景，比如跨城大车、企业服务、零担，甚至还有汽车租赁、加油充电等。截至2022年底，货拉拉的业务范围已覆盖了中国内地的360个城市，月活跃司机数量达到了68万，月活跃用户数超过950万。在这样的业务模式和业务规模下，技术稳定性的必要性和重要性是不言而喻的。
我在2021年加入货拉拉，当时技术稳定性刚刚处于起步阶段，很多工作待建。经过2年的努力，货拉拉技术稳定性体系完成了从0到1的建设，整体故障数降低了78%，同时SLA也从3个9提升到了4个9。今天的分享将结合过往在阿里本地生活技术风险体系下的经验沉淀，以及在货拉拉的实践成效，探讨技术稳定性的重要性和建设方法。我们需要建立一套能够描述稳定性水平的一系列指标，这些指标就称之为稳定性度量指标。回顾生活中的一些经历，你会发现要清晰地描述一件事情是有一定难度的。举个例子，阿诺德·施瓦辛格大家应该都不陌生，要描述他的体型特征，可能很多人会用强壮、高大威猛这样比较模糊的词语来形容。但如果我们用指标度量的方式来描述，比如身高一米九，体重200斤，加上其他更详细的数据，比如体脂率不到10%等，这样的描述会更加具体，并可以将其与其他人进行对比，他的强壮和高大威猛就不言而喻了。回到我们日常的稳定性工作中，比如去年你做了很多与稳定性相关的工作，过程也很顺利，积累了不少经验，整体结果也不错，公司里的技术人员肯定都会注意到这一点，他们会说“最近系统很稳啊！”。然而作为整体稳定性的负责人，或者某个稳定性领域的负责人，你不能直接向老板表达这种感受，而是需要将这种感受转化为绩效指标来进行表述。因此，我们需要建立一套稳定性度量指标，通过这些指标来描述系统的稳定性水平。这些指标应该是可衡量、可比较的，可以让我们对系统的稳定性进行更加精准的描述和分析，同时也可以为稳定性建设提供具体的目标和方向。稳定性指标度量不仅可以帮助清楚地表达成果，更重要的是它能够推动整体稳定性体系的进步。首先，它是一个非常强大的监控工具，可以帮助监测当前稳定性的状态。其次，它具备预警能力，可以提供数据供拆解分析，找出当前稳定性的短板和亟待解决的问题。最后，我们需要评估解决问题的风险成本，这将成为我们下一阶段工作的目标。以往，我们可能会在线上故障发生后才能发现问题，这是一种亡羊补牢的过程，而指标体系能帮助我们更主动、全面地看待问题。因此，稳定性指标度量的核心价值在于帮助整体稳定性体系向前演进。货拉拉在初始阶段遇到了一些问题，其中包括以下几点。
首先，指标非常零散。公司可能有一些稳定的指标，但这些指标无法追溯到最终目的，也无法充分体现其价值。
其次，指标定义不够清晰。同一个名词在不同人的理解中可能有不同含义。
再次，指标数据不容易获取。需要通过梳理文本信息进行统计，但准确性和可操作性不易掌握。
最后，很少有人将稳定性指标度量视为一个体系化的事情来做。通常只在年初或年终进行一次评估，而没有将其作为常态化、体系化的工作。
以上这些痛点，是我们在做体系建设之初就思考到的，也明确了解决这些问题的重要性。
我们需要明确指标度量是一项长期的工作，而不是一次性任务。同时，这些指标必须围绕目标建立，具有目标价值。在数据收集和分析方面，我们应尽可能使用平台工具，以避免痛苦的过程。正如前面所述，指标度量的核心在于建立一整套运营机制，定期观测分析并发现问题，治理问题，将机制体系反馈到下一个阶段的行动中。2.3.1 定义指标
在每个指标被定义出来之后，反问自己这么一句话：指标定义出来到底是想要做什么？它想表达什么？如果能回答上来这个问题，答案也是自己能认同的，大概率不会有什么大问题。最终这些定义的指标需要进行公示并收集领导、产研同学的反馈。我们需要从稳定性的KPI倒推，比如高可用性和业务连续性。从这些指标出发找到一级指标，比如故障数和不可用时间，并在此基础上进一步拆分。拆分的逻辑基于稳定性的定义公式，即减少问题发生的概率和加快问题恢复速度。只有逐层拆解，才能确保指标的充分性，而非直接定一个监控告警覆盖率或响应达标率。在定义指标时必须与当前的稳定性体系相结合，以确保指标定义能够完善地描述当前问题的状态。比如，一家刚起步的公司，不需要太多复杂的指标，只需要定义一些能够描述最终稳定性KPI的指标；随着公司的发展，工作会拓展到其他领域，如应急响应领域，那么就需要建立一套适合应急响应体系的指标。最终，这些指标还需要反馈到整体的问题结果上。2.3.2 收集数据
许多人都经历过使用Excel进行指标度量的阶段，这应该不会是什么美好的回忆。虽然Excel功能强大，包括记录、计算和图表展示等等，但仍有许多问题是无法避免的。首先是准确性问题，人工处理很容易出错，而且数据文件互相传递，会发现版本越来越多，各团队拿到的数据不一致，全局稳定性工作的权威性也会丧失。其次是效率问题，数据量大时，人工维护成本高，做数据挖掘分析也会非常耗时。还有数据留存也是非常严重的问题。历史数据难以找到，监控系统的数据存储也是有限的，无法存储所有的监控数据……因此，虽然平台的建设需要过程，但它一定是非常必要的一环。在制定指标度量体系时，首先需要具备横向的视角，类似于稳定性体系的视角。最初，公司可能只有一个全局指标的大盘或报表，如故障数、SLA、监控发现率、应急时效等。随着业务发展，需要有意识地将指标拓展到各个领域，如应急响应领域、预案领域、改进项等，让每个领域都有其指标度量体系。这样可以更好地衡量各个领域的表现，并为未来的运营提供更准确的数据支持。在每个领域的建设中，还需要有纵深的视角，这对平台的落地是非常关键的。需要明确数据从哪里来，基于什么逻辑统计。例如在应急响应领域，需要统计发现时间，就要从故障复盘或者故障记录的数据里出发，做好相关原始数据的字段设计。此外，还需要注意采用结果指标和过程指标相结合的方法。结果指标是度量领域表现好坏的指标，如前面提到的故障持续时间；而过程指标则帮助我们发现哪些方面需要改进，比如故障时间过长到底是哪个阶段的时间比较长，在响应、发现、定位、处理等环节还能做哪些改进，才能真正帮助减少整个故障时长。最后，维度下钻非常多，比如月份、部门。需要通过维度定义去有目的地分析问题，发现问题所在，进行针对性的治理。2.3.3 运营指标
指标建立并统计完成后，一定要做好运营工作。而运营也需要分不同的视角。向上的视角包括年初规划、年终总结，以及给老板做阶段性汇报、某个领域的汇报等。这有助于向上级领导展示公司稳定性的整体表现和各稳定性领域的情况。此外，还需要做对外的运营，这也是最容易被忽视的。技术团队的很多同学对稳定性不一定非常了解，因此需要定期对外输出稳定性知识，以及区域/部门视角的阶段性稳定性报告。同时，也可以对标业内一线的公司，了解公司在行业内的水平，从而更好地优化自身的策略。最后是对内的运营。团队内每个人负责的领域不同，指标数据可以帮助大家聚焦工作重点，也可以指导每个领域的负责人做KPI拆解和复盘。这些都是非常重要的事情，有助于提高团队的协作效率和工作效能。每家公司的情况不同，阶段性的关键任务也有所不同。因此，在整体建设前需要思考和明确需要解决的痛点，并对症下药。这有助于确保指标建设的针对性和实用性。需要特别强调的是，稳定性指标体系建设并不是一劳永逸的事情，相反它非常依赖后续的长期迭代不断完善。一方面，指标本身需要不断更新优化，以保证其与公司的实际情况相符。另一方面，整个体系也需要不断运作，以确保其不被时间腐蚀。因此，在建立稳定性指标体系后，需要制定长期的迭代计划，并定期对指标进行评估和更新。同时，还需要建立稳定性指标体系的运营机制，确保其能够长期有效地发挥作用。只有这样才能让指标体系在公司的稳定性建设中发挥出最大的作用。货拉拉有一套非常清晰的指标定义流程。从稳定性目标出发，我们设定了故障数目标。在这个目标背后，我们还有一个复杂的故障等级定义，根据受影响业务、影响面来区分严重故障和一般故障。尽管从故障数的表现来看，它们都是一个故障，但实际上影响是不同的。例如，去年的严重故障持续了一个小时，而今年的严重故障可能持续30分钟。除了故障数目标，我们还定义了连续无故障天数等具有里程碑或纪念意义的目标，如2022年货拉拉达成了连续180天无故障，这在我们制定目标之初是不太敢想象的。这些指标不仅仅是为了监控稳定性，也是为了激发团队的士气和自我提升的动力。随着时间的推移，我们在稳定性领域梳理和发展了许多领域，如应急响应、变更管控、预案、复盘改进等等。为了缩短故障持续时间，我们对整个生命周期进行了梳理，并对每个阶段的持续时间做了指标定义。货拉拉的稳定性指标体系建设非常注重细节和实用性，我们统计指标是为了提升稳定性，而非仅仅为了达到某个数字目标。在货拉拉，每个步骤都需要有明确的文字输出，以确保指标定义的准确性和可操作性。举一个大家可能都会遇到的例子，在复盘过程中，我们会对时间点进行定义，例如故障发生的时间。有时候这个时间点很容易确定，例如监控曲线下跌的时间点。但有些场景比较复杂，比如如果这个业务夜间是不提供服务的上午八点才有请求进来，那前一晚变更引入了问题，具体发生时间如何定义就会有不同看法。在这种情况下，我们需要对「故障发生时间」这个字段进行解释，并给出一个合理和明确的定义。为了保证指标定义的一致性和可管理性，货拉拉在每个领域都会有文字沉淀，包括分类、对外Push的指标名称、定义说明、价值等。此外，还包括平台是否具备数据收集、计算分析的能力，以及指标的计算方式等。我们规定以系统监控的异常开始时间为准，如无法确定，则以影响第一例用户的时间为准，最次以线下反馈的时间为准。尽管这个过程可能会比较复杂，但最终可以得出一个相对合理的结果。在货拉拉，我们搭建了一个全局稳定性大盘，其中包含全局的稳定性指标，以及其他一些领域的指标，例如过程领域、预防变更领域、复盘效率等，部分指标目前处于建设阶段。
（货拉拉全局稳定性大盘）在全局指标中，我们重点关注一些有里程碑式意义的指标，例如无严重故障的持续天数。这个指标可以给人一种成就感，能让人直观感受到工作的成果。此外，我们还有一些趋势分析，例如SLA指标趋势，可以帮助我们及时发现问题并采取相应的措施，以保证系统的稳定性和可靠性。
（货拉拉预案平台报表）在单个领域中，例如预案领域，也有相应的工具和报表。在预案平台上建设报表，可以帮助查看整体预案的状态，以及整体预案符合预期的比例等信息。我们还可以根据部门或其他维度进行排序。前面讲到了运营有多个角度，对上和对内都是必须的、有要求、有压力的管理手段，这里不做赘述。主要分享一下作为负责全局稳定性的团队，如何在公司内部运用数据营造稳定性文化氛围。首先，我们需要打造一个IP，通常这个IP是一个虚拟的角色，比如在应急响应领域有一个NOC的角色。在这个IP下，我们明确运营方向，如货拉拉的周期性全局总结、部门总结，以及重点治理专项和平台能力建设等。明确这些系列后，在我们运营的公司内部公众号上分栏目、分系列做推送。每个系列中的内容需要做一些编排，内容要适合受众的口味，这些可以和运营同学多取取经。最后，只有持续输出才能让稳定性成为一个习惯，营造出一个比较良好的稳定性的文化氛围，让大家觉得提高系统稳定性是理所应当的。经过2021年至今2年多时间的建设，货拉拉初步搭建起了指标度量体系，它帮助我们在过程中及时发现并治理稳定性薄弱点，帮助整个稳定性体系向前演进。从稳定性结果来看，货拉拉的故障数呈明显收敛趋势，2022年的故障数比2021年减少了78%；SLA也从3个9的水平提升到了4个9。当然，和业务侧讲这些数据提升，他们是无法直接感受到的。但是当你告诉他们，相比前几年业务少挂了近8个小时，他们会明显感受到稳定性提升带来的的价值。稳定性指标度量可以简单类比体检，在体检之前，我们需要选择哪些科目进行检查，比如血常规等，每个科目下面还有很多的细项。而稳定性可以比作一个人的身体健康状态。整个稳定体系里有各个领域，每个领域也有自己的指标。我们需要采集数据并输出报告。然而，每个人在不同阶段要进行的体检项目可能是不同的，比如孕妇需要产检，老年人需要关注一些特殊情况。与我们稳定性的发展也类似，不同阶段需要关注的问题也不同。有了体检报告之后，我们需要看哪些指标有异常，并采取相应的措施。我们还需要观察自己身体健康情况的趋势，如果越来越差，则需要加强锻炼、注重调理等。这个过程每年都需要进行，且有更谨慎的人频率则会更高一些，目的是让自己的身体始终处于一个良好的健康状态，形成一个正向的循环过程。而与体检不同的是，数据度量体系需要你承担多个角色，既是患者本身，也是医生，还是检验能力提供者，所以整体任务可以说是复杂又繁重。
接下来的工作将聚焦在三个方面。首先，我们要深入挖掘数据的价值，不仅仅局限于表面数据，还需要深入研究数据背后的原因，直达问题的痛点。其次，关于预警，我们需要更智能、更前置的指标异动检测技术，能够提前介入，避免问题的发生。最后，我们希望平台能够提供更强大的能力，比如更灵活的指标组合和维度展示，帮助我们做更精准的分析和运营工作，提升效率。（全文完）1、请问如何量化稳定性的工作过程？在目前在降本增效的环境下，怎么平衡稳定性和成本？2、货拉拉在集团层面是否有稳定性指标的运营者呢？比如谁当裁判员评判业务的稳定性指标是否达成？
3、请问稳定性建设要考虑的范围有多广，比如说有些问题可能是开发导致的，那么是否需要涉及开发规范的制定，测试工作流程的制定？
4、稳定性体系建设落地的优先级一般怎么选定？如何根据业务的发展阶段，打造更适合自己的稳定性保障体系？
更多详细内容，欢迎点击“阅读全文”，观看完整版解答！
添加助理小姐姐，凭截图免费领取以上所有资料
并免费加入「TakinTalks读者交流群」
声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。
更多故障治理内容
📢点击【阅读原文】直达TakinTalks稳定性社区，获取更多实战资料！
本篇文章来源于微信公众号：TakinTalks稳定性社区
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫