文章目录
HiveOS 批量指令越过测试组，可能让整排矿机一起掉线
凌晨 2 点 17 分，值班手机连续震了十几次。A3 机架的在线数从 186 台降到 41 台，算力曲线像被刀切开一样往下掉。现场同事先拔插交换机，随后准备重启整排机器。直到我打开 HiveOS 的活动记录，才看到 9 分钟前有一条批量 Flight Sheet 切换操作：原计划只改 8 台测试机，实际选中了整个 Farm。
这次故障没有烧卡，也没有断电。问题出在最普通的操作上——测试范围没有被系统和流程真正隔开。
从恢复第一台机器到全部算力回稳，我们用了 47 分钟。损失不算致命，却暴露出一个更危险的事实：矿场已经习惯用 HiveOS 批量管机器，却仍按单机时代的方式分配权限、确认告警和保存旧配置。只要一个选择范围出错，效率工具就会变成事故放大器。
夜班切换矿池——故障源头是范围失控
事故当天，原矿池出现间歇性拒绝连接，值班员收到多台矿机掉线告警。按照临时安排，他需要挑选 8 台同型号机器，切换到备用矿池观察 15 分钟。
问题出在筛选条件。
测试机此前加过临时标签，但设备调整后，有两台已经换到其他机架，另外几台的标签没有及时更新。值班员搜索标签未得到预期结果，随后回到 Farm 页面重新勾选。页面切换过程中，原先的全选状态没有被他识别，批量命令最终覆盖了 186 台 Worker。
更麻烦的是，新 Flight Sheet 里的钱包模板有一处变量引用错误。部分机器立即停止提交份额，部分机器不断重启矿工程序，还有一些机器保持在线，却没有有效算力。HiveOS 面板上的异常表现并不一致，现场因此误判为网络波动。
复盘时我没有把责任归结为“值班员粗心”。一个批量操作只靠操作者肉眼确认数量，本身就不可靠。特别是在夜班、告警密集、远程页面有延迟的情况下，人最容易忽略的正是勾选范围和目标数量。
流程改造后，任何影响超过 10 台 Worker 的操作，都必须在工单中写明三个数字：计划操作数、页面选中数、执行后回报数。三者不一致，操作立即停止。超过 50 台则需要第二名值班人员复核目标 Farm、标签和 Flight Sheet 名称。
面板同时变红——告警数量不能代表事故规模
这次事故中，手机收到了大量告警，却没有第一时间告诉我们“同一批机器刚刚执行过同一条命令”。
单台矿机掉线、算力下降、矿工重启、GPU 报错，各自看都有意义。可当 100 多台机器在几分钟内同时异常时，继续逐条推送只会制造噪音。值班员面对几十条消息，很容易先处理最显眼的温度或网络告警，反而错过批量操作这个共同原因。
我们随后调整了告警判断方式。
同一 Farm 内，如果 5 分钟内超过一定比例的 Worker 出现相同异常，值班群只保留一条聚合告警，同时附上异常机器数量、涉及机架、最近一次批量操作和当前 Flight Sheet。单机温度过高仍然单独处理，但集体掉算力优先检查最近变更，不允许直接从重启整排机器开始。
告警还被分成了三个处置级别：
- 少量单机异常，由当班人员按设备编号处理；
- 同型号或同机架集中异常，暂停该组后续变更；
- 跨机架大面积异常，立即冻结 Farm 级批量操作，只允许事故负责人执行恢复命令。
告警的价值不在于手机响得快，而在于能否把人引向正确动作。矿场最怕的情况，是系统已经提醒了很多次，现场却仍不知道该先查网络、配置还是刚刚发生的操作。
临时账号能改全场——权限设计已经失效
复盘权限时，我们发现当晚使用的是一个共用值班账号。这个账号既能查看 Worker，也能修改 Flight Sheet、调整超频模板、重启设备和执行 Farm 级命令。最初这样设置是为了方便交接，后来人员增加、班次变多，共用账号就成了无法追责的隐患。
HiveOS 运维权限应该按工作内容拆开，而不是按职位名称笼统划分。
日常巡检人员需要查看状态、确认告警和处理单机重启，但没有必要修改全场配置；网络维护人员可以查看连接异常，却不应碰钱包和矿池设置；能够批量修改 Flight Sheet 的账号，应控制在少数负责人手里；外包维修人员只应看到分配给他的设备组，并设置明确的使用期限。
我们取消共用账号后，又加了两条规定。第一，人员离岗、调班或外包结束，当天检查并收回权限，不能等月底统一清理。第二，所有高影响操作必须使用个人账号，工单编号写入操作备注，确保活动记录能对应到具体人员和具体任务。
权限收紧并不会拖慢运维。真正拖慢矿场的是事故发生后，没人能确定谁改过配置、为什么改、改了哪些机器。只要责任范围清楚，常规操作反而更快。
旧配置找不到——没有快照就谈不上回滚
当晚恢复时间拉长，还有一个直接原因：备用 Flight Sheet 虽然存在，但并非事故前正在使用的版本。原配置曾在一周内调整过矿池地址、钱包变量和矿工参数，修改内容分别留在聊天记录和个人笔记里，没有形成完整快照。
所谓回滚，绝不能理解为“切回一个看起来差不多的旧模板”。如果旧模板中的钱包、矿池、内核参数或超频值已经变化，回切本身可能制造第二次故障。
现在每次批量变更前，我们都会保存一份可核对的变更包，内容包括原 Flight Sheet 名称、矿工版本、矿池地址、钱包模板、关键参数、超频设置、目标 Worker 清单以及截图时间。变更完成后观察 15 至 30 分钟，确认拒绝率、有效算力、重启次数和功耗没有异常，再把本次版本标记为可用。
回滚触发条件也写成数字，不再依赖现场感觉。例如，测试组中超过两台无法连接矿池，或者有效算力在两个统计周期内低于基准值，就恢复旧配置；批量上线后异常比例达到设定值，立即停止向下一组扩散。
需要注意的是，回滚同样要分批。全场配置出错后，再用一条全场命令强行恢复，风险仍然很高。我们的顺序是先恢复 3 台验证机，确认能够正常启动、提交份额和接收监控数据，再按机架逐组恢复。
白班准备变更——测试组必须长期固定
过去我们经常临时挑几台“看起来正常”的机器做测试。这样做的问题是，设备型号、显卡批次、驱动版本和超频参数可能并不一致，测试结果很难代表全场。
目前每个主要机型都保留固定测试组，并使用清晰标签标记。测试组包含正常体质、较弱体质和近期维修过的机器，目的是提前暴露兼容性问题。标签调整必须进入设备变更记录，不能由值班员随手增删。
任何矿工版本、驱动、Flight Sheet、矿池地址或超频模板变更，都要经过固定步骤：
1. 在测试组执行，记录变更前基准；
2. 观察有效算力、拒绝率、温度和重启次数；
3. 扩到单个机架，继续观察；
4. 按批次覆盖其余设备，每批保留间隔；
5. 完成后核对实际在线数与计划设备数；
6. 保留上一版本，直到稳定运行满一个值班周期。
这套步骤看起来比“一键全选”慢几分钟，却能把事故影响压在几台或一个机架内。矿场运维追求的速度，应当包括出错后的恢复速度，而不能只计算命令发出去用了几秒。
交班前核对一次——今天就能堵住的漏洞
如果矿场正在使用 HiveOS，今天最值得做的不是继续增加自动脚本，而是抽半小时检查一次批量操作的影响范围。
先查看现有账号，删除共用账号，收回不需要修改配置的权限；再检查 Farm、机架和测试组标签，确认设备移动后标签是否同步；随后挑一份常用 Flight Sheet，验证事故前配置能否在 10 分钟内被准确恢复；最后检查告警群，确认大面积掉算力时能不能显示受影响数量和最近变更。
交班本上还应固定留下四项内容：当前生效版本、当天批量操作、未关闭告警、可用回滚版本。下一班接手时逐项确认，避免配置只存在于上一位值班员的记忆里。
HiveOS 能把几百台矿机放进一个面板，也会让一次误选迅速覆盖几百台设备。作为运维负责人，我更关心的已经不是谁能最快点下批量执行，而是谁能在执行前说清影响多少台、失败后退回哪个版本、出了问题由谁接管。把这三件事写进流程，下一次夜班告警响起时，现场才不会靠猜。
