HiveOS 批量改配置前，今天最怕的是旧镜像被一键推到全场

凌晨两点四十，值班手机连续震了七次。第一条是 HiveOS 里 3 号棚掉算力，第二条是 5 号棚离线数量跳到 18 台，第三条开始已经不是单机告警，而是整组矿机的负载曲线一起塌下去。现场同事戴着头灯进机房，第一反应是查交换机和电源，结果风扇声正常、网口灯也亮，真正的问题藏在面板操作记录里：有人把原本只给测试组推送的旧镜像，点成了全场批量执行。

这类事故看起来像一次误操作，其实不是一个人的手抖。作为矿场运维负责人，我现在更愿意把它当成流程问题：HiveOS 能把几百台机器一起管起来，也能把一个小错误放大成几百台机器的停机。今天要发布这篇，不是教大家怎么点按钮，而是把我们踩过的坑摊开讲清楚，尤其是批量管理、告警、权限和回滚这几件事，不能只停留在“知道有这个功能”。

测试组配置被推到全场，判断是分组边界失效

那次事故最直接的原因，是测试组和生产组在 HiveOS 里的命名太像。测试组叫 A1-test，生产组叫 A1，页面筛选时只看到了 A1，操作者以为自己选中的是测试组，实际勾上了同一棚位下的全部矿机。

后来复盘，我们没有把责任只压给夜班同事。因为系统里如果允许一个账号在深夜直接对全场执行镜像切换，本身就说明分组边界没有真正生效。

矿场里常见的错误，是把分组当成“方便查看”的标签，而不是操作边界。HiveOS 里的 farm、worker、tag、flight sheet、钱包和矿池配置，都应该有清楚的隔离。测试机不应该和生产机共用同一套批量操作入口，临时调试机也不应该混在正常收益机里。

我们后来把分组改成三层：棚位、机型、风险级别。比如同一棚里的机器，也会分成稳定运行组、参数验证组、维修返场组。任何涉及镜像、内核、超频模板、矿池地址的动作，都必须先在风险级别最低的一组跑满一个结算周期，至少要跨过一次矿池统计刷新，而不是看 HiveOS 面板恢复就算结束。

这个改法很笨，但有效。因为事故真正发生时，最怕的是大家说不清“这批机器到底属于哪一类”。

告警同时响成一片，判断是消息没有分级

那天凌晨手机一直震，反而让人更难判断。温度告警、掉线告警、算力下降、矿池拒绝率升高，全挤在一个群里。现场的人问“先看哪一个”，远程的人在群里刷截图，五分钟过去，没人能说清第一台异常机器从哪里开始。

HiveOS 的告警如果只是把消息推到 Telegram 或邮箱，并不等于矿场有了告警体系。消息越多，值班人员越容易麻木。我们后来把告警分成三类：需要马上叫醒人的、需要当班处理的、只需要第二天复盘的。

比如全场 5% 以内的单机掉线，不再直接打电话，而是进入当班队列；同一 flight sheet 下连续出现拒绝率升高，才升级；同一棚位在十分钟内出现多台离线，才触发现场巡检。温度告警也不再只看单台温度，而是结合风扇转速、算力曲线和同排机器表现。单台高温可能是灰尘、风扇或硅脂问题，一排机器同时高温，才更像风道或空调问题。

还有一个小细节很关键：告警内容必须写明“下一步动作”。以前群里只显示某某 worker 掉线，现在改成“先查网络，再查电源，再确认最近 30 分钟是否有批量任务”。这不是为了显得规范，而是为了让半夜值班的人不用靠记忆救火。

临时账号能改钱包，判断是权限给得太宽

矿场最容易被忽视的风险，不是机器坏，而是账号权限太大。尤其是赶工、扩容、搬迁的时候，外部维修、临时工、远程协助人员都可能短时间接触 HiveOS 面板。很多矿场为了省事，直接给一个能看、能改、能执行的账号，出事以后再查聊天记录。

我们曾经遇到过一次险情：维修人员为了排查矿池连接，把一组机器的 flight sheet 复制出来测试，差点把钱包地址也一并改掉。幸好当时有二次确认，没有真正推送到生产组。那次以后，我们重新拆了权限。

现在的原则是：看板权限和执行权限分开，配置权限和钱包权限分开，批量操作权限和单机维护权限分开。现场维修只需要看到机器状态和执行重启，不应该能改钱包；夜班值守可以切换预设方案，但不能新建收益地址；运维主管能审批批量任务，但最好也不要用日常账号直接操作。

