文章目录
今天最容易把矿场拖停的风险，是 HiveOS 批量操作没人二次确认
凌晨两点十七分，值班手机连续震了六次。不是矿池掉线，也不是机房断电，而是同一排 84 台机器的算力曲线一起往下掉。监控屏上看得很清楚：温度没冲高，风扇还在转，网络延迟正常，但显卡功耗像被人一刀切平。五分钟后，第二排也开始掉。
我第一反应不是去看矿池，而是打开 HiveOS 的活动记录。问题很快暴露出来：一个本来只该下发到测试组的飞行表，被批量推到了生产组。操作人不是新人，是我们最熟的夜班同事；问题也不是他不会用 HiveOS，而是我们的流程默认“能点就能发”，没有把批量动作当成高危动作来管。
这次事故没有烧卡，也没有造成长时间停机，但它给了我一个很明确的提醒：矿场现在最危险的不是不会自动化，而是自动化太顺手以后，错误也能被顺手放大。
夜班一键下发到全场，我判断这不是误操作而是流程缺口
事故发生前，我们在做一组新内核和新超频参数的验证。测试组只有 12 台机器，卡型、内存批次、散热位置都比较接近，本来计划跑满 24 小时再扩大到 60 台。
问题出在 HiveOS 的农场分组命名上。测试组叫 A1-Test，生产组叫 A1-Run，排序挨得很近。夜班同事根据工单执行“应用飞行表”，但工单里只写了 A1，没有写完整组名，也没有附截图确认。HiveOS 本身可以很方便地批量应用配置，这个优势在矿场扩容时很省人，可当分组、标签、工单描述都不严谨时，它也会把一个小错误放大成一排机器的问题。
复盘时我没有把责任压在个人身上。因为这类事如果只罚一个操作人，下次还会发生。真正的问题是我们没有给批量操作设置更高门槛：没有要求二次确认，没有限定夜间可执行范围，也没有把测试组和生产组在命名上彻底区分开。
后来我们改了三件小事。
第一，所有测试组统一加上 Sandbox 前缀，生产组统一加上 Prod 前缀，中间不再使用相似缩写。第二，任何超过 20 台矿机的 HiveOS 批量配置变更，必须由另一个人确认设备数量、飞行表名称和目标钱包。第三，夜间只允许执行恢复类动作，不允许扩大新参数范围，除非负责人在群里明确授权。
这些听起来不复杂，但对矿场很有用。因为事故往往不是发生在没人会操作的时候，而是发生在大家太熟、太相信习惯的时候。
告警一晚上响了三十多次，我判断先要砍掉噪音
这次掉算力，HiveOS 告警其实有触发，但它没有第一时间把最关键的信息推到我面前。原因很简单：我们的告警太多了。
单卡低算力、矿工重启、温度短时波动、矿池短连、风扇转速跳变，很多都在群里刷。值班人员看多了以后，会自动把告警当成背景音。等真正需要判断“是不是批量配置事故”时，反而要在一堆消息里翻。
事故后，我把告警分成了三档。
第一档是必须叫醒人的告警，比如同一分组 10% 以上机器在 5 分钟内同时掉算力、同一钱包收益路径异常、同一飞行表变更后大面积重启。这类告警要走电话或高优先级推送，不能只丢到群里。
第二档是值班处理的告警，比如单机离线、单卡降算力、温度持续偏高、矿工进程重启失败。这类保留在运维群，但必须绑定处理时限，不能只看不管。
第三档是记录类告警，比如短时网络抖动、单次重连、低于阈值的小幅波动。这类不再打扰人，只进日报，用来观察趋势。
HiveOS 的通知能力够用，关键是矿场自己要决定什么值得吵醒人。以前我们追求“什么都报”，现在改成“只让关键风险大声报”。告警如果不能帮助值班人员排序，它就不是保护，反而会消耗注意力。
临时账号能改钱包，我判断权限已经越过了运维边界
复盘时还有一个细节让我后背发凉：夜班账号虽然没有动钱包，但它具备修改钱包和飞行表的权限。也就是说，这次事故只是参数下错；如果同样的权限被误用，或者账号被盗，损失就不只是停机几个小时。
矿场里很多人习惯把 HiveOS 账号当成“登录后台的钥匙”，谁要干活就给谁开一个权限大一点的账号，方便沟通。但矿场规模一上来，这种方便会变成风险。尤其是外包维修、临时调试、远程协助时，权限如果不拆细，后面很难追责。
我们现在的做法是把账号按工作场景拆开。
巡检人员只能看状态、标记问题、重启单机，不能改飞行表。调参人员可以对测试组应用配置，但不能改钱包，也不能碰生产组。值班主管可以执行生产组恢复动作，但扩大范围要二次确认。只有少数管理账号能改钱包和全场策略，而且不能用于日常登录。
同时，临时账号必须有到期时间。以前我们给厂商远程看问题，开完账号经常忘记关。现在所有临时账号默认当天失效，延期必须重新申请。HiveOS 里能看活动记录，但前提是你先把人和权限分清楚，否则日志里只会显示“某账号做了某动作”，却很难说明这个动作当时是否应该被允许。
权限管理的核心不是不相信人，而是不要让一个人、一个账号、一次误点有能力影响全场。
回滚只靠记忆找旧参数，我判断这会拖慢恢复速度
事故处理中最耗时间的，不是发现错误，而是回到之前状态。那天我们要确认原来的飞行表、超频模板、矿工版本、钱包配置是否一致。幸好工单里有部分截图，不然恢复会更慢。
这件事让我意识到，很多矿场说自己有回滚，其实只是“老员工记得怎么改回去”。这种回滚靠经验，平时看不出问题，一到夜里、跨班、多人协作，就会变得很慢。
现在我们要求每次 HiveOS 变更前都留下四样东西：目标机器列表、变更前飞行表截图、变更后参数说明、预计观察时间。只要是超过 20 台机器的动作，还要写清楚回滚触发条件，比如 15 分钟内掉算力超过 5%、拒绝率明显上升、温度超过某个线，就立刻撤回，不再继续观察。
另外，回滚不能只写“改回旧配置”。要把旧配置保存成明确的模板，并注明适用卡型和日期。比如同样是稳定参数，夏季和冬季未必一样；同样是 3070，三星显存和海力士显存也不能混着套。HiveOS 可以让我们批量管理，但批量回滚也必须精确，不然恢复动作本身又会制造新的问题。
复盘后我们做过一次演练：随机抽一个生产分组，假设新飞行表导致算力下降，要求值班人员在 10 分钟内定位变更记录、找到上一版本、完成回退并截图记录。第一次演练花了 23 分钟，第二次压到 11 分钟，第三次才勉强进入 8 分钟以内。这个过程比写制度更真实，因为它能暴露谁不知道模板放哪、谁没有权限、谁不清楚通知谁。
工单写得像聊天记录，我判断责任链断在了执行前
很多矿场出问题后喜欢查日志，但我现在更愿意先查工单。因为日志记录的是已经发生的动作，工单决定的是动作发生前有没有被说清楚。
这次事故的工单就很典型：一句“今晚 A1 组套新参数，观察稳定性”，看着没问题，实际上埋了很多坑。A1 是测试组还是生产区域？新参数是哪一个版本？观察多久？异常后谁拍板回滚？有没有禁止扩大范围？这些都没写。
后来我们把 HiveOS 相关工单改成固定格式，但不做成复杂表格，只要求每次说清五句话：
要动哪一组机器，具体到分组名和数量；
要改什么，具体到飞行表、矿工版本或超频模板；
为什么改，是测试、恢复、降温还是切矿池；
多久判断一次结果，用什么指标判断；
出问题怎么退，谁有权决定退。
这五句话写清楚，很多事故会在执行前就被拦下来。比如执行人看到“12 台测试机”，但 HiveOS 页面显示选中了 84 台，他自然会停手确认。流程不是为了把人拖慢，而是为了让人有理由在不确定时按下暂停。
今天的改造重点，我建议先从三条硬规则做起
如果你的矿场正在用 HiveOS，而且机器数量已经超过几十台，我建议今天就检查三件事，不用等大事故发生后再补。
第一，检查所有能批量操作的账号。凡是能改钱包、飞行表、全场配置的账号，都要重新确认使用人、使用场景和是否需要保留。临时账号当天关，离职人员账号立刻清，外部协助账号只给最小权限。
第二，把批量变更门槛写死。超过一定数量的矿机，必须二次确认；夜间禁止扩大新参数范围；测试组和生产组命名必须一眼能分开。不要相信“大家都知道”，系统页面不会替你理解习惯。
第三，做一次真实回滚演练。不要只问“会不会回滚”，而是让值班人员当场操作：找到上一版配置、确认目标机器、执行回退、检查算力恢复、补齐记录。演练中卡住的地方，就是下一次事故里会拖住你的地方。
HiveOS 对矿场的价值很大，批量装机、远程监控、飞行表管理、告警通知，都能节省大量人力。但越是好用的系统，越要把危险动作管细。今天最该防的，不是某个按钮不好用，而是一个太顺手的批量操作，在没有确认、没有权限边界、没有回滚准备的情况下，把小问题推成全场问题。
