挖矿软件的自动化越快，配置账本越要跟得上

凌晨 1 点 17 分，值班群里跳出第一条掉算力提醒。不是整场断网，也不是矿池挂了，而是 B 区 36 台机器的有效算力开始一台接一台往下掉。面板上看，矿机还在线，风扇转速正常，温度也没越线，可 20 分钟后，拒绝率从平时的 0.8% 拉到了 7% 以上。

当晚我接到电话时，第一反应是查矿池延迟。结果延迟没问题，矿池状态也正常。再看挖矿软件日志，发现这些机器在 0 点 50 分左右被推过一次配置：矿池地址没变，钱包地址没变，变的是一段看起来不起眼的启动参数。更麻烦的是，后台没有清楚记录这次配置来自哪个模板、谁点了确认、覆盖了哪些机器。

这类事故以前很容易被归到“自动化误操作”。但从运维工具管理员角度看，真正的问题不是自动化本身，而是自动化跑得太顺，配置账本却没跟上。

这次事故到底改了什么

复盘时，我们把 36 台机器的现有配置、前一天备份配置、挖矿软件版本、任务下发记录逐项拉出来对比。最后定位到一个细节：有人把测试机上的优化参数保存成了通用模板，随后在批量任务里选错了分组。

这段参数在测试机上没有出问题，因为测试机用的是新版挖矿软件，驱动和内核参数都匹配；但 B 区那批机器还停在旧版本，某个参数会导致提交 share 时偶发异常。异常不至于让软件崩溃，所以机器仍然显示在线，温度和功耗也正常，只有有效算力和拒绝率在慢慢变坏。

最让人难受的是，事故不是一键全场炸掉，而是“看起来还能跑”。这种故障比直接离线更容易拖时间。因为值班人员会先怀疑矿池、网络、矿机单体状态，最后才回头查配置差异。

如果当时有完整配置账本，事情会简单很多：哪一批机器在几点几分收到了哪个配置包，配置包来自哪个模板，模板相对上一个版本改了哪几行，谁审批、谁执行、谁有权覆盖生产分组，都应该能在几分钟内查出来。

容易误判的地方：把面板正常当成系统正常

很多矿场现在都已经有自动化工具：批量改矿池、批量调参数、批量重启软件、自动拉起进程、掉线后自动切备用矿池。功能越多，面板越漂亮，反而越容易让人忽略一个现实：挖矿软件的配置变化，往往不会马上表现为“红灯”。

比如启动参数不匹配，可能只让拒绝率慢慢升高；备用矿池顺序错误，可能在主矿池波动时才暴露；钱包备注填错，不影响算力显示，却会让结算对账出问题；某些版本的挖矿软件对同一参数解释不同，今天看着正常，下一次重启才开始异常。

运维工具管理员最怕的不是有人改错，而是改错之后没人知道“错从哪里来”。如果只有当前配置，没有历史配置；只有机器状态，没有配置来源；只有执行结果，没有审批记录，那么每次排障都会变成猜谜。

这里还有一个常见误区：认为备份配置就等于配置治理。备份只是把某一刻的文件存下来，配置账本要记录的是一串变化：谁在什么时候把什么值从 A 改到 B，为什么改，影响范围多大，是否经过灰度，能不能按机器组回退。没有这串记录，备份文件再多，也很难在事故现场派上用场。

自动化不该绕过版本管理

这次事故还有一个关键点：同一套参数，被推到了不同挖矿软件版本上。

很多矿场为了省事，会按机型、币种或矿池来分组，却很少按挖矿软件版本来分组。平时看不出问题，一旦参数和版本强相关，风险就会被放大。尤其是挖矿软件更新频繁时，新版本修了一个兼容问题，旧版本可能还存在；新版本支持的参数，旧版本可能会忽略，也可能按另一种方式执行。

所以版本管理不能只停留在“现在装的是哪个版本”。更实用的做法，是把版本和配置绑定起来看。

