文章目录
今天别让一条批量指令改完整个矿场
凌晨两点十七分，值班群里先跳出来的不是掉线告警，而是一张手机拍的配电柜照片：A 区第三排风扇声突然降了下来，巡检员以为是空开问题，跑过去才发现一排机器还亮着灯，但 HiveOS 面板上的算力在往下滑。再往前翻操作记录，问题很快露出来——一个本该只发给 24 台测试机的 Flight Sheet，被批量推到了整组 600 多台机器上。
这类事故不新鲜，但每次发生都让人难受。因为它不是硬件坏了，也不是矿池抽风，更不是网络完全断了，而是我们自己把一条指令放大了。矿场做大以后，HiveOS 的批量管理很省人，可省人的工具一旦没有边界，出错时也会成倍放大。
我现在看 HiveOS 运维，不再只看面板上算力漂亮不漂亮，而是看三件事：谁能发批量指令，指令发出去前有没有挡板，发错后能不能在十分钟内退回来。今天这篇就按一次真实事故复盘的方式，把我们后来改掉的流程讲清楚。
夜班改配置的现场，判断是权限边界先塌了
那天夜班的原计划很简单：把 A 区一小组机器从原矿池切到备用矿池，测试延迟和拒绝率。操作员在 HiveOS 里选了一个 Worker 分组，准备套用新的 Flight Sheet。问题出在分组命名上。
测试组叫 A3-test，生产组叫 A3-all。界面里两个名字挨得很近，加上夜里处理了几轮温度告警，人已经有点疲劳，最后选中了 A3-all。配置下发后，第一分钟没有明显异常，第三分钟开始部分机器重连，第五分钟拒绝率上升，第八分钟算力曲线变形。
事故复盘时，我们没有先骂人。人当然有责任，但只盯着人没用。真正的问题是，一个夜班账号为什么有权限给整组机器改 Flight Sheet？一个测试动作为什么能覆盖生产组？分组命名为什么允许这么接近？这些才是矿场系统管理里最容易被忽略的地方。
后来我们把 HiveOS 权限拆成三层：值班账号只能重启单机、查看日志、处理温度类动作；班长账号可以处理小批量分组，但不能改全场关键配置；负责人账号才能改矿池、钱包、批量超频和系统升级。更关键的是，负责人账号不再长期登录值班电脑，只在审批后临时使用。
权限不是为了显得管理正规，而是为了让一个疲劳的人在凌晨犯错时，错误不要直接穿透到全场。
分组命名混在一起的现场，判断是批量管理缺少安全距离
很多矿场用 HiveOS 管几百台、几千台机器时，最开始都是按区域、机架、币种随手建组。刚开始机器少，大家都认识，A1、A2、B1、test 这些名字也够用。等到规模扩大，问题就来了：测试组、生产组、待维修组、低功耗组、临时切换组混在一起，界面上看似清楚，夜里操作时就很危险。
我们后来做了一次分组清理，原则很笨，但有效。
生产组名称必须带固定前缀，比如 PROD；测试组必须带 TEST；维修组必须带 FIX；观察组必须带 OBS。生产组和测试组不能只差一个单词，不能出现 A3-all 和 A3-test 这种容易误点的组合。每个组下面还要写备注，说明机器数量、所在区域、默认矿池、默认钱包、责任人。
另外，超过 50 台机器的组，不允许直接做第一次配置变更。必须先在 3 台机器上试，再扩大到 20 台，再进正式组。这个流程看起来慢，但矿场最怕的不是多花十分钟，而是错一次之后全场陪你恢复两个小时。
HiveOS 的批量操作本身没有错，错的是我们把“批量”理解成“一次点完”。真正适合矿场的批量管理，应该是有坡度的：小组验证、半组观察、整组执行。任何能影响收益的钱包、矿池、超频、系统版本，都不能从零直接打到全场。
告警同时刷屏的现场，判断是消息太多反而没人负责
事故当天，值班群里其实有告警。掉算力、矿池连接异常、拒绝率上升、离线重连，几类消息几乎同时刷屏。问题是，消息太多，大家反而没有第一时间判断出“这是配置误发”，而是在猜网络、矿池、交换机、电源。
这也是很多矿场的通病：HiveOS 告警开得很多，但没有分级。温度高也响，单卡掉线也响，矿池拒绝也响，整组算力下跌也响。时间长了，值班员会形成免疫，看到一串红字先等一等，结果真正要命的告警也被淹没。
我们后来把告警重新分成四类。
第一类是立刻处理，比如整组算力在短时间内下跌超过设定比例、同一分组大面积重连、钱包或矿池配置变更后异常扩大。这类告警必须电话叫醒负责人，不只是在群里发消息。
第二类是班内处理，比如单台机器高温、单卡掉算力、个别矿机离线。值班员按工单处理，不需要全员惊动。
第三类是观察类，比如轻微拒绝率波动、短时延迟升高。这类只记录，不刷屏。
第四类是变更关联告警。只要有人在 HiveOS 里执行批量配置、批量重启、批量升级，系统监控就进入半小时观察期。这个时间段内出现的异常，不再按普通故障看，而是先和刚才的操作做关联。
这个改动救过我们几次。因为矿场出事时，最怕方向错。明明是刚刚改了配置，却先去查网线；明明是某个账号发了命令，却先怀疑矿池。告警不是越多越好，告警要能把人带到正确的地方。
回滚脚本找不到的现场，判断是恢复能力不能靠记忆
那次事故最狼狈的一幕，是大家已经知道配置发错了，却没有马上退回去。原因很现实：旧 Flight Sheet 有几个版本，备用矿池参数也有几套，谁也不敢保证哪个是事故前正在用的。最后只能翻操作记录、问白班、查截图，一边恢复一边确认。
这暴露出一个问题：很多矿场有变更动作，却没有变更快照。
后来我们给 HiveOS 运维加了一条硬规则：凡是涉及矿池、钱包、超频模板、系统版本的批量动作，执行前必须保存当前配置截图和导出记录，并写进变更单。不是为了应付检查，而是为了出事时能马上知道退到哪里。
回滚也不能只写一句“恢复原配置”。具体要写清楚：回滚用哪个 Flight Sheet，目标分组是多少台，先回哪几台，观察几分钟，什么指标恢复才算成功。如果回滚后拒绝率还是高，下一步是切备用矿池还是恢复旧超频，都要提前写出来。
我们还把常用回滚动作做成固定清单，放在值班电脑本地和云端各一份。这样即使 HiveOS 面板一时卡顿，或者某个负责人不在线，值班班长也知道按哪份流程走。
矿场恢复速度，不能依赖“老张记得怎么弄”。人会休假，会离职，也会在凌晨脑子发懵。流程写得越具体，事故越不容易扩大。
升级前临时加人的现场，判断是审批不能只靠群里一句话
HiveOS 运维里还有一个容易出问题的地方：临时授权。
比如要升级系统、调整一批异常机器、排查某个区域故障，负责人在群里说一句“给他开一下权限”，账号就加上了。事情做完以后，权限有没有收回？很多时候没人记得。几个月下来，矿场系统里会留下不少“临时账号”“外协账号”“曾经帮忙的人”。
这些账号平时不出声，一旦密码泄露、电脑中毒、人员离职，就会变成隐患。尤其是能改钱包、矿池和批量模板的权限，不能因为对方熟悉业务就长期挂着。
我们现在的做法是，临时权限必须带有效期。当天处理，当天收回；跨天处理，第二天重新审批。外协人员只能看指定分组，不给全场视图，更不能碰钱包和收益相关配置。所有临时权限变更，都要在工单里留下原因、时间、账号和操作范围。
审批也从“群里一句话”改成了固定格式：谁申请，为什么申请，操作哪一组机器，需要什么权限，预计多久结束，谁负责验收。格式看起来麻烦，但真正执行以后，反而减少了争论。出了问题，大家能迅速知道是谁动了哪里，不用在聊天记录里翻半天。
权限管理的目标不是防自己人，而是防混乱。矿场越大，越不能靠熟人关系管理系统。
复盘会只谈结果的现场，判断是流程改造要落到每天
事故结束后，如果复盘只写“加强培训、提高责任心”，那基本等于没复盘。我们以前也写过这种话，写完下次还会犯。后来复盘会只问五个问题。
第一，这次操作为什么能影响这么多机器？
第二，告警为什么没有第一时间指向配置变更？
第三，回滚为什么没有在十分钟内完成？
第四，哪个权限本不该存在？
第五，明天早班能改掉哪一条规则？
这五个问题逼着我们把事故拆成可执行的改动。比如分组重命名、权限降级、批量操作加二次确认、回滚清单更新、告警分级调整。每一条都指定责任人和完成时间，第二天早会上检查，不拖到月底。
HiveOS 是工具，矿场系统是流程。工具再好，如果流程里允许一个账号、一条指令、一次误点直接打穿全场，迟早会出事。相反，只要权限有边界，分组有安全距离，告警能分轻重，回滚能按清单执行，很多事故在刚冒头时就能被压住。
从今天开始，建议矿场运维负责人先做三件具体事：第一，检查 HiveOS 里所有能批量改矿池、钱包、超频和系统版本的账号，把不必要的权限降下来；第二，挑一个生产分组做回滚演练，记录从发现异常到恢复算力用了几分钟；第三，把最近一次批量操作的告警记录翻出来，看它有没有帮助值班员找到真正原因。
别等下一次夜班群里刷满红色告警，才发现问题不是机器不稳，而是我们给一条批量指令开了太大的门。
