HiveOS 批量命令最怕一次误选全场

凌晨 2 点 17 分，值班员在 HiveOS 里给 36 台掉算力的矿机更换 Flight Sheet。命令发出后不到一分钟，监控墙上连续出现红色状态：先是 70 台，随后超过 300 台 Worker 算力归零。现场风扇声没有明显变化，矿机也没有大面积断电，但矿池侧的有效算力迅速下滑。值班员这才发现，自己选择的标签包含了上周临时并入的两个机房，实际命令范围是 312 台。

这次事故没有烧机器，也没有丢钱包，可从错误配置下发到算力基本恢复，持续了 43 分钟。按照当时币价、电价和矿池结算规则计算，直接损失并不算致命，真正让我警觉的是另一件事：如果当天批量下发的是激进超频参数，或者改错了钱包地址，后果就不会停留在几十分钟的停机上。

作为矿场运维负责人，我最终给这起事故的定性很明确：HiveOS 没有失控，失控的是我们对批量操作的信任。

凌晨批量切换：事故从过期标签开始

复盘时，我们把操作记录、聊天消息、矿池曲线和 HiveOS 活动记录按分钟对齐，发现问题由三个小疏忽叠加而成。

第一，标签没有按机房资产变化及时维护。“低算力待处理”原本只对应 36 台设备，但此前检修时，有人为了方便筛选，把另外两批矿机临时加进了同一标签，检修结束后没有清除。

第二，值班员看到 Worker 列表顶部显示 36 台异常设备，便默认批量操作对象也是这 36 台，没有再次核对最终选中数量。

第三，新的 Flight Sheet 沿用了旧矿池模板，其中一个矿池地址已经停用。矿机收到命令后能够正常启动挖矿程序，却无法建立有效连接，于是出现“机器在线、算力为零”的状态。

单看其中任何一个问题，都有机会被及时纠正。可批量管理会把多个微小错误瞬间放大。单机配置错了，影响一台；标签范围错了，影响一个机房；模板本身又有问题，故障便会同时落到几百台机器上。

因此，批量能力越强，操作前确认就越不能依赖人的记忆。标签名称、Worker 数量、机房编号、目标 Flight Sheet 和钱包尾号，必须在执行前同时出现，缺一项就不允许下发。

看板仍显示在线：绿色状态不能证明正在赚钱

事故发生后的前几分钟，值班员判断偏慢，还有一个重要原因：HiveOS 页面上大部分 Worker 仍然在线。

在线只说明 Agent 还能汇报状态，不代表矿机正在向正确的矿池提交有效份额。风扇转速正常、温度正常、负载存在，也可能是挖矿程序反复连接错误地址，或者矿池认证未通过。矿场如果只盯 HiveOS 在线率，就容易把真正的收入中断当成短暂波动。

流程改造后，我们把告警分成了三类。

设备类告警关注离线、重启次数、温度和风扇异常；算力类告警关注单机算力偏差、同型号机器的平均值变化；收益链路告警则检查矿池连接、拒绝率、有效份额和全场算力落差。

其中，全场算力突降的告警优先级最高。若五分钟内，HiveOS 汇总算力与矿池接收算力的差距超过设定比例，值班员不能只重启 Miner，必须立即检查最近一次批量变更。这样做的原因很现实：大面积同时掉算力，通常很少是几百台矿机一起出现硬件故障，更可能是统一配置、矿池网络或批量命令出了问题。

告警内容也被重新写过。过去只发“算力异常”，现在必须带上受影响 Worker 数量、机房、机型、最近变更人、变更时间和所用模板。夜班收到消息后，能直接判断该找电工、网络人员，还是先撤销配置。

一个人能改全场：方便已经变成高危条件

出事前，我们的账号管理很粗。资深运维、夜班值守和临时技术支持都使用权限较大的账号，理由是现场故障复杂，权限受限会耽误处理。事实证明，这种安排省下的是几分钟申请时间，增加的却是全场误操作概率。

整改时，我们先按工作内容拆分人员权限。巡检人员负责查看状态、确认告警和提交工单；机房值班员处理指定区域的重启及单机操作；能够修改钱包、矿池、Flight Sheet 和超频模板的权限，只保留给少数负责人。外部技术支持需要排查时，使用临时账号，并限定可见矿场和使用期限。

权限调整之外，我们还规定，共享账号不得用于日常值班。每一次高风险操作都必须能对应到具体人员，不能在复盘时只看到一个所有人都知道密码的管理员名称。

修改钱包地址、批量更换 Flight Sheet、调整整批机器的超频参数，被列入双人确认范围。执行人负责操作，确认人通过工单核对目标范围和配置摘要。确认不是在群里回复一句“可以”，而是要写清 Worker 数量、机房编号及回滚版本。

权限管理的价值不在于限制运维做事，而在于让一次手滑最多影响一个可控区域。矿场规模扩大以后，任何人都能随手改全场，本身就是事故条件。

回滚按钮找得到：旧配置可用才算退路

这次故障处理中，我们虽然很快意识到需要回退，却多花了十几分钟寻找正确版本。原因是 Flight Sheet 名称长期由各班组自行填写，列表里同时存在“正式版”“新版”“最终版2”和“临时恢复”等名称。没人能立即确认哪一个版本对应事故前配置。

从那以后，所有生产模板采用固定命名，至少包含机房、机型、矿池、日期和版本号。每次变更前，先复制当前可用配置并标记为回滚版本，禁止直接覆盖。回滚版本还要保留钱包尾号、矿池地址、Miner 版本和超频参数快照。

更重要的是，我们不再默认旧配置一定可用。矿池地址可能失效，Miner 版本可能与当前驱动不兼容，钱包模板也可能被人修改。因此，每周会从不同机型中抽取少量机器做回滚演练：先切到测试配置，再恢复生产版本，核对上线时间、有效算力和拒绝率。

一次可靠的回滚应当回答三个问题：回到哪个版本、由谁批准、恢复后看什么指标。只把旧模板留在列表里，却从未验证能否启动，出事时它很可能只是一个看上去熟悉的名字。

白天做小批验证：批量下发必须设置刹车距离

事故后最明显的改变，是全场批量操作被拆成多个批次。涉及 Miner 升级、矿池切换、Flight Sheet 调整和超频修改时，先选取少量同型号设备验证。观察一个完整周期，确认算力、温度、拒绝率和重启次数正常，再扩大到一个机架、一个区域，最终覆盖目标设备。

夜间原则上不执行非紧急的大规模变更。行情波动、CPI 公布前后或币价快速变化时，团队容易因为收益切换而催促运维提速，但市场越急，越要控制单次影响范围。收益策略可以快速决定，配置下发仍要经过验证。

我们还为批量操作设置了硬性中止条件：试运行设备中出现连续重启、拒绝率明显上升、算力低于基准，或 HiveOS 与矿池数据持续不一致，后续批次立即暂停。执行人没有权力为了赶进度跳过观察时间。

现在，每次 HiveOS 变更工单都必须留下六项内容：目标 Worker 清单、操作账号、配置版本、验证批次、停止条件和回滚版本。完成后再补充矿池侧结果以及异常机器名单。

对矿场来说，HiveOS 最危险的时刻往往不是页面报红，而是所有按钮都能正常点击、操作人员也确信自己选对了对象。今天就该检查三件事：清理过期标签，收回不必要的全场权限，并选十台非关键设备完成一次真实回滚。做完这三步，下一次误选范围时，损失才有机会停在十台以内。