背景

稳定性建设需要一系列具体的建设活动推进和落地，这些建设活动涉及人员、机制和文化，全方位的建设活动才能更好地落实建设模式。

一、稳定性保障机制

稳定性涉及团队所有不同水平技术人员、所有系统、研发所有环节、线上时时刻刻，单个技术人员是无法保障好的，必须建立团队流程机制来可持续保障。

人为因素的根源一方面是专业能力不足，经验不足，另一方面很多都是无心之失，所以需要通过流程、规范来保住“底线”，减少人为因素导致的故障。大家严格遵守咱们的各种规范即可（CodeReview 规范、发布 xbp 流程、上线后 doublecheck 机制）。通过流程和 doublecheck 机制确保每个人发布不会太差，解决人的因素。永远要记住团队的力量是无穷的，要学会借力。

1、规范先行

稳定性关键还是要靠大家，如何靠大家呢？稳定性工作，规范先行.就是要落地一套稳定性的机制体系，用机制的严格执行来约束大家，不然无法展开。这套机制包括：

•方案评审机制：在完成系统的建设或改造方案初稿后，需通过由业务、技术、测试、运维领域组成的团队进行方案评审，才能进一步对方案进行实施。

•架构设计规范：概要设计、模块详细设计、API、Domain、数据缓存、容错设计、风险设计等。

•代码编写规范：规范覆盖代码基础、日志、配置、多线程、数据库、异常使用等多层面，提升代码质量；

•代码评审规范：changelist 描述、兼容性、性能、复杂性、团队评审文化等。

•代码提测规范：Test 单测、代码编译构建、系统运行稳定性等、

•代码测试规范：进入稳定性测试阶段，要严格审查系统是否达到测试准入条件，即满足测试实施的所有必要条件，如果未满足，则不开展稳定性测试。在稳定性测试实施结束后，严格检查所有测试准出条件是否满足，如：没有进行中的缺陷等，否则不予测试通过。

•预发 &引流压测规范：黄金链路必须进行 R2 引流验证。

•发布上线规范：可灰度、可验证、可回滚等

•验收规范： 业务、产品验收规范

•制定变更规范：提供变更级别、角色职责、活动阶段以及输入输出的详细规定

•制定运维操作规范：针对公司日志标准，提供统一的日志排查命令及规范。

•报警响应机制：针对运维相关的监控告警制定告警处理流程、告警升级机制

•值班及责任判定机制：设置值班制度，每天有技术人员负责值班，值班周期内的所有问题由值班人员治理，不能及时完成的，添加到 BUG 定期跟踪并统计。在出现生产事件后，由专家团队对该问题进行详细分析，确定问题的发生原因、解决办法后，对该问题进行问责，明确责任团队、责任人、责任承担比例等内容。避免在稳定性治理中产生“囚徒困境”。

•故障管理机制：故障管理机制包括规范管理故障响应流程、故障升级机制、故障复盘机制，规范技术人员在应对突发故障时的操作流程，明确职责边界，提升沟通效率，推动故障闭环，提升故障处理效率

2、开发和 SER 的区别

提到稳定性，先讲个概率 SRE（Site Reliability Engineering，站点可靠性/稳定性工程师）

一说到 Software Developer，人们脑子里就能反映出需求评审、编码、调试、测试、上线、修 bug 等具体工作内容。那 SRE 呢？SRE 与普通的开发工程师（Dev）不同，也与传统的运维工程师（Ops）不同，SRE 更接近是两者的结合，也就是 2008 年末提出的一个概念：DevOps，这个概念最近也越来越流行起来。SRE 模型是 Google 对 Dev+Ops 模型的一种实践和拓展（可以参考《Google 运维解密》一书），SRE 这个概念我比较喜欢，因为这个词不简单是两个概念的叠加，而是一种对系统稳定性、高可用、团队持续迭代和持续建设的体系化解决方案；

都是做技术的，很多开发刚刚转向稳定性方面时，有些弯转不过来。 举个例子：对于“问题”，传统的开发人员更多的倾向于是“bug/错误”，而 SRE 倾向于是一种“风险/故障”，所以，两者对“问题”的处理方法是不一样的：

•开发：了解业务 -> 定位问题 -> 排查问题 -> 解决问题

•SRE：了解业务归属 -> 快速定位问题范围 -> 协调相关人投入排查 -> 评估影响面 -> 决策恢复手段

可见，开发人员面对问题，会首先尝试去探究根因，研究解决方案；而 SRE 人员首先是评估影响，快速定位，快速止损恢复。目标和侧重点的不同，造成了 SRE 思考问题的特殊性。

所以，成为一名 SRE，就一定要从态度和方式上进行转变，切换到一个“团队稳定性负责人”的角度上去思考问题。

3、谈谈个人对 SRE 的几点要求

1.责任心、细心、耐心。

1.负责任是第一要素，主动承担，对报警、工单、线上问题、风险主动响应，不怕吃苦；一个不负责任的人，遇到问题与我无关的人，边界感太强的人，难以做好稳定性的工作；

