一、三层监控：缺一层就会盲飞

直播链路很长，只盯推流端是最常见的误区——推流端一切正常，观众却打不开的情况并不少见。完整的监控要覆盖三层：

  • 推流层：现场这一侧，回答「我们有没有把画面送出去」。
  • 分发层（平台/CDN）：中间这一侧，回答「有没有送到、送得稳不稳」。
  • 播放层：观众这一侧，回答「观众实际看到的是什么」。

三层里最容易缺的是播放层。它是唯一直接反映真实体验的信号，也是唯一能发现「鉴权失效、域名解析异常、终端兼容问题」这类事故的层级。

二、核心指标表（建议只盯这 8 个）

指标不是越多越好。值班时盯超过 10 个指标，人会被噪音淹没，真正的问题反而没人处理。建议核心指标控制在 8 个以内：

层级 指标 正常范围 告警阈值参考 第一动作
推流实际上行码率设定值 ±10%连续 2 分钟低于设定值 20%查上行占用，必要时降档
推流丢帧率<1%连续 1 分钟 >3%降码率或切备用链路
推流推流中断次数0任何一次中断立即切备用链路
分发同时在线并发按预估超预估容量 80%联系扩容准备
分发卡顿率<3%连续 2 分钟 >5%查分发节点与码率档位
分发回源失败率≈0>1%查源站与鉴权
播放首帧成功率>98%<95%查鉴权与终端兼容
播放播放错误码分布无新增类型出现新错误码类型立刻定位该错误码

阈值设定有一个关键技巧：加持续时间条件。「卡顿率 >5%」几乎必然误报，改成「连续 2 分钟 >5%」就稳定得多。另外要为不同规模设不同阈值——100 人的内部场和 5000 人的发布会，同一个卡顿率代表的绝对人数完全不同。

三、告警分级：P0–P3 与处置时效

级别 判定标准 响应时效 处置动作
P0直播中断或大面积无法观看立即切备用链路 / 备用地址，同步通知主持人与主办方
P1部分观众体验明显下降，直播仍在进行10 分钟内有结论降档或调整分发，持续观察
P2指标异常但观众基本无感本场内有记录记录时间点与现象，观察趋势
P3纯提示信息事后复盘汇总进复盘报告

分级的核心是按观众感知判级，而不是按技术严重性判级。一个看起来很严重的后台报错，如果观众毫无感知，就不该触发 P0——否则值班人员会对告警麻木，真正的事故来临时反应不过来。

四、值班 SOP：把判断提前固化

值班人员不需要懂底层技术，但必须有一张决策卡：什么指标到什么值、做什么动作、找谁。技术判断应该提前写进 SOP，而不是等出问题时临时分析。一个可用的最小决策卡包含四列：

  1. 现象：用非技术语言描述（如「观众反馈画面一直在转圈」）。
  2. 判定：对应哪个指标、到什么阈值、属于哪一级。
  3. 动作：第一步做什么（必须是一个具体动作，不是「排查原因」）。
  4. 升级：多少分钟内没解决就找谁，联系方式是什么。

同时要明确一个规则：处置优先于归因。先恢复服务（切链路、降档、换地址），事后再分析根因。现场最常见的时间浪费，就是一边直播中断一边争论是谁的问题。

五、开播前的监控准备清单

  1. 确认核心指标看板已打开且可见（不要开播后才找入口）。
  2. 确认告警阈值已按场次规模设定，且加了持续时间条件。
  3. 确认告警能触达到值班人（手机端可收到，而不是只在邮箱）。
  4. 打印或打开决策卡，确认值班人知道第一动作是什么。
  5. 确认至少一台设备在看播放端实际效果（不是只看推流画面）。
  6. 确认升级联系人与电话，且在开播前测试联系过一次。
  7. 确认备用链路/备用地址已就绪，并演练过切换动作。

最后一条最容易漏：备用链路如果只在文档里存在，从没演练过，那它在真正出事时不算可用。

相关技术手册

📘 现场值班没人兜底？企业直播服务提供监控配置、决策卡制定、彩排演练与现场驻场保障，出问题时有人按预案处置，而不是临时分析。