国内互联网公司事故启示录（学习篇）#

国外大厂翻车各有各的花样，国内互联网公司也没闲着——百度被黑过、滴滴崩过 12 小时、B 站全站宕过机、腾讯 94 款游戏集体掉过线。

这一篇把国内互联网公司最经典的几起事故整理成报告合集，同样讲清楚：发生了什么、为什么、整个流程、涉及哪些域名、怎么收场、能学到什么。

一、百度域名被劫持事件（2010 年 1 月 12 日）#

这是中国互联网史上最著名的一次域名劫持，也是百度成立以来最严重的服务器事故。

发生了什么#

涉及域名：baidu.com（被劫持）、baidu.com.cn（正常，没被波及）
时间：2010 年 1 月 12 日早上 6 点起，持续约 8 小时
攻击者：自称”伊朗网军”（Iranian Cyber Army）的黑客组织

当天早上，全国用户发现：百度打不开了，或者打开后跳转到伊朗网军的网页、雅虎的错误页面，更多用户看到的是”该网页无法显示”。

为什么是”域名劫持”而不是”网站被黑”？#

这是整起事件最关键的细节：黑客没有攻击百度的服务器，而是攻击了美国的域名注册商（DNS 服务商）。

原理是这样的：

你在浏览器输入 baidu.com，先要通过域名解析（DNS） 找到它对应的 IP 地址
正常情况：baidu.com → 121.14.89.10（百度服务器）
被劫持后：DNS 里存的映射被篡改，baidu.com 被指向荷兰的 IP 或攻击者指定的地址
于是用户访问”百度”，实际到了黑客的页面

因为域名注册和顶级域名解析服务器都在美国，黑客在美国那边动了手脚，百度自己在美国之外反而控制不了。

整个流程#

早上 6 点，域名 DNS 记录被境外黑客篡改
全国多地用户访问 baidu.com 失败或跳转到黑客页面
波及北京、辽宁、浙江、山西等多个省市，连美国、欧洲、澳大利亚的百度都无法访问
百度内部发邮件通知员工：“baidu.com 的域名在美国域名注册商处被非法篡改”
当天中午，北京地区率先恢复，全国陆续恢复
百度事后公告：黑客没有攻击百度服务器，而是攻击了美国域名注册商——这是个新现象

影响有多大#

百度当时平均日营收约 1420 万元，此次断网约半天，损失估计 700 万元以上
引发全国对 域名安全、DNS 解析安全的大讨论

教训#

域名和 DNS 是命门：服务器再安全，域名注册商被人搞了，用户照样找不到你
域名要有冗余解析：用多个 DNS 服务商，避免单点被劫持
.com 和 .cn 都要有：这次 baidu.com.cn 没被波及，说明多域名有兜底作用

二、B 站全站宕机（2021 年 7 月 13 日）#

“B 站崩了”——2021 年 7 月 13 日晚上，这个热搜第一挂了很久。B 站 App、网页端、客户端全球用户全部无法访问。

发生了什么#

涉及域名：bilibili.com（含 App、网页、客户端）
时间：2021 年 7 月 13 日 22:50 左右开始

当天晚上 22:50 左右，B 站突然全站瘫痪——App 打不开、网页 502、视频加载不出来，范围波及全球用户。

根因（B 站官方后来详细复盘）#

这不是简单的”机房故障”。B 站官方后来发布了详细的事故复盘（《2021.07.13 我们是这样崩的》），根因很硬核：

SLB 集群（负载均衡集群）CPU 100%
具体原因：OpenResty 的 lua-resty-balancer 模块在处理 weight=0 参数时，触发了死循环
结果：负载均衡层被彻底卡死，所有请求都进不去后端

大白话：负责”把流量分配到服务器”的那一层，因为一个参数处理 bug 转进了死循环，把自己 CPU 跑满，整个网站就进不去了。

整个流程#

22:50 左右，SLB 集群 CPU 飙升到 100%
全站请求无法处理，App、网页、客户端全部不可用
技术团队紧急排查，发现是 OpenResty 模块的死循环问题
处理过程中多次尝试，陆续恢复
7 月 14 日凌晨，B 站官方在微博宣布：“部分服务器机房发生故障，已恢复正常”，并向全体用户致歉
补偿：给用户发放 1 天大会员（还闹出了”自动续费”的乌龙——部分用户领补偿后发现自己被开了自动续费）

教训#

负载均衡层是高危点：流量入口一旦出 bug，全站跟着瘫痪
参数边界要防御：weight=0 这种边界值，正是最容易触发隐藏 bug 的地方
复盘要公开透明：B 站事后发布详细技术复盘，这个做法值得点赞

三、滴滴史上最长宕机（2023 年 11 月 27 日）#

“滴滴崩了”——2023 年 11 月 27 日晚上，滴滴出行全线崩溃，持续约 12 小时，是滴滴历史上最长的一次故障。

发生了什么#

涉及产品：滴滴出行 App（乘客端、司机端）、青桔单车
时间：2023 年 11 月 27 日晚间开始，28 日逐步恢复

