光缆被挖断引发全美服务宕机60小时：物理层高可用深度复盘

事情发生之后的那个早上，我手机上同时弹了十几个告警群消息，从“美东视频起播失败”到“私信大面积超时”再到“登录态频繁失效”，范围刷得人头皮发麻。这是一次全美范围内持续了整整 60 小时的严重服务不可用，主体是 TikTok。外界看到的是“App 打不开、视频刷不出来”，而我们内部要回答的问题是：到底哪一层出了问题？

一开始的排查方向其实非常具有迷惑性。应用团队确认没有发布、没有变更，数据库没有慢查询，API 的 CPU 也不高，CDN 那边只是看到边缘节点命中率下降。如果不看底层，谁都不会第一时间想到，真正的病灶在一段被第三方施工队挖断的主干光缆上，而且连备用路由也在同一个物理区间里遭了殃。

这篇复盘我会站在一线参与者的视角，把从告警爆发到最终恢复的全过程拆开讲。文章里涉及到的节点名、IP、容量数值都做了脱敏处理，但判断逻辑、排障流程和踩坑点都保留了当时真实使用的版本。如果你是做网络、SRE 或者大规模平台运维的，这篇内容应该能直接借去用；如果你刚接触基础设施，我会尽量把每个概念都讲明白，不会上来就堆积术语。

1. 事故画像：60 小时里用户到底经历了什么

1.1 故障在前端的具体表现

故障并不是一瞬间“全黑”的。刚开始是美东几个州的视频起播失败率突然往上跳，紧接着私信发送超时、评论区刷新失败，再过了半个多小时，中西部也开始出现同样的反馈。这个过程让一线支持团队很难受——因为如果问题是“服务全挂”，那反而好定位；现在这种“部分区域、部分接口、间歇性异常”的状态，最容易被误判成某次功能上线带来的连锁问题。

实际表现归纳起来，常见几条就是这样：

• 地区聚集性非常明显，问题集中在某一片地理区域，而不是全网均匀劣化；
• 连接建立的时间明显变长，但连接一旦建立起来，服务端返回内容本身是正常的；
• 不同运营商用户感知差异很大，有的运营商网络下完全正常，有的则频繁超时；
• 用户换一个网络出口（比如从家庭宽带切到蜂窝网络），症状可能立刻减轻甚至消失；
• 监控上可以看到网络层丢包率上升，但应用层错误率并没有“全场飘红”。

这五条特征放在一起，基本可以直接把怀疑对象从“应用代码”挪到“网络链路”。但“网络链路”本身也分很多层：可能是互联网出口的 BGP 路由被污染，可能是运营商互联互通的质量劣化，也可能就是最硬核的物理光缆出了问题。前四小时我们就在这几层之间反复横跳，浪费了一些时间。

1.2 物理层故障和软件故障的判定区别

真正做过故障处理的人会有一个体会：物理层故障和软件故障虽然在用户侧表现可能类似，但特征差异很大。软件故障往往可以通过发布回滚、开关降级快速止血；物理故障则受制于地理距离、备件库存、现场施工条件，恢复时间很难预估。

我整理了一张对比表，方便你以后做第一轮判断时直接参考：

这个表帮我们在事故早期做过一次“排除法”：TikTok 的服务是分地域部署的，用户访问会就近调度到离自己最近的数据中心。如果问题是机房内部代码问题，那么无论从哪个网络入口访问，失败概率应该差不多；但当时从东岸到西岸的测试结果却有天壤之别，这就强烈指向“用户到机房中间的物理路径”出了问题。

1.3 把 60 小时拆成一张时间线

为了让大家对整个“持久战”有概念，我把过程压缩成一张时间线表：

时间线里最折磨人的其实是 20 到 60 小时这段。光缆从定位到重新熔接只花了 12 小时左右，但流量调度、备用链路稳定性、回切验证这些环节把总时长拉得很长。接下来我会按根因、排障、修复、复盘四个板块，把这个过程还原清楚。

2. 物理层根因：光缆被挖断为何升级成全美级事故

2.1 骨干光缆不是一根线，而是一条复杂链路

