文章目录
今天别让 HiveOS 批量操作直接打到全场机器
凌晨两点十七分，值班手机连续震了六下。第一条是 3 号棚 47 台矿机掉算力，第二条是矿池侧拒绝率抬高，第三条才是 HiveOS 面板上的批量任务完成提示。等我从宿舍走到机房门口，门禁记录显示，现场没有人动过机器，风扇声也没有异常，但后台一看，问题很清楚：一条本来只该发给测试分组的 flight sheet，被批量推到了整组 312 台机器。
这类事故最烦人的地方，不是机器全黑了，反而是它们还在跑，只是跑错了。算力曲线看起来没有断崖式下跌，矿池端却开始出现大量无效提交。夜班同事第一反应是重启，结果重启之后配置仍然错误，白白多耗了二十多分钟。
这次复盘后，我在矿场里改掉的第一条规则就是：HiveOS 的批量操作不能再默认信任“选中了哪些机器”，必须先问一句，这条命令有没有机会越过测试组，直接打到全场。
夜班误推配置，判断不是人手不熟而是分组边界太软
事故当天的操作并不复杂。我们准备给一批显卡机切换一个新矿池地址，原因是原矿池延迟在晚高峰时明显抬高，测试组跑了半天没有问题。夜班同事按流程复制 flight sheet，修改钱包和矿池，准备先推 20 台。
问题出在分组方式上。HiveOS 里原来按“棚区”和“机型”建了多个 farm 和 worker 标签，但同一批机器在上架、维修、换卡之后，标签并没有及时清理。夜班同事按标签筛选时，以为自己筛出来的是测试组，实际上里面混进了生产组机器。再加上页面上机器数量需要向下翻才看全，最终一条看起来很小的操作，直接扩大到了三百多台。
复盘时，如果只把责任归到“操作员没看清”，那下次还会再发生。真正的问题是，我们把 HiveOS 的标签当成了资产事实，把筛选结果当成了安全边界。标签可以错，备注可以漏，机器可以换位置，单靠眼睛扫一遍列表并不可靠。
后来我们做了两件很笨但有效的事。
第一，测试组不再用临时标签表示，而是单独建立固定分组，机器进入测试组必须在工单里登记 SN、机架位、HiveOS worker 名称，三项对上才允许加入。
第二，任何批量修改 flight sheet 的动作，页面截图必须带机器数量、分组名称和前十台 worker 名称，发到值班群里等另一个人确认。很多人觉得截图麻烦，但矿场里最贵的不是多点一次鼠标，而是凌晨三点没人知道刚才到底推给了谁。
告警一口气刷屏，判断不能只按声音大小排优先级
那晚的告警特别吵。温度、掉卡、无效份额、离线提醒一起弹，手机像坏了一样。问题是，告警越多，值班人员越容易失去判断。他看到“离线”就想重启，看到“温度”就想查风道，看到“无效份额”又想切矿池，几条线同时拉扯，现场处置就会乱。
后来我们把那次告警记录拉出来看，最早出现的不是离线，也不是温度，而是矿池拒绝率和无效份额上升。也就是说，机器本身还活着，网络也没断，真正的变化来自配置侧。可惜当时我们的告警没有分层，所有提醒都用同样的声音、同样的颜色、同样的推送渠道，夜班只能凭经验猜。
HiveOS 的告警很好用，但不能把所有异常都当成同一种“报警”。矿场要做的是给告警定性质：哪些代表硬件风险，哪些代表收益风险，哪些代表操作风险。
我们现在的做法是，涉及批量任务完成、flight sheet 变更、钱包地址修改、超频模板调整的消息，全部进入“操作类告警”；掉算力、拒绝率、矿池连接失败进入“收益类告警”；温度、风扇、掉卡进入“设备类告警”。三类告警不混在一个群里刷屏。
更关键的是，操作类告警永远优先看。因为硬件坏一台，影响是一台；配置错一批，影响可能是一整排。尤其是 HiveOS 这种适合批量管理的系统，便利性越高，错误扩散速度也越快。告警设计如果还停留在“响了就看”，迟早会在真正出事时把人淹没。
临时账号还能改模板，判断权限不是给方便用的
事故复盘时还有一个细节让我后背发凉：那天夜班用的并不是主管账号，而是一个临时运维账号。这个账号本来只给外包人员查机器状态、处理离线重启，结果权限里还保留着修改 flight sheet 和应用超频模板的能力。
这不是技术漏洞，是管理偷懒。
很多矿场一开始用 HiveOS，会为了方便给几个常用账号开大权限。白天要调机，晚上要救火，老板要看面板，外包要协助排查，最后大家都能点很多按钮。平时看不出问题，一旦某个人点错，或者账号泄露，影响范围就很难控制。
我们后来把账号分成了四类。
值班账号只能看状态、重启单台机器、备注故障，不允许批量下发配置。
班长账号可以对指定分组做批量操作，但不能改钱包地址，也不能改全场模板。
运维负责人账号可以改 flight sheet、钱包、矿池和超频模板，但必须开启二次验证，且每次变更都要留工单编号。
老板和财务账号只看收益、在线率和矿池数据，不参与机器配置。
权限收紧后，刚开始确实有人抱怨麻烦。尤其是夜班遇到异常时，过去一个人就能改，现在要叫醒负责人审批。但矿场要算的是总账：一次误操作造成的损失，远高于多等五分钟确认。HiveOS 的权限如果只是按职位大概分一分，就会变成“谁常用谁权限大”；正确做法应该是按风险分，谁需要做什么，最多只能做到什么。
回滚找不到旧版本，判断平时没演练等于没有预案
那次事故真正拉长停机时间的，不是定位慢，而是回滚慢。
我们知道配置推错了，也知道应该回到上一版 flight sheet。但现场没人能马上说清楚，上一版到底是哪一个。HiveOS 里有一些操作记录，可是当时命名混乱，多个配置名字相似，只差一个日期后缀。有人说用“pool-bak”，有人说应该用“eth-old”，还有人说昨天白班刚改过钱包地址，不能随便回。
最尴尬的是，回滚这个词大家都会说，但平时没人真正演练过。到了事故现场，回滚就变成了翻记录、问同事、猜版本。机器等不起这种犹豫。
现在我们把回滚拆成三个固定动作。
第一，每次正式变更前，必须复制一份当前配置，名字写清日期、机型、矿池和负责人，比如“20260428-A棚-3060ti-原矿池-张三”。名字长一点没关系，出事时能看懂最重要。
第二，批量变更只允许先打到灰度组。灰度组至少跑两个结算周期，观察拒绝率、平均算力、功耗和掉线次数，再决定是否扩大。这里不追求快，追求的是出错时影响小。
第三，每周做一次小规模回滚演练。选 5 台测试机，从当前配置切到备用配置，再切回来，记录耗时和异常。演练不是为了证明系统没问题，而是为了让夜班知道，真的出事时第一步点哪里，第二步找谁确认，第三步看什么指标算恢复。
很多矿场把回滚当成事故后的动作，但我的经验是，回滚必须在变更前就准备好。没有旧配置命名、没有适用机器范围、没有验证指标，所谓回滚只是安慰自己。
全场面板一片正常，判断收益异常要去矿池端交叉看
还有一个容易被忽视的问题：HiveOS 面板上显示的算力，并不等于最终到账收益。
那次配置误推后，面板算力并没有马上大幅下降。几乎所有机器都还在线，GPU 温度正常，风扇正常，功耗也正常。假如只盯 HiveOS，看起来像是“小波动”。但矿池端已经明显不对，无效份额持续增加，部分 worker 的有效提交下降，收益预估开始偏离。
这提醒我们，HiveOS 是矿场运维的核心工具，但不能只相信单一面板。运维负责人至少要把三组数据并排看：HiveOS 的在线率和本地算力，矿池端的有效算力和拒绝率，电表或 PDU 的功耗变化。三者对不上时，优先按收益端异常处理。
我们后来给值班流程加了一个硬要求：凡是发生批量变更，半小时内必须截图保存 HiveOS 和矿池端数据；两边差异超过设定阈值，就算 HiveOS 没有红色报警，也要进入人工确认。
有些问题机器会自己报出来，有些问题不会。特别是矿池地址、钱包、代理、抽水参数、超频模板这类配置错误，机器往往还在勤勤恳恳地跑，只是把电费烧到了错误方向。运维如果只看面板绿不绿，就容易错过最贵的那类故障。
工单没人补，判断事故复盘不能停在群聊记录
事故当天处理完，很多人都松了一口气。机器恢复了，矿池曲线也回来了，群里发一句“已处理”似乎就结束了。但第二天上午复盘时，我们发现一个更大的问题：没有完整工单。
谁先发现的？谁执行了第一次重启？谁判断是配置问题？谁确认了回滚版本？什么时候矿池端恢复正常？这些关键信息散落在微信群、电话和 HiveOS 操作日志里，拼起来很费劲。
矿场事故不怕发生一次，怕的是每次都从头学。HiveOS 本身能记录很多操作，但它不会替矿场写清楚决策过程。为什么当时没有停批量任务？为什么先重启而不是回滚？为什么选这个配置恢复？这些判断如果不落到工单里，下次值班换个人，还是会按自己的习惯处理。
现在我们要求每次中等以上异常必须补一张复盘单，内容不求长，但要有五项：异常开始时间、影响机器范围、第一判断、实际原因、以后禁止动作。尤其是“以后禁止动作”必须写得具体，比如“未确认机器数量不得执行批量 flight sheet 下发”，而不是写“加强检查”。
流程改造最怕写成口号。矿场里真正有用的流程，是值班人员困得睁不开眼时也能照着做的东西。
今天该改的不是面板，而是批量动作的刹车
HiveOS 的价值就在于能管很多机器，能批量装机、批量改配置、批量看状态、批量处理异常。可对矿场来说，批量能力也是一把快刀。用得好，省人、省时间、少停机；用不好，一个误选、一个错模板、一个权限过大的账号，就能把小问题放大成整场事故。
如果今天只能改一件事，我建议先给批量操作加刹车，而不是急着优化更多参数。
具体可以从四个动作开始做。
把测试组从普通标签里拆出来，做成固定分组，并用工单维护机器名单。
把能改 flight sheet、钱包、矿池和超频模板的账号重新清一遍，临时账号一律降权。
把每次批量变更前的旧配置复制并规范命名，确保夜班能在一分钟内找到可回滚版本。
把 HiveOS 告警和矿池端数据放在同一套值班检查里，配置变更后必须同时看拒绝率和有效算力。
这几件事不高级，也不花哨，但能挡住矿场里最常见、也最贵的一类事故：机器没坏，人也没偷懒，只是系统太方便，错误跑得太快。今天发布配置前，多停三十秒确认影响范围，可能就是今晚少损失一整排机器收益的差别。
