挖矿软件的自动化会越来越像一套变更管理系统

凌晨 2 点 17 分，值班手机连续震了三次。不是全场掉线，也不是矿池宕机，而是 3 号机架的一批机器算力忽高忽低，十几分钟里从正常值掉到六成，又慢慢爬回来。面板上看，挖矿软件还在运行，矿机没有重启，温度也没异常。最麻烦的是，值班同事只看到“自动切换配置已执行”，却不知道到底是哪条规则触发了切换、切到了哪个配置、谁在前一天改过这条规则。

这类事故放在几年前，多半会被归到“软件抽风”或者“矿池波动”。但从运维工具管理员的角度看，真正的问题不在某一次切换，而在配置没有账本，版本没有留痕，自动化脚本的边界也没划清。挖矿软件越能批量控制机器，越不能只靠经验和口头交接。

发生了什么：一条自动规则改动，带偏了半个机架

这次事故复盘下来，触发点很小。

前一天下午，有同事为了应对某个矿池短时延迟，把一组备用配置的优先级调高了。原本这组配置只用于 5 台测试机器，里面的抽水地址、矿池端口、备用节点顺序都没问题，但它配套的超频模板偏激进，适合温度较低的测试区，不适合靠近热通道的 3 号机架。

问题出在配置命名太像。一个叫“pool-bak-lowfee”，一个叫“pool-bak-lowfee-rack3”。前者是通用备用配置，后者才是给 3 号机架单独调过风扇策略的版本。管理员在批量规则里选错了对象，系统也没有二次提示：这个配置影响多少台机器、对应什么温控模板、上一次在哪些机器上验证过。

到了凌晨，矿池延迟触发了自动切换。软件按规则把 3 号机架的一批机器切到了那套测试配置。矿机没有立刻崩，反而更难查：算力不是归零，而是抖动；错误率有上升，但没有超过旧告警阈值；脚本执行日志里只有“success”，没有展示配置差异。

最后把问题定位出来，靠的是人工翻聊天记录和操作截图。也就是说，挖矿软件负责执行了动作，但运维侧没有一套清晰的配置账本告诉我们：谁在什么时间改了什么，改动影响哪批机器，改动前后差异是什么，是否经过灰度验证。

容易误判的地方：自动化成功，不等于运维成功

很多矿场在评估挖矿软件时，很容易被“批量”“自动”“一键”吸引。批量下发配置、自动切矿池、掉线自拉起、异常自重启，这些功能确实能省人。但如果没有治理规则，自动化只是把人的误操作放大得更快。

第一个误判，是把执行结果当成变更结果。

软件显示配置下发成功，只能说明文件写入了、进程重载了，不能说明这套配置适合当前机器。矿机型号、固件版本、所处机架温度、矿池延迟、网络出口都可能影响结果。管理员真正需要看的，不只是“执行成功”，还要看到变更后 5 分钟、30 分钟、2 小时内的算力、拒绝率、功耗、重启次数有没有偏离基准。

第二个误判，是把配置文件当成普通文本。

很多团队的配置管理还停留在“复制一份”“改个名字”“群里发一下”的状态。短期看方便，长期看一定混乱。一个矿池地址改动、一个钱包尾号变更、一个启动参数调整，都应该进入配置账本。账本不一定复杂，但至少要记录配置名称、适用机器范围、关联模板、修改人、修改原因、验证状态和当前版本。

第三个误判，是把软件账号当成值班账号。

挖矿软件的管理后台常常被多人共用。白班要改矿池，夜班要处理掉线，外包维护要看日志，老板也想打开面板看收益。结果一个账号给太多人用，出了问题只知道“管理员操作”，不知道具体是谁。更糟的是，有些账号既能看收益地址，又能批量下发脚本，还能改自动规则。权限混在一起，等于把矿场的方向盘、油门和刹车都交给同一个按钮。

配置账本要记什么：别只留最终文件，要留改动关系

如果今天让我接手一套矿场挖矿软件，我不会先问有没有最新脚本，而是先看配置账本有没有成型。

配置账本不是为了写文档好看，而是为了事故发生时能快速回答几个问题：当前机器跑的是哪一版配置？这版配置从哪里来的？上一次变更改了哪些字段？有没有在小范围机器上跑过？如果要退回，退到哪个版本？

最简单的做法，是把配置分成三层记录。

第一层是矿池与钱包信息。包括主矿池、备用矿池、端口、协议、钱包地址、Worker 命名规则。这里最怕的是地址被误改，或者不同机架用了不同格式，后面对账时查不到来源。

第二层是运行参数。包括核心频率、功耗限制、风扇策略、重启条件、连接超时、重试次数。这一层直接影响机器稳定性，不能和矿池切换规则混在一起随便动。

第三层是自动化规则。包括什么条件触发切换，连续几次失败才执行，执行后观察多久，失败后是否自动退回。这一层应该最谨慎，因为它会在没人盯着屏幕的时候替人做决定。

