HiveOS 今天最该防的是批量操作误伤整场矿机

凌晨 3 点 17 分，值班员在 HiveOS 里勾选了一组掉算力的矿机，准备替换 Flight Sheet 并重启矿工程序。提交后不到两分钟，监控墙上原本零散的红点突然连成一片。现场风扇声没有明显变化，但矿池侧算力从正常值快速下滑，受影响的不是计划中的 12 台，而是同一标签下的 312 台。

这次事故最终持续了 46 分钟。47 台矿机恢复后仍反复掉卡，18 台需要现场断电处理，当班人员先后执行了三次批量命令，反而让故障范围继续扩大。

复盘时我们发现，真正的问题并不是某个超频参数填错，也不是 HiveOS 无法管理大规模设备，而是批量操作从选择对象、执行审批、异常告警到恢复配置，缺少一道道明确的限制。面板越方便，错误扩散得越快，这才是矿场今天最该警惕的风险。

夜班只想改十台：执行范围比配置内容更危险

事故发生前，值班员通过标签筛选掉算力矿机。这个标签平时用于标记同型号设备，但其中还混入了刚完成维修、等待观察的机器。操作人员看到页面上方显示了目标分组，却没有确认最终勾选数量，随后直接应用新的 Flight Sheet。

这类失误很常见。矿场往往花很多时间审核矿池地址、钱包、矿工软件和超频参数，却很少检查“这条命令究竟会落到多少台机器上”。对于 HiveOS 批量管理来说，参数错误只影响运行结果，范围错误却决定事故规模。

我们后来把批量操作拆成了三个确认项：

目标设备数量必须与工单一致，允许有少量差异，但不能只看标签名称；
执行前导出或截图设备清单，至少保留 Worker 名称、机型和机架位置；
超过设定数量的任务必须由第二个人复核，夜班不能单人直接下发。

其中最有效的改动，是取消“临时筛选后直接全选”的习惯。现在所有批量变更都先进入固定测试组，测试组内设备数量保持在 5 至 10 台，并且同时包含正常机器和近期维修机器。观察通过后，再按机架分批扩大范围。

批量管理的价值不是一次改完几百台，而是能精确控制每一批改多少台。

算力突然下坠：告警数量不能代替事故判断

当晚 HiveOS 已经发出了多条离线和低算力通知，但值班群里短时间涌入数百条消息。第一条真正有价值的异常，很快被后续重复告警淹没。值班员看到大量通知后，下意识认为是矿池连接不稳，于是先切换备用矿池，没有立即停止批量任务。

复盘后，我们不再按“每台机器发生一次异常就发一条消息”的思路配置通知，而是按影响范围分级。

单台矿机短时掉卡，进入普通队列，由值班员在规定时间内检查；同机架连续出现多台低算力，升级为区域异常；全场算力在短时间内超过设定跌幅，则直接按变更事故处理，第一动作是暂停正在执行的批量任务，第二动作才是排查矿池、网络和设备。

告警还必须带上足够的判断信息。只有“Worker 离线”几个字，现场很难决定该重启还是等待。我们要求通知至少能对应到以下内容：

异常开始时间；
受影响矿机数量；
是否刚执行过 Flight Sheet、超频或矿工版本变更；
故障是否集中在同一机型、机架或网络区域；
矿池侧算力是否同步下降。

对于矿场负责人来说，告警的目标不是证明系统发现了问题，而是帮助值班员在一分钟内判断：这是单机故障、局部故障，还是一次正在扩散的操作事故。

共用管理员账号值班：方便通常意味着无法追责

那次事故还有一个麻烦：三名运维人员使用的是同一个高权限账号。系统记录能看到操作发生的时间，却无法仅凭账号确认是谁选择了设备、谁修改了配置、谁又执行了第二次重启。最后只能结合群聊记录和现场口述还原过程。

共用账号的问题不止是追责困难。只要登录凭证泄露，拿到账号的人就可能修改钱包、替换 Flight Sheet、调用批量命令，甚至删除用于定位问题的信息。矿场设备越多，这种权限带来的风险越高。