一台机器当前运行哪个挖矿软件版本，对应哪个配置模板，模板适配哪些版本，最近一次重启是否加载了新配置，这些信息应该放在同一个页面或同一份记录里。否则自动化任务下发时，操作者只看到“B 区 36 台”，看不到里面有 12 台新版、24 台旧版，就很容易把测试结论误用到生产机器上。

版本回滚也一样。很多人以为回滚就是把软件退回上一个版本，但真正要回滚的往往是一组东西：挖矿软件版本、配置文件、启动参数、插件或脚本、矿池优先级。只退软件不退配置，可能继续报错；只退配置不退软件，可能触发另一个兼容问题。

对运维工具来说，比较靠谱的回滚单位应该是“可运行组合”。也就是把软件包、配置模板、参数说明和适用机器组打成一个可追踪的组合。出了问题，不是现场临时拼，而是直接回到上一个验证过的组合。

权限边界不能只靠群里提醒

事故复盘时，还有一个不好听但必须说的问题：为什么测试模板能被保存成通用模板？为什么一个值班账号可以把测试参数推到生产分组？

很多矿场喜欢在群里写规则，比如“测试参数不要推生产”“夜间不要大批量操作”“改模板前先说一声”。这些提醒有用，但不能替代权限边界。人会困，会急，会点错按钮，尤其在行情波动、矿池不稳定、老板催收益的时候，靠自觉很难长期稳定。

权限设计要贴近实际动作，而不是只分管理员和普通用户。比如，有的人可以查看配置，但不能保存模板；有的人可以保存测试模板，但不能改生产模板；有的人可以对 5 台以内机器执行任务，超过数量必须二次确认；涉及钱包地址、矿池地址、抽水比例、启动参数的改动，应该有更高等级的审批。

另外，权限还要有时间边界。夜间值班账号可以重启软件、切备用矿池，但不应该有修改全场模板的权限。临时外包维护人员可以查看日志，不应该能导出钱包相关配置。离职、换岗、项目结束后的账号清理，也要进固定清单，而不是靠谁想起来再处理。

权限边界做得细，不是为了增加流程，而是为了让自动化少背锅。很多所谓“系统误操作”，最后查下来都是账号权限过大、模板命名混乱、确认步骤太少。

下一步怎么改：把配置账本做成日常动作

如果今天要给矿场的挖矿软件运维提一个最具体的建议，我会先从配置账本开始，而不是立刻换一套更复杂的自动化平台。

第一，把所有生产配置模板编号。不要只叫“BTC 稳定版”“高算力参数”“备用模板 2”这种名字，要能看出适用范围、挖矿软件版本、创建日期和负责人。模板说明里必须写清楚改了哪些关键项，不能只留一句“优化参数”。

第二，配置下发前做差异确认。不是让人肉眼翻完整文件，而是至少把矿池地址、钱包地址、启动参数、抽水相关项、超频或功耗项、备用策略这些关键字段列出来。执行人要知道这次到底变了什么。

第三，批量任务按小范围灰度。哪怕只是 3 台机器先跑 20 分钟，也比一口气推 300 台安全。灰度机器最好包含不同批次、不同版本，别永远只拿最新测试机当样本。

第四，回滚方案要提前绑定。每个生产模板旁边都应该有上一个稳定模板，最好能一键回退到对应的软件版本和配置组合。回滚不是事故发生后再讨论，而是发布前就要写好。

第五，每周做一次配置对账。随机抽几组机器，对比工具后台记录、机器实际文件、运行日志里的加载参数，看三者是否一致。很多问题不是当天冒出来的，而是在多次小改动里慢慢积累。

挖矿软件的自动化还会继续加速，批量调度、自动切换、智能参数推荐都会越来越常见。但在矿场现场，真正能减少损失的往往是几件朴素的事：每次改动有账可查，每个版本能回到原点，每个账号只做它该做的事。

今天就可以先做一个小动作：找出最近 7 天所有挖矿软件配置改动，逐条补上执行人、影响机器、对应版本和回滚位置。补完这本账，你会马上知道，下一次掉算力时，自己到底能不能在 10 分钟内找到问题源头。