文章目录
挖矿软件越自动，配置版本越要像账目一样逐笔可查
凌晨 2 点 17 分，值班群里出现了一条看似普通的提醒：一批矿机拒绝率升到 4.8%。当班人员判断备用矿池线路不稳，便打开共享模板，把备用地址和重试次数改了两处，然后点击批量同步。
三分钟后，186 台矿机开始反复重启挖矿进程。其中一部分切到了错误的钱包标签，另一部分因为新配置字段与旧版挖矿软件不兼容，直接卡在启动检查。值班人员尝试恢复“上一版配置”，控制面板却只保留了最后一次保存结果。备份目录里虽然有旧文件，却没人能确认它对应哪个软件版本、哪批机器，以及当时使用的是哪组环境变量。
这次故障持续了 41 分钟。真正耽误恢复的并非问题多复杂，而是现场回答不了三个问题：谁改了什么，变更实际覆盖了哪些机器，哪一个版本可以安全恢复。
发生了什么：一次小修改被自动化放大
从操作记录看，值班人员只改了两个字段，动作本身也符合当时的判断。事故之所以扩大，关键在于共享模板同时被三个自动任务引用。
第一个任务每两分钟检查配置差异，发现模板变化后自动下发；第二个任务检测进程退出，连续失败两次就重启服务；第三个任务根据矿池响应状态切换备用地址。三个任务单独看都有明确用途，叠加后却形成了循环：错误配置下发、进程退出、服务重启、再次切换、重新下发。
更麻烦的是，矿场里同时运行着两个小版本的挖矿软件。新版支持新增的连接参数，旧版遇到同名字段会直接报错。过去大家习惯把“软件文件”和“配置文件”分开管理，升级时只登记程序版本，修改模板时也没有记录适用范围。自动同步一启动，版本差异立刻从局部问题变成批量停机。
作为运维工具管理员，我在复盘里最关注的不是谁点了按钮，而是系统为什么允许一份未经验证、没有适用范围的配置直接覆盖 186 台设备。
最容易误判的地方：有日志不等于有账本
不少控制面板都能记录登录、保存、下发和重启，看上去已经足够审计。但操作日志只能证明“发生过一次点击”，未必能还原当时的完整状态。
一份可用的配置账本，至少要同时保存以下内容：
- 修改前后的配置差异，不能只留最终文件；
- 操作者、审批者、发布时间和关联工单；
- 目标设备清单，以及实际成功接收的设备清单；
- 挖矿软件版本、配置格式版本和启动参数；
- 密钥或钱包字段的引用编号，避免直接记录明文；
- 自动任务的触发结果，包括跳过、失败和重复执行；
- 对应的恢复版本，以及恢复前必须满足的条件。
事故中虽然查到了操作账号，却无法证明模板保存后是否被其他脚本二次改写。面板显示“下发成功”，实际只代表接口返回成功，不代表进程已经使用新配置正常提交份额。
因此，配置账本还要记录验证结果，例如进程存活时间、有效算力、拒绝率、矿池侧矿工名和钱包标签。没有这些结果数据，所谓成功发布只完成了一半。
第二个误区：保留旧文件就能随时回滚
版本回滚常被理解为把旧配置复制回去。这个做法只在环境完全没有变化时可靠，而现实中的挖矿软件经常同时改动程序、配置结构、驱动依赖、启动脚本和监控插件。
本次事故第一次回滚失败，就是因为旧配置恢复后，机器仍运行新版启动脚本。脚本会自动补全一个新版字段，随后旧版程序再次退出。直到我们把程序包、配置、启动脚本和环境变量一起恢复，服务才稳定下来。
以后每次发布都应生成一个完整版本包，至少绑定四项内容：
1. 挖矿软件安装包及文件校验值；
2. 对应的配置模板和格式编号；
3. 启动参数、环境变量及依赖版本；
4. 健康检查规则和明确的回滚条件。
版本包还要标注适用设备。不同显卡、驱动、固件和操作系统镜像不能默认共用一个版本。回滚按钮背后必须执行完整恢复动作，不能只替换某个配置文件。
同时要定期验证旧包能否真正启动。存档半年却从未演练的版本，很可能已经遇到下载地址失效、证书过期、依赖缺失或矿池接口变化。这样的“备份”只能带来心理安慰。
自动化的权限边界要按影响范围划分
自动化最危险的地方，是机器执行得太快。人工误操作可能只影响当前设备，拥有全场权限的脚本则能在几分钟内覆盖所有节点。
权限设计不能只分管理员和普通用户。更实用的做法是按动作和影响范围拆开：
- 巡检账号只能读取状态，不能修改模板；
- 模板编辑者可以提交变更，但不能直接批量发布；
- 发布账号只能操作指定设备组，并设置单批数量；
- 自动切换程序可以选择预先批准的矿池地址，不能修改钱包；
- 紧急值班人员可以暂停任务和执行已审核的恢复包，不能创建新版本；
- 钱包、矿池密钥和代理凭证由独立凭证服务提供，配置人员只接触引用编号。
高风险动作还应增加时间限制。例如夜间允许暂停同步和恢复稳定版本，但禁止修改全局模板；临时权限在故障结束后自动失效；超过 20 台设备的发布需要二次确认。
这并非拖慢处置。事故中如果值班账号只能先改 10 台测试组，186 台机器就不会同时重启。
配置发布要能自动刹车
治理配置并不意味着放弃自动化，恰恰要给自动化加上可测量的停止条件。
一次正常发布可以按 5 台、20 台、一个机架、一个区域逐步扩大。每批执行后观察固定指标：进程启动成功率、十分钟有效算力、拒绝率、重启次数、钱包标签和矿池连接状态。任何一个指标越线，系统立即停止后续下发，并保留现场，不再让重启任务反复覆盖证据。
还要避免多个自动任务同时改动同一对象。模板发布期间，矿池切换脚本应进入只读状态；回滚期间，配置同步任务必须暂停；设备处于人工排障状态时，自动修复不得抢回控制权。每台机器在同一时刻只能有一个配置写入者，这条规则应由工具强制执行。
下一步：把今天的配置整理成可恢复版本
矿场可以从一次小范围盘点开始，不必等到更换整套管理系统。
今天先选一个机架，导出当前挖矿软件版本、配置文件、启动参数和自动任务清单，为它们生成统一版本号。随后做一次配置差异记录，明确哪些字段由人工维护，哪些由脚本生成，钱包与凭证分别从哪里读取。
明天安排一轮十台机器的回滚演练：发布一个测试改动，确认账本完整记录，再恢复到上一版本，核对算力、拒绝率和矿池侧标签。演练结束后，收回共享管理员账号，把“编辑模板”“批准发布”“执行恢复”分配给不同角色。
最后给所有批量任务设置设备上限和自动停止条件。做到这一步，下一次凌晨出现异常时，值班人员无需凭记忆翻找旧文件，只要从配置账本中找到最近一次稳定版本，核对适用设备和恢复条件，再按受控批次执行即可。
