Skip to content

线上问题不过夜：WebRTC 生产故障排查与修复作战手册

6 min read

WebRTC 线上故障的典型特征是“用户体感强、问题链路长、根因跨团队”。同一句“卡顿”，可能来自信令重协商冲突、ICE fallback、SFU 队列拥塞、端侧编码过载，甚至是地域路由漂移。没有系统化排障方法，值班会陷入“每次都从头猜”。本文给出一套可执行的生产排障体系，目标是缩短 MTTR，并把临时止血转化为长期治理。

一、故障分层模型：先分层，再定位

建议将 WebRTC 故障分为五层：

  1. 接入层：鉴权、信令连接、会话创建。
  2. 建连层：SDP 协商、ICE candidate 交换、连通性检查。
  3. 媒体层：编码、转发、解码、播放。
  4. 网络层：RTT、丢包、抖动、跨区路由。
  5. 资源层：节点 CPU、带宽、队列、TURN 容量。

值班时第一件事不是查日志，而是判定故障层级。层级判错，会导致排障方向完全跑偏。

二、故障响应流程：15 分钟止血、60 分钟归因

推荐响应 SLA：

  • 0-5 分钟：确认影响范围与级别。
  • 5-15 分钟：执行止血动作（降级、限流、切流、回滚）。
  • 15-60 分钟：收集证据并形成初步根因。
  • 24 小时内：输出复盘与预防动作。

关键是“先止血，再求全责备”。生产故障中，业务连续性优先于技术完美。

flowchart TD
    A[告警/用户投诉] --> B{影响范围评估}
    B -->|广泛影响| C[P1 应急流程]
    B -->|局部影响| D[P2/P3 排查流程]
    C --> E[执行止血: 降级/回滚/切流]
    D --> F[分层定位: 信令/ICE/媒体/资源]
    E --> G[证据采集与会话快照]
    F --> G
    G --> H[初步根因结论]
    H --> I[修复方案与验证]
    I --> J[复盘与防复发任务]

三、架构设计视角：为了可排障而设计系统

很多系统“功能可用但不可排障”，根因是架构缺少可观测性设计。建议在架构层面预置：

  • 全链路会话 ID（客户端、信令、SFU、TURN 统一）。
  • 关键状态事件（offer/answer、ICE 状态、层切换、降级动作）。
  • 错误码标准化（统一语义、统一级别、统一可检索）。
  • 快照机制（出现异常时自动抓取关键统计与日志）。

可排障性不是后期补丁，而是架构目标之一。

四、常见故障模式与快速判断

模式 A：建连失败率突升

快速判断：

  • 信令握手是否正常。
  • ICE 状态是否卡在 checking。
  • relay 占比是否突然上升。

止血动作：

  • 强制开启稳定 TURN 路径。
  • 临时降低候选复杂度，缩短检查窗口。
  • 回滚最近信令版本。

模式 B：通话中途大面积卡顿

快速判断：

  • SFU 队列时延是否上升。
  • 节点 CPU/带宽是否接近上限。
  • BWE 是否异常震荡。

止血动作：

  • 全局降级视频层，音频保底。
  • 启用热点房间分片。
  • 限制非关键流优先级。

模式 C：区域性质量劣化

快速判断：

  • 区域链路 RTT/丢包是否异常。
  • 是否发生路由偏移或节点故障。
  • 某运营商是否集中异常。

止血动作：

  • 切换接入区域和 TURN 节点。
  • 临时调整路由策略。
  • 对异常运营商启用保守编码策略。

五、质量治理：把事故指标转成长期改进指标

每次故障后，至少沉淀以下数据：

  • MTTD（发现时长）。
  • MTTR（恢复时长）。
  • 影响会话数和影响时长。
  • 根因分类（信令/ICE/媒体/资源/变更）。
  • 止血动作有效性。

治理目标不是“事故清零”，而是“同类事故规模和恢复时长持续下降”。

六、容量与成本联动排障：避免“止血动作把账单打爆”

生产止血常见副作用是成本激增，例如全量强制 TURN、过度冗余重传。建议建立“应急成本看板”，实时观察：

  • relay 占比。
  • 跨区流量。
  • 节点单位会话成本。
  • 资源利用率。

应急动作要有“成本上限”，超限时触发二级策略（例如限制低价值视频流），避免故障演变为财务事故。

七、排障工具链：最小可用组合

生产环境至少应具备：

  • 会话级时间线视图。
  • getStats 与服务端事件关联查询。
  • webrtc-internals/浏览器调试导出。
  • 节点指标实时面板。
  • 一键生成事故报告模板。

工具不在多，在于是否能快速回答三个问题：哪里坏了、为什么坏、现在怎么止血。

八、故障演练：没有演练就没有可靠值班

建议每月进行场景化演练：

  1. 信令网关抖动。
  2. 单地域 SFU 故障。
  3. TURN 服务部分不可用。
  4. 客户端错误版本灰度放量。
  5. 跨区链路时延突增。

演练输出必须包含：响应时间、操作步骤、瓶颈点、改进任务和责任人。只做“演练通过”没有价值。

九、组织协同：明确战时分工，减少沟通损耗

推荐角色分工：

  • IC（Incident Commander）：统一决策与对外同步。
  • 媒体负责人：处理 SFU/编码/调度问题。
  • 网络负责人：处理 ICE/TURN/路由问题。
  • 客户端负责人：处理版本与终端适配问题。
  • 记录员：实时记录时间线与动作。

战时最怕“多人同时改、无人负责”。明确角色能显著降低恢复时间。

十、复盘模板：从“事故纪要”升级为“防复发系统”

高质量复盘应回答：

  • 触发条件是什么。
  • 为什么监控没有提前发现。
  • 哪个止血动作最有效，哪个无效。
  • 哪些系统设计缺陷导致问题放大。
  • 需要哪些长期改造、负责人和截止时间。

并将结果写入“故障模式库”，下次值班可按模式直接执行预案。

十一、实操检查单

故障发生前，确保：

  • 关键指标和告警覆盖核心链路。
  • 策略版本可追溯且可回滚。
  • 值班手册包含 15 分钟止血动作。
  • 每个故障层级有默认负责人。
  • 历史高频故障有对应自动化检测。

这些准备工作看似基础，却决定了故障时能否稳住局面。

结语

WebRTC 生产排障不是“大神经验合集”，而是可制度化、可训练、可持续优化的工程体系。把分层定位、应急止血、容量成本和复盘治理串成闭环，才能让线上问题真正“不过夜”。