文章目录
今天别让 HiveOS 批量更新越过夜班审批
凌晨 2 点 17 分，值班手机连续震了 6 次。第一条是 HiveOS 面板里的离线提醒，第二条是矿池端算力下滑，第三条才是机房巡检员发来的照片：A 区第三排指示灯还亮着，但一整排机器的提交份额已经掉下来了。现场没有跳闸，没有断网，风扇声也正常。真正的问题出在十分钟前，有人把一组原本只该灰度测试的 Flight Sheet 批量推到了 184 台机器上。
这类事故最麻烦的地方，不是机器坏了，而是机器看起来都还在跑。面板有算力，风扇有转速，温度也没炸，但矿池端接受率开始变差，部分卡反复重启挖矿进程。等到人反应过来，已经过了两个结算周期。
我今天想写的不是 HiveOS 有多方便，而是站在矿场运维负责人的角度，复盘一次典型的批量操作事故：告警为什么没挡住，权限为什么放得太宽，回滚为什么慢了半小时，以及我们后来怎么把流程改掉。
夜班误点批量按钮：这不是手滑，是权限边界没画清
事故当天，夜班同事本来只需要处理 12 台掉卡机器。按照旧流程，他有权限修改矿工配置，也有权限对整个 Worker 组执行批量应用。问题就出在这里：一个“临时处理人”拿到了“全组发布权”。
HiveOS 的批量管理很适合矿场，几百台机器改钱包、改矿池、切换挖矿软件，不可能靠人工一台台点。但便利性一旦没有权限分层，就会变成事故放大器。单机操作错了，影响一台；批量组点错，影响一排；如果 Farm 级权限没有收紧，影响的就是整个场。
我们后来把账号拆成了三类。
第一类是观察账号，只能看算力、温度、在线状态、告警记录，给巡检员和财务核对使用。
第二类是处置账号，可以重启矿工、重启单台机器、切换已批准的预设配置，但不能新建钱包、不能改矿池地址、不能对超过固定数量的机器批量发布。
第三类是审批账号，掌握批量变更、钱包修改、系统升级和大范围回滚权限，但必须两个人确认后才执行。
很多矿场觉得权限分这么细麻烦，尤其是熟人团队，大家都在一个群里，有事喊一声就行。可真正出事故时，系统不会识别“这个人只是想救急”，它只认权限。权限给大了，事故就会按最大权限范围扩散。
算力掉得不快：判断不能只看面板上的绿色数字
这次事故最误导人的地方，是 HiveOS 面板上的算力没有瞬间归零。很多机器还显示 Hashrate 正常，温度也在合理范围内，离线数量并不多。夜班一开始判断是矿池抖动，准备再观察 10 分钟。
但矿池端的数据已经变了：接受份额下降，拒绝率抬头，部分 Worker 的提交间隔明显拉长。也就是说，机器在“努力工作”，但有效产出变差了。
这给我们一个很实际的教训：HiveOS 运维不能只盯本地算力，还要把矿池端结果纳入告警。面板算力像发动机转速，矿池接受份额才像车有没有往前走。只看发动机声音，很容易误判。
后来我们把告警条件改成了三层。
第一层看 HiveOS 本身：离线、掉卡、温度异常、风扇异常、矿工重启次数。
第二层看矿池：有效算力、拒绝率、最后提交时间、Worker 数量变化。
第三层看变化速度：不是等到总算力掉 20% 才报警，而是某个机架、某个标签组在 5 到 10 分钟内出现同步下滑，就先触发提醒。
尤其是批量管理场景，异常往往不是“一台坏了”，而是“一组同时变差”。这种模式比单台掉线更危险。因为它通常意味着配置、版本、矿池地址、超频参数或系统更新出了问题。
告警群刷屏三分钟：噪音太多等于没有告警
事故发生后，告警群里同时出现离线、重启、低算力、温度恢复、矿工重启成功等多种消息。三分钟内几十条，大家反而不知道哪条最重要。
这也是很多矿场的老问题：告警不是越多越安全。告警太碎，人会麻木；告警没有分级，真正危险的消息会被普通消息淹没。
我们复盘后，把告警重新分成了四档。
普通提醒：单台机器短暂离线、温度轻微波动、矿工自动恢复。这类只进日志，不打电话，不吵醒负责人。
值班处理：连续离线超过设定时间、单台多次重启、某张卡掉算力。进入值班群，由夜班处理。
负责人确认：同一标签组多台机器同时异常、矿池端有效算力连续下滑、批量操作后出现拒绝率异常。必须通知运维负责人。
冻结级告警：钱包地址变化、矿池地址变化、大范围 Flight Sheet 应用、系统批量升级、批量超频参数变更。这类告警触发后，相关批量权限暂时锁住，必须人工确认解除。
这一步改造很关键。过去我们把告警当“消息”，后来才意识到，告警应该直接改变处置流程。不是提醒你看一眼，而是告诉系统：现在别让更多操作继续往下走。
回滚花了 38 分钟：慢在找版本，不是慢在执行
这次事故从确认配置错误到恢复大部分机器，花了 38 分钟。HiveOS 本身执行回滚并不慢，真正耗时的是我们当时没有把“上一个稳定版本”标清楚。
有些机器最近换过矿池，有些机器刚调过超频，有些机器因为显卡型号不同用了不同挖矿软件。要回滚时，大家先在历史记录里翻，再问白班谁改过，再对照矿池 Worker 名称。时间就是这样被耗掉的。
后来我们做了一个很土但很有效的规定：每个 Worker 组必须有一个“可回退配置”，名字里写清楚日期、矿池、钱包尾号、挖矿软件版本和适用机型。每次正式变更前，先确认回退配置存在；没有回退配置，不允许批量发布。
另外，系统升级也不再直接推全场。HiveOS 更新、驱动调整、矿工版本升级，都必须按 5 台、20 台、单排、全区这样的节奏走。每一档至少观察一个完整结算周期，矿池接受率没问题，再放下一档。
回滚不是出事后才想起来的动作，而应该是变更前就准备好的退路。很多矿场的事故不是不能恢复，而是恢复前要先猜“原来是什么样”。
工单里只有一句已处理：判断事故有没有真正结束，要看证据
事故刚恢复时，群里有人发了一句“已处理”。如果按以前习惯，这事可能就过去了。但从负责人的角度看，“已处理”三个字没有意义。我要知道的是：影响了多少台、持续多久、损失多少有效算力、谁触发操作、系统有没有记录、为什么没被拦住、下次靠什么避免。
所以我们把 HiveOS 运维工单改成了固定格式。
每次批量变更，必须写明操作对象、机器数量、配置名称、执行人、审批人、开始时间、观察指标和回滚方案。
每次异常处置，必须补充故障开始时间、发现来源、第一条告警、最终原因、恢复时间、是否影响钱包或矿池地址。
每次回滚，必须记录回滚到哪个配置、覆盖多少台机器、还有哪些机器未恢复、是否需要现场巡检。
这不是为了事后追责吓人，而是为了让事故有证据可查。矿场最怕的是同一个坑每个月踩一次，每次都靠经验救火，每次都说“下次注意”。流程不改，注意没有用。
白班交接一张截图：判断风险不能靠记忆
这次事故还有个隐蔽原因：白班做过一轮小范围测试，但交接时只发了截图，没有在系统里标注测试组，也没有把“禁止扩散”的说明写进工单。夜班看到配置存在，以为是已验证方案，才误选了它。
从那以后，我们规定测试配置必须单独命名，前缀写“测试”，并限制只能用于测试标签组。测试组的 Worker 不能和生产组混在一个列表里。任何没有审批编号的配置，不能出现在生产批量操作选项中。
HiveOS 的标签和分组功能，本来就是用来减少混乱的，但很多矿场只拿它按地区、机架、币种做粗分。真正做运维时，还应该有生产组、测试组、隔离组、待检组。机器不是只有“在线”和“离线”两种状态，它还处在不同风险级别里。
尤其是行情波动大的日子，大家容易急着切池、换币、调参数。越是这种时候，测试组和生产组越不能混。一次未经验证的配置，如果直接碰到生产组，矿场相当于拿整晚收益做测试费。
今天可以立刻改的三件事：先把事故半径缩小
如果你现在也在用 HiveOS 管矿场，今天不一定要做一套很复杂的制度，但至少可以先改三件事。
第一，检查账号权限。夜班、巡检、临时外协、财务查看账号，不应该拥有同样权限。能看、能重启、能改配置、能批量发布、能改钱包，必须拆开。
第二，给每个生产组准备可回退配置。不要只相信历史记录，也不要靠某个老员工记得参数。回滚配置要提前命名、提前验证、提前绑定对应机型和矿池。
第三，把批量操作告警单独拎出来。凡是涉及大范围发布、钱包地址、矿池地址、挖矿软件版本、系统升级的动作，都不应该和普通低算力提醒混在一起。它们应该触发更高等级确认，必要时临时冻结继续操作。
HiveOS 让矿场管理几百台机器变得容易，但它不会自动替你判断谁该操作、什么时候该停、出错后该退到哪里。运维负责人真正要做的，是把人的冲动、夜班的疲劳、配置的混乱和告警的噪音，都关进流程里。
今天发布前，我会再检查一遍生产 Farm 的批量权限，把测试配置从生产组里移出去，并让夜班按最新回滚清单演练一次。机器可以 24 小时跑，人不能 24 小时保持清醒。流程的价值，就是在人不清醒的时候，也别让一个按钮影响整片矿场。
