HiveOS 批量改配置前，今天最怕的不是掉算力，是没人知道谁按了确认

凌晨 1 点 37 分，值班手机连续震了 12 下。不是矿机全场离线，也不是矿池挂了，而是 C 区两排机器算力像被剪了一刀，先掉 20%，再掉到 60% 左右。现场同事拿着手电过去看，风扇声还在，网线灯也亮，机器没死，但 HiveOS 面板上同一批 worker 的 Flight Sheet 已经被换成了另一套配置。

最麻烦的地方在于，面板里能看到配置变了，却一时说不清是谁改的、为什么改、改了哪些组、有没有同步到其他区。那半个小时里，我们不是在修机器，而是在追动作：哪个账号登录过，哪个标签被选中，哪条批量命令执行成功，哪几台因为离线没吃到新配置。

这次事故损失不算最大，但把矿场运维里最容易被忽视的一件事暴露得很彻底：HiveOS 的批量管理越方便，误操作的半径就越大。以前一个人改错一台，现在一个人点错一次，可能就是几百台。

夜班批量切换：方便不等于可以随手点

那天晚上本来只是要给 36 台高温机器降一点超频参数。值班工程师为了图快，在 HiveOS 里按标签筛选了“C 区高温”，但标签维护不干净，里面混进了上周临时测试过的另一批机器。更糟的是，他没有先点开 worker 列表逐台确认，而是直接套用了新的 Flight Sheet 和 OC 模板。

从运维负责人的角度看，这不是个人粗心这么简单。真正的问题是，我们把“批量操作”当成了高级按钮，却没有把它当成高风险动作管理。

HiveOS 的强项就在于能批量下发配置、改矿池、切钱包、调整超频、重启 miner。矿场规模一大，如果还靠一台台 SSH 或人工进后台，效率肯定不行。但批量操作必须有边界：哪些标签能批量改，哪些动作必须二次确认，哪些账号只能看不能改，哪些区域不能跨组执行。

事故后我们做的第一件事，不是培训大家“以后小心点”，而是把标签重新拆了一遍。生产区、测试区、维修区、待观察区分开；高温、低算力、频繁重启这种状态标签只作为筛选参考，不能直接作为执行对象。真正允许批量下发的，必须是经过确认的固定分组。

这个改法很笨，但有效。矿场里最怕的不是没有工具，而是工具太顺手，顺到让人忘了它的杀伤范围。

面板还在出数：掉算力不一定会触发正确告警

这次事故还有一个细节：HiveOS 没有一开始就把它当成严重故障。因为机器在线，矿工进程也在跑，只是算力下降、拒绝率上升。对很多告警规则来说，这种状态比“离线”更难处理。

以前我们设置告警，喜欢盯几个简单指标：离线、温度过高、风扇异常、算力低于阈值。可矿场实际出问题，经常不是这么干脆。配置改错后，机器可能还在跑；矿池地址填错一位，面板可能还没立刻红；OC 参数不合适，算力会抖，不会马上归零；某些显卡会降频自保，看起来像“还能挖”，但收益已经漏了一截。

所以复盘时我要求把告警从“单点报警”改成“组合判断”。比如同一组机器在 10 分钟内同时出现算力下降、功耗变化、拒绝率抬高，就要比单台机器掉线更优先；某个账号执行批量配置后，相关 worker 在 30 分钟内出现异常，也要自动推送给值班群；夜间任何超过 20 台机器的配置变更，都必须把变更记录单独发出来，而不是埋在日志里等人去翻。

告警不是消息越多越好。以前我们的群里一天几百条提醒，真正有用的反而被淹没。现在我们把告警分成三类：需要立刻到现场的，值班工程师 5 分钟内响应；需要远程处理的，先看面板和日志；只做记录的，白天统一复盘。分类以后，夜班反而安静了，但该响的时候更刺耳。

HiveOS 面板能告诉你很多数据，但矿场要自己定义“什么组合意味着要停手”。这是运维负责人的活，不能全丢给系统默认规则。

临时账号能改生产组：权限松一次就够出事

追日志时我们发现，执行那次批量动作的账号并不是主管账号，而是一个给夜班临时开的维护账号。它本来只应该处理维修区机器，但权限开得太宽，能看到生产区，也能改生产区配置。

这类问题在矿场很常见。机器多、班次多、外包维护多，大家为了方便，会临时给账号权限。今天要换风扇，明天要查网线，后天要帮忙看矿池，权限越开越大，最后没人记得收回来。

HiveOS 的团队和权限管理如果不用好，等于把矿场大门钥匙挂在值班室墙上。不是所有人都应该能改 Flight Sheet，也不是所有人都应该能下发超频模板。更不是所有人都应该能批量重启、批量刷机、批量修改钱包地址。