我们随后按工作内容重新划分账号：

普通巡检人员只查看状态和处理单机告警；值班人员可以重启矿工程序、调整指定设备，但不能修改钱包和全场配置；高级管理员负责账户、关键模板及大范围变更，日常不用于值班登录。

涉及钱包、矿池地址、全场超频模板和系统镜像的操作，需要单独审批。离职、调岗和外包维护结束后，当天回收访问权限，同时检查个人令牌、接口密钥和仍处于登录状态的终端。支持双重验证的账号全部开启，恢复方式由负责人保管，不能留在公共值班电脑上。

权限管理做得是否有效，可以用一个简单问题检验：夜班人员的账号一旦被盗，最坏能影响多少台机器？如果答案仍是全场，权限就没有真正收住。

第一次恢复失败：没有旧配置就谈不上回滚

事故发生后，值班员尝试把矿机切回原来的 Flight Sheet，但部分设备此前使用了不同的超频模板和矿工版本。由于旧配置没有统一留档，大家只能凭经验恢复。结果是多数机器重新上线，少数机器却因为参数不匹配继续报错。

这说明矿场常说的“可以回滚”，很多时候只是“记得大概改过什么”。

一次完整回退至少要保留四类信息：原 Flight Sheet、原矿池与钱包配置、原超频参数、原矿工或系统版本。对于混合显卡、不同批次电源以及维修后设备，还要记录例外项。否则统一恢复会再次伤到那些本来就需要特殊设置的机器。

现在我们的变更工单必须写明回退条件。例如测试组出现两台以上掉卡、算力低于变更前一定比例、拒绝率连续超限，就停止扩大发布并恢复旧配置。不能等全场算力明显下降后，再临时讨论要不要撤回。

回滚也需要演练。我们每周从测试组随机挑选几台机器，完成一次“应用新配置—验证异常—恢复旧配置”的完整操作，并记录恢复耗时。只有旧配置确实可找到、可应用、可验证，才算具备恢复能力。

机器恢复上线：矿池数据才能证明事故结束

HiveOS 面板重新变绿，并不代表生产已经恢复。当晚大多数矿机显示在线后，矿池侧有效算力仍低于事故前水平，部分设备虽然持续提交份额，但拒绝率明显偏高。若只看在线数量，事故会被过早关闭。

我们现在把恢复验收分成三个时间段。

操作完成后的前 10 分钟，检查矿机在线状态、GPU 数量、温度和错误日志；随后 30 分钟观察矿池侧有效算力、拒绝率和连接稳定性；再经过一个统计周期，对比变更前后的平均数据。任何一个环节未达到标准，工单都不能标记完成。

现场还要确认有没有设备被“恢复动作”掩盖问题。比如某台矿机重启后短暂正常，十分钟后再次掉卡；某个机架恢复速度明显慢于其他区域；某类显卡只有在新超频模板下出现错误。这些差异比全场平均值更值得追查。

下一次批量变更开始前：先把五个动作写进工单

经历这次事故后，我对 HiveOS 运维的要求已经从“会不会批量操作”改成“能不能限制批量操作的后果”。今天准备调整矿池、Flight Sheet、超频模板或矿工版本的矿场，可以先完成五件事：

1. 建立固定测试组，禁止直接拿生产分组做首次验证；

2. 为批量任务设置数量复核，超过阈值必须双人确认；

3. 按影响范围整理告警，确保全场算力突降能触发最高级别通知；

4. 拆分查看、值班操作和关键配置权限，停用共用管理员账号；

5. 保存变更前配置，并实际做一次恢复演练，记录恢复所需时间。

HiveOS 能把几百台矿机集中到一个面板里，也能让一次误操作在几分钟内覆盖几百台设备。矿场负责人真正要管住的，是命令下发前的范围、执行中的异常，以及出问题后能否按原路径退回。下一张变更工单发出前，先确认谁能操作、操作多少台、什么情况停止、旧配置放在哪里。把这四个答案写清楚，比多盯一小时算力曲线更有用。