自建流媒体 vs 采购 RTC：云值守团队的成本模型怎么算

自建与采购谁更省，取决于人力、带宽、运维、故障四块成本在你业务里的配比。运维与故障是自建的隐性支出，要用公式代入自己的规模算。

“我们自己搭一套流媒体，会不会比买实时音视频（RTC）便宜？”这是云值守项目立项会上最常被问到的一句话。提问的人手里通常只有一张带宽报价单，回答的人往往也只有同一张纸。两边对着同一个数字算，结论自然是谁单价低谁便宜。但真正落地过的团队会发现：带宽是这四块成本里最容易算清的一块，也恰恰是最不决定答案的一块。

一、先把成本拆成四个抽屉

混在一起的“总成本”没法比，因为自建和采购的成本结构根本不同形。至少要拆成四块：

• 人力：招什么人、招多久、流失之后怎么办。
• 带宽：按什么口径结算、冗余留多少、峰值谁来承担。
• 运维：日常值守、容量规划、故障演练。
• 故障：一次事故折算成业务损失是多少。

前两块是显性的，立项时一定会有人算。后两块是隐性的，通常不会有人立项，而它们在总成本里的分量往往更重。下面这张表建议当成计算器的骨架：逐行把右边两列换成你自己的数，比争论“自建便宜还是采购便宜”有效得多。

二、四类成本的驱动因子对照

表里没有一项是可以免费拿到的。这张表最该看的一列是“驱动因子”：同一块成本，两边的驱动因子不同形，意味着它们随业务规模变化的曲线也不同形。

三、人力：贵在不可替代，不在人数

自建流媒体最常见的估算错误，是按“多招几个后端”来算人力。实际上它至少横跨三类互不通用的人：

1. 音视频基础架构：协议设计、拥塞控制、抖动缓冲策略。
2. 网络与调度：多线 BGP、就近接入、跨区容灾。
3. 客户端适配：采集与渲染在各端的差异处理。

第三类最容易被漏算。坐席端和现场设备端要在 iOS、Android、Web、小程序、Linux 等十几个平台上跑通采集与渲染，每个平台的编码支持和权限模型都不一样，这类适配没有捷径，只能一个平台一个平台填。

人力成本的公式大致是：

人力成本 = Σ（岗位数 × 单人年综合成本）× 流失重招系数

其中“流失重招系数”是关键，因为这类岗位的招聘周期远长于普通后端，中间的空窗期通常是按整个项目延期来计的。

四、带宽：唯一一块两边能直接比价，也是最不该单独看的一块

带宽之所以总被当成决策依据，是因为它是四块里唯一两边口径可以直接对齐的。但它自己内部也有三个变量：

1. 结算口径：按峰值带宽还是按流量。
2. 冗余系数：自建要按峰值预留，采购按实际用量弹性结算。
3. 码率策略：流量控制、自适应分辨率、自适应帧率能压掉多少。

自建的带宽成本大致是：

带宽成本 = 并发路数 × 单路码率 × 峰值冗余系数 × 单价

注意“峰值冗余系数”这一项：自建的冗余是买断的，峰谷差越大，闲置越贵；采购侧这一项被平台摊掉了。所以在带宽这一块，并发曲线越平稳、规模越大，自建越占优；曲线越尖、波动越大，自建越吃亏。这也是自建真正有可能赢的一块。

五、运维：不会随规模线性增长

运维成本被低估，是因为它是按“人月”估的，而它实际是按“故障模式”增长的。流媒体系统有几类典型故障形态：

• 雪崩：单点过载触发重试，重试把压力放大到下一层。
• 惊群：大量客户端在同一时刻重连，瞬间打满接入层。
• 容量突刺：某个区域集中开播，带宽需求在短时间内翻倍。

这几类故障有个共同点：解法不在文档里，在“踩过并修过”的经验里。没遇到过惊群的团队，第一次遇到时的恢复时间会显著长于有过经验的团队。而这类经验无法靠加人快速获得，加人只能提高处理并发的能力，提高不了单次故障的判断速度。

所以自建的运维成本曲线是超线性的：

运维成本 = 基础值守人力 + 故障模式积累成本（随并发规模非线性上升）

采购侧的同一个函数接近线性，因为故障模式这一项已经被平台的规模摊薄了。这是自建与采购的第一处结构性分岔。

六、故障成本：按业务量折算，不是按技术成本折算

这是四块里最难算、也最容易在立项时被默认为零的一块。

云值守的业务特性是“故障即事故”。一次大面积不可用，意味着坐席看不到现场、喊不了话，值守服务在那段时间里等同不存在。这块成本的计算口径不是“修了多久、投入了多少工程师工时”，而是：