我们后来的做法很直接：权限按动作拆，不按人情拆。现场维修只能看状态、重启单台、备注故障；夜班值守可以处理离线和低算力，但不能改钱包和矿池；高级运维可以改配置，但批量超过一定数量要主管确认；外部协助账号必须限定时间，到点自动停用；离职、调岗、项目结束当天清账号，不拖到月底。

还有一条规定很不讨人喜欢，但必须执行：任何能影响收益路径的动作，都不能只有一个人知道。改矿池、改钱包、批量套模板，必须留下工单编号和原因。不是为了追责好看，而是出问题时能少花 20 分钟猜谜。

矿场事故很多时候不是技术难，而是权限太松，导致错误动作跑得太远。

有备份也慌乱：回滚不能只靠记忆

事故发生后，大家第一反应是“赶紧改回去”。问题是改回哪一版？C 区原来有几套参数？哪些机器因为温度不同已经单独调过？那批测试机是不是本来就不该回到生产模板？

如果没有清晰的版本记录，回滚就会变成另一轮赌博。矿场运维最怕的就是第一次操作错了，第二次补救又扩大问题。

HiveOS 里常用的 Flight Sheet、钱包、矿池、OC 模板，都应该有命名规则。我们以前的命名很随意，什么“新配置”“临时降压”“C区优化版”“测试2”一堆，看起来像个人草稿。复盘后全部改掉：区域、币种、矿池、日期、用途、负责人写进名称；生产模板和测试模板分开；停用模板不删除，先归档；重大改动前导出当前配置，并在工单里截图留存。

回滚流程也重新写了一遍。不是出了事再问谁记得，而是规定动作：先冻结继续批量操作，确认受影响 worker 列表，拉取最近一次变更记录，选定回滚模板，小批量恢复 5 到 10 台观察，确认算力、温度、拒绝率正常，再分组放大。每一步都有人报数，不能一句“应该好了”就结束。

这套流程看上去慢，但比全场乱点快得多。真正耽误时间的不是谨慎，而是没有路线图。

白天复盘现场：事故报告要写给下一班人看

第二天上午复盘，我没有让大家先讨论“谁的问题”，而是把时间线投在屏幕上：1 点 28 分账号登录，1 点 31 分筛选标签，1 点 33 分下发配置，1 点 37 分告警开始，1 点 46 分现场确认机器在线，2 点 08 分第一批回滚，2 点 31 分算力恢复到 95% 以上。

时间线一摊开，问题就很清楚：标签不准、权限过宽、告警不够敏感、模板命名混乱、回滚没有固定顺序。任何一个环节扎实一点，事故都不会拖那么久。

矿场复盘不能写成“加强管理、提高意识”。这种话贴在墙上没用。我们现在要求每次事故复盘必须产出三样东西：一条规则修改、一项权限调整、一个可检查的动作。比如这次对应的结果就是：批量操作前必须导出目标列表；夜班账号取消生产组配置修改权限；所有生产 Flight Sheet 重新命名并归档旧版本。

写给老板看的报告可以简短，写给下一班人的记录必须具体。下一班人不需要知道你有多后悔，他需要知道下次手机响的时候先点哪里、问谁、停哪个动作、用哪套模板回滚。

今天就能改的几件小事：先把误操作半径缩小

如果你现在也在用 HiveOS 管矿场，今天不一定要大改系统，但有几件事可以马上做。

先查账号。把所有能修改钱包、矿池、Flight Sheet、OC 模板的账号列出来，临时账号该停就停，外包账号该限就限。不要等事故后才发现一个半年没用的账号还握着生产区权限。

再查标签。凡是用于批量执行的标签，必须干净、固定、有人负责维护。状态类标签只做观察，不直接拿来下发配置。

然后查告警。不要只盯离线，把同组算力下降、拒绝率异常、配置变更后的波动放进夜间提醒。告警少一点没关系，但要能打到真正需要醒的人。

最后查回滚。把当前生产模板命名清楚，导出一份，写明适用区域和负责人。挑一个非高峰时段，拿 5 台机器演练一次从错误配置回到正常配置的过程。演练时别只看能不能点回去，要记录用了几分钟、谁有权限、哪一步最容易卡住。

HiveOS 能帮矿场省很多人力，但它不会自动替你建立纪律。批量管理、告警、权限、回滚这四件事，平时看起来像文档工作，出事时就是少掉多少算力、少熬多少夜的区别。今天最该注意的风险点很具体：在你准备批量确认之前，先确认这次操作真的只会影响你想影响的那一批机器。