很多人对“光缆断了”的理解是一根网线被咬断，实际远远没那么简单。骨干光缆内部有几十甚至上百根纤芯，每个纤芯两端要经过 ODF 光纤配线架跳接到传输设备，再通过波分设备把不同波长的光信号复用进同一根光纤，最后才接到路由器上。所以“断缆”既可能是整根光缆所有纤芯全断，也可能是某一束管受损、部分纤芯光衰减严重。

这次事故属于前者，而且断点位置相当不凑巧：正好在主路由和备用路由的物理交汇段附近。这里要说一个我后来反复强调的概念——“逻辑冗余”和“物理冗余”根本不是一回事。主备路由在路由表上是两套独立逻辑，但在地图上可能走的是同一根管道、同一座桥、同一条涵洞。只要施工挖斗下去的位置对准了，主备链路会同时完蛋，此时上层路由协议再聪明也没有用。

更隐蔽的是，物理链路不会像软件报错那样给你弹一个明确的“光缆断了”日志。大多数时候，你看到的只是丢包率升高、链路震荡、路由协议不断重新收敛。如果不把层析关系弄清楚，很容易在排查时把锅甩给“网络波动”四个字，然后等着它自己恢复，这是最危险的做法。

2.2 流量自动调度为什么反而放大了故障

断缆发生之后，BGP 协议自动感知到链路失效，开始把原本应该走美东主干节点的流量往中部和西岸调度。从路由层面看，这是正确的自愈行为；但问题在于，备用节点和替代路径的容量是按照“正常情况下少量余量”来规划的，突然涌入几倍的流量，立刻把备用链路打成过载。

这里用一个简化模型解释：假设美东区域正常回源流量是 800Gbps，主干主备链路各规划了 1Tbps 的承载能力，平时主链路 800Gbps，备用链路只有少量监控流量。断缆后 800Gbps 全部压到备用链路上，备用链路单条带宽可能够，但它两端的处理设备、光模块、对端提供商的互联带宽都不一样，其中一截变成“小水管接大水管”，拥堵就发生了。

用户侧感知就是“连接建立非常慢、视频加载像看幻灯片”。网络通了，但吞吐量不够，依然等于不可用。这个阶段最容易做出错误决策——有人会建议把所有流量都切到更远的数据中心，但距离越远，TCP 的建连握手往返时延越高，对短视频这种大量短连接业务来说，体验会更差。所以流量调度必须分层、分步，而不是一键切换。

2.3 用数据反向定位物理断点

在没有直接告警的情况下，如何证明这是物理层问题？最有效的办法是多点同时检测。我们在十几个城市发起连通性测试，画一张地图，看丢包和延迟是否沿地理路径呈现出规律分布。美东大面积异常、美西完全正常，而从美西绕路访问美东反而比美东本地访问还快，这种反直觉现象基本就是物理链路被切断的实锤。

为了拿到更细的证据，排障组在关键节点用类似 mtr 的工具做了持续探测，记录每一跳的丢包率和时延：

bash复制# 从边缘节点持续探测回源机房地址
mtr -r -c 200 -i 1 10.32.44.9

# 脱敏后的输出示例
HOST                            Loss%   Snt   Last   Avg  Best  Wrst  StDev
1.  10.10.1.1                    0.0%   200    0.3   0.3   0.2   0.8   0.1
2.  10.20.3.9                    0.0%   200    0.4   0.4   0.3   1.1   0.2
3.  10.88.12.6                   0.0%   200    0.9   0.9   0.5   2.4   0.4
4.  10.88.254.22                 0.0%   200    1.2   1.3   0.8   3.1   0.5
5.  10.88.254.29                12.5%   200    1.1   1.1   0.9   4.2   0.1
6.  10.88.254.205                0.0%   200    1.3   1.6   1.2   7.8   0.8

单看第 5 跳的 12.5% 丢包率，可能有人会说“这不是很正常吗，偶尔丢包”。但注意第 4 跳和第 6 跳都接近 0%，中间一跳单独丢包，这就是非常典型的“过某个物理段时光信号衰减”的信号。网络团队看到这种图形，第一反应就是准备 OTDR 测试，而不是继续纠结应用层。