HiveOS 本身提供了团队和权限管理能力，但很多矿场没有把它当回事。权限不是写在制度里给老板看的，而是要体现在每一个账号能点什么、不能点什么。尤其是钱包、矿池、超频模板、镜像升级这几类动作，必须留痕，最好还要有审批截图或工单编号对应。

如果一个矿场里还存在“大家都用一个管理员账号”的情况，迟早会遇到说不清责任的事故。那时候不是技术问题，是管理已经失控。

回滚文件找不到，判断是预案没有跑过

事故发生后，我们第一反应是回滚。问题来了：上一版镜像放在哪里？上一套 flight sheet 是谁改的？超频模板有没有单独备份？有几台机器是特殊显卡混插？这些问题在平时没人关心，真出事时每一个都要命。

最尴尬的是，面板里能看到历史操作，但不能替你判断哪一个版本最安全。回滚不是点一下“恢复”那么简单，它需要提前准备材料。我们后来要求每一次批量调整前，都必须留下四样东西：调整前的 worker 清单、使用中的 flight sheet 截图、超频模板版本、回滚负责人。

回滚也要分批。第一批只回 3 到 5 台，确认上线、算力、拒绝率和温度都正常，再扩大到一个机架，然后才是一个棚位。很多人一着急就想全场回退，结果如果回退包本身也有问题，就等于把第二次事故叠在第一次事故上。

还有一点，回滚不是只看 HiveOS 面板。矿池端的算力延迟、拒绝率、结算统计都要看。有些机器面板显示正常，实际矿池端掉了有效份额；有些机器刚恢复时算力漂亮，半小时后因为参数不稳又掉。我们现在把“回滚完成”的标准定为至少观察两个统计周期，而不是机器上线就算完事。

复盘会只问谁点错，判断是事故还会再来

很多矿场复盘会开得很快：谁操作的，为什么点错，下次注意。听起来有结果，实际上没有任何改变。真正有用的复盘，应该把事故拆成几个环节：为什么这个人能操作全场，为什么测试组和生产组容易混，为什么告警没有指出批量任务，为什么回滚材料不完整。

我们现在复盘不先问“谁的锅”，而是先还原时间线。几点创建任务，几点开始掉算力，第一条告警是什么，现场几点响应，远程几点确认原因，几点开始回滚，最终损失多少有效算力。时间线一出来，问题自然会露出来。

比如有一次复盘发现，真正拖慢处理速度的不是找不到原因，而是没人敢决定暂停全场任务。于是我们增加了一条值班授权：当同一棚位异常超过设定比例，夜班负责人有权先停止正在执行的批量任务，不用等老板或主管回复。这个权限以前没有，大家只能在群里等人拍板，机器就在那儿掉算力。

复盘最后必须变成改动项，而且要有截止时间。比如本周内完成账号拆分，下次升级前完成测试组命名调整，月底前把告警分级接入值班表。没有这些动作，复盘就是情绪宣泄。

假期前还想批量升级，判断是时间选择不合格

今天不少矿场会遇到一个现实问题：行情波动、假期值班、人手不齐，但系统升级、矿池切换、参数调整又不能完全停。越是这种时候，越不能把大动作安排在交接班、深夜或负责人外出的时间段。

HiveOS 的批量管理很适合提高效率，但它不适合在没人盯的时候冒险。我们现在给批量任务设了几个硬规则：节假日前一天不做非必要升级；夜间只允许执行已有预案里的动作；涉及钱包和矿池地址的调整必须白天双人确认；大规模镜像切换必须提前通知现场，让人知道异常时该去哪个机架看。

还有一个简单但很有用的办法：每次批量操作前，在群里发一条固定格式的确认消息，写清楚操作对象、机器数量、预计影响、回滚方案和负责人。不是为了形式，而是让所有人看到“这次到底要动哪里”。如果连这五项都写不出来，就说明这次操作还没准备好。

HiveOS 能让矿场少跑很多路，也能让管理更清楚，但前提是别把它当成万能遥控器。批量按钮越方便，越要先把范围锁住；告警越密集，越要分出轻重；权限越多，越要拆细；回滚越重要，越要提前演练。

今天如果只做一件事，我建议矿场运维负责人马上检查三项：第一，生产组和测试组是否真的隔离，批量任务会不会误选；第二，当前账号里有没有人能同时改钱包、改矿池、推全场；第三，最近一次升级或配置调整，能不能在十分钟内拿出回滚清单。查完这三项，再决定要不要点那个批量执行按钮。