文章目录
HiveOS 批量操作今天最怕手快，一条错配置能让整排矿机白跑半夜
夜班交接时，我在监控墙前看到一个很刺眼的细节：A3 区第 4 排的算力曲线没有直接掉到零，而是像被人轻轻拧小了一样，十几分钟内一格一格往下滑。风扇转速正常，温度也不算离谱，HiveOS 面板上机器还在线，值班同事第一反应是矿池波动。我让他先别重启，点开批量操作记录，才看到半小时前有人把一组超频模板推错到了这排机器上。
这类事故最麻烦的地方，不是机器立刻死给你看，而是它会装作“还在运行”。面板有算力，矿池有提交，机房里也没有明显异常声音，但实际收益已经开始漏。等到第二天财务按日结对账，少出来的那一截就很难解释。
我现在越来越怕“看起来成功”的批量操作。HiveOS 好用，正是因为它能把几十台、几百台机器一起管起来；但也因为它太顺手，权限、告警、回滚如果没提前收紧，一次点错就会被放大成整片机架的损失。
夜班点错模板，判断不是人的锅先问流程有没有挡板
那次事故复盘时，最容易说出口的一句话是：谁点的，谁负责。
但矿场运维不能停在这一步。点错的人当然要复盘，可真正要问的是，为什么一个夜班账号能把非本区域的超频模板推到整排机器？为什么 HiveOS 里同名模板没有做区域标记？为什么执行前没有二次确认清单？为什么执行后没有自动抽样验证？
我们后来查了当时的操作过程。值班同事本来要给 A2 区一批同型号卡换配置，HiveOS 里模板名写得很省事：low、mid、high。平时大家都懂，但夜里换班、机器编号又临时调整过，点开 Farm 后再切 Worker 组，选错并不奇怪。问题不在于他不会用系统，而在于系统里的命名和权限默认让他“有机会犯一个很大的错”。
复盘后，我们把模板名全部改成了带区域、机型、功耗目标、日期的格式。比如不再叫 mid，而是写成 A2-3070Ti-140W-202604。名字长一点，点击时慢一秒，但能少一次整排误推。
更重要的是，夜班账号只保留本班负责区域的操作权限。临时跨区处理必须由二线账号授权，授权原因写进工单。不是为了折腾人，而是为了让“手快”这件事不能直接打到全场。
HiveOS 的批量管理很适合大矿场，但前提是先把“谁能批量改什么”说清楚。否则批量就是放大器，放大的可能是效率，也可能是事故。
算力慢慢下滑，判断告警不能只盯离线和高温
很多矿场的告警设置很粗：离线报警、高温报警、风扇异常报警。听起来够了，但真正吃亏的往往不是这些大故障，而是“半坏不坏”的状态。
这次错模板推送后，机器没有离线，也没有高温。反而因为功耗配置不合适，部分卡降频运行，算力下降但温度还挺好看。HiveOS 面板如果只看绿色在线，值班员很容易以为没事。
后来我们把告警分成了三类。
第一类是硬故障，比如离线、温度超过阈值、风扇转速异常，这类继续走即时通知。
第二类是收益型异常，重点看算力偏离。不是单台掉一点就报警，而是按机型、区域设置一个正常范围。例如同一批机器在同一超频模板下，单台 15 分钟平均算力低于组内中位数一定比例，就推送到值班群。这样可以抓到“还活着但跑歪了”的机器。
第三类是操作后验证。只要有人执行批量超频、矿池切换、钱包修改、系统更新，HiveOS 操作完成并不代表结束。我们要求 10 分钟、30 分钟、60 分钟各看一次抽样数据，至少包括在线率、平均算力、拒绝率、温度、功耗估算。没有这三次回看，工单不能关闭。
以前我们把告警当消息看，响了就处理，不响就放心。现在看，告警更像是值班员的第二双眼睛，必须能发现“收益正在变薄”这种不够吵但很要命的问题。
尤其在行情波动大的时候，矿场会更频繁地调币种、调矿池、调功耗。操作越密，越不能只靠离线告警。机器没掉线，不代表钱没有掉。
同一个管理员账号多人共用，判断事故会变成无头账
矿场早期经常有一个坏习惯：为了方便，几个人共用一个 HiveOS 管理员账号。谁有空谁登录，谁值班谁操作。小场子还能凑合，机器一多，出事就查不清。
我们之前就遇到过一次，凌晨有人改了钱包地址备注，后来发现实际钱包没变，只是备注写错。损失没有发生，但复盘时很尴尬：操作记录显示是管理员账号，具体谁登的，只能靠群聊时间和口头回忆。
这件事之后，我把账号权限当成矿场运维的硬规定处理。
管理员账号只留给负责人和备份负责人，日常值班不用管理员。每个运维人员单独账号，不共用，不借用。区域操作员只能管理自己负责的 Worker 组，能重启、能看日志、能处理普通故障，但不能改钱包、不能改全场 Flight Sheet、不能删模板。
涉及收益路径的动作，比如修改钱包、矿池地址、支付相关配置，必须两个人确认。一个人发起，一个人审核，截图进工单。哪怕 HiveOS 本身某些动作可以一步完成，我们也在流程上要求留下确认痕迹。
临时外协更要收紧。维修厂商、驻场电工、网络服务商，不应该拿到可以改挖矿配置的账号。他们需要看哪台机器、哪个 IP、哪条网线，就给对应范围的只读或有限权限。维修结束当天收回，不允许“先放着下次还用”。
权限管理看起来不像技术活，但它决定了事故复盘能不能找到人、找到动作、找到原因。找不到，就只能靠骂人；找得到，流程才有机会变好。
系统更新后掉卡，判断回滚必须在动手前准备好
HiveOS 更新、驱动更新、挖矿软件版本切换，这些动作本来很正常。问题是很多人把“更新”当成单向动作，觉得点下去成功就完事。一旦新版本和某批显卡、某个内核、某个矿工程序不合拍，回头才发现没准备退路。
我们有一次在小范围更新时就踩过坑。测试组 20 台机器里有 3 台更新后出现掉卡，重启能恢复，但跑一段时间又掉。幸好当时没有全场推送，否则夜里就要靠人工一台台救。
从那以后，任何 HiveOS 相关更新都按三步走。
第一步，只选测试组。测试组不是随便挑几台，而是要覆盖矿场里最常见的机型、显卡批次、主板型号和网络区域。只在“最听话”的机器上测试没有意义，因为它们本来就不容易出问题。
第二步，记录更新前状态。包括当前 HiveOS 版本、驱动版本、挖矿软件版本、Flight Sheet、超频模板、核心温度、平均算力、拒绝率。不要相信自己记得住，真出事时，人会乱，群里也会乱。
第三步，提前写好回滚动作。能一键回退的，写清楚按钮在哪里；需要切换镜像或恢复旧配置的，提前把文件和命令准备好；需要现场插屏操作的，标出机架位置和负责人。回滚不是出事后再想办法，而是更新方案的一部分。
我们现在有个硬规定：没有回滚方案的批量更新，一律不执行。哪怕版本说明写得再好，群里别人反馈再稳定，也不拿全场机器做实验。
HiveOS 的价值在于让矿场少跑腿，但它不能替我们判断风险。每一次大范围动作前，都要先问一句：如果 20 分钟后情况变坏，我能不能把它拉回来？
批量重启看似省事，判断现场设备也要分批承受
不少运维喜欢用批量重启解决问题。机器卡了，重启；算力不稳，重启；更新完，重启。HiveOS 上点起来很方便，但矿场现场不一定承受得住。
批量重启会同时拉起电流波动，网络也会瞬间涌入大量设备请求。如果某个区域交换机老化、PDU 余量不够、路由器负载偏高，一次“软件动作”就可能变成现场故障。机房里最怕这种连锁反应：本来只是十几台算力不稳，最后搞成一片机器反复上线下线。
我们后来把批量动作改成分组执行。按机架、按供电回路、按网络交换机分批，每批之间留观察时间。HiveOS 上能一口气选 500 台，不代表应该这么做。尤其是重启、更新、切换矿工程序这类动作，必须考虑现场电力和网络的承受能力。
还有一个细节：批量操作前通知现场人员。远程运维如果只在后台点，现场听到一片风扇起停，很容易误判为电力故障。现在我们要求大动作前在值班群发操作范围、开始时间、预计影响和联系人。现场知道这是计划内动作，远程也能及时收到异常反馈。
这不是把简单事情复杂化，而是把远程系统和真实机房接上。HiveOS 面板上的 Worker 是一行行数据，机房里却是一台台吃电、发热、接网线的机器。只看面板，很容易忘了这一点。
工单写得太简，判断下一次还会踩同一个坑
事故复盘最怕写成几句套话：已处理、已恢复、加强巡检。这样的记录看着完成了，过一阵子换个人值班，同样的问题还会回来。
我们现在要求 HiveOS 相关事故工单至少写清六件事：什么时间发现，谁发现，影响哪些机器，执行过哪些动作，最终怎么恢复，后续要改哪条规则。
拿那次错推超频模板来说，最后的整改不只是“提醒夜班注意”，而是落到几条具体变化：模板重命名、夜班账号限区、批量操作二次确认、操作后 10/30/60 分钟回看、异常算力告警阈值调整、每周抽查一次权限列表。
这些动作看起来琐碎，但矿场运维本来就是靠琐碎减少大损失。系统越自动化，流程越不能靠记忆。因为自动化执行得快，人犯错也会被执行得快。
今天如果让我给使用 HiveOS 的矿场提一个最直接的建议，我不会先建议你升级哪个版本，也不会先建议你加多少告警项，而是先把最近 30 天的批量操作记录拉出来看一遍：
哪些账号做过全场动作？
哪些模板名字容易混？
哪些告警只报离线不报算力偏离？
哪些更新没有回滚记录？
哪些外协账号还没收回？
把这五件事查完，再改权限、改模板、改告警、补回滚方案。HiveOS 本身能把矿场管得很细，但前提是运维负责人先把规则写细。否则系统越顺手，事故扩散得越快。