OTDR（光时域反射仪）的工作原理可以理解成：往光纤里打一个光脉冲，遇到断点或者折射率变化就会产生反射，根据反射回来的时间和光在光纤里的传播速度，能算出断点距离。它就像你在隧道里喊一嗓子，通过回声时间判断前面塌方的位置。现场测试队带着 OTDR 从机房出发，沿着图纸一路测，不到两小时就把断点锁定到一个公路施工段附近，后来去现场确认，果然是一台挖掘机挖破了管道。

3. 完整排障与修复复盘：从发现到恢复的每个环节

3.1 故障定界的五步操作法

这里把排障流程整理成五步，每一步都有明确的输入和输出，方便以后遇到同类问题直接套用：

第一步，先按区域看，不看单个用户。单个用户“刷不出视频”没有信息量，但一万个用户集中在一个区域报障，就明确指向区域性基础设施或骨干网络。第二步，先按运营商对比。同一个区域内，A 运营商故障、B 运营商正常，说明问题大概率出在互联互通或物理回程上，而不是我们的机房里。第三步，多点 traceroute 锁定高丢包链路，把范围从“区域”收敛到“某一条链路段”。第四步，联系 ISP 和链路提供商要物理路由图纸，确认这一段经过了哪些道路、管道和机房。第五步，用 OTDR 实测断点坐标，组织现场抢修。

这五步看起来不复杂，但每一步都需要平时有积累。比如第四步，如果你和电信基础设施团队不熟，工单在系统里躺两小时是很正常的事；再比如第三步，你需要有遍布全网的监测节点，否则只能像盲人摸象一样东测一下西测一下。

3.2 流量调度：为什么不能一把梭

找到问题之后，接下来就是止损。把流量切走听起来很简单，实际操作里有很多限制。首先是物理距离变长，时延必然升高；其次是备用链路的设备容量、互联带宽未必匹配，切得太多会雪上加霜；还有就是冷数据问题——用户流量切到远距离的边缘节点后，原来的缓存全部失效，大量请求打到源站，会给存储和数据库带来额外压力。

我们的操作是先切 10%，观察丢包率和建连耗时，如果没有恶化再逐步加到 30%、50%，最后一档一档加满。这个节奏看起来保守，但在这种事故里非常必要。果然，加到某个区域满切时，我们发现备用链路出现 CRC 误码增长——虽然链路还能跑，但已经埋下了“隐性隐患”。当时想着等主链路修好赶紧回切，结果这个隐患在回切时直接爆发了，这个后面细说。

3.3 光缆熔接现场的细节

现场修复没有想象中那么快。施工许可以及交通协调就花掉几个小时，真正开始熔接已经是凌晨。熔接这个环节特别考验细节：每根纤芯要用熔接机精确对准，然后高压电弧放电把两根光纤熔在一起。损耗验收一般要求单模光纤熔接点低于 0.1dB，做得好的施工队能稳定在 0.03 到 0.05dB；一旦超过 0.1dB，就必须剪掉重新做，不能凑合。

前几芯的损耗老是超标，原因是熔接机的放电强度和这批光缆的纤芯型号不太匹配。现场调整放电参数之后才稳定下来，但这个过程非常消磨士气——你在凌晨的路边，打着探照灯，一遍一遍重复“切割、清洁、熔接、测试”的循环，标准还不达标，心里会非常焦躁。好在那位老师傅稳得住，调整参数后一鼓作气把整根光缆的纤芯全部接完。

还有一个容易忽略的坑是光纤余长。管道里的光缆被大型机械拉拽过以后，能操作的长度往往不够，盘纤的时候非常难受。一旦盘纤弯曲半径过小，又会产生新的损耗，弄不好就要重新做。接续盒的密封同样重要，如果防水做不好，回填之后雨水渗进去，光衰会随时间缓慢变大，这种隐性故障是最麻烦的。

3.4 回切难在哪里：一次“单通”插曲

光缆修通，所有纤芯测试通过之后，我们以为快结束了，结果回切时遇到了新的问题。备用链路出现“单通”——正向光纤传输正常，反向光模块收光功率过低，导致路由协议一直不稳定，部分地区出现间歇性变慢。排查后发现是备用链路一侧的光模块接收端被灰尘污染，重新清洁后指标恢复正常。

