“没想到月底了，竟然因为这个原因没了全勤……”

“滴滴崩了”成为昨夜今晨的热词。虽然滴滴于今日早间发博表示网约车服务已恢复，但是依旧有不少用户反馈无法正常打车，只能选择别的平台或方式出行。

“技术人员因为出门打不到滴滴 无法及时到达工作岗位导致修复延迟。”

虽然网友们已经开始玩起了黑色幽默，但不得不深思的是，如此大规模的宕机事故为何历时一夜仍未恢复正常？

1、混乱一夜，对手爆单

综合各平台用户反馈看，此次滴滴App的崩溃是从昨日晚间10点多开始的。

有司机接受采访时表示，在这次突发事件中，滴滴平台在接单、定位、计费等各环节均出现了问题。有乘客表示，7公里路程花了将近270元。

更有司机提到，接了一单距离为8公里的订单，收费显示1540元。计费系统的混乱可见一斑。

经过一夜抢修，在早高峰来临之际，滴滴发布微博表示“非常惭愧”，并更新了恢复情况。

滴滴称“经技术团队连夜修复，滴滴网约车等服务已恢复，用户可下载滴滴App使用打车服务。骑车等服务还在陆续修复中，所有可开锁或未关锁的青桔车辆均可免费骑行，希望能为缓解早高峰压力努力多做一点点。”

遗憾的是，对于早间出行的上班族来说，这次系统故障的影响仍在持续。时至今天早上8点31分，依然有用户反馈：好不容易打上了车，司机还是无法点击确认“已接到乘客”，取消订单也取消不了，客服也联系不上。

在微博相关话题下，不少网友提到因滴滴崩溃影响了早上通勤。与此同时，除滴滴以外的多个出行平台，如高德、T3，出现了爆单现象。

据滴滴出行此前公布的2023年第三季度财报显示，单季度中国出行业务总交易额为725亿元，日均单量达到3130万单。如果将此次故障时长计算为12小时，估计将会让滴滴损失过千万的订单量和超4亿的交易额。

截至发稿，滴滴尚未对本次故障的具体原因作出说明。

2、天崩背后，原因难测

这不是滴滴第一次出现类似的问题，但可能是滴滴恢复耗时最长、影响最广的一次。

2022年9月22日，滴滴称“由于机房网络故障，导致滴滴部分服务受影响”。不到半天，经紧急修复后全面恢复。

2021年2月25日，由于“系统异常”，也出现了“部分订单服务无法使用的情况”。

更早可追溯到2015年10月8日，“滴滴深圳部分服务器遭遇技术故障”，部分地区出现无法叫车的情况。

可以看到，以往滴滴出现技术故障，基本可以在较短时间内解决，影响范围较小。相较之下，本次事件中，平台功能几乎全面瘫痪，仅网约车服务功能恢复时长近12小时。

鉴于滴滴尚未给出崩溃的根因，而目前披露的信息较少，所以出现了多方猜测。

有互联网从业者在社交平台爆料称，是滴滴系统半夜被攻击所致。“服务器没有物理隔离，物理攻击后台服务全挂，dc都上不去。”

隶属于不同板块的业务之间本应有隔离，但从表象上看，打车、共享单车等业务全崩了，据此有人推测，问题可能出在更加底层的基础设施。更有人指出，滴滴云可能就是此次系统崩盘的关键环节。

2017年11月，滴滴公有云，伴着“为开发者而生”的口号低调上线。然而这个愿景最终落空，今年滴滴云官方宣布，由于产品线调整，自2023年3月31日起不再对外提供公有云服务。

虽然不知道具体问题在哪里，但是有一点是明确的：云服务的不稳定性对于使用服务的企业杀伤力是巨大的。

3、阿里、滴滴事故频发的背后

如果说去年阿里云香港节点的崩溃，让大家认识到即便是技术巨头，也无法保证云产品的稳定性，意识到单一云厂商会给企业带来不小的风险，让多云部署+混合云部署的诉求再度上升。

那么今年11月12日阿里云产品的全线崩溃，则是让全国用户在对于日常高频使用的近乎垄断的App不再那么信任了。一点云服务上的配置不当，就会造成全国范围内的应用故障，轻则数据丢失，重则业务受损，代价非常昂贵。

然而，弹性扩容、异地多活、灾备这些故障防治措施预案，到底在故障发生时，能起到几分效果，能否真正支撑起N个9的高可用数字？又一次引起了人们的质疑。

再好的预案没演练过也只是预案。就像平时，很多公司都会声称我们的系统有备份能还原。实际上最后真的需要还原的时候发现，要么备份没成功，要么备份成功了但是数据陈旧，要么找到数据采集设备出故障了，总之无法还原。演练的缺失，导致相关人员对于故障场景缺乏应用的理解和认识。

针对各种故障场景下服务的容错能力、配置合理性、服务健壮性、监控告警实效性、定位与解决问题应急能力，也许只有在真实演练之后，这些名词才能真正经得起现实的考验，知道现有系统和线上服务的薄弱性。

“墨菲定律”告诉我们，永远不要心存侥幸，怕什么往往就会来什么。

而除了技术层面，此次滴滴事件还折射出了更深层次的问题。据脉脉一名滴滴员工声称，不止外部的App，就连滴滴内部的办公系统也瘫痪了。

这种自家系统故障当天不能修复的情况比较少见，不少声音都认为是“降本增效”导致的。有经验的技术人员在当下增速放缓的环境下，被企业砍掉，系统熵增的问题很难一时得到解决。

单纯的技术问题往往只是表象。正如航空业所提出的，一个事故的发生，往往是一系列事故链条的最终结果。关于人、关于组织和流程的问题，我们或许更应该深思。

4、大范围崩溃何时休

首先，要杜绝系统大范围故障，需要企业真正的重视和投入。业内流行这样一句话：面试造火箭，工作拧螺丝。面试筛选人才的时候问的问题都很高大上：如何保证系统的高可用，真到上岗干活的时候，往往由于许多原因并不会做出很多的设计和实现。

“有些业务会为了一点点性能，坚决不接入这些设计，怎么劝都没用。”

对于内部的安全放置、运维工作，不应该被视为负资产。今天系统的故障都是昨天买下的雷。

其次，企业对于应急响应机制需要高度重视，尤其在技术层面，不能应付了事。

针对可能出现的突发事件，要确保在发生问题时能够迅速响应、有效处置。

最后，做好事后分析，避免重蹈覆辙，两次踏进同一条错误的河流。崩溃的直接原因是什么，为什么，当时是如何应对的，如何降低此类事件再发的可能性或影响，如何使我们在此类事件中的沟通更有效。

5、写在最后：巨头担当，知耻而后勇

滴滴出行崩溃事件不仅仅是一家企业的问题，更反映了互联网企业在快速发展中普遍面临的挑战。作为行业巨头，滴滴在追求经济效益的同时，应充分履行社会责任。如何保护用户的数据安全？如何提供稳定可靠的服务？如何推动行业健康发展等等，都是亟待回答的问题。无论是阿里云还是滴滴，大范围宕机后，都是牵一发而动全身。对于互联网企业而言，只有不断加强技术研发、优化服务体验、履行社会责任，才能持续赢得用户的信任和支持。