今天最危险的不是矿机掉线而是 HiveOS 批量指令发错对象

凌晨两点十七分，值班手机连续震了二十多下。监控屏上不是一台机器红，也不是一排机器灰，而是东二区、南一区、临时测试架一起掉了算力。最刺眼的是 HiveOS 面板里那条操作记录：同一个账号，在 2:13 对 428 台矿机下发了同一套飞行表。

这不是我们第一次遇到批量操作事故，但这次最让人后背发凉的地方在于，指令本身没有错，目标错了。配置是给新到的一批显卡机准备的，频率、电压、矿池参数都经过测试；问题是测试分组和生产分组在前一天搬机后没有重新核对，值班同事在 HiveOS 里选组时，以为自己点的是“测试架”，实际覆盖到了两个生产区。

事故持续了 34 分钟，表面损失是这一段时间少出的币，真正的损失是现场被迫停下其他巡检、远程和机房反复确认、两名工程师半夜赶回宿舍开电脑处理。复盘以后我给团队定了一条规矩：HiveOS 的风险，不只在机器坏了会不会报警，更在于人点错一次，系统会不会帮你挡一下。

测试架和生产区混在一起，判断分组名称不能再靠记忆

这次事故的起点很小。前一天晚上机房调整风道，把 60 多台机器从临时架挪到东二区。搬完以后，线缆、IP、机器名都更新了，但 HiveOS 里的农场分组没有同步改完。面板上还能看到“test”“temp”“GPU-new”这些名字，值班同事按过去经验操作，结果选中了包含生产机器的组。

以前我们觉得分组只是为了方便看面板，后来才发现，分组就是批量操作的安全边界。边界一旦模糊，HiveOS 越好用，风险越大。一个按钮能批量换矿池、批量改钱包、批量重启、批量升级，这些功能在正常情况下省人，出错时也会放大人的失误。

复盘后我们把命名规则重新做了一遍，不再用“临时”“新机”“测试”这种容易过期的词。现在分组必须带三个信息：机房区域、机器类型、操作级别。比如“东二区-A卡-生产”“西一架-N卡-测试”“维修台-禁止批量”。只要机器从测试区转入生产区，现场人员必须在交接单上勾选 HiveOS 分组更新，不更新就不能算搬机完成。

还有一个细节很重要：每天下班前，白班要抽查当天移动过的机器，核对面板分组和实际位置是否一致。不是为了形式，而是为了防止第二天凌晨值班的人拿着旧信息做新操作。

夜班收到上百条告警，判断告警太多等于没有告警

事故刚发生时，HiveOS、矿池、机房温控、网络监控都在发消息。算力下降、矿机离线、风扇异常、矿池拒绝率升高，一分钟内刷了一屏。值班同事第一反应是网络问题，因为同时掉了很多台；第二反应是电力波动；直到翻 HiveOS 操作记录，才看到批量飞行表变更。

这说明我们的告警不是不够，而是没分层。所有消息都用同一种声音推到群里，最后真正关键的“有人对几百台机器做了配置变更”被淹没在一堆结果告警里。

现在我们把告警分成三类。第一类是资产级告警，比如钱包地址变更、矿池地址变更、批量飞行表切换、批量升级、批量重启，这类不管发生在白天还是夜里，都必须单独推送到负责人手机，并且要求值班人员在 5 分钟内回复确认。第二类是生产级告警，比如大面积掉算力、大面积离线、拒绝率异常，这类推值班群和区域负责人。第三类是设备级告警，比如单台温度高、单台风扇异常、单台掉线，按区域汇总，不再逐条轰炸。

HiveOS 本身能提供不少状态信息，但矿场不能把所有信息都当同一种“报警”。对运维来说，先知道“谁动了什么”，往往比先知道“哪些机器掉了”更重要。因为前者能直接指向原因，后者只是结果。

一个账号能改全场，判断权限设计已经不适合大矿场

事故账号是夜班值班号，按老习惯给了比较高的权限。原因也很现实：夜里出问题，如果账号权限太低，值班人员还要等负责人授权，可能耽误恢复。这个逻辑过去在几十台机器时能凑合，但到几百台、上千台时就不行了。

一个夜班账号既能看状态，又能改飞行表，还能批量执行命令，本质上就是把半个矿场交给一次点击。人不可能永远不困、不急、不看错，权限设计必须默认人会犯错。

我们后来把 HiveOS 权限重新拆开。值班账号可以查看全场，可以重启单台或少量机器，可以对指定测试组应用配置，但不能对生产组做大批量修改。生产组如果要换矿池、换钱包、批量升级、批量降频，必须由负责人账号发起，另一个管理员复核。夜间确实需要紧急处理时，先临时授权到具体分组和具体时间，过期自动收回。

这里最容易被忽视的是离职、换岗和外包维护账号。以前有些临时账号用完没有删，只是没人再登录。复盘时我们专门查了一遍，发现仍有几个账号保留了查看或操作权限。现在每周一固定导出账号清单，检查最近登录时间、权限范围、绑定邮箱和手机。权限不是开一次就完事，它需要像巡检矿机一样定期巡检。

