一、前言

货拉拉是大家耳熟能详的互联网物流公司，致力于为个人、商户及企业提供高效的物流解决方案，让货物出行更轻松。

截至2022年12月，货拉拉业务范围已覆盖360座中国内地城市，月活司机达68万+，月活用户达950万+。

这些数字不仅说明货拉拉业务规模已十分庞大，更多地表明我们在承担着一份非常重要的社会责任。而稳定性正是我们履行好这份社会责任的必要因素。

二、背景与挑战

技术稳定性即系统平稳连续运行的能力，通常采用MTBF/(MTBF+MTTR)来定义，结果越趋于1说明系统越稳定：

其中MTBF即MeanTimeBetweenFailure，指系统连续无故障的时间；MTTR即MeanTimetoRecover，指系统发生故障到恢复的时间。

通俗来说，稳定性期望我们系统的故障率越低越好，处理问题的时长越短越好。同时站在全局的视角下，稳定性工作还需要充分考量与成本、效率之间的平衡关系，否则只靠堆叠机器、禁止变更就可以大大提升系统稳定性。

基础原理比较容易理解，但涉及到落地阶段就会发现，稳定性工作极具挑战性，主要体现在以下三点：

• 组织

稳定性工作与系统生命周期紧密相关，涉及到系统生命周期的每一个环节，也因此关系到参与其中的开发、测试、运维乃至产品、运营、客服等各个角色。

货拉拉的技术团队规模已远超千人，如何在庞大的组织中通过跨团队沟通协同的方式取得良好工作成效是稳定性建设过程中最常面临的挑战。

• VUCA

当今互联网系统具备典型的乌卡（VUCA）特性，即易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）。

货拉拉的系统也是如此。空间上存在3000+应用服务、错综的依赖调用关系；时间上伴随着各种系统重构、架构改造，使得系统健壮性难以维系，脆弱易腐化是常态。而复杂易变的系统又带来高昂的认知成本，进而导致其中风险难以被快速发现和处理，对系统稳定性造成极大威胁。

• 木桶效应

几乎所有系统运行以来都发生过问题，而造成这些线上问题的原因也是多种多样的，比如技术架构缺陷、外部依赖故障、人为操作失误等等，甚至还可能是因为恶意破坏。

所以稳定性工作必须要考虑到方方面面，不仅仅包含技术，还需要把控人员的稳定性意识和技能，团队的管理，以及明确各种流程规范制度标准，因为任何地方出现短板都可能造成全局瘫痪，导致公司业务和用户体验受损。

货拉拉的技术稳定性体系建设也是围绕上述痛点进行了重点攻坚。

三、过程回顾

下面我将对货拉拉技术稳定性体系建设的思路历程和实战经验进行回顾，希望能对大家的工作有所帮助。

1. 团队搭建

术业有专攻，稳定性工作是专业的事，需要有专业的人来做。

21年之前，货拉拉已初步完成稳定性虚拟小组的搭建，主要负责处理各种稳定性相关的任务，不至于让稳定性成为无人管辖的蛮荒之地。但虚拟小组里始终缺少专业专职稳定性技术角色，导致货拉拉的稳定性难以以体系化的形式向前发展，落地效果得不到保障，各类问题层出不穷，最终导致业务稳定性结果一直不甚乐观。

21年中期，货拉拉全职稳定性小组成立，负责全局技术稳定性体系的设计、搭建及演进，把控公司稳定性建设的主要方向和核心价值，补齐了全局稳定性团队的最后一块拼图。

全局稳定性团队搭建完成后，我们迅速明确了各成员的职责，使得团队可以更好地发挥合力的作用。

2. 认知提升

认识世界是改造世界的必要前提。稳定性工作也是如此，想要提升业务的稳定性，先要提升对业务和系统的认知水平。

将一家公司的业务流程、系统架构、调用链路梳理清楚是一件极其耗费精力的事，其难点主要在信息的复杂性和零散性。货拉拉光业务种类就非常多，包括同城/跨城货运、企业版物流服务、搬家、零担、汽车租售及车后市场服务。

稳定性的前期工作要特别注意短时间周期内的ROI，因为随着时间的推移，风险演变为故障的概率会越来越大。

基于此，我们决定先从体量最大业务的核心功能点着手梳理，具体过程如下：

1. 明确业务核心功能点，如用户下单、司机抢单等；

2. 梳理业务功能点对应的系统入口服务及接口，比如用户登录对应为A服务下的userLogin接口；

3. 依据入口接口递归出所有下游依赖的服务接口，生成调用链路，并整理出关联服务集合及特征信息。

最终在各领域架构师、研发、测试等人员的共同努力下，我们在货拉拉梳理出一份核心业务功能点及调用链路信息库，为后续治理提供了有效的认知基础，帮助稳定性工作在前期能够快速取得成效，比如在进行监控告警覆盖治理中，会对核心链路相关的服务提出更严格的结果质量和治理时效要求。

