文章目录
今天最该防的是 HiveOS 批量操作把一台小故障放大成整排停机
凌晨 2 点 17 分，值班手机只震了三下就安静了。A3 排有 18 台矿机算力掉到 0，HiveOS 面板上先是红了一片，随后又恢复成“在线”。当班同事以为是矿池短暂抖动，按惯例在群里发了一句“观察中”。到 3 点 40 分，我被电话叫醒时，A3 排已经扩散到 A4、B1 两排，合计 67 台机器在反复重启，真正稳定出算力的只剩三分之一。
这次事故后来查清楚了：起因并不复杂，一台机器风扇转速异常，触发了温度告警；值班人员想批量套用一份保守配置，把同型号机器先降频保住运行。但他点选矿工组时多勾了一个标签，配置被推到了另一批不同显存、不同超频参数的机器上。更糟的是，告警规则之前被调得太松，连续重启没有及时升级到电话通知，直到矿池端收益曲线明显断崖，才有人意识到问题变大了。
我写这篇不是为了说 HiveOS 不好用。恰恰相反，矿场离不开这类系统。问题在于，批量管理越方便，事故放大的速度也越快。今天矿场运维最该盯紧的风险，不是面板上有没有红点，而是有没有一套流程能限制“一个误操作”扩散成“整排停机”。
夜班只看到在线：在线状态不能当作机器健康
这次复盘里，最容易被忽略的细节是：大部分机器在 HiveOS 里显示“在线”。
值班人员看到在线，就会本能地觉得机器还活着，问题不大。但矿场真正关心的不是机器有没有连上系统，而是它有没有稳定提交有效份额。事故发生时，有些机器每隔几分钟重启一次，HiveOS agent 会短暂上线，面板看起来并没有彻底失联；矿池端却已经几乎收不到正常 share。
后来我们把夜班检查口径改了。在线率只能排第三，前两项是矿池有效算力和最近 15 分钟拒绝率。如果有效算力低于本地显示算力太多，或者拒绝率突然抬头，即使 HiveOS 仍然显示在线，也要按异常处理。
这条规则听起来简单，但很管用。以前值班喜欢盯着总算力曲线看，现在要求按矿机组看，尤其是同一排、同一电箱、同一批显卡的变化。因为矿场里的事故很少平均发生，通常都是一组先出问题。早发现一组，就能少拖一小时。
批量推配置前多勾一个标签：方便操作必须配限制
HiveOS 的批量管理是矿场效率的来源，也是误操作最容易扩散的地方。
事故当天，值班人员原本只想处理 A3 排同型号机器，但标签命名太随意：A3-3060、A3-old、temp-safe、night-group 混在一起。有人为了方便，给部分机器临时加过标签，后来没删。结果一批本不该接收新参数的机器，被一起推了配置。
复盘会上我没有只追究“谁点错了”。点错当然要承担责任，但更大的问题是系统允许他在夜班一个人完成这种操作。
现在我们把批量操作拆成了三个等级。
第一类是低风险操作，比如重启单台矿机、刷新状态、调整告警备注，值班可以独立完成。
第二类是中风险操作，比如批量重启、切换矿池备用地址、调整轻微超频参数，需要在运维群里发操作截图，另一个人确认机器数量、标签和目标配置。
第三类是高风险操作，包括批量刷系统、批量升级镜像、推送新 flight sheet、修改大范围超频模板，夜间默认禁止。除非出现明确的收益损失或安全风险，必须由负责人电话确认，并留下操作前后截图。
这不是为了把流程搞复杂，而是为了让系统别把人的手滑变成矿场的停机。HiveOS 可以一键推送，我们就必须给“一键”加上刹车。
告警没有升级到电话：消息太多等于没人听见
这次事故里，告警其实发出来了，但没有变成有效提醒。
原因很现实：过去一段时间，矿场温度波动、单卡掉线、矿池短时拒绝都很多，群里每天几十条告警。值班人员慢慢形成习惯，只看红色持续多久，不看每条含义。为了减少打扰，我们还把部分告警的电话通知关掉了，只保留 App 推送和群消息。结果真正该叫醒人的时候，它没有叫醒。
后来我们重新整理了 HiveOS 告警规则，重点不是“多报警”，而是分清楚什么必须升级。
单台矿机掉线 5 分钟，只发群消息；同一机架 3 台以上同时掉算力，发给值班手机；同一矿工组有效算力 10 分钟内下降超过设定比例，直接电话通知；连续重启超过两次，不再当普通离线处理，而是进入事故检查。
还有一条很关键：告警必须绑定动作。比如“温度过高”后面写清楚先看风扇转速、再看环境温度、再决定是否降频；“批量拒绝率升高”后面写清楚先查矿池连接，再查最近配置变更。告警如果只告诉你“出事了”，它很快就会变成噪音。告警如果能告诉你“先查哪三件事”，夜班才有机会稳住局面。
临时账号能改全场：权限松一次就会留下隐患
事故后查操作记录，我们发现一个更危险的问题：当晚执行批量配置的人，用的是一个临时提升过权限的账号。
这个账号原本是为了白天协助新机上架，给过较高权限。按规定当天应该收回，但因为忙，没人处理。到了夜里，它还可以改矿工组、推配置、重启多台机器。也就是说，即使这次没有误操作，权限本身也已经埋了雷。
矿场里最怕这种“临时方便”。临时给权限、临时建标签、临时改模板、临时关告警，单看每一步都有理由，累计起来就会让系统变得不可控。
现在我们的做法是把 HiveOS 账号按岗位拆开。巡检人员只能看状态和备注；夜班可以处理单台机器和低风险动作；组长可以发起批量操作，但需要二次确认；管理员账号只在固定电脑上使用，不再给个人长期登录。临时权限必须写明截止时间，到点就撤，不靠人记。
还有一点我们要求很死：共享账号停用。以前为了方便，几个人共用一个账号，出事后只能知道“这个账号做了操作”，不知道是谁做的。现在每个人单独账号，操作记录能对应到人。不是为了事后甩锅，而是为了让每个人在点确认前多看一眼。
回滚文件找不到：没有退路的升级就是赌博
很多矿场在 HiveOS 上做升级，喜欢盯着新版本能不能提升稳定性、识别新卡、修复驱动问题，却容易忽略一个问题：失败了怎么退？
这次事故虽然不是系统升级引起的，但回滚混乱把处理时间拉长了。我们想把受影响机器恢复到事故前配置，却发现模板版本没有统一备份。有的机器用的是上周参数，有的机器临时改过风扇策略，有的机器备注里写了“勿动”，但原因没人记得。最后只能一台一台比对，越急越慢。
复盘后，我们给 HiveOS 运维加了一条硬规则：任何批量操作前，必须留下可恢复的状态。
具体包括三件事。第一，批量改配置前，先导出或截图当前 flight sheet、超频参数、矿工组名单。第二，新参数不直接推全场，先选 3 到 5 台同型号机器跑满一个观察周期。第三，每次批量操作都要写回滚方案，哪怕只有两句话：回到哪个模板、影响哪些机器、谁负责确认恢复。
回滚不是出了事才想的动作，而是操作前就该准备好的退路。矿场运维里，最值钱的不是你能多快把新配置推下去，而是推错之后能不能在 15 分钟内拉回来。
事故复盘只骂人：流程不改，下次还会换个人出错
事故处理完那天早上，我把当晚所有记录拉出来看：告警时间、操作时间、矿池曲线、重启日志、账号记录、群消息。看完之后很明显，这不是一个人的问题，而是一串小漏洞连在一起。
标签没有清理，权限没有回收，告警没有升级，回滚没有备份，夜班没有二次确认。任何一个环节拦住了，损失都不会那么大。
所以复盘会最后没有停在“以后注意”。“以后注意”在矿场里基本没用，夜里困、机器多、行情波动、老板催收益，人一定会犯错。能防住事故的，是把容易犯错的地方提前堵住。
我们当天就改了四件事：清理所有临时标签；收回超过岗位需要的权限；重写告警升级规则；建立批量操作前后的截图归档。第二天又补了一件：每周随机抽一次回滚演练，挑一组机器模拟配置推错，看值班能不能按文档恢复。
HiveOS 给矿场带来的效率很明显，但效率不能只体现在批量开机、批量换池、批量调参上。真正成熟的运维，是批量动作有边界，告警能叫醒对的人，权限不会越放越大，回滚不是靠记忆。
今天如果你负责一个矿场，建议先别急着研究新版本功能，先打开自己的 HiveOS 后台做六个检查：有没有长期不用的高权限账号；有没有含义不清的机器标签；告警是否能区分单台故障和成组异常；批量操作是否需要二次确认；关键模板有没有备份；最近一次回滚演练是什么时候做的。
这六项查完，可能不会让今天收益立刻变高，但它能减少一次深夜大面积停机。对矿场来说，少一次这种事故，就是实打实的利润。
