视频里有推流、转码、片库回源、观众播放四段。观众越多，越不应该让所有人直接打到源站。源站带宽按回源并发估，不按观众人数估。选错这一条，端口数字会很大，热门文件一来仍然缓冲。
源站用独立服务器，转码可以上云
片库需要稳定的磁盘和网卡，放独立服务器。大陆观众的回源第一跳常用 香港服务器。日本观众的源或边缘靠近 日本服务器。北美观众靠近 洛杉矶服务器 或 西雅图服务器。不要为了少管一台机器，让北美观众每次都从香港拉完整文件。
转码吃 CPU，活动时用 香港云服务器 按场次扩，结束再缩。云的磁盘和网络邻居不稳定，不适合当唯一片库。直播推流看上行抖动，点播看热门文件把下行打满。两种带宽的差别、独享和共享的差别，见 大带宽用在哪。观众分布更广时对照 视频方案 和 大带宽方案。
验收分推流和回源
推流用真实码率推 15 分钟，看上行有没有周期性掉速。掉速且端口没到购买值，查是不是只买了下行。点播同时让多个边缘节点拉同一个热门文件，看源站网卡和磁盘。磁盘读不出时，把端口加大只是让网卡空等。大陆观众缓冲、海外观众正常，查香港回程，必要时把大陆入口的路径换成 香港 CN2 GIA 服务器 这一类优化回程，而不是把洛杉矶的源站搬到香港。方向反了：海外观众缓冲、大陆正常，把文件放到观众所在的城市，不要继续加香港的下行。
回源并发可以按热门文件来估。十个边缘节点同时拉一部片子，源站看到的是十路大文件，不是一个观众。冷门片子大部分时间不产生回源。把端口按全部注册用户数去买，热门档仍可能打满，冷门档全年空着。先统计上一周同时回源的最大路数，再决定源站端口。推流路数同样分开算。多位主播同时推到一台香港机器，上行余量按同时在线的路数相加，每路在标称码率上留重传。只按最忙的那一路买上行，第二位主播进来就会挤兑。
转码云和片库独立服务器之间走内网或同城专线最好。转码结果再推回片库，观众仍只访问边缘或回源地址，不直接访问转码云。转码云的公网端口保持很小，避免和片库抢带宽。活动结束把云缩掉，片库磁盘保留，下一次活动不用重新上传底片。直播和点播不要共用一个已经被打满的下行。直播的观众连接多、单连接不一定大；点播的热门文件单连接大。混在一台机器上，热门点播会把直播的下行挤出抖动。预算只够一台时，先保证直播上行独享，点播热门文件优先放到边缘。
记录三项就够复盘：推流上行有没有顶到购买值，热门文件回源时磁盘等待是否升高，大陆和海外观众的首帧差多少。三项对应三台机器或三条路径。首帧差集中在大陆，动香港回程；集中在海外，动文件所在城市；磁盘等待高，动片库磁盘而不是动端口。
边缘节点的数量先按观众聚集的城市加，不要按国家数量加。日本观众集中在关东，一台东京附近的节点就够开始；北美若集中在西海岸，洛杉矶或西雅图先放一份热门文件。节点加上之后，源站的回源路数会上升，源站端口按这个新路数复核一次。只加节点、不复核源站，热门档会把源站打满，边缘节点拿到的是半截文件。直播活动的推流地址和点播的回源地址分开写进运行说明。值班的人看到缓冲，能知道该看上行还是看磁盘。两个地址混用，排障会在错误的机器上加带宽。
热门文件列表每周更新一次，只把这一周真正被回源的片子留在源站的热盘上，其余放到容量盘。热盘排队时，加容量盘没有用。容量盘很空、热盘等待高，把热门文件挪位置，比把网卡升一档更直接。观众首帧和源站带宽图放在同一张值班表上。首帧变差但源站带宽没满，查边缘节点或回程。源站带宽满了，再决定加端口还是加边缘、减少回源。只看首帧，会把两种原因做成同一种升级。
值班表上再加一列磁盘等待。带宽没满、首帧变差、磁盘等待升高，处理磁盘和热门文件的位置。三项一起看，才不会把磁盘问题买成更大的端口。