一间机房里的第一张容量表

2021年深秋，pg直营站视讯业务的第一个独立机房还在调试阶段。当时团队只有七个人，负责采集、转码、分发和前端播放的同事挤在同一排工位上。容量规划这件事，最初就是一张手写的表格：峰值并发预估、单节点出口带宽、转码集群的核数配比，全部靠经验拍板。负责基础架构的罗启明回忆，那会儿最怕的不是流量涨，而是涨得没有规律——一场晚间档的视讯活动，在线人数可能在十分钟内翻三倍，也可能平稳得像一条直线。

pg直营站的第一版容量模型，是从“最坏情况”倒推出来的。团队把历史上所有异常峰值拉出来做包络线，再留出三成余量，形成了最初的扩容触发线。这套方法笨重，却让系统在早期扛住了数次突发流量。更重要的是，它逼着团队养成了一个习惯：每次扩容之后必须复盘，把实际峰值和预估值的偏差记进共享文档。这份文档后来成了pg直营站视讯容量规划的“家谱”。

三城联动：从单点冗余到区域协同

到了2023年，单机房模式开始吃力。pg直营站视讯业务覆盖的区域越来越广，南方用户反馈首帧加载偏慢，北方用户则抱怨晚高峰偶有卡顿。团队决定做三城联动：在三个区域节点之间建立流量调度与内容预热机制。听起来是架构问题，落地时却全是人的问题。

  • 调度策略由谁定？运维希望保守，研发希望激进，最后折中成“分级灰度”，每周评审一次阈值。
  • 内容预热怎么协同？三个节点的缓存团队各自为战，后来统一了预热清单的格式和优先级规则。
  • 故障演练如何组织？每季度一次跨城切换演练，值班表排到每个人头上，谁都不能只当观众。

负责调度算法的程一舟说，三城联动最大的收获不是延迟数字降了多少，而是团队终于理解了“容量是流动的”。pg直营站视讯的容量规划从此不再是静态表格，而是一套带反馈的循环：监控、预测、调度、复盘，四个环节各有负责人，也各有话语权。

那些被指标掩盖的决策瞬间

外界看容量规划，看到的是一串指标：首帧加载时长、端到端时延、月度可用性。但在pg直营站视讯团队内部，真正难的是指标之外的取舍。比如某次大版本上线前，测试环境发现多视角切换在特定机型上有概率掉帧。修复需要两周，上线窗口只剩五天。团队最后选择先上线、后修复，但把受影响的机型从推荐列表里暂时降权，并在客户端内做了温和提示。

这个决定在当时并不轻松。产品负责人沈岚在评审会上说了一句话：“我们不是要掩盖问题，是要给修复争取时间，同时不让用户替我们承担代价。”pg直营站的视讯业务后来把这套做法沉淀成了“灰度降权”流程，写进了工程规范。类似的瞬间还有很多，它们不会出现在任何一份对外报告里，却构成了团队真正的成长轨迹。

如今三城联动的容量体系已经平稳运行，pg直营站视讯团队又开始琢磨新的课题：如何在边缘节点做更细粒度的码率自适应，如何让调度策略对突发活动的响应从分钟级压缩到秒级。机房里的灯火换了几茬，那张手写表格早已被系统取代，但“先算最坏情况、再留复盘余地”的习惯，一直留了下来。