文章目录
今晚批量改 HiveOS 配置前，先确认谁有一键下发权限
凌晨 3 点 17 分，值班手机在铁皮桌上连震了十几下。第一条是 6 号棚算力跌破阈值，第二条是同一批机器掉线，第三条开始，告警已经没有意义了：一个矿场 400 多台机器同时从面板上变红，风扇还在转，电表也没跳，但有效算力像被人一刀切掉。
我赶到机房时，值班员第一句话是：“我没动电。”这句话其实已经把方向排掉了一半。电没断、网没全断、矿池没发公告，HiveOS 面板里又出现同一时间的批量操作记录，事故原因基本清楚了：有人把原本只该发给测试分组的 Flight Sheet，推到了整场。
这类事故最难受的地方不在技术有多复杂，而在它来得太“顺手”。HiveOS 的批量管理本来是为了省人，几百台机器一键切矿池、一键换钱包、一键更新驱动，平时确实高效。但矿场规模上来以后，最该害怕的恰恰是这个“一键”。
凌晨全场掉算力，判断先看批量动作边界
那次事故复盘时，我们没有先查矿池，也没有先骂值班员，而是把 HiveOS 里的操作记录、分组标签、Flight Sheet 修改时间全部拉出来对时间线。
结果很快出来：凌晨 2 点 58 分，一个临时维护账号修改了测试用 Flight Sheet，原计划给 18 台新卡测试不同内核版本。3 点 05 分，值班员在面板里选择目标机器时，没有按“测试组”筛选，而是点到了默认视图下的全场 Worker。3 点 08 分，下发完成。3 点 17 分，算力告警开始集中出现。
这不是单纯的“点错”。如果一个点错动作能影响全场，说明系统边界本来就没设好。
矿场使用 HiveOS 批量管理时，分组不能只按棚号、机架号做展示，还要按风险等级做操作边界。测试机、观察机、稳定生产机必须拆开。我们后来把所有机器重新打标签：新上架、维修返场、可测试、禁止批量变更、生产稳定组。真正的关键是，生产稳定组不允许直接被临时账号批量操作，哪怕对方能看见机器，也不能一键改配置。
很多矿场的 HiveOS 面板看起来很整齐，棚号、机型、显卡型号都标得清楚，但一到操作权限上还是一锅粥。能看、能改、能重启、能切 Flight Sheet、能执行 Shell 命令，全塞给同一个账号。平时没事，一出事就是整场停摆。
告警群刷屏十分钟，判断先降噪再定位
事故发生后，第二个问题也暴露出来：告警太多，反而没人知道先看哪条。
当时 Telegram 群、短信、邮件同时响。GPU 温度异常、矿工离线、算力下降、矿池拒绝率升高、Watchdog 重启失败，全都挤在一起。值班员看到的是一串红字，而不是可执行的判断。
复盘之后，我们把 HiveOS 告警分了三层。
第一层是会影响收益但不需要立刻停机的，比如单机算力低于平时 10%、单张卡温度略高、风扇转速波动。这类告警进普通群，白班处理。
第二层是需要值班员马上确认的，比如同一机架多台掉线、同一矿池拒绝率突然升高、某个 Flight Sheet 下机器集中重启。这类告警必须带上机器标签、机架位置、最近一次配置变更时间，不允许只发“Worker offline”。
第三层是可能由批量操作引发的事故，比如 5 分钟内超过一定比例机器切换 Flight Sheet、超过一定数量机器同时重启、同一账号连续下发多条批量命令。这类告警直接打到运维负责人和现场主管手机上，同时暂停后续批量任务。
HiveOS 的告警能力够用，但矿场不能只把它当消息推送工具。告警要和处置动作绑定：谁收到、几分钟内确认、先查哪三项、是否需要冻结批量操作。否则告警越多，现场越乱。
临时账号能改矿池，判断权限已经越过岗位
那次事故里，最刺眼的不是值班员误选机器，而是临时维护账号居然能修改生产用配置。
这个账号最初是为了让外部技术人员远程看几台异常机器，后来因为省事，一直没收回。它没有绑定个人责任，也没有严格限制操作范围。密码几个人都知道，双重验证也没有统一要求。这样的账号留在 HiveOS 里，就像机房门口放了一把万能钥匙。
我们后来做了三件事。
第一，账号按岗位拆开。现场值班员可以重启单机、查看日志、切换指定测试组，但不能改钱包地址，不能改生产 Flight Sheet。技术负责人可以创建配置，但不能单独对生产组批量下发。财务相关的钱包模板只允许少数人维护，且修改后必须留痕。
第二，所有临时账号设到期时间。外部维修、远程协助、厂家排查，都只给最小范围权限，到点自动停用。临时账号不能进入生产稳定组，更不能拥有全场批量执行能力。
第三，重大动作双人确认。切矿池、换钱包、升级系统镜像、批量超频、批量重启，这些动作不靠口头说一句“我操作了”，而是必须在工单里写清对象、数量、原因、预期影响和回退办法。另一个负责人确认后再执行。
HiveOS 本身提供了团队和权限管理，但很多矿场用得太粗。越是熟练的团队，越容易相信“大家都懂”。事故往往就出在这种默认信任里。
新版本只在几台机器跑过，判断回滚还没算完成
批量管理还有一个常见坑：大家喜欢说“先测过了”，但测试和可回滚不是一回事。
我们之前升级过一次显卡驱动和矿工版本，办公室测试机跑了 6 小时没问题，现场就开始推。结果到一批混合显卡机型上，部分机器启动后掉卡，Watchdog 反复拉起，HiveOS 面板显示在线，但有效算力很低。最麻烦的是，现场没有准备好对应版本的回退包，也没有记录每台机器原来的超频参数和 Flight Sheet 组合，只能一台台查。
从那以后，我们把回滚当成升级的一部分，而不是事故发生后的补救。
每次批量变更前，必须先保存三类东西：当前 Flight Sheet、当前超频模板、当前系统与矿工版本。测试组通过后，也不能直接全场推，而是按 1%、5%、20%、50% 分批推进，每一批至少观察一个结算周期或一个固定时长。只要拒绝率、离线率、重启次数超过阈值，立刻停止下一批。
回滚动作也要演练。不能只在文档里写“可回滚至上一版本”，而要让值班员真的操作过：从哪里选旧配置，回退后多久看算力，哪些机器需要手动重启，哪些日志能证明已经恢复。没有演练过的回滚，在凌晨事故里大概率会变成临时摸索。
HiveOS 的优势是集中管理，但集中管理也意味着错误传播速度很快。升级、切换、批量命令都应该默认带有回退方案。
复盘会只问谁点错，判断流程还会再出事故
事故第二天开会，最容易走偏的话题就是“到底是谁点错”。这个问题当然要问，但只问这个，矿场下次还会栽在同一个地方。
我们复盘时把问题拆成五个环节：为什么临时账号还在；为什么测试配置能被推到生产组；为什么下发前没有数量确认；为什么告警没有直接提示最近批量操作；为什么值班员不知道第一时间冻结后续命令。
拆完以后，责任反而更清楚。值班员有操作责任，账号管理员有权限清理责任，运维负责人有流程设计责任，现场主管有培训责任。事故不是一个按钮造成的，而是多个小口子长期没堵。
后来我们要求每次 HiveOS 重大操作都留下四样东西：操作前截图或导出记录、工单审批记录、执行人和确认人、执行后 30 分钟和 2 小时的观察结果。不是为了增加形式，而是为了出问题时能快速还原，不靠记忆吵架。
矿场运维最怕“人没少忙，账说不清”。HiveOS 面板里的历史记录、告警记录、Worker 状态变化，本来就是复盘材料，关键是平时要养成固定留存习惯。
今天值班前检查三处，判断能不能放心批量操作
如果今天你的矿场也准备用 HiveOS 调整配置，我建议先别急着点下发，先做三项检查。
第一，打开团队权限，看有没有长期不用的临时账号、共用账号、离职人员账号。凡是说不清用途的，先停用；凡是能改生产 Flight Sheet 的，必须绑定明确责任人。
第二，随机挑一个生产分组，确认它是否会被默认全选影响。尤其是按机型、棚号筛选时，要看批量操作对象数量是否有二次确认。超过预设数量的动作，必须暂停并重新确认。
第三，拿一小组机器做一次回滚演练。不要等事故来时再试。把 Flight Sheet、超频参数、矿工版本回退一遍，记录耗时和卡点。值班员能独立完成，才算这个流程真的可用。
HiveOS 能把矿场运维效率拉高，但它不会自动替你管住人、管住权限、管住误操作。批量管理越顺手，越要把账号、告警、审批和回滚做细。今晚开工前，先确认谁能一键下发、能下发到哪里、下错了谁负责拉回来。这个问题不查清，算力面板再漂亮也不踏实。
