崩了 36 小时，滴滴：系底层系统软件故障，现所有服务已恢复！

整理 | 苏宓

出品 | CSDN（ID：CSDNnews）

这两天，无数打工人打开滴滴打车软件发现：网络加载异常，本以为是个人的网络问题，然而，当涌进微博、朋友圈等社交媒体平台时，发现自己绝非个例，这才意识到这款占全国网约车市场 75% 以上的滴滴软件出了 Bug。

而后本想扫个青桔单车换个方式出行之际，发现同样出自滴滴的共享单车也依然扫不了码，甚至早一步发现“端倪”的众多用户早已把美团、哈啰单车也骑没了......

紧接着，#滴滴崩了#、因迟到而导致的 #全勤奖没了#等相关词条相继出现在热搜榜单，一时之间，各种口诛笔伐，滴滴成为众矢之的。

这样的宕机事件，足以从滴滴连续三天发了三条致歉声明中就足以知晓事件的严重性。就在今天在 11 月 29 日，滴滴宕机发生的近 36 个小时后，其才正式宣布：目前，滴滴 App 的所有服务已经全部恢复。

滴滴崩了的 36 小时，信息时代的乱象

根据 11 月初，滴滴发布的 2023 年第三季度业绩报告显示，滴滴三季度核心平台总单量达到 35.79 亿单，同比增长 34%。其中，中国出行总单量为 28.78 亿单，同比增长 32%，意味着中国出行三季度日均单量达到 3130 万单，突破单季度历史峰值。

数字经济时代，如此体量的 App 一时崩溃，带来的影响必然是巨大的，也正如网友所评价的，「滴滴作为媒介已经渗入了大众生活的方方面面，滴滴崩了，但不止于崩了如此简单」。

而一切的混乱是从 11 月 27 晚间开始的。

彼时据澎湃新闻报道，有网友称，使用滴滴叫网约车后，迟迟等不来车，App 也无法使用，司机更是不知道用户在哪里。

还有司机反馈，「正在送乘客途中，出现导航无法使用，地图无法加载等情况」。

虽然当时滴滴反应迅速，在第一时间便发布了公告来安抚用户：

“滴滴出行后来发布公告，由于系统故障，晚间滴滴 App 服务出现异常，经技术同学紧急修复，目前正陆续恢复中。无法锁车的骑行用户无需原地等待，到达终点无法结账的乘客可正常下车回家，无需担忧因故障造成的车费问题，请大家耐心等待后续通知，后续都会妥善处理。”

但是在用户的「一个滴滴的程序员，如果没法远程工作，要回办公室紧急处理，又打不到车，他会用____平台打车？」反问声中，一夜之后，迎来次日流量更大的早高峰时，滴滴网约车功能并未恢复使用，依然显示网络加载异常。

当时，此次宕机事件已经波及上海、北京、广州等全国多地的用户。

据第一财经报道，从员工的各方反馈看，此次滴滴系统崩溃属于全面瘫痪。不仅用户端无法正常使用，司机端以及滴滴内网同样出现了问题。

打开滴滴网站时，会报「502」错误：

有网友表示：“我打车打不到，好不容易打到了司机接上我了，结果司机点’已接到乘客‘点击不了，我都到目的地了他还没点击成功，最后我单独微信付了钱给他，然后我取消滴滴订单还取消不了，找客服也是一堆代码。”

还有司机称：

• “我可以提现，只是好久了，一直没有到账。不过有的司机说到账了，只是时间都不一样。”

• 接了一单距离为 8 公里的订单，收费显示 1540 元。

甚至有网友吐槽：「我被错误地派单到了距离两千公里以外的地方」。

随着事件愈演愈烈，滴滴紧接着发布第二封致歉信：”经技术团队连夜修复，滴滴网约车等服务已恢复，用户可下载滴滴 App 使用打车服务。骑车等服务还在陆续修复中，所有可开锁或未关锁的青桔车辆均可免费骑行，希望能为缓解早高峰压力努力多做一点点。“

对于滴滴而言，这样一次大范围的宕机还是极为罕见的。

