众所周知，业务高峰带来的流量大幅增加会对系统造成巨大的压力和风险，就像消防局在火灾高发期需要加强火灾风险关注一样，货拉拉也需要在高风险时段投入更多资源识别和解决问题。而业务高峰通常还具备一些特殊意义，往往伴随着公司业务目标的达成，如单日订单破峰。如果因为系统故障导致目标未达成，影响也会非常恶劣。当前货拉拉会经历各种业务高峰场景，像新业务开城放量、优惠权益秒杀、节前货运需求激增等等，都要求系统具备高度稳定性和抗风险能力。

自2020年下半年起，货拉拉开始系统化地进行业务高峰保障，经过三年多努力，技术团队累计发起34次业务高峰保障，且自2021年以来连续三年多在业务高峰期间保持零故障记录。接下来我将与大家分享在此过程中积累的实践心得和思路。

对于业务高峰稳定性保障，毫无疑问，我们最重要的目标是确保期间不发生任何系统故障。除此之外，要与业务部门充分沟通，对齐要保障的具体业务目标。比如，确定用户下单指标的具体目标数值是多少，100万还是200万。如果业务目标单量过于夸张，比如相比日常增长100倍，那技术团队肯定需要提前评估这一目标的可行性和成本。这样，我们才能向业务部门提供准确信息，帮助他们做出合理决策。

除了上述目标之外，技术内部也有一些关键过程指标，比如系统的SLA表现、线上问题的应急处理时效等。

最后，难度较大的目标还是关于成本的目标管理，在发展初期，稳定性保障往往需要较大的投入，成本管理也是较容易被忽视的点。这方面需要思考的主要问题，一个是我们在进行保障工作的过程中，人效是否能有所提高；其次，在相同增长规模下，服务器资源的单位投入是否有所降低：举例来说，如果之前业务高峰时，需要投入50万的服务器成本，那么下一次同样的单量增长情况下，投入的资源成本是不是能比之前要少？

定好目标之后，就需要从项目管理的视角出发，来审视和规划后续的工作。

我们先来看下业务高峰保障的特点。稳定性保障项目相比一般项目来说，参与的人数更多，涉及的部门跨度也更大。而且，业务高峰保障通常是一个不能延期的项目——有些业务开城或许可以适当延期，但像双11这样的大型促销活动，以及货拉拉随着市场需求增加而面临的高峰，是不可能推迟的。因此，保障项目组在整个过程中扮演着至关重要的角色。相比攻克技术难题，如何组织不同职能的人员共同达成目标可能更具挑战性。    

可以通过以下这些措施，确保项目管理视角下的保障工作有效开展。

从技术视角来看，整个业务高峰保障流程的核心是风险管理，从风险识别到风险消除，确保没有遗漏的风险点，并为每个已识别的风险制定解决方案。

在主体层面，可以将风险分为三个主要部分：公司内部、外部使用者、三方依赖。根据稳定性保障的通用经验，风险类别又可大致分为——容量风险、变更风险、链路风险、人员风险。结合风险类别和风险主体，可以构建起整个技术保障的框架。    

1）云商重保

三方依赖这里，我将就云服务商的保障重点展开分享，因为云商的稳定性对完全上云的业务系统是至关重要的。    

最后再次回顾下整个保障思路中的两个重点内容。

1）项目组织

①PMO 参与

必须高度重视项目组织工作。就像修建高楼需要各个工种通力合作一样，项目的顺利进行也需要专业的PMO人员。在货拉拉，有专业的PMO团队负责整体项目的组织与协调，确保项目按计划推进并统筹解决实施过程中的各种问题。

②部门接口人机制

由于项目涉及的人员众多，可采用接口人机制。项目组与各部门接口人对齐，再由接口人与部门内部的具体实施者对接。这样可以有效降低保障工作的复杂度，明确责任分工，提升沟通效率，确保信息准确传递和任务顺利执行。

③固定会议把控进度

确保项目例会制度严格执行，以把控整体项目进展。通过定期例会，各部门可以及时沟通任务进展、分享工作经验、暴露过程风险、提出诉求、协调资源配置等等，确保项目按计划高质量推进。

2）系统容量

