移动智能时代，每天依赖的平台却突然“失智”，怎么办？

11月27日晚间，移动出行平台滴滴因系统故障导致App服务异常，不显示定位且无法打车。在全国多地，不少晚归的打工人和司机困在了路上。

11月28日凌晨，“滴滴崩了”相关话题登上微博热搜，多个用户表示滴滴App无法正常使用。对此滴滴紧急回应称“由于系统故障，27日晚间滴滴App服务出现异常，经技术同学紧急修复，目前正陆续恢复中”。

经过一夜修复，用户发现青桔出行的自行车仍然无法扫码。从用户反馈看，11月27日晚间10点多起，陆续有用户反馈无法使用滴滴旗下相关App，滴滴抢修超过了9小时。

在11月28日早间，虽然滴滴表示网约车服务已恢复，但是不少用户早间在微博反馈仍然无法打车，只能选择其他平台出行。第一财经尝试发现，早晨8时左右滴滴网约车已经恢复定位功能，但是下单时显示“发单失败”。截至上午9时许，滴滴北京地区打车功能已恢复。

对于滴滴系统长时间崩溃的具体原因，滴滴官方并未给出明确解释。有业内人士表示，出问题的应该是滴滴自己的互联网数据中心（IDC），这种事故也会加速滴滴全部上云的步伐。从过往情况看，滴滴崩溃多是因为机房网络故障等原因，不过故障当天都能修好，本次故障维修时长或是滴滴历次故障之最。

早高峰其他平台爆单

从司机反馈看，此次滴滴平台在接单、定位、计费等环节上都出现了问题。

有网约车司机对第一财经表示，27日晚App崩溃时刚好在接单，“从晚上10点20分开始什么都做不了，客服电话也进不了线。目前恢复了少部分功能，但不能正常使用，很多错单乱单，还出现了多位司机接同一单的现象。”

经过一夜维修，滴滴司机表示早上仍然没有恢复。“目前无法使用，所以司机都在说，接到订单时有听单声音，但无显示，到达乘客位置又找不到乘客，接到乘客又无法结束订单等一大堆问题。”

截至28日9时，滴滴司机端的计费系统依然混乱。有司机表示，接了一单距离为8公里的订单，收费显示1540元。此外，小桔充电桩当时也依然无法充电。另有司机反馈，11月28日早间司机端页面依然一片空白。受此影响，上述司机对第一财经表示已回家休息。

用户方面，不少用户反馈滴滴系统的崩溃影响了早间出行。在微博相关话题下，多个用户表示因为网约车叫车和青桔扫码问题，导致上班迟到。此外，不少消费者受滴滴系统崩溃影响选择尝试其他平台，有消费者表示“因为滴滴用不了，第一次使用高德打车。”还有消费者表示“出门发现滴滴一直显示网络异常就打了T3，上车后司机给我展示他的T3群里都在大喊‘快起来跑车，爆单了’。”日常习惯使用其他出行App的用户发现平台28日的打车排队过长，有用户表示“早上用高德打车排队四十几个，平时就一两个”。

不仅如此，有用户反馈28日早高峰没有了往日拥堵，不少出租车在路边揽客。

目前滴滴由滴滴云提供服务。滴滴云官网称，滴滴出行的云计算服务基于滴滴出行的业务技术和经验积累，采用领先的云计算架构、高规格服务器集群搭建、高性能资源配置机制、精细化运营模式，致力于为开发者提供简单快捷、高效稳定、高性价比、安全可靠的IT基础设施云服务。在今年2月，滴滴云发布公告，由于产品线调整，滴滴云在2023年3月31日起将不再对外提供公有云服务。

问题是“家里”的问题

对于滴滴闪崩而且未能较快修复背后的原因推测，360安全专家对第一财经记者分析称，可能有几个方面：一是系统更新升级过程中出现了编程错误、逻辑错误或未处理的异常情况。一般情况下，互联网厂商发布更新都会在晚上，与滴滴发生故障的时间也能对应，当然业务升级维护是放量更新，但现在滴滴全平台、全业务都故障了，说明肯定是他“家里”的问题。

二是服务器故障：比如滴滴的核心机房，可能恒温恒湿环境出了问题，导致服务器过热、CPU烧了，或者核心机房所在地发生了自然灾害如地震、洪水、海啸等，这种情况下，硬件需要重新更换，里面的服务软件也需要重新配置，恢复周期相对较长，但这个可能性比较小。

三是第三方服务故障：滴滴的后台架构可能使用了第三方服务或者组件。如果第三方出了问题，也可能会影响滴滴的正常运行。但出于安全性考虑，滴滴可能不会将核心业务托管给第三方，这个可能性也较小。

四是攻击层面，如DDos攻击：黑客采用分布式拒绝服务的方式，抢占了大量的服务器资源，导致用户无法访问，但这点的可能性不高，因为DDos（分布式拒绝服务攻击）不会导致数据出错，而且滴滴从体量上来说，有足够的成本和能力去对抗。或者其他网络攻击：某些黑灰产团伙可能会通过拖库盗取数据，然后在暗网上售卖，在这个过程中不排除会有误操作，破坏了数据库。

但网络安全公司专家孙甫对记者表示，如果是来自外部的黑客攻击，公司一般会在第一时间进行声明。他的猜测更集中于滴滴发生了内部重大业务调整，或有新业务接入原系统，但没有做好预案，导致关联业务或关联系统出现重大故障，这是大公司系统故障最常见的原因。

其他可能性包括员工违规操作或误操作，导致整个系统停产；员工误操作或违规操作导致内部系统或系统端口意外暴露，如员工为了方便远程办公，把3389、445等端口暴露在外，端口一旦暴露，就有可能打破一切隔离措施；或内鬼恶意行为，如前两年曾发生过微信供应商微盟的核心工程师因对公司不满，人为删除大量的用户数据，导致系统一度停止服务，很多数据最终也无法恢复。

但需注意的是，此次滴滴事故爆发后，滴滴体系产品全线崩溃，并未发生容灾设备及时响应进行辅助的情况。容灾是指在自然灾害、设备故障、人为操作破坏等的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。

一位网络安全领域人士表示，理论上容灾设施遇紧急情况自动启用并继续提供不间断的服务。但从滴滴此次事故的表现来看，似乎并没有提供充分的容灾支持。

孙甫对记者表示，容灾未能启动，侧面验证他所猜测的主要事故原因——自身业务调整引发故障。因为灾备是在系统遭到破坏或攻击时，原有系统被迫停掉，灾备系统才得以启用。但如果是新业务接入，或是内部人员的违规操作，结果就是整个系统都乱了。打个比喻的话，就是大楼有备用电源，停电时是可以救急，但如果是维修工由于误操作或违规操作将一个楼层的电缆给剪断了，或者是正在对某个楼层的线路进行重新铺设——也就是所谓的企业业务调整，这样的情况下即使将备用电源启动了，整个楼层照样停电。

（应受访者要求，孙甫为化名）