HiveOS 批量操作最危险的疏忽，是沿用上一次选中的机器范围

凌晨 2 点 17 分，值班员在 HiveOS 里给 12 台掉算力的矿机切换矿工版本。命令发出后不到一分钟，机房群里连续跳出离线通知，在线机器数从 486 台迅速降到 300 台以下。现场人员跑到机柜前，发现大量机器正在重复重启，风扇转速一阵高、一阵低。

真正的问题很快查清：值班员打开的是上个班次保留下来的筛选页面，界面里仍然选中了整个机型分组。他以为操作对象只有刚刚点开的 12 台，实际执行范围却覆盖了 486 台。新版本与其中一批旧显卡驱动不兼容，矿工程序启动失败；自动重启策略又把单次配置错误放大成了持续震荡。

这次事故没有烧坏硬件，却造成了近两个小时的有效算力损失。作为矿场运维负责人，我复盘后最在意的并非某个版本有缺陷，而是一个常见误区：很多人把 HiveOS 的批量功能当成节省点击次数的工具，却没有按高风险生产操作来管理它。

夜班大面积重启：批量范围必须在执行前二次确认

事故当天，值班员的操作路径看上去并不复杂：筛选异常机器、调整 Flight Sheet、指定矿工版本、执行更新。单看每一步都符合日常习惯，问题出在“当前选中对象”没有被重新核对。

HiveOS 适合管理大量 Worker，也正因为操作方便，一个错误动作可以在几十秒内覆盖整排机架。矿场规模越大，操作范围越不能依赖值班员对界面的印象。标签、筛选条件、机型分组、离线状态都可能改变最终选中的机器数量。

我们后来增加了一条硬要求：任何超过 20 台机器的批量操作，提交前必须截图保留三个信息——目标 Worker 数量、机器标签、准备下发的配置内容。超过 100 台时，由另一名值班人员复核；夜间只有一人值守，则只能先做小批验证，禁止直接全量下发。

截图并非为了事后追责。人在夜班状态下很容易忽略页面顶部的数量变化，复核动作能强迫操作者停几秒，把“我准备改什么”与“系统实际会改到哪里”对齐。

我们还取消了含义模糊的标签。以前使用“A 组”“临时组”“待处理”这类名称，时间一长，没人说得清里面有哪些机器。现在标签直接写明机房、机型、驱动代际和用途，例如“2号厅-3070-旧驱动-观察组”。名称虽然长，却能减少误选。

十二台试跑正常：小样本通过不能代表全场安全

事故发生前，新矿工版本已经在 12 台机器上运行了约 40 分钟，算力和拒绝率都没有明显异常。值班员因此判断可以扩大部署。后来才发现，这 12 台使用的是较新的系统镜像和驱动，出问题的机器大多来自另一批次。

矿场常把“试过几台”当成灰度验证，实际上，随手挑选的几台机器缺乏代表性。HiveOS 里的 Worker 即使显卡型号相同，也可能存在主板、内存、驱动、系统镜像、超频参数和矿工版本差异。只验证最稳定的一组，得到的结果往往过于乐观。

流程改造后，我们不再随机找测试机，而是按配置差异选样本。一次版本变更至少覆盖新旧驱动、不同显存批次、常见主板以及高温机位。若计划操作 500 台，第一批通常控制在 5 至 10 台，观察 30 分钟；第二批扩大到一个机架或一个明确分组，继续观察掉卡率、重启次数、无效份额和功耗变化。

只有第二批稳定，才允许继续扩大。批次之间必须留出观察时间，不能连续点击几次，把所谓灰度部署做成延迟几分钟的全量更新。

告警瞬间刷屏：没有分级的通知等于现场噪音

这次事故中，告警确实发出来了，而且发了很多。离线、重启、低算力、矿工程序异常等消息在群里连续滚动。可值班员面对数百条近似通知，最初误以为是网络抖动，没有马上把它识别为批量配置事故。

告警数量多，不代表运维更安全。矿场需要区分单机故障、局部故障和全场异常。单台机器短时离线可以进入普通队列；同一标签下多台机器在几分钟内同时掉算力，则应提升优先级；如果异常发生在批量操作之后，更要直接触发变更中止和人工确认。

我们调整告警规则时做了三件事。

第一，给机器分组设置不同阈值。测试组允许更频繁重启，生产组对连续掉算力更敏感，避免所有 Worker 共用一套标准。