另一个重点，作为系统工程师，在高峰来临前应当特别重视系统容量风险。业务高峰意味着流量的增加，如果系统健壮性不足，可能还有容错空间，但如果容量不足，问题一定会发生。在容量方面，应当关注以下几点：

①打好提前量

不论是三方容量还是云商资源，如果这一点有疏漏，当紧急需要资源时，将无计可施，大概率要牺牲业务或用户体验。    

②关注爬坡阶段

与秒杀场景不同，货拉拉的业务高峰在高峰当日会有一个缓慢的爬坡过程。在这段黄金时间内密切关注系统表现，迅速发现并解决短板容量问题，可以大幅降低故障发生的概率。

③为最坏的情况做好打算

如果容量保障做得不够好，出了问题，需要准备保大舍小，部分用户可使用总比所有用户都不能使用要好得多。例如，是否可以将流量做进一步限制，以确保系统容量水位健康，或者根据前期准备进行必要的业务功能降级。哪怕业务因为降级而减半或者用户体验大幅受损，也比完全崩溃要好。

首先，站在巨人的肩膀上，借鉴他人成功经验。如果完全靠自己摸索，效率会非常低。

其次，有意识做好本土化工作。因为从他人那里学来的知识或方法，不一定完全适用于自己的情况。

第三，必须不断优化。要通过不断复盘和优化，确保每次都比上一次做得更好。

最后，保持激情至关重要。采用一些运营手段来激发团队的激情。相比简单地下达指令验收执行效果，我们更倾向于激发大家的主动意识。所有人自发地为即将到来的业务高峰考虑要做什么，能带来更好的结果。    

1）如何站在巨人的肩膀上？

我之前在阿里本地生活有几年工作经验，因此借鉴了阿里双11大促的保障经验，快速建立起了货拉拉业务高峰保障的初步方案。这样做的好处是，确保了整个保障工作覆盖的颗粒度足够细致。阿里的保障经验已经经过了大量优化改良和实践检验，可以有效避免重复别人已经踩过的坑。

货拉拉在业务稳定性保障发展初期只提供了一些高峰保障的待办事项列表，对问题的认知不够全面。现在已经有了一套完整的保障框架体系，主要围绕风险预防和应急快恢两大主题开展。

2）如何做本土化改善？

我们在实践过程中发现，按照最初的一套方案执行后，有些保障手段在货拉拉的收益并不大，同时存在可能还没有关注到一些风险。因为相比电商大促，货拉拉作为一个订单撮合平台，更关心供需特征订单匹配。

展开说一下。业务高峰时，需求量通常比供给量要多很多。用户下单量增长迅猛，但能够承接的订单的司机数量不会一下子增加，甚至还可能减少，比如在五一前，有些司机可能选择休假。这种运力不足的情况非常明显，直接导致系统里待配对的订单越来越多。

对于待配对的订单，我们的系统会有一些既有策略。例如，如果一个订单发布后没有人接单，系统会扩大搜索范围，比如从10公里扩大到20公里，从而圈选到更多的司机重复推送这个订单（实际策略要复杂很多）。所以在业务高峰运力不足场景下，系统的压力增长是非常恐怖的，单纯依靠扩容代价太大。    

因此，我们将保障重心调整到了整个订单调度系统的稳定性保障上。在研发团队出色完成架构优化的基础上，结合着相关场景降级预案的梳理和演练，比如最严重的情况下可以完全关闭重推逻辑以降低系统负载，现在我们面对这种场景具备非常充足的信心。

1）时空维度上的策划（宏观视角）

首先，我们会进行一个宏观视角上的策划。这个策划工作主要是在年初时，就会列出全年会遇到的业务高峰和重大事件的时间表。这样做的好处是，全年的保障工作计划都能心中有数，能够提前规划好在大概什么时间需要开展哪个业务高峰的保障工作，并给出消息提醒，避免遗漏。

图1 - 货拉拉全年大事件一览表

其次，所有保障工作都会进行文档沉淀，将相关信息统一存放在一个共享空间中，方便查阅。

图2 - 货拉拉高峰保障文档空间

2）项目视角下的管理（执行落地）

