今天，我们从研发效能的视角聊一聊「滴滴崩了」。
01 近期事故回顾
2023年11月28日早7点，滴滴出行官方微博公告故障已恢复，内容如下：
从27日晚11点到28日早7点，滴滴崩了一夜，「滴滴崩了」话题冲上热搜，南方日报称，广州等地故障持续到更晚的时间，滴滴“崩了”接近12小时，损失千万订单量和超4亿成交额，这也是近年来滴滴出行瘫痪时间最长的一次故障[1]。
11月前后，语雀、阿里云、滴滴出行相继出现大故障[2]，为2023年的互联网行业大事记添上浓重的一笔。对于现象级的国民产品来说，大范围故障是很严重的事件，除了严重的经济和信誉损失外，还会造成各方面巨大的压力，包括舆论危机等等。
对于这些产品来说，稳定性就是业务，应该像做业务一样持续投入稳定性建设，这样才能更大程度地保障业务不受损，把故障扼杀在摇篮里。正如毕玄所说，做稳定性，难的不是技术，而是持续地投入，因为没有银弹，只能靠大量的细节来落地做好稳定性[3]。
技术上有代码层面、设计层面、变更层面很关键的一些指导思想，最难的是稳定性需要靠大量的细节工作落地，但是做这些事儿的人的产出很难被认可，做得好讲不出收益，因为系统本来就在好好地运转呢，做得不好，甚至出问题了，更是质疑你到底做了什么，也就导致没人长期做得下去。但是一旦不做了，停止投入了，风险就会逐渐累积，说不定哪天就爆发了。
02 研发效能视角看稳定性建设
那么我们从研发效能的角度来看一看，做好稳定性建设究竟要关注哪些要点呢？
1、内建质量
所谓内建质量，就是在开发过程中，要求软件生命周期之间参与的各个角色都需要实时地对软件的质量负责，确保软件在交付到下一环节前已经有了基础的质量保证。把整个软件质量的保障内嵌到开发的过程中去，而不是留到后面再去检测，因为越往后修复的成本越高。其核心目的就是减少因为质量问题导致的返工，而浪费大量人力成本。
内建质量的核心有两点：
1、团队的所有角色都要对最终质量负责，而不是质量团队；
2、问题尽早发现，这样修复成本更低。
内建质量的重要实践是设置质量门禁，确保软件交付到下一环节前通过了质量门禁，这样就有了基础的质量保障。比如，需求在正式开发前通过了团队各角色评审，代码开发前完成了技术方案评审，代码提测前经过了静态扫描、自测和代码检视，需求正式上线前通过了完善的功能测试、性能测试等等。这需要团队制定清晰的标准，标准达成了共识，并持续优化改进，团队严格按照标准执行。
为了团队更好的实施内建质量，需要做自动化，平台和工具支持团队方便地实施质量门禁，这样既能保障内建质量的实施效果，也能提升质量检查效率，保障内建质量切实落地实施。
2、低风险发布
据 Google SRE 统计，线上 70% 的故障都是由某种变更而触发的[4]，可见变更是导致服务故障的主要原因。当然，这些变更不仅仅是狭义的上线新版本代码，也包含配置变更，数据变更，操作系统变更，网络变更，基础设施变更等方面。在互联网各大公司都在追逐尽快抢占市场先机的今天，新版本代码的发布无疑要求更多更频繁，也因此有更大概率引发线上故障。
低风险发布是有效避免重大变更故障的重要手段，常见的低风险发布策略有：灰度发布（金丝雀发布）、蓝绿发布等。借助于云原生相关的基础设施，可以比较容易地实现低风险发布。
为了防范变更产生重大故障，我们可以采取强制核心服务，包括核心业务服务、鉴权认证等核心基础服务，采用低风险发布策略的措施，降低因核心服务故障导致业务大范围故障的风险。
3、完善的监控告警及响应预案
完善的监控必不可少，在发布的过程中、发布后都需要查看监控、日志相关数据和指标，一旦确认有问题，需要及时回滚止损。
线上故障处理的原则大多是：先止损、再查因。可以看下B站技术委员会的倡导：
监控发现的问题也要主动告警，告警需要分类分级，每一项严重告警都需要有标准的响应措施和处理流程。业务问题千万万，随时软件规模的扩大，监控、告警、响应需要持续地扎实地投入才能建设得比较好。业界好多公司的告警一塌糊涂，要么太多、噪声太大，要么发现不了问题，要么告警没有完善的响应流程，文档“年久失修”，缺少日常的预案演练，故障一旦发生，只能临场发挥了，解决效率可想而知。
此外，日常服务维护也需要定期对服务及相关组件、上下游依赖进行风险评估，每月、每周巡检核心服务是很有必要的，这样才能更早发现风险，及时修复，把问题扼杀在摇篮里。
这些需要大量的投入，绝非一朝一夕可以完成，需要从上到下建立安全生产的意识，才能取得更好的效果。
4、无问责复盘
以上讨论的都是如何避免故障、减少故障或事故范围，但是事故很难避免，出了事故也要端正对事故的态度，充分复盘，思考改进措施并落地，避免类似事故再次发生。
DevOps提倡的是无问责文化，在这种机制下，大家都会积极地思考问题根因，畅所欲言，而不是逃避，甚至隐瞒。在问责文化中，找到直接责任人是终点，但在无问责文化中，找到责任人只是起点，需要进一步探究为什么当事人会做出那样的决策，是环境、还是什么机制促使他当时做出了那样的选择，然后应该去着手推进机制或系统的变革。
举个丰田的例子，工厂车间地上漏了一大片油，常规的处理方式就是先清理地上的油，然后检查机器哪个部位漏油，换掉有问题的零件就好了。但是按照丰田的思路，会引导工程师继续追问：为什么地上会有油？因为机器漏油了。为什么机器会漏油？因为一个零件老化，磨损严重，导致漏油。为什么零件会磨损严重？因为质量不好。为什么要用质量不好的零件？因为采购成本低。为什么要控制采购成本？因为节省短期成本，是采购部门的绩效考核标准。你看，问了一系列的“为什么”，漏油的根本原因才找到了。所以对漏油事件的根本解决方案，其实是改变对采购部门的绩效考核标准，除了关注成本还要加强质量因素的比重，这样才能防止以后发生类似问题[5]。
通过连续追问为什么，能帮助我们找到问题的根因，当然，有时候拥有解决根因问题的能力或环境或许更重要。
5、关注、重视人的因素，提升员工幸福感
最后我要谈的一点是：关注、重视人的因素，提升员工的幸福感。
软件工作是一场脑力劳动，最终都是需要人来完成，需求规划、分析、方案设计、编码、测试用例设计、代码评审、上线前修改配置、上线过程中和上线后观察日志、操作回滚、故障定位解决、根因分析等等，涉及软件交付的全流程，无一都需要各种软件人员角色的深度参与。
即使我们完善了流程，做成了先进的平台工具帮助我们执行软件工作，总会有顾及不到的地方。工程师心情好了，思路敏捷，考虑周全，往往工作效率很高，软件质量又好。但是如果工作热情很低，大概率会直接影响软件的质量，造成线上稳定性事故就不足为奇了。
有这样一个比喻，或许你更能理解，软件交付的过程就像做菜，大厨给出了各类菜肴标准的配方和流程，但是厨师们真实操作的时候，可能还是会盐加多了、糖放少了、火候大了或者小了，最终做出来的菜品质可想而知，必然还是参差不齐。
软件交付的流程更加复杂，更是要充分发挥人的主观能动性，激发人，创造好的产品。
03 总结
我从研发效能的视角分析了如何避免或减少线上事故，提到了内建质量、低风险发布、监控告警及响应预案、无问责复盘机制等，最后强调了关注、重视人，提升员工幸福感的重要性。稳定性建设之路漫漫，持续投入、持续改进之路上需要不断求索。
参考链接：
[1] https://news.sina.com.cn/c/2023-11-28/doc-imzwcxcv6622948.shtml
[2] https://mp.weixin.qq.com/s/er6gGIV281tK5k7yO3XbYQ
[3] https://mp.weixin.qq.com/s/9rAhbG6lu-flNIGQEF5w0g
[5] https://www.merico.cn/blog/analyzing-the-system-fault-recovery-from-the-rd-efficiency