苏黎世贝勒爷事情发生之后的那个早上，我手机上同时弹了十几个告警群消息，从“美东视频起播失败”到“私信大面积超时”再到“登录态频繁失效”，范围刷得人头皮发麻。这是一次全美范围内持续了整整 60 小时的严重服务不可用，主体是 TikTok。外界看到的是“App 打不开、视频刷不出来”，而我们内部要回答的问题是：到底哪一层出了问题？
一开始的排查方向其实非常具有迷惑性。应用团队确认没有发布、没有变更，数据库没有慢查询，API 的 CPU 也不高，CDN 那边只是看到边缘节点命中率下降。如果不看底层，谁都不会第一时间想到，真正的病灶在一段被第三方施工队挖断的主干光缆上，而且连备用路由也在同一个物理区间里遭了殃。
这篇复盘我会站在一线参与者的视角，把从告警爆发到最终恢复的全过程拆开讲。文章里涉及到的节点名、IP、容量数值都做了脱敏处理，但判断逻辑、排障流程和踩坑点都保留了当时真实使用的版本。如果你是做网络、SRE 或者大规模平台运维的，这篇内容应该能直接借去用；如果你刚接触基础设施，我会尽量把每个概念都讲明白，不会上来就堆积术语。
1. 事故画像：60 小时里用户到底经历了什么
1.1 故障在前端的具体表现
故障并不是一瞬间“全黑”的。刚开始是美东几个州的视频起播失败率突然往上跳，紧接着私信发送超时、评论区刷新失败，再过了半个多小时，中西部也开始出现同样的反馈。这个过程让一线支持团队很难受——因为如果问题是“服务全挂”，那反而好定位；现在这种“部分区域、部分接口、间歇性异常”的状态，最容易被误判成某次功能上线带来的连锁问题。
实际表现归纳起来，常见几条就是这样：
- 地区聚集性非常明显，问题集中在某一片地理区域，而不是全网均匀劣化；
- 连接建立的时间明显变长，但连接一旦建立起来，服务端返回内容本身是正常的；
- 不同运营商用户感知差异很大，有的运营商网络下完全正常，有的则频繁超时；
- 用户换一个网络出口（比如从家庭宽带切到蜂窝网络），症状可能立刻减轻甚至消失；
- 监控上可以看到网络层丢包率上升，但应用层错误率并没有“全场飘红”。
这五条特征放在一起，基本可以直接把怀疑对象从“应用代码”挪到“网络链路”。但“网络链路”本身也分很多层：可能是互联网出口的 BGP 路由被污染，可能是运营商互联互通的质量劣化，也可能就是最硬核的物理光缆出了问题。前四小时我们就在这几层之间反复横跳，浪费了一些时间。
1.2 物理层故障和软件故障的判定区别
真正做过故障处理的人会有一个体会：物理层故障和软件故障虽然在用户侧表现可能类似，但特征差异很大。软件故障往往可以通过发布回滚、开关降级快速止血；物理故障则受制于地理距离、备件库存、现场施工条件，恢复时间很难预估。
我整理了一张对比表，方便你以后做第一轮判断时直接参考：
| 维度 | 物理层故障 | 软件/配置故障 |
|---|---|---|
| 影响范围 | 通常按地理区域切分 | 可能按用户、版本、功能切分 |
| 出现时间 | 突发性很强，没有规律 | 常常与发布窗口、流量高峰相关 |
| 跨业务影响 | 所有依赖主干链路的业务同时劣化 | 往往只影响特定接口或服务 |
| 换网络测试 | 换网后可能有明显改善 | 换网后一般无变化 |
| 恢复方式 | 需要现场维修，时间不可控 | 回滚、改配置、重启即可，分钟级 |
这个表帮我们在事故早期做过一次“排除法”：TikTok 的服务是分地域部署的，用户访问会就近调度到离自己最近的数据中心。如果问题是机房内部代码问题，那么无论从