2.及时、快速的响应，这是最关键的一点，作为一个 SRE，能够及时、快速的响应是第一要务，遇到报警、工单、线上问题，能够第一时间冲上去，不要去问是不是自己的，而是要问这个事情的影响是什么，有没有坑，有没有需要优化的风险？

3.主动走到最前面、主动想优化的办法、主动出头解决问题、主动挖掘系统风险薄弱点。

2.不能只做当下，要看到未来的风险，善于总结。

3.把机制建立好，切实落地。作为一个 SRE，想做到“不出问题”这个基线，关键还是要靠大家。

二、稳定性建设方向

1、地基要打牢

稳定性建设工作重在预防，根据多年的工作经验，至少 70%的线上故障都可以通过预防工作来消除。因此，在日常工作中，我们需要投入相应的精力来进行根基建设。所谓的根基建设，就是要把开发、测试和上线这三大流程做到透彻。包括：DesignReview、CodeReview、提测流程、上线流程、引流验证、性能测试等。

2、工作在日常

俗话说养兵一日，用兵一时。稳定性工作不是一蹴而就，而是日常的点点滴滴，一步一个脚印走出来的。

需要团队人人参与、持续完善监控告警、检查每一个告警是否配置、及时消灭线上小隐患。可参考每周的稳定性会议。

•梳理： 主动梳理团队的业务时序、核心链路流程、流量地图、依赖风险，通过这个过程明确链路风险，流量水位，时序冗余；

•技术债务治理： 主动组织技术债务的风险治理，将梳理出来的风险，以专项的形式治理掉，防患于未然。但需要注意别由于治理而导致线上问题，需要加强引流验证比对。

•演练： 把风险化成攻击，在没有故障时制造一些可控的故障点，通过演练来提高大家响应的能力和对风险点的认知。

•报警： 除了前面说过的主动响应之外，还要经常做报警保险和机制调整，保证报警的准确度和大家对报警的敏感度。同时也要做到不疏忽任何一个点，因为疏忽的点，就可能导致问题。

3、预案是关键

我们需要认识到预案的重要性，并投入相应的精力来进行预案的制定和更新。这样，我们才能更好地应对各种突发情况，保障项目的顺利进行。通过每周的稳定性去深入挖掘每个接口的隐患及不足，比如业务指标是否加上、业务指标是否能真实反馈该接口的特性等。

4、大促特殊场景

系统在大促的稳定性和日常稳定性的区别在哪呢？个人理解核心是两点：

1、 【技术】高并发流量：大促流量峰值是日常的 N 倍（几十、几百倍），需要具备更高的并发流量处理能力，以保证系统的稳定性这方面。针对这评估好流量，做好容量规划即可。

2、 【业务】业务场景多样化：大促会增加很多日常用不到的场景，很明显的比如预售场景、Promise 特殊时效控制、停运降级功能等。针对日常不用，大促才用的功能点。可整理功能点，在大促前 1 个月模拟大促，业务进行相关功能配置，演练全流程，类似每年大促都进行的预售场景演练。因为每年需求都在迭代增加，难免会影响之前的功能点。这样就可避免大促期间突然使用功能发现不好用的问题

5、执行是王道

其实听复盘会学东西是一方面，最主要是应该问问我们系统是不是也存在这种问题，我该怎么规避或解决这类风险问题，别人暴露的我也存在，应该第一时间去解决，而不是我知道但我不做。

三、前置：扁鹊三兄弟

与扁鹊三兄弟一样，如果想要让稳定性有价值，SRE 同学一定不能站到系统的屁股后面等着擦屁股，必须走到前面，看到未来的风险。

既要在发生问题时快速解决问题（做扁鹊）

也要把风险归纳总结，推动解决（做二哥）

还要在系统健康的时候评估链路，发现隐藏的问题（做大哥）；

1. 做扁鹊大哥：擅长的是“事前控制”，具有敏锐的洞察力和战略眼光，防患于未然，在系统健康时发现问题。2. 做扁鹊二哥：擅长的是“事中控制”，具有出手迅速、果断、干练的特点，在系统有隐患时发现问题。3. 做扁鹊：   擅长的是“事后控制”，是临危受命型的关键人物，在系统发生问题时快速解决问题。

根据《鶡冠子·卷下·世贤第十六》的记载，有一次，魏文王问扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢？”扁鹊回答说：“长兄最好，中兄次之，我最差。”魏文王又问：“那么为什么你最出名呢？”扁鹊回答说：“长兄治病，是治病于病情发作之前，由于一般人不知道他事先能铲除病因，所以他的名气无法传出去；中兄治病，是治病于病情初起时，一般人以为他只能治轻微的小病，所以他的名气只及本乡里；而我是治病于病情严重之时，一般人都看到我在经脉上穿针管放血，在皮肤上敷药等大手术，所以以为我的医术高明，名气因此响遍全国。”

参考：

公众号普惠出行产品技术：https://mp.weixin.qq.com/s/R2qBQgJCueErBL35ld4KZQ