滴滴崩了18小时，事故危机谁买单
The following article is from 51CTO技术栈 Author 诺亚、云昭
第一时间收到文章更新
撰稿丨诺亚、云昭
“没想到月底了，竟然因为这个原因没了全勤……”
“滴滴崩了”成为昨天的热词。虽然滴滴于昨日早间发博表示网约车服务已恢复，但是依旧有不少用户反馈无法正常打车，只能选择别的平台或方式出行。
“技术人员因为出门打不到滴滴 无法及时到达工作岗位导致修复延迟。”
虽然网友们已经开始玩起了黑色幽默，但不得不深思的是，如此大规模的宕机事故为何历时一夜仍未恢复正常？
混乱一夜，对手爆单
综合各平台用户反馈看，此次滴滴App的崩溃是从前日晚间10点多开始的。
有司机接受采访时表示，在这次突发事件中，滴滴平台在接单、定位、计费等各环节均出现了问题。有乘客表示，7公里路程花了将近270元。
更有司机提到，接了一单距离为8公里的订单，收费显示1540元。计费系统的混乱可见一斑。
经过一夜抢修，在早高峰来临之际，滴滴发布微博表示“非常惭愧”，并更新了恢复情况。
滴滴称“经技术团队连夜修复，滴滴网约车等服务已恢复，用户可下载滴滴App使用打车服务。骑车等服务还在陆续修复中，所有可开锁或未关锁的青桔车辆均可免费骑行，希望能为缓解早高峰压力努力多做一点点。”
遗憾的是，对于早间出行的上班族来说，这次系统故障的影响仍在持续。时至昨天早上8点31分，依然有用户反馈：好不容易打上了车，司机还是无法点击确认“已接到乘客”，取消订单也取消不了，客服也联系不上。
在微博相关话题下，不少网友提到因滴滴崩溃影响了早上通勤。与此同时，除滴滴以外的多个出行平台，如高德、T3，出现了爆单现象。
据滴滴出行此前公布的2023年第三季度财报显示，单季度中国出行业务总交易额为725亿元，日均单量达到3130万单。如果将此次故障时长计算为12小时，估计将会让滴滴损失过千万的订单量和超4亿的交易额。
截至发稿，滴滴尚未对本次故障的具体原因作出说明。
天崩背后，原因难测
这不是滴滴第一次出现类似的问题，但可能是滴滴恢复耗时最长、影响最广的一次。
2022年9月22日，滴滴称“由于机房网络故障，导致滴滴部分服务受影响”。不到半天，经紧急修复后全面恢复。
2021年2月25日，由于“系统异常”，也出现了“部分订单服务无法使用的情况”。
更早可追溯到2015年10月8日，“滴滴深圳部分服务器遭遇技术故障”，部分地区出现无法叫车的情况。
可以看到，以往滴滴出现技术故障，基本可以在较短时间内解决，影响范围较小。相较之下，本次事件中，平台功能几乎全面瘫痪，仅网约车服务功能恢复时长近12小时。
鉴于滴滴尚未给出崩溃的根因，而目前披露的信息较少，所以出现了多方猜测。
有互联网从业者在社交平台爆料称，是滴滴系统半夜被攻击所致。“服务器没有物理隔离，物理攻击后台服务全挂，dc都上不去。”
隶属于不同板块的业务之间本应有隔离，但从表象上看，打车、共享单车等业务全崩了，据此有人推测，问题可能出在更加底层的基础设施。更有人指出，滴滴云可能就是此次系统崩盘的关键环节。
2017年11月，滴滴公有云，伴着“为开发者而生”的口号低调上线。然而这个愿景最终落空，今年滴滴云官方宣布，由于产品线调整，自2023年3月31日起不再对外提供公有云服务。
虽然不知道具体问题在哪里，但是有一点是明确的：云服务的不稳定性对于使用服务的企业杀伤力是巨大的。
阿里、滴滴事故频发的背后
如果说去年阿里云香港节点的崩溃，让大家认识到即便是技术巨头，也无法保证云产品的稳定性，意识到单一云厂商会给企业带来不小的风险，让多云部署+混合云部署的诉求再度上升。
那么今年11月12日阿里云产品的全线崩溃，则是让全国用户在对于日常高频使用的近乎垄断的App不再那么信任了。一点云服务上的配置不当，就会造成全国范围内的应用故障，轻则数据丢失，重则业务受损，代价非常昂贵。
然而，弹性扩容、异地多活、灾备这些故障防治措施预案，到底在故障发生时，能起到几分效果，能否真正支撑起N个9的高可用数字？又一次引起了人们的质疑。
再好的预案没演练过也只是预案。就像平时，很多公司都会声称我们的系统有备份能还原。实际上最后真的需要还原的时候发现，要么备份没成功，要么备份成功了但是数据陈旧，要么找到数据采集设备出故障了，总之无法还原。演练的缺失，导致相关人员对于故障场景缺乏应用的理解和认识。
针对各种故障场景下服务的容错能力、配置合理性、服务健壮性、监控告警实效性、定位与解决问题应急能力，也许只有在真实演练之后，这些名词才能真正经得起现实的考验，知道现有系统和线上服务的薄弱性。
“墨菲定律”告诉我们，永远不要心存侥幸，怕什么往往就会来什么。
而除了技术层面，此次滴滴事件还折射出了更深层次的问题。据脉脉一名滴滴员工声称，不止外部的App，就连滴滴内部的办公系统也瘫痪了。
这种自家系统故障当天不能修复的情况比较少见，不少声音都认为是“降本增效”导致的。有经验的技术人员在当下增速放缓的环境下，被企业砍掉，系统熵增的问题很难一时得到解决。
单纯的技术问题往往只是表象。正如航空业所提出的，一个事故的发生，往往是一系列事故链条的最终结果。关于人、关于组织和流程的问题，我们或许更应该深思。
大范围崩溃何时休
首先，要杜绝系统大范围故障，需要企业真正的重视和投入。业内流行这样一句话：面试造火箭，工作拧螺丝。面试筛选人才的时候问的问题都很高大上：如何保证系统的高可用，真到上岗干活的时候，往往由于许多原因并不会做出很多的设计和实现。
“有些业务会为了一点点性能，坚决不接入这些设计，怎么劝都没用。”
对于内部的安全放置、运维工作，不应该被视为负资产。今天系统的故障都是昨天买下的雷。
其次，企业对于应急响应机制需要高度重视，尤其在技术层面，不能应付了事。
针对可能出现的突发事件，要确保在发生问题时能够迅速响应、有效处置。
最后，做好事后分析，避免重蹈覆辙，两次踏进同一条错误的河流。崩溃的直接原因是什么，为什么，当时是如何应对的，如何降低此类事件再发的可能性或影响，如何使我们在此类事件中的沟通更有效。
写在最后：巨头担当，知耻而后勇
滴滴出行崩溃事件不仅仅是一家企业的问题，更反映了互联网企业在快速发展中普遍面临的挑战。作为行业巨头，滴滴在追求经济效益的同时，应充分履行社会责任。如何保护用户的数据安全？如何提供稳定可靠的服务？如何推动行业健康发展等等，都是亟待回答的问题。
无论是阿里云还是滴滴，大范围宕机后，都是牵一发而动全身。对于互联网企业而言，只有不断加强技术研发、优化服务体验、履行社会责任，才能持续赢得用户的信任和支持。
https://www.zhihu.com/question/632226716