账本里还要有“影响范围”。一条配置如果只影响 5 台测试机，风险可控；如果会影响 500 台机器，就必须有审批和灰度。很多事故不是配置本身错得离谱，而是范围选大了。挖矿软件界面如果不能清楚显示影响机器数量，管理员就应该在自己的台账里补上这一列。

版本管理别停在备份：能退回，才算有版本

不少矿场也会做备份，但备份和版本管理是两回事。

备份通常是一堆压缩包，名字像“配置最终版”“配置最终版2”“4月修正版”。真到出事时，没人敢确定哪一个能用。版本管理要解决的是确定性：每个版本都有编号，有说明，有适用范围，有上线时间，有验证记录。

挖矿软件的版本管理，至少要覆盖两类东西。

一类是软件自身版本。矿工程序、管理面板、驱动依赖、API 插件，都可能因为升级造成行为变化。比如旧版本对连接超时的判断比较宽，新版本更敏感；旧版本日志字段叫 timeout，新版本拆成 network_timeout 和 auth_timeout。如果脚本还按旧字段判断，就会误触发动作。

另一类是配置版本。配置版本不能只跟着软件升级走。矿池策略调整、机器搬架、固件更换、电价时段变化，都可能需要新配置。这里最好建立“稳定版、灰度版、测试版”三个状态。测试版只跑少量机器，灰度版扩大到一个机架，稳定版才允许全场使用。

回滚也要提前演练。很多人以为回滚就是把旧文件覆盖回去，但实际现场没这么简单。旧配置是否兼容新软件？旧矿池端口是否还可用？回滚后进程是否需要重启？回滚会不会把已经修正的钱包地址也退回去？这些都要在演练时写清楚。

一个可靠的回滚动作，应该能在 10 分钟内完成三件事：确认当前版本，选择目标版本，核对影响机器。执行完以后，还要自动或人工检查算力恢复、拒绝率回落、进程稳定。否则回滚只是第二次盲改。

权限边界要按动作拆：能看、能改、能执行不能混在一起

挖矿软件后台最容易被低估的风险，是权限过宽。

运维工具管理员要做的，不是把所有人都挡在门外，而是让每个人只能做自己该做的动作。看日志的人不一定能改配置，改单台机器的人不一定能批量下发，能新建配置的人不一定能启用自动规则。

可以把账号按动作拆成几类。

观察账号，只能看机器状态、日志、算力曲线和配置名称，不能导出钱包明文，也不能执行命令。给老板、财务、普通值班人员使用。

处置账号，可以重启单台进程、暂停某台机器、切换到已批准配置，但不能创建新脚本，不能改钱包地址，不能批量覆盖全场。给夜班和现场维护使用。

变更账号，可以修改配置、提交版本、发起灰度，但需要审批后才能扩大范围。给运维管理员使用。

高级账号，只保留给少数人，用于修改权限、接入新矿池、调整自动化策略。这个账号不能日常登录，更不能多人共用。

此外，自动化脚本也要有身份。不能所有脚本都用同一个超级权限跑。切矿池脚本只该拥有切矿池权限，拉起进程脚本只该拥有进程控制权限，读取日志脚本不该顺手拿到钱包和批量执行能力。脚本权限越细，出错时损失越小。

下一步怎么做：从今天开始补三本小账

如果矿场今天已经在用挖矿软件做批量运维，不必等到系统大改版再行动。先补三本小账，就能明显降低误操作成本。

第一本是配置账。把现有配置全部梳理一遍，标清名称、用途、适用机器、关联钱包、关联矿池、创建人和最后修改时间。命名不要只追求短，要能看出机架、币种、矿池和状态。废弃配置不要直接删除，先标记停用，避免有人继续引用。

第二本是版本账。给正在使用的软件版本、矿工程序版本、关键插件版本和配置版本统一编号。每次升级或改配置，都写一句人能看懂的说明：为什么改，改了什么，影响哪些机器，如何退回。不要把说明写成“优化参数”这种空话，至少要具体到矿池、端口、频率、重试次数这类字段。

第三本是权限账。列出所有后台账号、API Token、脚本密钥和外包访问方式，逐个确认能做什么。共用账号要尽快拆开，长期不用的账号要停掉，能批量执行命令的账号要单独记录。夜班需要应急能力，但不应该拥有修改全场自动规则的能力。

挖矿软件以后会继续变得更自动，更多判断会交给规则和脚本完成。对运维工具管理员来说，重点不是反对自动化，而是让每一次自动动作都有来源、有范围、有版本、有退路。今天就可以从一件小事开始：挑一个正在全场使用的配置，补齐它的版本说明和回滚目标。等下一次凌晨手机响起时，你至少能先回答清楚：现在跑的是哪一版，谁改过，能退到哪里。