自动化覆盖的矿机越多，挖矿软件越要把每次配置变更记成账

晚上 22 点 10 分，一次计划内更新从 8 台测试机开始。管理端、矿工程序和驱动都没有报错，算力也在十分钟内恢复，值班人员于是放开了后续 96 台机器的自动升级。十五分钟后，31 台矿机反复重启，矿池端显示授权失败。

现场第一反应是退回旧版程序。安装包很快降了回去，故障却没有消失。继续查才发现，新版在首次启动时改写了备用矿池字段，旧版无法识别迁移后的配置格式。看起来只是一次软件升级，实际同时动了程序版本、配置结构和启动参数。团队有旧安装包，却没有升级前的完整配置快照。

这类事故最麻烦的地方，通常不在更新失败本身，而在于没人能立刻回答三个问题：哪些配置被改过，当前机器究竟运行着什么组合，以及谁有权让自动化继续扩散。

发生了什么：回退程序以后，配置还停在新版

复盘这次更新，故障链路并不复杂。

新版矿工程序调整了备用矿池字段的写法，管理端在下发任务时自动执行了配置迁移。8 台测试机只使用主矿池，没有触发相关字段，因此升级结果正常。后续机器中有一部分保留了备用矿池和独立 Worker 命名规则，迁移脚本生成了旧版无法读取的参数。

更棘手的是，自动化任务带有连续重试策略。矿工程序启动失败后，守护进程立即重启；多次失败后，管理端又尝试重写配置。短短几分钟内，同一批机器上出现了数个配置状态。有人手工修过矿池地址，有人执行过版本降级，自动化程序随后又覆盖了人工修改。

到了这个时候，“退回上一版本”已经不是一个动作，而是一组动作：退管理端组件、退矿工程序、恢复配置结构、核对启动参数，并确认自动任务已经停止。少做一步，机器就可能继续处于半新半旧的状态。

容易误判的地方：版本号相同，不代表运行条件一致

矿场做软件盘点时，常把版本号当成唯一依据。管理面板显示全部运行 4.8.2，似乎就能判断环境已经统一。实际运行中，至少还要核对五项内容：

• 管理代理的版本；
• 矿工程序及其内核版本；
• 显卡驱动或设备固件版本；
• 配置结构的版本；
• 参与生成配置的插件、脚本和模板版本。

任何一项不同，都可能让相同配置产生不同结果。例如，同一个功耗字段，在旧脚本里可能被当作固定值，在新脚本里可能被解释为偏移量；同一个矿池变量，在模板更新后也可能改变拼接顺序。

因此，版本管理不能只记录“安装了哪个包”，还要记录这台机器当时使用了哪套配置、由哪个模板生成、经过哪个脚本处理。对运维工具管理员来说，真正可复现的对象应当是一个完整版本组合，而不是页面上的单个数字。

测试范围也不能只按机器数量决定。8 台测试机不一定比 3 台更有代表性。更合理的做法是按配置差异选样本：有无备用矿池、不同显卡型号、不同驱动、独立超频参数、特殊启动项以及长期未重装的老机器，都应至少覆盖一台。

有备份仍然恢复不了，通常是备份内容记少了

不少团队确实在升级前做了备份，但备份的只是配置文件副本。等到需要恢复时才发现，文件来自哪个模板、当时引用了哪些变量、谁在页面上改过参数，全都无法确认。

配置账本应该比普通备份多记录一层变更关系。每次发布至少留下这些信息：

• 变更对象，包括矿机、机架、分组和模板；
• 修改前后的差异，具体到字段和值；
• 变更来源，是人工编辑、定时任务还是脚本生成；
• 执行人、审批人和实际生效时间；
• 对应的软件包、驱动、插件及配置结构版本；
• 发布后的算力、拒绝率、重启次数和连接状态；
• 可用的恢复点，以及恢复步骤是否演练过。

这里最重要的是“修改前后的差异”。只保存一份完整文件，发生故障时仍要花时间逐行查找；把差异直接记进账本，值班人员可以迅速判断问题来自矿池地址、功耗参数还是启动项。

账本还应避免被原任务覆盖。自动化服务既能改配置，又能删记录，审计就失去了意义。变更记录应写入独立存储，普通执行账号只能追加，不能修改历史内容。紧急修复也不能例外，可以先执行后补审批，但必须留下操作者、时间和原因。

自动化账号权限过大，会把一次错误放大成整场事故

这次事故中，更新服务同时拥有上传软件包、迁移配置、重启程序、覆盖人工修改和扩大执行范围的权限。这样设计很省事，却让一个任务具备了从“准备变更”到“全场执行”的全部能力。

更稳妥的方式是把权限拆开。

日常维护人员可以查看配置并提交修改草稿，但不能直接发布到生产分组；发布账号可以使用已经批准的版本组合，却不能临时上传未知程序；自动化服务只执行签名任务，不允许自行改变目标范围；应急账号可以暂停任务和恢复指定快照，但不能顺手改收益地址。

尤其要限制收益地址、矿池凭据和下载源。这些字段一旦与普通性能参数放在同一权限层，调功耗的人也可能无意中改到结算路径。涉及钱包地址、矿池账户、代理地址和软件源的修改，应单独审批，并要求第二人核对。

权限边界并不会拖慢所有操作。恰当的做法是把高频、低风险动作预先批准，例如重启单个矿工进程、切换到已验证的备用矿池；把低频、高影响动作单独拦截，例如改全场模板、替换程序源、升级配置结构。

下一步怎么做：让发布任务先经过配置账本

挖矿软件的更新流程可以从“选机器、点升级”改成“生成版本组合、记录差异、分组验证、逐步放量”。

发布前，系统先生成一份不可修改的任务清单，列明软件包校验值、配置结构版本、模板版本、目标机器和恢复点。任务开始后，如果执行对象临时增加，必须重新审批，不能沿用原授权。

验证时不要只看算力是否恢复。至少观察矿池连接、拒绝率、进程重启次数、设备识别数量和配置文件校验值。算力恢复只能说明程序暂时跑起来，无法证明配置没有漂移。

自动化还需要熔断条件。例如，同一分组有 5% 的机器连续启动失败，任务立即暂停；配置校验值与发布清单不一致时，停止覆盖；回退后仍失败的机器退出自动队列，交给人工处理。无限重试看似积极，实际会清掉现场痕迹，也可能把原本可控的错误写进更多机器。

回退则要同时准备两份内容：旧程序包和旧配置快照。凡是涉及字段迁移的版本，都要提前测试“新版升上去后，能否完整退回旧版”。如果只能升级、无法反向恢复，就不应直接用于大批量生产机器。

今天就能落地的六个动作

运维工具管理员可以先做一次小范围治理，不必等待系统全面改造：

1. 导出当前所有矿机的软件、驱动、模板和配置结构版本，找出同组内的混用情况。

2. 给每套生产配置建立唯一编号，禁止继续使用“最终版”“新版2”这类无法追踪的名称。

3. 将每次变更的前后差异、执行账号和任务编号写入独立账本。

4. 为最近三个常用版本准备程序包与配置快照，并实际恢复一台测试机。

5. 收回自动化服务修改收益地址、上传软件源和扩大目标范围的权限。

6. 给批量任务设置失败比例、重启次数和配置校验三类熔断条件。

挖矿软件越依赖自动执行，一次小改动传播得就越快。把配置记清、把版本组合固定、把执行权限切开，目的不是增加运维手续，而是让值班人员在故障发生后的十分钟内，知道该停什么、退到哪里，以及哪些机器绝不能继续自动处理。