今年 3 月中旬，我们在华北某科研院所守了整整七天。学术周，每天 2 到 3 场报告，累计 17 场，方向覆盖先进材料、能源装备、信息技术和装备制造这几块。七天的学术周直播运维和单场活动完全是两码事——单场是百米冲刺，七天是马拉松，你得会配速。
这个比喻不是我硬套的。第一天干完，队里最年轻的小周说了句"照这个强度我撑不到周五"，我当时就意识到，节奏排错了。所以这篇按天写，每天给一个"当日配速"：投了几个人、出了几次故障、观看多少。摄行科技做过不少长周期项目，但七天连轴、场地还固定在同一间报告厅的，这次算是最典型的一回。
开跑前：把学术周直播运维当成一场马拉松来配速
出发前一晚我们在会议室开了个小会，白板上画了条曲线：第一天不能冲太猛，第三到第五天是掉速期，最后两天靠储备撑。听起来玄，落到执行上其实很实：第一天只上必要设备，别把备件全拆出来；中间三天设备和人都会疲，所以提前把轮班表排到小时；最后两天不再折腾任何配置，能不动就不动。
报告厅是院里的老楼二层，能坐 200 人，层高只有 3.2 米，窗帘是那种老式厚绒布，拉上之后闷得厉害。空调开了七天，滤网上一层灰，每天早上进屋都有股淡淡的旧地毯味儿。这些细节看着无关紧要，实际上直接决定了设备散热的余量。
第一天：起跑别冲太猛
3 月 16 号，周一，早上七点四十进场。两台摄像机、一台导播机、一台编码器、一路 PPT 采集，人力 4 人。第一场九点半开始，讲的是储能材料方向，观看峰值 2,180 人。
第一天我们只干了一件"多余"的事：把所有设备的开机时间、机身温度、剩余存储都记在一张纸上，贴在导播位侧面。后来证明这张纸是七天里最有用的东西。当日故障 0 次，收工五点二十。有人问要不要顺手把明天的机位也调好，我说不用，先睡够。这就是配速——学术周直播运维的第一天，克制比勤快值钱。
第二天到第三天：机器开始有脾气
第二天下午两点半左右，导播机机箱后面的排风开始变调，从平稳的呼呼声变成一阵一阵的。摸了摸外壳，烫手。那台机器已经连续开机 31 小时了。我们把它抬到离窗户近一点的位置，底下垫了两块泡沫板架空，风道通了，温度从 68.5 度掉到 54 度左右。
第三天出现的是存储问题。云端录制没事，本地那张 512G 的卡在第三场中途报满，剩下 11 分钟没录上。这条我认，是我排期的时候按"每天 2 场"算的容量，实际有两天是 3 场。后来改成每天收工必换卡，旧卡当晚导出到移动硬盘，第二天早上格式化回用。设备连轴转的这类风险，能源集团安全生产月的班组同步直播那次也踩到过类似的坑。摄行科技现在的长周期项目清单里，"每日换卡"是一条硬规定。
掉速期第四第五天：学术周直播运维最容易崩的窗口
第四天是我最不想回忆的一天。早上八点五十，负责音频的小李迟到 12 分钟，不是懒，是前一天收工太晚，闹钟按掉了。第一场开场前 3 分钟才把无线麦调好，我在中控位置手心全是汗。
人的疲劳比设备的疲劳来得更早也更隐蔽。第四天开始我们强制执行两班倒：上午班 7:30 到 13:00，下午班 12:30 到 收工，中间有半小时交接。晚上导素材的活儿单独派人，不占白天的人。这套排法第五天就见效了，故障从第四天的 3 次降到 1 次。
顺带说个反常识的：很多人觉得连续七天应该每天新建推流地址，图个"干净"。我们的做法正相反——七天用同一组推流地址，只换直播间标题和封面。原因很简单，每天新建就意味着每天要重新在四五个端配置一遍，人在疲劳期最容易配错，而复用地址的唯一风险是历史录制混淆，这个用命名规范就能解决。第四天那次 1 分 20 秒的中断，恰恰就是因为有人手贱新建了一条地址又忘了同步给编码器。
七天配速表
| --- | --- | --- | --- | --- | --- |
| D1 周一 | 2 | 4 人 | 0 | 3,860 | 起跑，压着走 |
| D2 周二 | 3 | 4 人 | 1 | 4,220 | 略提速 |
| D3 周三 | 2 | 4 人 | 2 | 3,140 | 掉速开始 |
| D4 周四 | 3 | 5 人 | 3 | 2,970 | 谷底 |
| D5 周五 | 3 | 5 人 | 1 | 3,510 | 回稳 |
| D6 周六 | 2 | 3 人 | 0 | 1,880 | 靠储备 |
| D7 周日 | 2 | 3 人 | 1 | 2,240 | 冲线 |
观看量的日间波动挺有意思：周三周四明显低，周一和周五高。院里的人后来解释说，中间几天大家都在实验室赶进度，周五那场是院士报告，所以又拉回来了。这种波动在做数据复盘的时候一定要标注原因，不然客户看到掉了三成会以为是技术问题。
配速表还有个隐藏用途。第五天早上主办方问我们"后面两天能不能加一场"，我把这张表推过去，指着 D4 那行的 3 次故障说：人力已经在谷底了，加场可以，但得再补一个人。对方看了两秒就同意了。学术周直播运维里，数据比嘴皮子好使得多，摄行科技现在每个长周期项目都要求现场留这么一张表。
PPT 共享清晰度这事儿，我们改了三回
七天里最反复的不是网络，是 PPT。第一天用的是 HDMI 采集 1080p，讲者的公式字号只有 14 磅，观众端反馈"看不清角标"。第二天改成 1440p 采集再下变换，好一点但不多。第三天我们干脆改了逻辑：PPT 单独走一路 2560×1440 的画面，和讲者画面做画中画，讲者缩到右下角占 22% 面积。这一改评论区就安静了。
第五天又出了个岔子——一位讲者用的是自带笔记本，接口是雷电口转 HDMI，输出分辨率被系统锁在 1280×720，怎么调都上不去。最后是借了院里一台机器重新拷贝文件解决的，耽误了 4 分钟。所以我们现在的开场检查表里，"讲者自带电脑必须提前 20 分钟接机测试"是加粗的一条。类似的清单化管理，直播项目的交付物清单应该有哪些里整理得比较全。
第六、第七天：靠前面攒的储备撑完
周六周日两天场次少，人也减到 3 个。这时候设备已经连续工作 130 多个小时，我们做的唯一一件事是每天中午强制关机 40 分钟——不是为了省电，是给电池和主板一个降温窗口。手持云台的电池从第五天开始按三块轮换，用一块、充一块、晾一块，晾着那块是为了避免刚充满就上机导致发热。
第七天下午三点四十，最后一场收尾，讲者讲超时了 18 分钟，我们没停流，一直录到他说完最后一句。那会儿窗外天已经暗了，报告厅里剩下十几个人，桌上还堆着中午没吃完的盒饭。这种时候摄行科技的规矩是宁可多录十分钟，也不在收尾上省。
素材归档命名与推流地址复用，学术周直播运维里最省事的两条
七天下来产出 17 条完整录像，总时长 28 小时 45 分左右，加上切片一共 96 个文件。命名规则统一成"20260316-D1-S02-储能材料-讲者姓"，日期在前，天序号次之，场次第三。为什么把日期放最前面？因为客户后来要按周检索，日期在前排序最自然。归档时同时生成一份 CSV 索引，写清每条的时长、方向、观看峰值。
这套东西看着琐碎，但七天体量下不做就是灾难。多点位、多场次的归档思路，高校百年校庆直播的多点接力和教育机构的公开课直播复盘里各有侧重，可以对着看。涉及科研单位的内容合规要求，中国政府网和国家标准全文公开系统上的公开文件是我们每次开工前都会翻一遍的。
七天里那三次小故障，处置记录都在这
第一次是第二天的编码器掉线，7 分 30 秒左右恢复，原因是院内网络做了一次 DHCP 续租，我们后来把编码器改成静态 IP。第二次是第四天那条重复建的推流地址，中断 1 分 20 秒。第三次是第七天开场前监视器黑屏，其实是 HDMI 线被椅子腿压到接触不良，换线 40 秒解决。
三次加起来不到 10 分钟，放在 28 小时的总时长里可以忽略，但每一次当时都够呛。所以学术周直播运维的核心能力，说白了不是不出错，是出了错能在两分钟内定位。摄行科技的做法是每天收工写一条 200 字以内的短记录，第二天早会念一遍，比什么复盘文档都管用。
如果你们院里也有学术周、系列讲座这类连续多天的直播要安排，早点找人聊比临时抱佛脚强太多。摄行科技可以先去报告厅看一趟，量层高、测网络、看电源位，出一份带七天排班和设备轮换方案的报价单，勘场不收费，方案聊完不合适也没关系。
#摄行科技