HiveOS 批量操作最危险的瞬间，是错误配置被一键推满全场

凌晨 2 点 17 分，值班员在 HiveOS 里勾选了一组 Worker，准备给 12 台测试机更换 Flight Sheet。确认按钮按下后，机房监控墙上的绿色状态块开始成片变黄。不到三分钟，186 台矿机的在线算力下降了 38%，其中 23 台直接离线。

我赶到控制台时，值班员还在反复刷新页面。他以为矿池连接不稳定，连续执行了两轮重启。直到我们检查操作记录，才发现真正的问题：测试标签和生产标签命名过于接近，批量筛选时多选了一个设备组，尚未验证的矿工软件参数被下发到了整排机器。

这次故障从出现到恢复用了 47 分钟。单看时间不算特别长，但它暴露出的风险很明确：矿场规模越大，HiveOS 的批量管理越省事，一次错误操作影响的机器也越多。

测试配置覆盖整排机器，判断是批量对象没有关进笼子

事故发生前，我们一直把“批量执行成功”当作效率指标。现在回看，这个指标本身就有问题。系统执行得越快，错误扩散得也越快。

当晚值班员使用名称搜索设备组，测试组叫“RX-A-Test”，生产组叫“RX-A”。两个标签在列表中相邻，批量勾选后又没有进行数量核对。原计划操作 12 台，实际任务对象却变成了 186 台。

这类事故不能只归因于“员工不细心”。只要流程允许一个人在夜班、疲劳状态下直接对上百台设备执行高风险动作，迟早还会发生第二次。

复盘后，我们先改了 HiveOS 中的设备分组规则。测试机不再按型号夹在生产设备中，而是放入单独 Farm，命名加入明显前缀，标签颜色也与生产区分开。任何新版本、超频参数、矿池地址或钱包模板，必须先经过三个范围：

• 2 台实验机连续运行 30 分钟；
• 10 至 20 台同型号机器运行一个完整值班周期；
• 生产批次按机架逐组放量，每次不得覆盖全场。

同时，批量任务提交前必须核对目标 Worker 数量。计划是 12 台，界面显示 186 台，这个差异本应在执行前就把操作拦住。

算力下降触发二十多条消息，判断是告警只负责制造声音

故障发生后的五分钟内，值班群收到了掉算力、离线、温度异常和矿池拒绝连接等多类通知。看起来告警很密，实际却没有帮助值班员迅速定位。

原因有两个。其一，同一批机器产生的关联事件被拆成大量单条消息，重要信号淹没在通知里。其二，告警后没有规定谁负责确认、几分钟内做什么、达到什么条件必须升级。

我们随后调整了告警口径。全场运维不再把每一台矿机的瞬时波动都推到主群，而是重点监测设备组层面的变化：

• 同一机架五分钟内超过 10% 的 Worker 离线，触发高优先级通知；
• 某一 Flight Sheet 下的平均算力突然下降超过设定比例，优先检查最近变更；
• 矿池拒绝率集中上升时，暂停自动重启，避免反复拉起造成更多干扰；
• 批量任务完成后的十分钟内，单独观察目标组在线率、算力和功耗偏差。

每条高优先级告警都对应一个处置人。夜班收到后要在三分钟内回复“已接手”，五分钟内判断影响范围。超过十分钟仍无法止损，必须通知当班负责人，不能靠不断重启拖延时间。

告警的价值不在于发了多少条，而在于能否让人少走一步弯路。

共用管理员账号查不清操作人，判断是权限划分已经失效

这次事故还有一个尴尬细节：最初的活动记录只能证明管理员账号执行了操作，却不能立刻确认是谁下发的。因为夜班为了方便，几个人长期共用一个高权限账户。

矿场里最危险的便利，往往就是“大家都能改”。

我们取消了共享管理员账户，按照工作内容重新分配权限。巡检人员主要查看状态、确认告警，不允许修改钱包、矿池和全场配置；值班工程师可以处理指定 Farm 内的重启和配置切换，但不能调整其他区域；涉及钱包模板、批量升级、全场 Flight Sheet 替换的操作，只保留给少数负责人。

高风险任务还增加了双人确认。提交人负责说明变更内容、设备数量和预计影响，复核人核对目标范围以及恢复方案。两个人不能使用同一账号，也不能由提交人自己完成复核。

权限收紧后，临时操作确实多了一道手续，但它换来的是清晰的责任记录。出现异常时，我们能直接回答三个问题：谁在什么时间改了什么，影响了哪些机器，谁批准了这次变更。

故障后继续批量重启，判断是恢复动作缺少优先级

当晚损失最大的动作并非首次误推，而是后续两轮全量重启。错误配置仍然存在，重启只能让机器再次加载同一套参数。部分矿机因此反复离线，恢复时间被进一步拉长。

现在我们的故障处置顺序已经固定下来。遇到批量异常，值班员先冻结后续任务，保存当前页面、任务记录和关键日志；随后确认最近十五分钟是否发生过 Flight Sheet、矿工软件版本、超频参数或钱包配置变更；找到可疑变更后，只选择两台机器进行恢复验证。

验证机恢复正常并连续提交有效份额后，才允许扩大到一个机架。一个机架稳定后，再按设备组推进。恢复过程中禁止直接选择“全部 Worker”，除非已确认问题来自统一的外部网络或矿池故障。

这套顺序看似慢，实际比盲目重启快得多。矿场故障处理的目标并非让所有机器立刻有动作，而是阻止错误继续扩大。

旧版本找得到却不敢切回，判断是回滚没有经过实机检验

事故当天，我们虽然保留了上一版 Flight Sheet，但没人能马上确认它是否仍然可用。矿池备用地址有没有失效、钱包模板有没有变更、矿工软件包能否正常下载，都需要临时检查。

有备份不等于能恢复。未经验证的旧配置，只是一份心理安慰。

流程改造后，每次生产变更都要记录四项内容：变更前版本、变更后版本、适用机型、回退触发条件。旧配置至少保留两个稳定版本，名称中写明日期和设备范围，禁止使用“新版”“最终版”“临时修复”这类无法追溯的命名。

每周低负载时段，我们会抽取两台机器做一次真实回退：切换旧 Flight Sheet，确认矿工软件启动、矿池连接、有效份额和功耗表现，再切回当前版本。演练失败就立即修订，不能等事故发生后才发现旧版本已经不可用。

回退条件也要量化。例如，变更后十分钟内在线率下降超过 5%，或平均算力偏离基准超过 8%，值班员无需等待口头指示，可以先暂停扩大发布并启动小范围恢复。

白班复盘只谈个人失误，判断是事故还会换个人重演

我们没有把这次事故处理成一张处罚单。值班员确实选错了范围，但设备分组、账号权限、变更审核和告警处置都给错误留下了通道。

复盘会上，我们按时间线逐分钟还原：2 点 17 分提交任务，2 点 19 分首批机器掉线，2 点 22 分触发集中告警，2 点 25 分执行第一次重启，2 点 31 分才检查活动记录。这样梳理后，流程缺口比个人情绪更容易看清。

从今天开始，我们给 HiveOS 批量操作定下五个硬动作：生产与测试设备分开管理；超过规定数量必须双人确认；高权限账号不得共享；批量变更后保留十分钟观察期；每周抽机验证一次旧配置。

矿场运维负责人真正要盯住的，也正是这五件事。不要等面板大面积变黄才寻找恢复文件。先把可操作范围缩小，把异常通知交给明确的人，再用少量机器验证恢复路径。这样，即使下一次有人选错配置，事故也只能停在两台测试机上，而不会顺着一个确认按钮跑满整个矿场。