有媒体预估，根据此次「崩了」的故障时长计算，估计将会让滴滴损失过千万的订单量和超 4 亿的交易额。

滴滴再次致歉：底层系统软件发生故障

回看过往，滴滴发生宕机事件并不在少数。近三年间，滴滴发生过四次故障：

• 2020 年 9 月，多地用户使用滴滴出行打车时，出现网络故障的提示。后来滴滴只是回应称：技术故障已修复。

• 2021 年 2 月、3 月，滴滴再次出现打不了车、发布的行程也看不见、司机接到人后开启不了订单、司机无法结束订单等多种异常情况。

• 2022 年 9 月 22 日，滴滴出行官方微博致歉称由于机房网络故障，导致滴滴部分服务受影响。

过往的 Bug 修复时间很快便可完成，只是这一次耗费的时间之久也超乎众人想象。

而就在外界猜测滴滴此次故障到底是因为遭到了 DDoS 攻击，还是由于基础设施层升级出现问题时，滴滴首次向外界首次披露了宕机的原因：

初步确定，这起事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”，后续我们将深入开展技术风险隐患排查和升级工作，全面保障服务稳定性，尽最大努力避免类似事故再发生。

底层系统软件故障如何降低宕机事件的发生？

事实上，所谓底层系统软件，是指操作系统、驱动程序和其他核心组件，它们负责管理硬件资源、提供基本的功能和接口，以及支持其他应用程序的运行。发生故障可能包含软件错误、驱动程序问题、系统配置错误、硬件故障等。

当底层系统软件发生故障时，会导致设备、App 无法正常工作或无法执行特定的任务，这可能包括系统崩溃、应用程序崩溃、设备无响应、错误消息的出现等现象，也就是此次滴滴无论是网约车还是共享单车都出现了问题。

当然，具体是哪一块的问题，还需要滴滴自己进一步的复盘审查。而这次的底层系统软件发生故障的原因，也有媒体分析称或与滴滴企业内部人员优化有关。

有微博用户评论道，「这种事故会越来越多...原因不是在于裁人裁出问题了，而是经济上行阶段都有冗余，为了迎接随时爆发的订单，上行阶段要维持负载的上限不能过大，比如平时 70%（数字仅仅用作举例），这样遇到一个小爆发不用担心会出问题，足以应对小高峰，但是下行期的逻辑就不同了，负载很高的时候抗一抗就行了，虽然后面遇到小高峰可能会难受，但是随着时间的推移总体负载会下降，所以。。。」

站在企业内部面向基础设施的运营与维护，工程师究竟该怎么做？基于此，我们也采访了几位开发者的看法。

对此，蚂蚁集团高级工程师明明如月表示，「大型互联网公司出问题短时间无法解决，通常都是底层软件变动或者硬件故障。特点是难以快速定位和快速解决问题。对于底层软件变动，应该慎之又慎，每次变动应该做好评估，并且有可能进行“灰度”验证，重视底层软件的故障发现机制。另外，现在互联网公司上层应用的高可用做得挺完善，底层应用的高可用似乎做得并不好，也应该有类似的机制。」

资深开发者苏洋（https://github.com/soulteary）认为：

“在大公司做基础设施的工程师，相比做’主要赚钱业务‘的工程师收入相对较少，公司不论是物质资源、战略重视度倾斜都更偏业务。这块和安全部门在大公司的境遇类似，出了事儿，才能被证明价值，才会被人想起来。

其实，做 infra 的工程师的人数和平均水平线也相对不占优势，曾经做 infra 的朋友打趣戏虐的说，‘好人’谁做基础设施，但其实做基础设施的工程师要求往往比做业务的要更难。

此外，考虑降本增效，大家往往会对资源本就不充沛的部门进一步压缩成本。

infra 这类成本部门中的成本部门，往往会无限制的要求效能提升，也对做好底层系统稳定性有影响。希望‘降本增笑、开猿节流’的地狱笑话，慢慢不会再流通了。」

最后对于此次事件带来的广泛影响，截至目前，滴滴也非常有诚意地为所有用户准备了 1 张 10 元打车立减券用于致歉补偿，话说，你领到了吗？