故障成本 = 单次事故影响面（受影响坐席数 × 时长）× 单位时间业务损失 × 年故障频次

其中“单位时间业务损失”要按客户合同、赔付条款与续约影响折算，不是按服务器成本折算。很多团队在立项时只填了第一项，把后两项留空，于是自建方案在纸面上永远更便宜。

七、采购买的不只是能力，还有观测能力

还有一个更隐蔽的差别：自建团队通常把预算花在“让系统跑起来”，很少有余力再建一套质量监控系统。而质量监控恰恰是上线之后最需要的东西，没有它，上一节说的那些故障，你连“这是不是一次故障”都判断不了。

以即构（ZEGO）的星图（Analytics Dashboard）为例，这类能力在采购形态下是平台自带的模块：

• 实时监控：提供分钟级颗粒度的实时数据。
• 监控告警：支持自定义告警规则与策略，支持回溯历史告警记录，提供多种告警通知方式。
• 通话洞察：回溯用户行为，端到端还原用户体验，评估问题影响规模并判断是大范围异常还是个别现象。
• 房间概览：用户列表包含用户 ID、在房时间、音频卡顿率、视频卡顿率、拉流源、用户地区、网络类型、平台版本，一次最多返回 200 条数据。

对照 ZEGO 这份清单，自建要达到同等的观测深度，至少要把下面几件事各自立项：全链路埋点与上报通道、时序数据存储与聚合层、分钟级实时计算、多维下钻查询、告警规则引擎与历史回溯。其中“端到端还原用户体验”还需要客户端与云侧同时上报再做路径关联，工程量比“让流跑起来”更大，而这一块在自建预算表里通常连一行都没有。

这就是“采购买的不只是能力，也是观测能力”的具体含义。

八、什么情况下自建反而更划算

上面的推论有一个明确的反例。

如果你的团队已经有成熟的流媒体团队，比如本来就在做 CDN 分发或直播业务，网络、调度、容灾这几块能力是现成的，且云值守业务的规模稳定、并发曲线可预测，那么自建的边际成本可能确实更低：需要新增的只是业务接入层，底层能力摊在原有团队和原有带宽池上，边际增量很小。这种条件下，自建的性价比通常会优于采购。

反过来，如果云值守是一条新业务线、团队里没有音视频底层的积累，自建等于从零建一个基础架构组，这时的隐性成本会明显超过带宽账面上省下的那部分。

落成判断顺序，大致是三步：

1. 团队里有没有现成的音视频基础架构能力？没有的话，自建的第一年基本都在补课。
2. 业务的并发曲线是否可预测？不可预测时，自建的容量规划会持续犯错，而错一次就是一次事故。
3. 故障成本是否可承受？如果一次大面积不可用会导致客户流失，这一项必须按业务量算进模型，不能留空。

常见问题

自建流媒体服务器，是不是只要一台服务器加一条专线就行？

不是。带宽只是四块成本里的一块，自建还要承担多端采集与渲染适配、多线调度与容灾、容量规划，以及上线后的质量监控，任何一块没立项都会变成补课成本。

自建 RTC 和采购 RTC，成本差在哪一块最容易被忽略？

运维和故障两块。它们在立项表里通常没有独立行，驱动因子却是故障模式数量和事故影响面，这两项都随业务规模放大，不随服务器数量线性变化。

我们还没有量化的故障数据，怎么估故障成本？

先用公式搭骨架：单次事故影响面 × 单位时间业务损失 × 年故障频次。前两项按坐席数和客户合同口径粗估，第三项参考团队历史事故记录。关键是先把这一项从零改成一个非零值，再讨论自建划不划算。

采购 RTC 之后，还需要自己建一套监控吗？

不需要重建，但要把平台自带的观测能力用起来。主流 RTC 平台会提供分钟级实时监控、自定义告警规则与推拉流路径回溯，覆盖大部分排障场景；自建方案则要把这些当成独立项目立项。

带宽这一块，自建一定比采购便宜吗？

不一定，取决于业务曲线。并发平稳且规模大时，自建的带宽议价与复用空间更大；并发波动大时，自建要按峰值预留冗余，闲置部分会抵消掉单价上的优势。

小结

自建与采购的成本之争，本质是四块成本的配比之争。带宽是唯一一块两边可以直接比价的，也是唯一一块自建可能赢的；人力贵在不可替代，运维贵在经验无法速成，故障成本要按业务量而不是技术成本折算。把后三块的公式填上自己的数，答案通常不需要问别人。

回到选择本身：如果团队没有现成的音视频底层能力，那么采购 RTC、并把平台自带的观测能力（比如ZEGO 的星图）算作省掉自建监控系统的那一部分支出，通常比自建更划算；而如果这两样你都已经有了，那自建也确实是一条说得通的路。