9.1.3 链路各环节的角色与故障域：把 "卡了" 拆到具体环节

观众的一句 "卡了"，是流媒体工程师最熟悉也最怕听到的反馈。它信息量为零，却可能来自链路的任何一站：推流端的上行在发抖，源站的负载在报警，转码集群掉了队，CDN 边缘没接住，或者只是观众自己的手机在发烧。排障的第一步不是找原因，而是划地盘——每个环节的故障都有自己独特的 "症状签名"，认出签名，才能把锅准确地递到该接的人手里。本节给 9.1.1 的七站接力逐站开出故障档案。

推流端：上行的风一吹就晃

推流段的故障签名是源头性波动：码率忽高忽低、GOP 间隔不匀、严重时整路断流。病根多在最后一公里的上行网络——主播的 Wi-Fi 被抢道、移动网络切换基站，码流还没到源站就已带伤。这类故障的识别特征是全员同步受害：源头抖一下，下游所有观众同一时刻看到同样的瑕疵。7.5.3 的 SRT 用 ARQ 重传在这里上岗，正是为了给这段最不可控的旅程兜底。

源站：中枢的沉默与过载

源站的故障签名是全局性中断或登记错乱：流掉线、转推失败、单点过载导致整路流停滞。它是单点中的单点——推流端只跟它打交道，转码集群只听它派活，它一咳嗽，全链路卧床。工程上的解法是常规的热备与多源站容灾，而监控上的要点是把源站的接收质量与推流端的发送质量分开记：上行抖动是推流端的锅，接收正常却派发失败才是源站的锅，两本账不能混。

转码集群：流水线上的次品

转码段的故障签名是内容性缺陷：花屏、音画错位、档位缺失、ABR 切换时画面跳变。经典病因之一是关键帧不对齐——各档转码各自为政地放 I 帧，播放器切档时新档的关键帧迟迟不来，画面卡在原档或跳黑。另一类是集群过载掉帧：转码速度追不上实时速度，输出流的时间戳开始系统性漂移。这类故障的识别特征是按档位分布：只有 1080p 花而 480p 正常，锅多半就在转码流水线而非网络。

CDN 与边缘：洪峰下的漏接

分发段的故障签名是区域性、间歇性的：某片地区的观众集体转圈，换个城市却一切正常；高峰时段 404 与超时零星出现，深夜里风平浪静。病根常是回源风暴——热门赛事开场瞬间，海量请求同时扑向尚未缓存的新分片，边缘节点集体回源，把源站出口带宽挤爆；或是边缘节点磁盘故障、负载不均，让部分观众被调度到了病节点。识别特征永远带着地理与时间的指纹：同一运营商、同一区域、同一时段的聚集性故障，先查 CDN 调度。

播放端：最后一米的冤假错案

播放端的故障签名是个体性差异：同一个直播间，有人丝滑有人卡成幻灯——终端解码能力不足（8.3 实测过的解码压力）、本地缓冲水位策略保守（8.2.3）、Wi-Fi 信号穿了两堵墙。这类故障最难伺候：链路全程健康，锅却在观众手里那台设备。播放器侧的监控埋点（9.2.2 的主角）因此格外重要——只有把端上的卡顿率、起播时间采回来，才能证明 "链路没病"，或者承认 "病在端上"。

小结：故障域是排障的地图

把五份档案并排放，一张排障决策树就长出来了：全员同病查源头，按档分布查转码，区域聚集查 CDN，个体差异查终端。故障域的价值不在背诵，而在把 "卡了" 这句零信息量的话，翻译成可定位、可分工、可验证的工程语言——这也是 9.2 监控体系设计的出发点：每个埋点的位置，都对应着一份故障档案的取证需求。链路的地盘划完了，还剩最后一个结构问题：为什么这场接力里，每一棒说的都不是同一种语言？9.1.4，协议的链路分工。