回滚时才发现没有旧配置，判断备份不能只存在聊天记录里

事故发生后，我们第一时间想回滚到原来的飞行表。问题是，有些机器前两天刚调过参数，最新稳定版本没有完整记录。群里能找到几张截图，工程师电脑里有一份旧配置，HiveOS 面板也能翻一部分历史，但这些东西拼起来才勉强还原。

真正耽误时间的不是点击回滚，而是确认“回到哪一个版本”。如果不知道上一版稳定配置是什么，回滚就会变成另一轮试错。尤其是混合机型矿场，不同显卡、不同电源、不同散热位置用同一套参数，可能恢复了算力，却带来温度和拒绝率问题。

现在我们的做法很笨，但有效。每个生产分组保留一份“稳定飞行表”，命名里带日期和负责人，比如“东二区A卡稳定-0428-老周”。任何批量修改前，先复制当前配置，备注修改原因；修改后观察至少一轮结算周期，再决定是否把新配置升为稳定版。没有备注的配置不能用于生产组批量应用。

另外，回滚不再允许全场一把梭。即使事故看起来影响很大，也先选 5 到 10 台代表机器恢复，确认矿池连接、算力、温度、拒绝率正常，再扩大到一个机架，最后到整个分组。这样做会多花几分钟，但比全场来回切两遍安全得多。

现场喊人远程点按钮，判断工单必须比语音更可靠

这次事故里还有一个问题：夜班在群里喊“帮我把东二区切回旧表”，远程工程师看到消息后立刻处理，但两个人对“东二区”的理解并不完全一致。现场说的是物理区域，工程师看的却是 HiveOS 分组。幸亏第二次操作前多问了一句，不然可能又覆盖一批不该动的机器。

矿场运维最怕这种口头指令。现场急，远程也急，大家都想快点恢复，但语音和群消息很容易丢上下文。尤其是凌晨，几个区域同时出问题时，一句“那批机器”可能指三种对象。

我们现在要求所有批量动作必须有最简工单，即使夜里也一样。工单不用复杂，但必须写清楚四件事：操作对象、操作内容、影响范围、回退方式。比如“对象：东二区-A卡-生产，内容：回滚至 0428 稳定飞行表，范围：128 台，回退：如拒绝率超过 3% 切回 0427 配置”。执行人在 HiveOS 操作前截图，执行后再截图，放到同一条记录下面。

这不是为了事后追责谁，而是为了让正在救火的人少猜。流程写清楚，远程工程师不用反复问，现场负责人也能确认对方没有理解错。

大面积掉算力后恢复很快，判断复盘不能只看损失金额

34 分钟后，大部分机器恢复正常。矿池端算力曲线开始回升，机房噪音也恢复到平时的状态。那一刻大家都松了口气，很容易把这件事归为“小事故”。但我在复盘会上说，这次要按大事故处理。

原因很简单：如果当时下发的不是错误超频参数，而是错误钱包地址呢？如果不是 428 台，而是全场 1500 台呢？如果操作发生在行情剧烈波动、矿池切换频繁的那一天呢？损失金额只是这次运气下的结果，不是风险本身的大小。

所以复盘不能只问少挖了多少币，还要问几个更实际的问题：为什么错误对象能被选中？为什么高权限账号在夜间能直接批量操作？为什么关键操作告警没有优先跳出来？为什么回滚版本需要临时拼？为什么现场和远程对分组名称理解不一致？

这些问题每解决一个，HiveOS 的价值才真正发挥出来。它不是让矿场少雇两个人那么简单，而是让几百台机器的操作变得可确认、可限制、可恢复。

今天就能改的三件事，判断不要等下一次误操作提醒你

如果你的矿场也在用 HiveOS，今天不一定要大改系统，但至少可以先做三件事。

第一，打开面板，把所有生产分组和测试分组重新看一遍。凡是名字含糊、人员看不懂、机器已经搬走但分组没变的，马上改。不要相信“大家都知道”，矿场最不可靠的就是这句话。

第二，检查账号权限。夜班账号、维修账号、外包账号、离职人员账号，一个个过。能看就别给改，能改单台就别给批量，能操作测试组就别碰生产组。需要临时放权就设时间，到点收回。

第三，给每个生产分组留一份确认过的稳定配置，并写清楚回滚顺序。不要把配置截图散落在微信群，也不要只放在某个工程师电脑里。真正出事时，你需要的是一眼能找到、所有人都认的版本。

矿场运维最怕的不是机器坏，机器坏了有备件、有维修、有巡检。更麻烦的是系统把一个人的误判断放大成几百台机器的同一动作。HiveOS 用得越熟，越要给批量操作加护栏。今天花半小时把分组、告警、权限、回滚过一遍，可能就是下一次凌晨不用全员起床救火的原因。