文章目录
挖矿软件的自动化越深，配置版本越要像资产一样记账
凌晨 2 点 17 分，值班群里突然出现一串低算力提醒。最先掉下来的不是整台矿机，而是其中一批显卡的有效份额：本地算力看着正常，矿池端接收率却从 98.6% 降到 81%。值班人员检查网络、矿池状态和设备温度，都没有发现明显异常。直到半小时后才有人注意到，这批机器在凌晨 2 点执行过一次自动配置同步，矿池地址没有变，钱包地址也没变，但矿工名模板被覆盖，备用矿池的连接参数还沿用了旧版本。
事故不大，机器重载配置后很快恢复。麻烦在于，没人能立即回答三个问题：这次同步具体改了哪些字段，自动任务调用的是哪个版本，谁批准它覆盖生产机器。
这类问题正在变得常见。挖矿软件承担的工作越多，配置就越不能只保存在面板、脚本和管理员记忆里。矿场真正需要补上的，是一套能核对、能追溯、能准确恢复的配置账本。
发生了什么：一条自动任务改动了两处隐蔽字段
复盘日志后，我们把过程还原了出来。
前一天下午，运维人员为测试机组调整了矿工名规则，希望在矿池后台区分不同机架。配置修改完成后，他把这份模板保存成了“通用稳定版”。这个名称看起来没有风险，但模板里还带着测试期间使用的备用矿池端口，以及一项较激进的重连参数。
凌晨的自动化任务会检查矿机配置是否偏离“通用稳定版”。发现差异后，系统按照既定规则将模板推送给目标标签下的设备。问题恰好出在标签范围：测试机组和部分生产机组共享了同一个历史标签，自动任务因此覆盖了 126 台机器。
整个过程中，自动化程序没有报错。从它的判断看，模板读取成功、目标机器在线、配置下发完成、软件重载正常，每一步都符合预设条件。低算力直到矿池端统计周期结束后才暴露出来。
这正是挖矿软件自动化最容易制造的错觉：执行成功经常被当作业务正常。实际上，命令发出去了，只能证明任务跑完；矿池是否接受份额、拒绝率是否上升、矿工标识是否正确，还需要另一套结果核验。
容易误判的地方：面板里的当前值不等于完整记录
事故发生后，第一反应通常是打开面板查看当前配置。这个动作只能看到“现在是什么”，很难解释“之前是什么”和“为何变成这样”。
例如，同一份矿池配置至少可能来自四个位置：全局模板、机组模板、单机覆盖项和临时脚本参数。面板最终展示的往往是合并后的结果。管理员能看到当前矿池地址，却未必知道这个值由哪一层写入，也未必知道下一次同步会不会再次覆盖。
配置账本要解决的，就是这种来源不清的问题。每次变更至少应记录以下内容：
- 变更时间，以及任务实际执行时间；
- 操作账号、审批人和调用自动任务的身份；
- 目标对象，包括矿场、机房、机架、标签及机器数量；
- 变更前后的具体字段，不能只写“优化矿池配置”；
- 使用的软件版本、模板版本和脚本版本；
- 变更原因、关联工单及预期观察指标；
- 执行结果，以及矿池端接受率、拒绝率和在线数量。
这里最关键的不是多留几行日志，而是让一次配置变化拥有唯一编号。模板、脚本、审批单、设备范围和执行结果都挂在同一个编号下，管理员才能在事故发生时快速拼出过程。
如果配置修改仍靠截图、群消息和文件名区分版本，版本管理实际上就没有成立。“最终版”“稳定版”“新版2”都不能证明哪个文件真正用于生产。
第二个误判：有备份就一定能恢复
很多矿场确实会定期备份配置，但备份和可用回滚之间差着一次完整验证。
一份旧配置能否直接恢复，取决于当时的软件版本、驱动环境、矿工程序版本和接口格式。挖矿软件升级后，字段名称可能变化，默认值也可能被调整。旧模板即便成功导入，也可能出现部分参数被忽略、部分参数采用新默认值的情况。
所以，版本记录不能只保存配置文件，还要绑定运行环境。至少要明确这份配置对应哪个挖矿软件版本、哪个矿工程序版本，以及哪些机型已经验证。涉及混合显卡、不同固件或多个矿池时，适用范围更要写清楚。
回滚动作本身也应拆开。更稳妥的做法是先选择少量同型号设备恢复旧版本，观察启动、连接、份额提交和功耗变化；确认没有异常后，再逐批扩大范围。对于 100 台以上的机组，一次全量覆盖虽然省操作，却会把兼容性问题同时放大。
此外，系统要允许回滚单个字段。一次事故可能只涉及矿工名模板或重连间隔，没有必要把超频参数、风扇策略和钱包配置一起退回。回滚范围越粗，附带改变越多，恢复过程就越难控制。
自动化该加一道“刹车距离”
自动化任务需要的不只是开关，还需要执行边界。
第一道边界是目标数量。日常脚本如果通常只处理 10 台机器，当本次目标突然变成 126 台，系统应暂停并要求二次确认。数量异常是一种非常有效的风险信号，比弹出一句“是否确认执行”更有价值。
第二道边界是敏感字段。钱包地址、矿池地址、代理设置、远程访问凭据和批量升级源，一旦发生变化，就不应与普通参数采用相同审批规则。风扇转速微调可以由机组管理员处理，收益去向和远程控制方式则应由更高权限账号复核。
第三道边界是生效方式。配置可以先下发但暂不重载，等差异检查通过后再安排生效；也可以先作用于金丝雀机组，观察一个矿池统计周期。自动化追求速度，但矿场更应关注错误能扩散多远。五分钟覆盖全场并不代表效率高，也可能意味着事故没有缓冲区。
第四道边界是结果判定。任务完成后，系统应继续检查矿池端数据，而不是只检查进程是否存在。有效份额、拒绝率、重连次数和在线矿工数量，需要与变更前的基线比较。偏离设定幅度时，应停止后续批次，并保留现场数据。
权限问题往往藏在服务账号里
这次事故还有一个容易忽略的细节：配置由自动任务写入，日志显示的操作者是系统服务账号。它拥有全场配置权限，但没人定期检查这个账号能调用哪些模板、覆盖哪些机器。
管理员账号做了分级，不代表权限治理已经完成。定时任务、接口密钥、机器人账号和第三方运维插件，同样属于操作主体。它们通常长期在线，权限还比个人账号更宽，一旦范围设置错误，影响会持续重复。
较合理的办法是按照任务拆分身份。负责读取状态的账号只给查看权限；负责重启进程的账号不能修改钱包；负责同步普通参数的任务不能触碰升级源。跨矿场执行、修改收益地址、推送新版本等操作，则必须使用短期授权，并留下审批记录。
还要给服务账号设置有效期。某项临时迁移工作结束后，对应密钥应自动失效，避免几个月后仍被旧脚本调用。人员离职、职责调整、外包服务结束时，也要检查其创建过的自动任务，而不只是停用个人登录账号。
下一步怎么做：先把一条配置链路跑通
对中小矿场来说，没有必要一开始就搭建复杂系统。可以先选最常改动的一类配置，例如矿池和矿工名，连续执行四个具体动作。
第一，导出当前生产配置，按机型和机组建立基准版本，写明适用的软件版本与验证日期。第二，把模板每次修改后的字段差异保存下来，禁止用覆盖文件的方式维护“最新版”。第三，将自动任务限制在一个小机组，设置目标数量上限和矿池端结果检查。第四，安排一次真实回滚演练，记录从发现异常到恢复有效份额所需的分钟数。
完成这条链路后，再把超频参数、代理设置、矿工程序升级逐项纳入。每增加一类配置，都应补齐负责人、审批条件、验证指标和回滚方法。
今天就可以检查三件事：面板里名为“稳定版”的模板究竟由谁维护，凌晨自动任务使用哪个服务账号，以及最近一次备份是否在当前软件版本上恢复过。能把这三个答案写进同一条记录，下一次算力异常出现时，值班人员就不用从聊天记录里猜发生了什么。
