只记一个总时长，答案只会是资源#

那次实验是在一个 1 master + 1 worker 的测试集群上做沙箱平台的架构选型，四个阶段，每阶段几条并行的实验线。做到第三阶段，我被问了一句：「为什么感觉做实验做了这么久，是因为环境上可以使用的 node 比较少吗？」

这个问题有标准答案。节点确实少，一台 8 核 worker 被 4 到 5 个代理同时压，负载在 1.4 到 14.6 之间跳，峰值到过 58。说「资源不够」没人会反驳。

我没有直接答，让每条实验线各自算一份时间账，按日志时间戳分类。

总账 77 小时，09-25 21:47 到 09-29 02:30。其中 09-26 02:09 到 09-28 10:30 这 56 小时，本机锁屏导致 VPN 掉线，界面上重连不上，集群侧只有节点后台探针在跑。剩下约 20 小时是真能连上集群的时间。

这 56 小时不是「做实验慢」，是「没在做实验」。但在一本只记开始和结束的账上，它和实验时间长得一模一样。

分类之后，排序变了#

20 小时按类拆开，排在第一的不是等节点。

第一类是代理被中断后换实例重读。17:00 到 18:40 之间，子代理因为单次回复输出过长，约 3 分钟被掐一次。换一个实例接手，接手的要先把前面的记录全读一遍才能续上。有一条线 17:06 到 18:53 共 1 小时 47 分钟没留下任何实验记录，前 6 个实例整段白做。另一条线第一个实例 16:57 被掐，17:52 才续上，中间 55 分钟。

第二类是实验本身按时长跑。观察一次切主要盯 300 秒探测加 60 秒泄漏窗口，切 6 次就是 79 分钟；在 200 Mbit 限速下真冷拉一个镜像 190 到 270 秒。这类时间加多少节点也短不了。

第三类是流水线等最慢的那条线。四条线分别在 19:29、20:08、20:15、22:50 收完，复核要等全部收完才一起开始。2.5 小时里三条线干等一条。

第四类是自己脚本的 bug 返工，两条线各约 50 分钟和 45 分钟。

节点少排在最后。各线等别人释放资源的时间是 0 到 14 分钟：一条线 12 次占用日志里等了 0 次，一条线三次拿租约都立刻拿到，最长的一条纯空等 14 分钟。这一项占各线总时长 5% 到 20%。

最极端的那条线：3 小时 16 分钟里，13 个原始数据文件的首尾时间戳合计 9.3 分钟，约 5%。

节点少卡的是实验范围#

节点少确实是真问题，它决定了哪些实验根本做不了。

单台 worker 跑不了多节点一致性。只有一个 etcd，压不出控制面瓶颈。没有 GPU 和真 NAS，对应的路径也没法测。KWOK 能伪造 50 台 worker，伪造不出第二个 etcd。这些是「测不了」，不是「测得慢」。

两者混在一起说，结论就变成「给我更多节点」。真给了，56 小时的断网和 1 小时 47 分钟的白做一分钟都不会少。

按类归因之后，先修哪一条不用猜。

代理中断那条当天 19:08 就查明并改了做法：分块写文件、每小步存盘，后面没再被打断。代价是零，排在加机器前面。

这份账本身也有代价#

先说没做好的。这些数字是事后从日志时间戳倒推的，过程中没有专门记。倒推能做到，靠的是每条线都在往一个共享进度文件里追加带时间戳的行——写它是为了交接，顺带才能算账。没有这个习惯，56 小时和 20 小时分不开；就算有，这 56 小时也只在两头各留了一行时间戳，中间是空白，靠「这段没有任何记录」反推出来。

反推出的数字有误差。有一条线第 8 轮一开始写的是「排队等 29 分钟，占 39%」，复核时发现其中 14 分钟这条线自己在跑上一轮复测，纯空等只有 14 分钟，占比掉到 19%，由它推出的「多给一套控制面能省 39%」跟着改成「约 20%」。另一条线初版写了「串行排队约 40 分钟」，翻完 12 次占用标记日志，等别人释放的次数是 0，那 40 分钟全是实验自己在跑，这条被整句删掉。

分类记录不是免费的。它要求三件事：有带时间戳的流水账、分类在动手前就定好、算出来的数要有人复核。第三条最容易省，省掉之后拿到的是一份看起来精确的错账——39% 和 19% 都是具体数字，错的那个一样能写进汇报。

还有一条没解决。那 56 小时的修法是「编排跑在常开的内网机器上」，当天 19:00 上了一个自动重连脚本，但本机锁屏时仍然连不上，脚本没用。这条到实验结束都没修，只是记进了待办。时间账能告诉你该修哪一条，修不修得动是另一回事。

类目怎么分也看场景。我用的四类是断网、代理中断、按时长跑、脚本返工，加上排队和节点噪声，是从这次的实际断点归纳的，换个场景大概率不一样。判据是「每一类对应一个不同的修法」：两类的修法相同就该合并，一类里塞着两种修法就该拆开。