文章目录
今天最该防的是 HiveOS 批量指令打到错误矿组
凌晨两点十七分，值班手机连续震了四次。不是大面积断网，也不是矿池抽风，而是 3 号棚 27 台机器同时从正常算力掉到 0。值班员第一反应是看 HiveOS 面板，发现机器在线、温度正常、风扇也转，唯独矿工进程反复重启。再往操作记录里翻，问题就很清楚了：本来要给测试组推一个新 flight sheet，结果批量选择时勾到了生产组。
这件事没有造成灾难性损失，二十多台机器停了不到半小时。但对矿场来说，这类事故比单台机器坏风扇更值得复盘。风扇坏了，范围通常有限；批量操作点错，影响会沿着矿组、钱包、矿池配置一起扩散。HiveOS 的优势正是批量管理，可一旦流程没收住，它也会把人的手误放大得很快。
我今天想从运维负责人角度，把这次事故拆开说。不是讨论 HiveOS 好不好用，而是讨论矿场用 HiveOS 到一定规模后，怎么把“方便”管成“可控”。
夜班误选生产组，判断重点不在谁点错
这次事故发生前，测试组只有 8 台机器，生产组有 27 台同型号机器。两个组名称很像，一个叫 A6-TEST，一个叫 A6-01。值班员要把一版新参数推给测试组，打开 HiveOS 后按标签筛选，看到一批 A6 机器，顺手全选，然后应用了新的 flight sheet。
从结果看，是人误操作。但如果复盘只停在“值班员不仔细”，下次还会出事。真正的问题有三个。
第一，测试组和生产组命名太接近。人在白天可能能分清，夜班处理告警时注意力下降，就容易把相似名称看成同一类。
第二，测试机器没有独立农场或者独立权限边界。测试组只是生产农场里的一个标签，这意味着批量操作时，它和生产机器在同一个操作空间里。
第三，应用配置前没有二次确认清单。HiveOS 本身会展示目标机器数量，但如果内部流程没有要求“报数、报组名、截图留痕”，这个提示很容易被忽略。
所以我们的判断是：这不是一次单纯手误，而是批量管理边界没画清楚。HiveOS 越好用，越不能把所有机器都放在一个容易全选的界面里。
改法也不复杂。测试机器单独建 farm 或至少单独建 worker 命名前缀，命名上和生产组拉开距离，比如 TEST-AMD-001，不再混用生产排号。所有测试配置只允许测试权限账号执行，生产账号不做测试动作。这样即使夜班人员看错，也不至于一键打到生产组。
告警刷屏半小时，判断先分清噪音和事故
事故发生后，告警群里最先出现的是“miner offline”和“hashrate drop”。几分钟后，温度、负载、重启次数也开始刷屏。值班员一开始被这些告警带着跑，先查网络，再查矿池，甚至准备联系电工看配电柜。
但从 HiveOS 的状态看，机器在线，系统没有掉，GPU 也没有消失。真正异常的是矿工进程启动失败。也就是说，这不是机房层面的故障，而是配置层面的故障。
这暴露了我们告警规则的问题：告警发得很多，但没有帮值班员判断优先级。掉算力、进程重启、矿池连接失败、温度异常都往一个群里推，夜班看到的就是一片红字。告警如果只负责吓人，不负责指路，就会拖慢处理速度。
复盘后，我们把 HiveOS 告警分成了三类。
第一类是硬停机告警，包括机器离线、系统重启失败、GPU 丢失。这类需要优先判断现场问题，可能涉及网络、电力、硬件。
第二类是配置异常告警，包括 miner 反复启动、flight sheet 变更后算力归零、钱包或矿池地址异常。这类优先回看操作记录，不先跑机房。
第三类是收益波动告警，比如算力短时下降、矿池 reject 上升、延迟变高。这类需要观察趋势，不要一响就重启。
分类之后，告警群也做了调整。不是所有消息都进总群，严重告警进值班群和负责人手机，普通波动只进看板。这样做的目的不是少看告警，而是让真正要处理的告警更醒目。
这次我们还加了一条规则：凡是 10 台以上机器在 5 分钟内出现同类 miner 重启，第一动作不是重启机器，而是查最近一次批量配置变更。这个顺序改过来，能省很多无效排查。
账号都能全场操作，判断权限已经过宽
以前为了方便，几个值班账号都能改 flight sheet、执行批量重启、套用超频模板。理由也很现实：夜里出问题，谁在班上谁处理，别因为权限不够耽误恢复。
这套做法在几十台机器时看起来没问题，机器多了以后风险就变大。权限越大，事故半径越大。一个账号如果既能看告警，又能改钱包，又能推全场配置，还能删除 worker，那它就不只是运维账号，而是全场控制钥匙。
这次误推配置后，我们把 HiveOS 权限重新拆了一遍。
值班账号只保留查看、单机重启、单机 miner 重启，以及指定小组内有限操作。批量改 flight sheet、批量套参数、改钱包地址、改矿池配置，必须用主管账号。主管账号不在普通值班电脑上登录，平时只在需要审批时使用。
测试账号只管测试农场，不能碰生产农场。生产账号不能给测试机器随便试参数，避免测试和生产混在一起。
还有一点很容易被忽略：离职人员、临时外包、设备商远程协助账号，必须定期清理。HiveOS 账号如果长期没人盘点，最危险的不是密码泄露，而是大家都忘了某个账号还能操作多少机器。
我们现在每周做一次账号清单检查，重点看三项：谁有批量权限，谁能改钱包，谁最近登录过。这个动作花不了多久，但能把很多隐患提前拦住。
新参数推送前，判断依据不能只看测试机跑得稳
这次出事的直接动作，是推送一版新 flight sheet 和参数组合。测试机前一天跑得不错，reject 降了一点，功耗也压下来一些，于是准备扩大测试范围。问题在于，扩大范围没有分层，只是从测试组直接碰到了生产组。
矿场最怕的不是新参数没效果，而是新参数在小样本上正常，到不同批次机器上出问题。同型号机器也会有差别，显存批次、使用年限、温度位置、供电质量都可能不同。HiveOS 批量推送很方便，但不能因为方便就跳过灰度。
我们现在定了一套推送顺序。
第一层只给 3 到 5 台测试机，至少跑满一个完整收益周期，观察算力、功耗、reject、温度和重启次数。
第二层给同排、同环境的少量生产机器，不超过该组 10%。这一层重点看参数在真实生产环境里有没有异常。
第三层才扩大到整组，但必须避开夜间低人手时间。批量变更尽量放在白天，现场有人、负责人在线、能快速回滚。
如果确实要夜间处理，只允许做恢复类操作，不允许推新参数。夜班的原则是止血，不是优化收益。这个原则写进值班手册后，争议少了很多。
HiveOS 的批量管理适合标准化，但参数调整不能只追求速度。运维负责人要盯的不是“今天多挖一点”，而是“这次调整会不会把几十台机器一起拖下水”。
回滚找不到旧配置，判断备份做得还不够细
事故发生后，恢复并不难，难的是确认要回到哪一个版本。值班员知道“推错了”，但一开始不确定原来的 flight sheet 是哪个，超频模板是不是也被改过。幸好操作记录里能查到变更，群里也有前一天截图，才把机器拉回来。
这件事提醒我们，回滚不能靠记忆。很多矿场说自己有回滚预案，实际就是“出事了找老配置”。真正有用的回滚，应该提前把旧配置保存好，命名清楚，责任人知道在哪里。
我们现在对 HiveOS 配置做了三个要求。
每次批量变更前，先保存当前 flight sheet 和超频模板，名称里写明日期、机器组、用途。不要只叫“备用”或者“旧版”，这种名字过几天没人看得懂。
每次变更必须在工单里写清楚目标机器数量、目标组名、原配置名称、新配置名称、预计观察时间。工单不一定要复杂，用文档也行，但必须能回查。
每次变更后，至少保留一个可立即恢复的旧配置，不要改完新参数就顺手覆盖旧模板。覆盖旧模板是很多回滚失败的根源。
另外，回滚也要演练。不要等事故发生才第一次试。我们每个月会选几台测试机做一次配置切换和回退，确认账号权限、配置文件、值班人员操作都没有断点。演练时发现的问题，通常比真事故里发现便宜得多。
现场和值班群脱节，判断流程要写到动作级别
这次事故还有一个小插曲：现场人员接到电话后准备去重启交换机，因为他只听到“27 台掉算力”。如果当时他已经动手，问题可能会变复杂。后来我们要求值班员报故障时必须说清楚三句话：机器是否在线，HiveOS 是否显示系统正常，最近是否有批量操作。
这看起来像沟通细节，其实是流程改造的关键。矿场事故处理中，很多损失不是故障本身造成的，而是多人同时用不同判断去处理造成的。一个人在改配置，一个人在断电，一个人在重启矿池，最后谁也说不清变量变了几次。
所以我们把处置流程压成固定动作。
发现 5 台以上同类异常，先冻结新的批量操作。没有负责人确认，不再继续推参数、不再继续批量重启。
值班员先截三张图：HiveOS 机器列表、异常机器详情、最近操作记录。截图发群后再讨论，不靠口头描述猜。
负责人确定事故类型后，只指定一个执行人操作 HiveOS。其他人只观察，不同时动手。
现场人员在没有明确指令前，不做断电、拔网线、换交换机这类动作。除非有烟味、跳闸、明显硬件危险。
恢复后不马上散会，先记录开始时间、恢复时间、影响机器数量、执行过哪些动作。第二天再补完整复盘。
这些要求看着麻烦，但执行几次后反而省事。因为大家知道遇到问题该做什么，不会在群里来回问“现在要不要重启”。
今天就该改的三件事，判断从事故半径开始
HiveOS 对矿场运维的价值很明确：批量装机、批量监控、统一配置、远程处理。问题也同样明确：它把矿场的操作集中在一个面板上，任何权限过宽、命名混乱、回滚缺失，都会被批量能力放大。
如果今天只能改三件事，我建议先从下面三项做起。
第一，把测试和生产彻底分开。能分 farm 就分 farm，不能分也要在命名、标签、权限上拉开距离。测试机器不要混在生产列表里让人靠眼睛分辨。
第二，收紧批量权限。值班账号不要默认拥有全场配置权，改钱包、改矿池、批量推 flight sheet 这类动作必须单独审批。便利性可以通过流程补，权限放出去后很难靠提醒管住。
第三，做一份可用的回滚清单。每个主要矿组至少有当前稳定配置、上一个稳定配置、负责人、适用机器范围。配置名称要能看懂，不能靠某个人记忆。
矿场运维不能指望永远没人点错。真正可靠的做法，是承认人会疲劳、会误选、会在告警刷屏时判断失准，然后用 HiveOS 的权限、告警、配置保存和操作记录，把错误限制在小范围内。今天把这些流程改掉，下一次凌晨两点手机再响时，至少不会从一台机器的问题变成一整排机器的事故。
