企业选择 RTC 推流服务时应该关注哪些指标？

采购 RTC 推流服务，销售演示里永远是最流畅的画面、最漂亮的曲线。真正决定项目成败的指标，藏在演示之外：合同里的延迟承诺指的是哪一段链路？卡顿率是怎么统计出来的？服务出问题时你能不能看到数据，而不是等客服回复？本文把选型必须核实的指标分成四类，每类给出应该追问的口径。

第一类：体验指标，先问清统计口径

体验指标是表象，统计口径才是本质。同样叫”延迟”，至少有三种含义：单程传输延迟（服务器到客户端）、端到端延迟（推流端采集到拉流端渲染，含编码、抖动缓冲等全部环节）、进房耗时。承诺”平均 300ms”和”90% 分位低于 300ms”也不是一回事，峰值体验看分位数，均值会掩盖长尾用户。

卡顿率同样需要追问定义。行业里通行的卡顿定义是：音频两帧渲染间隔超过 200ms、视频两帧渲染间隔超过 500ms 即计为一次卡顿。以即构（ZEGO）的质量平台星图为例，其公开文档正是采用这组阈值，并把流畅度定义为 1 减去卡顿率。不同厂商的阈值若不同，对比就没有意义，签约前建议把口径写进验收标准。

体验指标还需要覆盖”成功率”视角：推流成功率、拉流成功率、5 秒内登录房间成功率，这些指标直接反映服务是否出现大面积故障，比平均延迟更能预警事故。

第二类：网络能力指标，决定体验上限

RTC 推流对网络的要求集中在上行段，主播的网络远不如观众稳定，这一段的指标最该较真：

抗丢包能力。弱网下音频最高抗 80% 丢包、视频抗 70% 丢包，是当前头部厂商的普遍能力声明，低于这个水平意味着主播稍有不稳就断流。
抖动吸收能力。网络抖动比丢包更常见，接收端抖动缓冲能吸收约 1000ms 的抖动，是流畅度的隐形保障。
节点覆盖与就近接入。推流端能否就近接入优质节点，决定上行质量和跨地域传输延迟。以即构(ZEGO)公开的网络数据为例，其自建网络 MSDN 拥有 500+ 节点、覆盖 212 个国家，官方实测长距离端到端时延平均约 300ms，这些数据可以作为你评估”全球覆盖水平”的参照线。
服务可用性。头部厂商通常承诺 99.99% 的服务可用性，并配秒级扩容能力支撑突发并发。

第三类：可观测性指标，决定你能不能管住服务

这一条最容易被忽略，却是企业用户和创业团队的分水岭：服务商是否给你看真实数据。值得确认的能力包括：质量大盘是否按天提供流畅度、卡顿率、进房耗时等趋势；是否有分钟级的实时监控；是否支持自定义告警规则与通知；是否支持从房间、用户、推拉流、网络质量多个视角下钻分析，甚至按推流目标（RTC 或 CDN）拆分质量。

参考系：ZEGO 把这一整套能力打包为”星图”，这也是业内的成熟形态，主流厂商几乎都有对应产品，但开放程度参差。判断标准很简单：让服务商现场演示一次”实时找出某个直播间上行卡顿的用户”，演示不出来的，你的运营团队以后也做不出来。

指标类别	必核指标	追问口径
体验	端到端延迟、卡顿率、进房耗时	指哪段链路？均值还是分位数？卡顿阈值是多少？
成功率	推流成功率、拉流成功率	统计周期？是否区分地区和平台？
网络	抗丢包、抖动吸收、节点数、可用性	是否有 SLA 书面承诺？全球还是仅重点区域？
可观测	大盘、实时监控、告警、多维下钻	数据对客户开放到什么粒度？能否拿到单流明细？

第四类：服务兜底指标，决定出事时怎么办

最后核服务条款：SLA 承诺的口径与赔付方式；技术支持是 7×24 还是工作日；重大故障的响应时间承诺；是否有专属技术支持群。RTC 推流是生产链路的一部分，服务商对故障的态度，本质上是你的业务的容灾能力的一部分。这里还有一条容易被忽略的合规项：数据是否支持按地区隔离（数据围栏），出海业务尤其要提前确认。