第二，把告警与近期操作记录放在一起看。值班员接到集中离线通知后，第一项检查不再是逐台重启，而是确认过去 15 分钟是否执行过 Flight Sheet、超频模板、矿工版本或系统更新。

第三，设置告警收敛。相同分组在短时间内出现大量同类异常时，群里只保留汇总消息，同时明确受影响数量、开始时间和对应标签。现场需要的是“2号厅旧驱动组已有 86 台异常”，而不是 86 条内容相同的离线通知。

共用管理员账号：事故发生后很难及时止住操作

复盘记录显示，当晚有三个人登录同一个管理账号。值班员下发错误配置后，另一名同事看到机器离线，又执行了一次批量重启。两人的动作叠加，延长了恢复时间。由于账号共用，最初无法立即确认每条命令是谁发出的。

矿场早期机器少，共用账号似乎省事。规模扩大后，这种做法会带来两个问题：权限过大，操作记录又缺少明确责任人。尤其是外包维修人员、临时值班人员和财务查看人员，没有必要都拥有修改钱包、Flight Sheet、超频参数及执行批量命令的能力。

我们的整改方式很直接：每个人使用独立账号，按岗位提供访问范围。只负责巡检的人保留查看权限；能处理单机故障的人，只管理指定机房或分组；能够修改全场配置的权限控制在少数负责人手里。临时授权必须写明到期时间，任务完成后当天收回。

涉及钱包地址、矿池账户和大范围配置的改动，还要经过单独审批。HiveOS 提供的是管理能力，具体如何分配权限仍取决于矿场自己的制度。管理员账号常年多人共用，再完整的操作日志也很难发挥作用。

回滚按钮找得到：没有旧配置快照仍然恢复不了

事故处置最慢的一段，是大家知道需要回退，却无法立即确定应该退回哪个版本。

当时的值班记录只写了“更新矿工程序”，没有记录原版本号、原 Flight Sheet、超频模板和驱动组合。有人凭记忆选择了一个旧版本，部分机器恢复，另一部分仍然报错。随后又调整参数，现场逐渐出现多个配置分支，恢复工作越来越乱。

矿场所说的回滚，不能只理解为换回旧矿工版本。一次完整回退至少要覆盖变更前的系统镜像或驱动状态、Flight Sheet、钱包与矿池配置、矿工版本、超频模板，以及相关自动重启策略。缺少其中任何一项，都可能出现程序能启动、算力却不正常的情况。

现在每次批量变更前，我们都保存一份变更单，记录旧配置、新配置、目标机器标签、操作时间、负责人和回退条件。重要参数会留存截图或导出记录，并明确“出现多少台异常时停止扩容”“达到什么指标时执行回滚”。

回退也要经过演练。很多配置备份只存在文档里，从未真正恢复过。我们每月选一个非关键分组，按记录执行一次恢复，确认旧版本还能下载、配置内容仍然可用、权限账号可以完成操作。能被实际恢复的备份，才有价值。

早班交接只写结果：事故教训很快会被下一班遗忘

矿场过去的交接内容通常很短：“已恢复”“观察中”“还有 8 台离线”。这些话能说明结果，却无法告诉下一班事故是怎样发生的，也无法防止同类问题再次出现。

这次以后，交接必须包含异常起点、影响机器范围、最后一次变更、采取过的动作、当前残留风险和禁止执行事项。比如：“旧驱动组已回退至指定矿工版本，上午 10 点前禁止再次批量升级，剩余 8 台保持停机排查。”下一班看到后，就不会把尚未稳定的机器重新拉进更新任务。

事故复盘也不再停留在“加强培训”。培训很难消除疲劳、误点和沟通偏差，流程需要让错误更难扩散。我们的整改清单最终落成五个具体动作：批量操作显示并复核目标数量；变更按配置差异分批验证；集中异常优先关联近期操作；生产权限按人员和机房拆分；每次更新保留可执行的回退记录。

如果今天要检查自己的 HiveOS 运维，建议先做一次十分钟抽查：打开当前 Worker 列表，查看是否残留旧筛选和旧选中范围；核对谁拥有全场修改权限；找出最近一次批量更新，确认能否在五分钟内说清旧版本、影响机器和回退步骤。

这三项中只要有一项答不上来，下一次批量操作就不该直接覆盖全场。矿场事故很少从惊天动地的故障开始，更多时候，只是某个人沿用了上一次选中的机器范围，然后按下了执行。