3. 韧性治理

链路梳理提升了我们对业务系统的认知能力，同时也帮助我们发现了系统中存在的诸多问题。

比如最常见的超时时间配置过长，还有重试、幂等、限流、强弱依赖等等设计，都存在一些不合理的情况。这些不合理导致我们的系统缺乏足够的健壮性，尤其是在遇到一些突发状况时。21年货拉拉就仅仅因为一个云上的分钟级网络抖动异常，导致订单跌底无法快速自愈，而原因就是核心服务Redis超时时间配置不合理引发的一系列系统崩溃。

所以紧跟着链路梳理，我们开展了对核心链路的风险治理，具体步骤如下：

1. 依托各方面专家经验，给出风险治理模型，并拉齐各领域架构师对风险治理模型进行商讨确认；

2. 依据风险治理模型对核心链路的每个调用环节开展集中评审，输出不满足标准的待改造项；

3. 针对待改造项进行排期追踪，并对已完成的改造项进行验收，确保改进落实完成。

经过这次集中治理，我们发现并治理了近200项线上风险，系统韧性得到可观提升。

值得注意的是，韧性治理并非能够一劳永逸，因为随着时间推移，新的风险会被再次引入，需要依靠标准化流程化的架构评审和自动化的风险扫描建立起韧性治理的长效机制。

4. 故障应急

《Google SRE》中有这样一句话：系统正常，只是该系统无数异常情况下的一种特例。相信大家一定深有体会。

核心链路的韧性治理只是帮助我们减小了故障发生的概率，还远达不到杜绝故障发生。

事实上，没有任何办法能够杜绝故障发生，故障必然发生是客观事实规律。在时间的不断流逝中，硬件一定会损坏，软件一定会有Bug，人也一定会犯错，而且不止一次。

所以做稳定性工作就要有故障随时会发生的觉悟，并且要以良好的心态去接纳故障的发生。

除了要培养良好的心态，我们还对以下几点进行了重点建设：

• 快速恢复

故障应急的第一原则是快速恢复，因为故障每多持续一秒，都会有更多的用户受到影响，更多的公司利益遭受损失，严重情况下还有可能发展成社会级别恶性事件。

结合应急响应生命周期分析可以发现，快速恢复的关键点主要在故障发现、应急组织、初因分析、恢复执行，以此思路我们分别做了以下事项：

1）故障发现：根据核心业务梳理建设相关监控看板及告警；

2）应急组织：应急人员模块化管理、应急群一键拉起、指挥官机制统筹应急秩序；

3）初因分析：变更关联、应用健康状态自动分析；

4）恢复执行：快恢SOP沉淀、应急预案梳理。

• 经验吸取

故障最大的价值就是带给了我们宝贵的经验教训，避免相似问题再次发生或再次造成不可接受的影响是故障恢复后的关键任务。

在货拉拉，我们主要依靠事后复盘、改进事项追踪和周期性故障回顾三个机制来确保故障价值在短中长期都能得到充分发挥。

• 变更管控

变更是极大的风险引入渠道，变更的前置准入已经有CR、QA、灰度等层层关卡把守，于是我们重点围绕异常变更发生后如何减小影响和如何快速恢复做了以下建设：

1）依据货拉拉订单量级的时间分布定义变更窗口并加以严格管控，禁止窗口期外尤其是业务高峰期的变更，并规范紧急变更流程规范。一个异常变更发生在业务高峰期和低峰期的影响面差异是非常巨大的；

2）收口各渠道的变更记录，做到异常发生第一时间自动查找近期变更信息，以便快速定位和引导回滚，这个能力极大地帮我们减少了问题恢复时长。

• 防微杜渐

海恩法则指出：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。这启示我们不仅要着眼于故障的处置，还要关注日常的细小问题，每一个细小问题的背后都可能在酝酿着一个重大故障。

基于海恩法则的金字塔模型，我们建设起了风险隐患机制，针对线上的每一个异常事件启动应急追踪，确保问题能够快速恢复，阻止事件恶化，并在事后开展复盘，将故障扼杀在摇篮里。

• 以演促防

疫苗通过主动注入减毒灭活细菌病毒的方式帮助人体免疫系统积累抵抗记忆和保护物质，我们的系统也需要经常通过演练的方式来帮助相关人员加强应急意识、熟悉应急流程、检验应急手段，甚至通过混沌工程无差别攻击的手段，主动暴露系统中存在的问题。

货拉拉也在此理解基础上建立起演练相关的机制和工具：

1）应急响应演练：通过一站式应急响应平台拉起线上事件，检验工具流程可靠性，考察人员响应质量，加强研发应急响应意识；

