11月29日，滴滴出行再就27日夜间系统故障致歉，提出了相应的补救措施和补偿方案。并公布了本次事故的初步调查结果：起因是底层系统软件发生故障，并非网传的“遭受攻击”。

同时，滴滴表示，当前所有服务已全部恢复，后续将深入开展技术风险隐患排查和升级工作，全面保障服务稳定性，尽最大努力避免类似事故再发生。

滴滴拥有庞大的业务线，其底层系统由复杂的软硬件构成，其中包括服务器、网络设备、数据库等等重要组成部分，任何一个环节出现故障，都有可能导致整个系统崩溃，用户无法正常使用服务。

然而，有网友对此提出质疑，表示“基础中台出问题，不太能接受，通常底层框架服务应该是最稳定的。”也有网传滴滴故障真实原因是：K8s版本升级错误，导致控制节点挂了……

更详细真实的故障复盘，我们也期待滴滴官方后续进一步的说明。

这次宕机持续近12个小时，算是滴滴近年来瘫痪时间最长的一次故障。据此，有媒体估计将会让滴滴损失过千万的订单量和超4亿的交易额。

而除了滴滴外，近期，阿里云在不到10天的时间里也出现了两次故障。

第一次是11月12日下午5点多，阿里云出现异常，随之“淘宝又崩了”“闲鱼崩了”“阿里云盘崩了”“钉钉崩了”等话题相继登上微博热搜。

原因是2023年11月12日17:44起，阿里云产品控制台访问及API调用出现出现使用异常，阿里云工程师正在紧急介入排查。当天晚上7点20左右恢复正常。

第二次同样发生在11月27日。阿里云声明称11月27日09:16起，阿里云监控发现北京、上海、杭州、深圳、青岛 、香港以及美东、美西地域的数据库产品（RDS、PolarDB、Redis等）的控制台和OpenAPI访问出现异常，实例运行不受影响。经过工程师紧急处理，访问异常问题已于当日10:58恢复。

还有一个月前。语雀（在线文档编辑与协同工具）发生服务器故障，在线文档和官网目前均无法打开。当日 15 时，语雀发布官方声明称，“目前因网络故障，出现无法访问的情况。此故障不会影响用户在语雀存储的数据，不会引起数据丢失，我们正在紧急恢复中，再次抱歉给你带来的损失。”

……

不断频发的宕机事件，警醒着大家：技术风险保障和高可用架构设计非常重要，确保数据备份、系统容错能力，如增加存储系统的异地灾备，实现快速恢复，并进行定期的容灾应急演练，缩小运维动作灰度范围。今后，我们也要加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生。

服务器宕机的原因五花八门，常见原因有：

除了以上原因，还要考虑天灾和极端情况的因素……

服务器宕机是个复杂的问题，可能受到多重因素的影响，背后的原因也比我们想象的复杂。

当然，宕机频发和长期的降本增效、大范围裁员同步出现，难免让人怀疑两者之间存在某种微妙的关联，不少人认为最近频繁的宕机或许和人员优化有关，得出人才缺失的结论。

不可否认的是，当前互联网大厂仍在疯狂砍预算，大规模裁员的信号在近两年从未消失。资深技术人员不仅业务水平有保障，可以更准确、快速识别系统漏洞，处理现场故障的经验更丰富，裁员引发的人员波动，资深技术人员流失，势必会产生一系列的影响。

而宕机是否和降本增效直接相关，是一个复杂的问题。