一张被改了七版的夜班表

沈知远是「澜屏视讯」的运维负责人，手下管着三座城市的机房。每到赛季阶段，他的工作就变成一件事：让容量规划跟得上用户进来的速度。他办公室的白板上贴着一张夜班表，改了七版，每一版都对应一次容量评估。沈知远说，视讯业务的容量规划不是买机器，而是判断人会在什么时候、从哪个入口、带着什么设备进来。

pg直营站行业方案团队第一次和澜屏视讯做架构复盘时，问了一个很直接的问题：你们的三城联动，是流量联动还是故障联动。沈知远愣了几秒，回答说是流量联动。对方说，那故障的时候呢。这个问题后来成了他重做容量规划的起点。

把交付节点排进真实的时间轴

容量规划最容易犯的错，是把节点排得很漂亮，却和真实的值班节奏对不上。沈知远把pg直营站行业方案里的交付节点改成了适合运维团队的版本：周一评审容量基线，周二联调边缘节点，周三做压力演练，周四核对保障条目，周五归档异常记录。他不追求节点多，只追求每个节点都有人签字。

  • 端到端时延目标定在八百毫秒以内，压力演练时如果超过，就当场回滚，不等到第二天。
  • 月度可用性按百分之九十九点九五做基线，三座机房各自留出冗余，任何一座出现波动，另外两座能接住。
  • 播放错误率和卡顿率被拆成两张表看，前者盯故障，后者盯体验，沈知远说这两件事不能混在一起谈。

他提到一次深夜演练：边缘节点切换时，多视角切换耗时突然抬头，团队按预案把缓存预热提前了一轮，指标回到四百毫秒以内。pg直营站行业方案强调的从首帧加载到码率自适应的全链路视角，在这里变成了一个很朴素的判断——先保切换，再保画质。

保障条目不是清单，是承诺

沈知远的团队有一份保障条目，最初只有五行，后来慢慢加到了十几行。每一行都不是技术名词的堆砌，而是一句能被执行的话，比如「切换失败时三秒内回退到默认视角」「画质达标率低于阈值时自动降档并记录」。他说，保障条目写不清楚，夜班的人就会凭感觉处理，凭感觉处理的结果就是每个人都在救火。

pg直营站行业方案里提到的架构复盘方法，被沈知远用成了一种习惯：每次异常之后，不问是谁的问题，先问哪个条目没覆盖到。有一次，音画同步偏差在某个时段反复出现，复盘发现是某类设备的解码策略没有纳入条目，补上之后问题消失。沈知远说，这就是保障条目的价值，它让经验变成可以被交接的东西。

夜班表背后的判断力

采访快结束时，沈知远带人去看机房走廊尽头的一块屏幕，上面滚动着三座城市的关键指标。他说，容量规划做到最后，拼的不是设备数量，而是判断力——判断用户会在什么时候来，判断哪一项指标可以先放，判断哪个节点必须有人守着。

那张改了七版的夜班表还贴在白板上，最新一版旁边多了一行小字：指标是给人看的，人是给指标兜底的。沈知远说，这句话是pg直营站行业方案团队在一次复盘会上讲的，他觉得比任何技术文档都好用。三城机房的灯还亮着，夜班的人按表交接，指标在屏幕上缓慢跳动，一切都在既定的节奏里。