这次插曲让我后来定了一条铁律：主路径和备用路径必须同时健康，才允许回切。任何人不能因为“主链路看着已经好了”就急着把流量切回来，必须先确认备用链路处于健康待命状态，再选择业务低峰期分步操作。某些时候，“修复”成功不等于“恢复”成功，验证阶段的严谨程度，才真正决定了故障会不会发生第二次。

4. 复盘与反思：哪里本可以更快

4.1 有余量、有备份，不等于高可用

这次事件之后，我们对着架构图做了好几次讨论，最大的结论就是：别再拿“有主备”“有多运营商”当作高可用的挡箭牌。真正的高可用，要求主备链路在物理路径上彼此独立、在维护关系上彼此独立、在设备链路上也彼此独立。如果两条路由最后都穿过同一段涵洞、同一个管道井，那它们在物理上就是同一条路，越是高峰期风险越大。

所以在运维计划里，除了看逻辑拓扑，还要花时间做“物理路由风险台账”，把所有关键链路在地理上可能重叠的点都标出来。比如跨河大桥、隧道、高速公路施工段，这些都是高风险位置。台账的价值不是在故障时临时查阅，而是平时就能帮你发现“这个节点只有一路物理路径”的致命隐患。

4.2 备件、人力、流程，缺一条腿都跑不快

复盘时我们列了一堆改进项，表面上看都是小细节，但关键时刻都能卡住进度。第一是备件管理：光模块、尾纤、熔接机电极、光功率计电池，这些要有多套库存，而且要定期检查是否在保质期内；第二是人力预案：现场抢修需要的是有资格、有经验的工程师，不是随便抓一个人就能上手，提前安排备用人力池非常必要；第三是流程时效，从故障发生到联系链路提供商、提交工单、等待审批，每一步都可能被流程拖住，平时一定要预建应急通道。

顺带说一句，熔接机这类设备平时也要“养”。电极用久了会老化，放电参数会漂移，如果不定期校准，真正上战场的时候就会像我们遇到的那样，第一次熔接老是损耗超标。团队后来规定每季度对所有熔接设备做一次标准样纤实测，不达标的设备直接淘汰，绝不留到应急时再用。

4.3 事故沟通机制消耗的隐形时间

复盘时我们统计过，真正花在纯技术修复上的时间大概只有一半，剩下的一半里，沟通和等待决策占了大头。前期因为各团队告警口径不统一，有说 CDN 缓存问题的，有说运营商互联问题的，还有觉得是被攻击的，信息非常割裂。一线支持团队根本拿不到稳定结论，只能告诉用户“技术团队正在处理”。

更糟糕的是，中间一度出现两个团队同时在操作的情况：网络团队在调整 BGP 策略，CDN 团队在改解析配置，两边没有同步，结果导致某些区域的流量路径被改了两次，症状反而加重。后面我们建立了事故期间“单一信息源+统一操作登记”机制，所有人工变更必须在一个共享文档里登记，任何结论必须有三方确认才向外同步。这个机制看起来朴素，但后来的几次小故障里，定位时间明显缩短了。

4.4 一份可以直接复用的物理层故障检查清单

最后把我后来每次演练都会用的检查清单贴在这里，可以作为团队监控和应急文档的底稿：

检查清单之外，还有两个长期动作值得坚持。一个是定期做“拔线模拟”，每个季度随机选一条主干链路断开，观察流量调度是否符合预期；另一个是每年和运营商、道路施工单位一起走一遍物理路由图，把新的施工计划纳入风险台账，提前做防护。

这次故障给我最大的感受是：大型系统稳定的底座，往往不是光鲜的软件架构，而是那条毫不起眼、埋在地底下的光缆。它不在监控大屏的中心位置，也很少有人为它写日报，但一旦出问题，能让所有上层业务瞬间归零。真正专业的基础设施团队，会把物理层当产品一样认真对待——定期体检、严格验收、把备用方案做到物理级隔离。这些工作平时看不到收益，但真到了关键时刻，就是唯一的底气。