当晚，北京、上海、广州等多地用户反馈：滴滴 App 无法定位、无法下单、地图加载失败。司机端同样崩溃——司机无法登录、无法接单。

更夸张的是：订单页面一片空白，乘客只能靠”报手机尾号”和司机对暗号上车。还有司机被派到 1218 公里外的单子（调度系统也乱了）。

根因#

滴滴官方 29 日公布初步调查结果：起因是底层系统软件发生故障，并非网传的”遭受攻击”。

有技术人员分析：滴滴 App 进行了大的版本升级，导致容器云出现故障——“容器云相当于一个盒子来回处理数据，现在盒子漏了。不是地图坏了，是整个底座坏了。“

整个流程#

11 月 27 日晚间，乘客端、司机端陆续异常
定位失败、无法下单、订单无法结束，青桔单车无法开锁/关锁
滴滴当晚致歉：“由于系统故障，滴滴 App 服务出现异常”
28 日上午，滴滴再次道歉，称网约车等服务已恢复，但实际仍有大量用户无法使用
29 日，滴滴第三次致歉，公布起因是底层系统软件故障
后续承诺开展技术风险隐患排查和升级

影响有多大#

按滴滴 Q3 财报：日均单量 3130 万单，单季度交易额 725 亿元
以 12 小时计算，损失超 4 亿元交易额、超千万订单量
期间出现”天价余额""司机收入 690 亿”等谣言，滴滴官方辟谣

教训#

底座系统升级要谨慎：容器云这种底层设施，上线前测试要通过，回滚方案要备好
越核心的系统，越要防”蝴蝶效应”：一个底层软件故障，打车、骑行、支付全崩
客服和补偿要跟上：故障后的用户安抚，和故障本身一样重要

四、腾讯 94 款游戏集体掉线（2019 年 3 月 23 日）#

发生了什么#

涉及产品：腾讯旗下 94 款游戏，包括《王者荣耀》
时间：2019 年 3 月 23 日下午

当天，大量玩家发现：腾讯游戏集体登录不上、掉线，《王者荣耀》等热门游戏全面崩溃，“腾讯服务器崩了”冲上热搜。

根因#

腾讯官方回应：上海当地网络运营商的光纤线路大面积故障——主光缆被挖断了。

是的，你没看错：施工把光缆挖断了，导致腾讯上海机房网络大面积故障，影响了 94 款游戏以及腾讯系多个外部应用。

整个流程#

施工挖断上海主光缆，机房网络中断
腾讯游戏大量服务不可用，94 款游戏受影响
16 时左右，腾讯游戏回应：光纤线路大面积故障
紧急切换到备用线路，逐步恢复

教训#

“挖断光缆”是经典事故：再强的技术也挡不住施工队的挖掘机，多线路冗余、异地容灾才是解药
外部依赖要兜底：自己的机房再稳，运营商光缆一断照样崩，要有备份线路

五、阿里系多款 App 集体故障（2023 年 11 月 12 日）#

发生了什么#

涉及产品：阿里系多款 App（淘宝、钉钉、闲鱼等）
时间：2023 年 11 月 12 日

当天，“阿里系多款 App 无法访问”的消息冲上热搜：淘宝打不开、钉钉无法登录、闲鱼服务异常，多个阿里系产品同时出现故障。

（注：2023 年 11 月那波集中故障，阿里系和滴滴先后出事，引发了”互联网大厂技术还靠得住吗”的广泛讨论。）

根因与流程#

阿里方面当时的回应是**“技术原因导致服务异常，正在紧急修复”，具体细节未公开披露。从行业惯例看，多款 App 同时故障，大概率是共用的底层基础设施（如账号体系、云服务、网关）出现了问题**。

教训#

共用底座是”一荣俱荣、一损俱损”：多个产品共享一套底层，底层一出事，全家桶一起挂
故障披露要及时：透明度和响应速度，直接影响用户信任

六、总结对比表#

事故	时间	涉及域名/产品	根因	影响时长
百度域名劫持	2010-01-12	`baidu.com`	美国注册商被篡改	约 8 小时
B 站全站宕机	2021-07-13	`bilibili.com`	SLB 死循环 CPU 100%	数小时
滴滴最长宕机	2023-11-27	滴滴 App	底层系统软件故障	约 12 小时
腾讯 94 游戏掉线	2019-03-23	腾讯游戏/《王者荣耀》	光缆被挖断	数小时
阿里系 App 故障	2023-11-12	淘宝/钉钉/闲鱼等	底层基础设施异常	数小时

国内事故和国外事故有个共同点： 大多数都是”自己系统内部的坑”——死循环、底层软件、光缆、依赖链——而不是被外部黑客攻击。

核心教训同样三条：

✅ 核心系统要防”雪崩”：负载均衡、容器云、共用底座，越是底层越要稳
✅ 依赖要有冗余：光缆会断、注册商会被黑、底层会崩，多套方案才有兜底
✅ 故障响应要快、披露要透明：修复很重要，安抚用户同样重要

本文内容基于各公司公开回应、官方公告和公开报道整理，细节以官方信息为准。