从项目管理的视角出发，确保整个保障团队的构成清晰明确。我们需要知道每个领域的接口人和负责人是谁，他们主要负责哪些内容，以及整个领域的协作成员包括哪些人。    

图1 - 业务高峰保障组织

在明确了团队成员和责任分配之后，我们会和各领域团队成员进行沟通，商讨制定保障方案，并进行KO会议。在会议中，我们会收集大家的反馈，看看方案中有哪些地方需要补充或改进。

图2 - 业务高峰保障方案框架

随后，PMO会设立一个项目进度看板，用来跟进整个项目的进度和完成情况。

图3 - 业务高峰保障项目进度看板

3）组织运营提振士气

高峰当日，我们会有一个被称为“小黑屋”的作战室。在这里，会确定关键人员的名单、时间安排，以及一些物资的准备工作。这些准备工作包括为团队成员安排下午茶等福利，以确保他们在紧张的工作中也能得到适当的休息和营养补充。

其次，在保障工作结束后，我们也会注重仪式感。PMO会提前准备一些物料，比如横幅、KT板等，组织大家一起进行合影留念。这样的活动不仅能够增强团队的凝聚力，也能让团队成员对参与高压力工作的辛苦付出有一个难忘的回忆。

4）复盘总结更进一步

在业务高峰过后，第一件事就是开展全面的复盘总结工作。

首先，我们会回顾目标达成情况。

接下来，我们会进行两个重要分析：

①对每一个保障子项进行深入分析。检查保障的目标是否达成，以及在治理过程中是否存在可以后续优化的点。

②收集复盘参与方的反馈和建议，帮助我们识别出后续改进项。这些改进项将被跟踪并反馈到下一次的保障工作中。

5）踩过的一些坑

货拉拉在业务高峰保障过程中，也遇到了一些教训——

只关注研发服务发布配置变更，结果因为其他领域的变更出了问题。之前在封网前只关注了研发自己服务的发布和配置变更。但问题却出在了其他领域的变更上，比如运营的一些配置变更，或者是业务上的AB实验变更，包括安全策略等的变更。后续我们把这类变更也被纳入了整个保障范围。

有个服务和业务流量负相关，结果出现在了待扩容名单里。我们在容量管理方面一直做得还不错，但在成本控制方面，确实也经历了一些摸索。比如有一个服务实际上与业务流量负相关，即业务单量越多，它的压力反而越小。这个服务和订单热力图有关，而订单热力图的作用是告诉司机哪里更容易接到订单。但在业务高峰时，司机其实并不缺单子，因此对热力图的访问量并不大。后来，我们对这类服务实施了更精细化的管理。

缩容的时候没有精打细算，如果缩掉特定的服务器，能更省钱。在缩容时，需要注意的不仅仅是扩容后的机器要缩容回来，更重要的是要思考缩容哪些机器才能更节省成本。因为扩容时扩的是新机器，但缩容时，并不一定非得缩容这些新扩的机器，而是可以选择已经在使用中的机器。这样做会涉及到一些成本计算规则，能够帮助节省更多的成本。在这方面，我们有专业的云成本团队来帮助我们进行管控。

经过2020年至今3年多时间的建设，货拉拉已经具备了非常成熟的业务高峰保障能力。截至目前，货拉拉技术稳定性团队已累计发起34次业务高峰保障；且2021年至今，货拉拉业务高峰期间已连续3年保持0故障水平。同时，业务高峰保障也帮助强化了日常稳定性水平，货拉拉全年故障数也在逐年下降。

图 - 货拉拉全年故障数逐年下降

未来的目标之一是逃不掉的降本增效，我们主要关注两方面的成本——

1）资源成本。各系统扩容资源的精细化管理；极致把控服务器资源使用天数，明确资源回收对象；

2）人力成本。加强各保障工作的工具化能力；关注多平台间的联动，打造流水线式的稳定性保障产品生态。

另一个目标是实现高峰保障的日常化。每次高峰保障都是对整体技术稳定性的一次加固，也是对日常治理工作的一次反哺。未来在提效的基础上，应该把风险识别风险治理手段放到每一天来做，自然可以极大提高全年系统稳定性水平。