2）预案演练：依托预案平台提前梳理线上应急预案，并针对预案开展演练，以检验预案执行决策逻辑合理性，并观察预案执行效果是否符合预期；

3）故障注入演练：通过故障演练平台实现生产环境真实异常注入，并以此开展故障演练检验系统健壮性，或开展攻防演练锻炼研发应急处理能力、检验告警规则有效性、暴露当前系统或机制中可能存在的问题；

4）灾备演练：检验公司面对灾难级事件时的数据及系统恢复能力，确保公司系统不会遭受毁灭性打击。

5. 文化建设

稳定性从来都不是几个人的事情，而是整个公司的事情。提高所有人员的稳定性意识和技能，是稳定性建设的重中之重，也是一家公司能在稳定性方面一直保持优秀状态的基础。

所以稳定性文化建设在货拉拉也是一门必修课，主要分为了以下几个阶段进行开展：

1. 第一阶段，我们邀请在稳定性方面能力优越的人开展分享或培训，帮助公司其他同事加深对稳定性的印象和理解；

2. 第二阶段，我们借助所有技术专家的力量，依靠Design for failure的系统设计理念，从设计规约、编码保护、信息安全、变更操作、工具使用、应急排错几个角度阐述了设计原则和最佳实践；整理完成后我们将内容印制成册，供所有技术人员日常学习，并开展考试检验掌握情况；

3. 第三阶段，我们试图让稳定性变得更具趣味性一些，于是策划开展了稳定性文化月活动，通过游戏、互动的方式，让大家在学习到稳定性知识点的同时还能收获有趣实用的精美礼品。

四、实战演练

经过上述介绍，大家应该对稳定性工作或多或少有了更多了解，那么假如现在你到了一家新公司负责稳定性建设工作，面对新业务新系统新同事，该如何开展具体工作呢。

1. 围绕应急响应

首先，短期工作一定要围绕应急响应出发。在稳定性建设的初期，各个环节存在各种漏洞，是线上问题频发的阶段，如何快速发现问题，快速组织人员应急，一定程度上决定着问题恢复的速度。用最快的时间梳理好公司核心业务指标，配置监控大盘和告警，明确应急拉群通告机制，确保能够以最快的速度发现问题并进入战斗状态。

2. 深挖系统问题

应急响应基础打牢之后，结合稳定性定义，下一步要考虑如何避免问题发生概率，建立起系统稳定性保护屏障。行之有效的手段是对关键业务下的系统链路进行梳理和治理，帮助我们认识到当前系统状态，发现短板解决短板，达到提升系统健壮性的目的。

3. 持续运营演进

解决两大核心问题之后，要把重点放在如何一劳永逸地解决稳定性问题这个目标上。通过集中治理改造，系统稳定性会在短期内得到提升，但随着时间推移，内部在变化，外部也在变化，人员在变化，稳定性资源投入也在变化，如何保障好的结果不遭受意外，如何让我们在最坏的情况下（如黑天鹅事件）还能有兜底措施，是需要花大量时间思考和建设的事，这个命题即为技术稳定性体系运营。明确稳定性各领域运行机制，各角色职责，并通过数据指标进行度量，确保系统稳定性处于一个健康的状态。

经过以上三个阶段，这家公司的技术稳定性将会扬帆起航，帮助公司在征服星辰大海的道路上越走越远。

五、总结与展望

相信大家在工作中也遇到过不是很重视稳定性的技术人员，觉得自己的本职工作只是应对业务需求写写代码，稳定性是额外的事，如果不是领导安排，是不会主动做的。这种想法一方面是没有深刻领会到Owner意识，另一方面也给自己的职业发展套上了枷锁。

还有一些技术人员认为稳定性工作不过是配配监控告警，日常值班处理一下线上问题，并且疲于很多稳定性治理项目，最后应付应付草草了事。这一方面是工作态度问题，一方面也侧面反映出稳定性工作的体感确实有待提升。

业内稳定性领域发展至今还算不上很成熟，没有很多公开的系统化的方案来指导稳定性建设工作，而且很多公司的稳定性建设需要因地制宜，生搬硬套往往得不到好的效果。

货拉拉的技术稳定性体系建设也经历了重重坎坷，1.0体系初具成效最大的功劳在所有参与者共同努力，稳定性做得好一定是合力的结果。

未来，货拉拉技术稳定性建设会在当前“保无故障”的基础上继续朝着“减负”和“智能化”两个方向演进：通过更强的工具自动化能力，提高稳定性工作效率，减轻稳定性工作负担；通过专家经验沉淀和AI能力的引入，提高稳定性工作的质量，降低故障带来的影响，帮助货拉拉更好地提升用户体验、履行社会责任。

本篇文章来源于微信公众号：货拉拉技术