文章目录
HiveOS 今天最该防的是一次批量操作放倒整排矿机
凌晨 2 点 17 分，值班员在 HiveOS 后台勾选了一组带“夜间优化”标签的 Worker，准备下调功耗。执行后不到三分钟，机房里原本连续的风扇声开始一片片断掉。监控屏上，离线数量从 6 台跳到 43 台，随后变成 186 台。
我赶到现场时，第一排机架的交换机指示灯还在闪，矿机却没有恢复算力。最后查明，问题不在网络，也不在矿池。那组标签半年没有清理，里面混进了另一批不同显卡、不同超频参数的机器。值班员调用了旧模板，又在批量执行时选中了标签下的全部设备，错误配置就这样覆盖了整个区域。
这次事故没有烧卡，却造成了两个多小时的有效算力损失。更麻烦的是，我们一开始甚至说不清哪些机器被改过、谁批准的、原配置存在哪里。HiveOS 提供了批量管理能力，真正把事故放大的，却是矿场自己留下的流程漏洞。
夜班一次全选：批量效率越高，误操作半径越要受控
矿场使用 HiveOS，最容易形成一个错觉：既然机器都在同一个面板里，统一修改就是最省事的做法。
实际上，“能批量操作”和“应该全量执行”是两回事。单机配置出错，影响通常局限在一台设备；批量模板选错，几十台甚至几百台机器会在几分钟内出现相同故障。矿场规模越大，这个放大效应越明显。
复盘后，我们取消了按临时标签直接全量执行的习惯。所有影响矿工软件、超频参数、矿池地址和系统版本的操作，都必须经过三层范围确认：
第一层是设备型号。不同显卡、不同显存颗粒、不同 ASIC 批次不能因为位于同一机房就共用配置。
第二层是当前状态。正在高温告警、频繁掉卡或者刚完成维修的机器，不进入常规批量任务。
第三层是执行数量。单次变更设置数量上限，超过上限必须拆批，并由第二个人核对 Worker 列表。
现在我们通常先选 3 至 5 台机器做测试，观察至少一个完整统计周期。确认算力、拒绝率、功耗和温度没有异常，再扩到一个机架。只有机架运行稳定，才允许继续覆盖同型号设备。
这个过程会比“一键全选”慢二十分钟，却能避免两小时的集体离线。
告警消息刷满群聊：没有分级的提醒等于没人负责
事故发生前，HiveOS 已经发出过几条异常信息，包括矿工重启、单卡掉线和算力下降。但值班群里每天都有大量温度波动、短时离线和自动恢复通知，真正有价值的信号被淹没了。
我们统计过一周的消息：夜班人员平均每小时收到四十多条提醒，其中大部分不需要人工处理。久而久之，值班员看到告警的第一反应不再是确认风险，而是等待系统自行恢复。
后来我们按处置需求重新划分告警。
单台矿机短时掉线，先进入观察队列，不立即打电话；同一机架在五分钟内连续离线多台，直接升级为区域事件；批量变更后出现算力同步下降，则视为高优先级事故，自动通知当班负责人，同时暂停后续变更。
告警内容也被改得更具体。只写“Worker Offline”没有多少帮助，值班员还要逐台查询。现在消息里必须包含设备组、离线数量、最近一次配置变更时间、执行账号以及受影响模板。这样一来，人到达现场前就能判断该查网络、查供电，还是立即撤销配置。
矿场告警的价值不取决于发送速度，而取决于收到以后谁来处理、多久响应、什么条件下升级。缺少这些规则，消息再及时也只是噪音。
共用管理员账号：查不到执行人就无法真正复盘
这次事故最尴尬的一幕，是我们花了二十多分钟确认操作来源。夜班长期共用一个高权限账号，登录信息保存在值班电脑上。记录只能说明该账号执行了修改，无法直接对应到具体人员和审批单。
共用账号确实方便交接，也把责任边界全部抹掉了。更大的风险是，一名只负责重启矿机的值班员，也可能拥有修改钱包、矿池地址和全场配置的能力。
我们随后按照岗位拆分 HiveOS 操作权限。巡检人员只处理设备状态和常规重启；维修人员可以调整指定测试组的参数，但不能触碰其他区域；班组负责人负责扩大批量范围；涉及钱包、矿池地址和大规模模板替换的操作，需要单独授权。
同时，个人账号必须开启双重验证，离职和转岗当天撤销权限，不再依靠“大家都知道密码已经换了”这种口头确认。临时授权设置失效时间，任务结束后自动回收，避免维修人员几个月后仍保留管理能力。
权限拆细以后，操作步骤确实多了一点。不过事故定位速度明显提高：谁在什么时间改了哪一组机器，可以直接和工单对应。对矿场来说，权限管理的目标不只是防外部入侵，也要限制一次无意点击能够影响多少设备。
现场找不到旧参数：没有快照的回滚只是重新猜配置
当时我们决定回滚，却发现旧配置并没有完整保存。有人记得核心频率，有人记得功耗限制，矿池参数则散落在不同交接记录里。所谓回滚，最后变成了几个人凭印象拼出一套“应该差不多”的设置。
这也是很多矿场容易忽略的问题：看到 HiveOS 里的修改记录，就以为随时可以恢复。实际上，能看到改过什么，不代表已经准备好一份经过验证、可以直接恢复的旧配置。特别是同时涉及 Flight Sheet、矿工版本、超频模板和钱包关联时，只撤回其中一项，机器仍可能无法恢复原来的运行状态。
现在每次变更前，我们都会保存四类信息：目标 Worker 清单、当前 Flight Sheet、当前超频参数、矿工与系统版本。快照名称统一包含日期、区域、设备型号和工单号，禁止使用“最终版”“新参数”“测试二”这类无法追踪的名字。
回滚条件也提前写入工单。例如，测试组十分钟内离线超过两台、平均算力下降超过设定比例、拒绝率持续升高，任何一项达到阈值就停止扩批并恢复旧配置。值班员不需要等负责人在线拍板，更不能抱着“再观察一会儿”的心态拖延。
回滚完成后还要验证。设备显示 Online 只说明连接恢复，不能证明生产状态正常。我们至少核对有效算力、矿池端份额、拒绝率、温度和矿工重启次数，确认这些指标回到变更前范围，事故才算收口。
交接班只说“已经好了”：缺少时间线就会重复犯错
那次故障恢复后，早班接手时只收到一句：“参数问题，已经回滚。”如果以这句话结案，下一班仍可能选中同一批旧标签，继续使用同一个错误模板。
因此，我们把复盘压缩成一张必须当天完成的事件单，内容不求长，但时间线必须完整：何时提交变更、谁审核、先在哪些机器执行、第一条异常何时出现、告警何时升级、何时停止扩批、使用哪份快照恢复，以及最终损失了多少有效算力。
事故原因也不能简单写“人员误操作”。这个结论几乎没有改进价值。值班员为什么能选中 186 台机器？为什么旧标签仍然有效？为什么高风险操作没有二次确认？为什么告警出现后，后续批量任务仍在继续？这些问题才对应真正需要修改的流程。
我们的处理结果包括：删除过期标签，将测试设备单独分组；旧模板改为只读存档，禁止继续调用；批量任务超过规定数量必须双人确认；高优先级告警触发后，暂停同一设备组的后续操作；每月随机抽一次回滚演练，验证快照能否使用。
今日值班台前：先完成这六个动作
如果矿场今天正在使用 HiveOS 做批量管理，我建议运维负责人不要先去增加更多自动化脚本，先花半小时检查以下六项：
1. 清理长期未更新的 Worker 标签，确认标签内设备型号和用途一致。
2. 检查共享账号，将批量修改、钱包配置和普通重启权限分开。
3. 为高风险任务设置小批测试组，禁止未经验证直接覆盖整场。
4. 调整告警分级，让区域性掉线和变更后异常能够直接通知负责人。
5. 对当前稳定配置制作快照，并实际挑选一台测试机完成恢复。
6. 把停止扩批和启动回滚的指标写进工单，避免现场临时争论。
HiveOS 可以让一个人管理成百上千台机器，也会让一个错误在极短时间内传遍整个矿场。运维负责人真正要控制的，是每次操作能影响多少设备、异常出现后多久停止，以及恢复依据是否可靠。把这三件事写进流程，下一次夜班出现红色告警时，现场才不会靠猜。
