文章目录
今天最该防的是 HiveOS 批量命令越权扩散
凌晨 2 点 17 分，值班群里先跳出 8 台矿机掉算力，紧接着变成 42 台。夜班同事打开 HiveOS，看到这些机器都挂着同一个标签，便重新套用了一次 Flight Sheet。三分钟后，掉线数量冲到 186 台。
我赶到机房时，交换机指示灯正常，机架也没有大面积断电。问题出在操作范围：值班人员原本只想处理一个机架，却选中了整个标签组。更麻烦的是，这个标签半个月前扩容时被复用过，里面混着两个矿区、三种显卡和不同版本的挖矿程序。
那次事故最终没有造成硬件损坏，但有效算力用了近 50 分钟才恢复。复盘会上，我们没有把责任简单归到“点错按钮”。一个人的误操作能够迅速影响上百台机器，说明矿场的批量管理、账号权限、告警分级和回退准备都存在缺口。
HiveOS 的批量能力确实能省人，但批量范围一旦失控，也会把一个小错误放大成全场事故。
夜班套错 Flight Sheet：批量对象必须能够被现场验证
过去我们给机器分组，主要依赖矿区名称和标签。表面上看很整齐，例如“A 区”“3070”“高功耗组”，实际使用一段时间后，标签会越来越乱。
矿机搬架后，旧标签未必删除；临时测试结束后，测试组也可能继续保留；不同班组还会用近似名称建立新标签。运维人员在 HiveOS 面板里看到的分组，与机房里的真实位置逐渐脱节。
事故发生后，我们把批量操作对象改成了三层确认：
第一层是物理位置，必须明确到矿区、通道和机架；第二层是设备类型，包括显卡型号、矿机类型和适用的超频模板；第三层是任务范围，明确这次操作究竟涉及几台机器。
现在，只要批量任务超过 20 台，执行人就要先在工单里贴出 Worker 数量、标签名称和抽样机器编号。复核人随机检查至少 3 台，确认它们的位置、Flight Sheet 和钱包配置一致后，任务才能继续。
这个动作看起来拖慢了几分钟，却能避免把错误配置推给几百台设备。矿场效率不能只计算一次操作节省了多少点击，还要计算选错对象后需要多少人、多少时间才能恢复。
告警突然刷屏：先识别共同变化，再逐台检查
当 186 台机器同时掉算力时，夜班人员第一反应是逐台重启。这也是矿场最常见的救火方式：看到一台异常就处理一台，看到十台就连续点十次。
这种做法适合零散故障，不适合批量事故。
大量机器在相近时间出现相同告警，通常意味着它们共享了某个变化，例如 Flight Sheet 被替换、矿池地址不可用、钱包字段填写错误、挖矿程序升级失败，或者超频模板被统一覆盖。此时逐台重启只会制造更多日志，还可能让原本在线的机器一起中断。
我们后来把 HiveOS 告警分成三类：
- 单机告警：单台温度、风扇、显卡丢失或系统盘异常，由值班人员直接处理。
- 同组告警：同一机架或同一型号在五分钟内连续出现异常，暂停批量动作并检查最近变更。
- 全场告警：多个区域同时掉算力，立即冻结配置修改，只保留查看权限，由当班负责人接管。
告警消息里也不再只写“低算力”或“离线”。必须带上异常数量、首次出现时间、影响标签、最近一次配置变更和当前执行人。没有这些信息，群里的每个人都知道出事了，却没人知道该从哪里查起。
告警的价值不在于声音够不够响，而在于它能否让值班人员迅速判断：这是单机损坏，还是一次正在扩散的操作事故。
临时账号长期保留：权限便利往往会变成事故通道
这次复盘还查出一个问题：执行批量操作的夜班账号，拥有超出岗位需要的权限。
最初给高权限，是因为夜间人少，现场遇到问题时不想再等负责人授权。时间久了，换 Flight Sheet、修改钱包、调整超频和执行重启都集中在同一个账号里。这个账号一旦误操作或凭据泄露，影响范围就不再局限于某一排机器。
我们随后按岗位拆分了使用方式。
监控岗只负责查看状态、确认告警和建立工单；现场维修岗可以重启单机、补充备注和处理指定机器；班组长才能批准批量修改；涉及钱包地址、矿池账户和大范围模板变更，则必须由运维负责人参与。
HiveOS 自身能够提供共享访问和一定的权限区分，但矿场不能只依靠系统里的角色名称。实际工作中，还要配合独立账号、登录验证、定期清理访问成员以及操作记录核对。若现有权限粒度无法完全覆盖内部岗位，就用审批单和双人复核补足，避免多人共用一个全权账号。
我们还取消了“临时账号默认长期有效”的习惯。外部维修人员、设备供应商和短期测试人员的访问权限，都要写明截止时间。任务结束当天，由班组长核对并撤销。
账号数量多并不可怕，可怕的是没人说得清某个账号属于谁、为什么还存在、现在能改哪些内容。
配置已经推错：回退依据必须在变更前保存
事故处理中最耽误时间的一步，是寻找上一版可用配置。
当时有人记得原来的矿池地址，却不确定备用池顺序；有人保存过超频参数截图，但截图对应的是旧驱动；还有几台测试机本来就使用不同 Flight Sheet，无法跟随大组统一恢复。最终我们只能一边查历史记录，一边分批尝试。
从那以后，每次正式变更前都要保存一份“可恢复快照”。它不只是截图，而是一组能够重新执行的信息：
- 原 Flight Sheet 名称及适用机器范围；
- 钱包、矿池和备用池配置；
- 挖矿程序及版本；
- 驱动、系统镜像和相关依赖版本；
- 超频模板与风扇设置；
- 变更前在线数量、平均算力和拒绝率；
- 明确的回退触发条件。
回退条件必须写成数据，不能写“情况不对就恢复”。例如，发布后十分钟内离线超过 5%，同型号平均算力下降超过 8%，拒绝率连续两个统计周期异常，或者出现批量 GPU 丢失，就停止扩大范围并执行回退。
此外，回退也要经过演练。某份旧配置曾经可用，不代表今天一定能恢复，因为矿池端口、程序版本和驱动环境可能已经变化。我们每月挑选少量非关键机器，完整走一次“变更—验证—回退”，确认保存下来的方案真的可以执行。
试点机器运行正常：小范围成功不能替代分批发布
很多事故都发生在一句话之后：“测试机已经跑过了，直接全推吧。”
单台测试只能证明配置在这一台机器上可以运行，无法证明它适用于同标签下的所有设备。矿场里常见的混杂情况包括显存品牌不同、显卡批次不同、系统镜像不同、网卡状态不同，甚至同型号机器的电源余量也不一样。
现在我们的发布顺序按比例推进。先选 3 至 5 台代表性机器，覆盖不同硬件批次；稳定运行后扩大到一个机架；观察至少两个完整统计周期，再扩大到同型号设备。每一批都设置暂停点，由值班人员核对在线率、算力、功耗、温度和拒绝率。
批次之间不能依赖“没听到告警”来判断成功。没有告警可能只是阈值过宽，也可能是通知渠道失效。发布人必须主动查看数据，并把结果填进工单。
至于全场批量重启、系统升级、矿池切换这类高影响动作，我们规定不得安排在交接班前后，也不能在现场只剩一名值班人员时执行。操作时间的选择，本身就是风险控制的一部分。
算力恢复以后：事故结束的标准不能只看面板变绿
那次事故中，HiveOS 面板恢复绿色后，大家一度以为处理完了。第二天对账才发现，有 11 台机器虽然显示在线，却连接到了错误的备用矿池；另有几台算力正常，但使用了测试钱包。
所以现在的恢复确认分为三步：机器在线只是第一步；算力、拒绝率和功耗回到正常区间是第二步；钱包、矿池及收益归属核对无误，才算真正结束。
每次批量事故关闭前，我们还会导出受影响机器清单，对照变更记录检查是否存在漏网设备。对于离线期间被人工单独修改过的机器，要额外标记，避免它们在后续同步时再次被覆盖。
事故复盘也不再停留在“加强培训”。培训当然有用，但人员再熟练也会疲劳、会看错标签、会在告警压力下做出错误判断。有效的改造应当能让错误更难发生，也让错误发生后更容易被发现和撤销。
今天接班前，我建议每个使用 HiveOS 的矿场完成五个具体动作：清理过期共享账号；核对高权限成员；检查常用标签是否混入其他矿区设备；为主要 Flight Sheet 保存一份可执行的恢复记录；挑选五台非关键机器做一次批量变更与回退测试。
做完这些，再把超过 20 台的操作纳入双人复核。矿场真正需要防住的，并非某一台机器突然掉线，而是一次未经确认的点击沿着批量管理迅速扩散。
