文章目录
挖矿软件会越来越像一套配置审计系统
凌晨两点十七分，值班群里先跳出来的不是掉线告警，而是一张收益曲线截图：同一排机器，算力还在，拒绝率却突然从 0.8% 拉到 6% 以上。看起来不像断网，也不像矿池大面积波动。值班同事按老习惯准备批量重启，我把他拦了一下，先去翻挖矿软件的操作记录。
问题很快浮出来：晚上十一点半，有人把一组备用矿池参数同步到了 320 台机器，但这组参数原本只应该给 20 台测试机用。更麻烦的是，这次同步不是通过正式发布流程走的，而是从个人脚本里直接推过去的。脚本执行成功，面板显示“配置已更新”，机器也没有掉线，于是没人第一时间意识到事故已经发生。
这类事在矿场里不算罕见。以前大家谈挖矿软件，更多关心能不能自动切矿池、能不能批量调参数、能不能把异常机器拉起来。现在我越来越觉得，挖矿软件的下一步变化，不在于再多几个自动化按钮，而在于它要能像一本清楚的配置账本：谁改了什么、改给了哪批机器、从哪个版本改到哪个版本、出了问题能不能按分钟退回去。
发生了什么：自动化把一次小配置推成了大范围偏差
这次事故本身并不复杂。
我们有三套矿池配置：常用池、备用池、测试池。测试池最近在调新的端口和延迟策略，只挂了少量机器观察拒绝率。按流程，测试配置应该打上标签，只能绑定测试分组，不能出现在生产分组里。
但问题出在一个“临时方便”的动作上。运维同事为了省时间，把测试池参数复制到本地脚本里，准备给小分组推送。脚本里原本写的是测试分组 ID，后来为了查另一批机器状态，临时改过一次筛选条件，执行前没有再核对。结果推送范围扩大到了整排机器。
挖矿软件本身没有报错，因为从软件角度看，配置格式正确，矿池地址能连，钱包地址也合法。它只负责把参数发下去，并确认矿机接受了配置。至于这组配置是不是该发给这些机器，软件当时没有给出足够强的阻拦。
这就是很多矿场容易忽略的地方：自动化不是只会提高效率，也会把人的一次手滑放大。手动改 20 台，最多错 20 台；批量脚本错一次，可能就是几百台，甚至一整个场区。
容易误判的地方：算力没掉，不代表配置没错
事故刚出现时，最容易被误导的是算力曲线。
算力没有明显断崖，机器也没有大面积离线，温度、电压、风扇转速都在正常区间。很多人会下意识判断是矿池短时抖动，或者网络质量不好，先等一等，或者批量重启。
但拒绝率上升、提交延迟变大、收益估算偏低，这些指标往往比“掉线”更早暴露配置问题。配置错了不一定会让机器停下来，它可能让机器继续干活，只是干得更低效。对矿场来说，这种状态比直接掉线更麻烦，因为它不够刺眼，容易拖几个小时才被认真处理。
还有一个误判，是把版本号当成了配置版本。
很多挖矿软件面板会显示软件版本，比如某个 miner 版本、某个管理端版本。运维看见版本一致，就以为环境一致。实际上，同一个软件版本下面，矿池地址、钱包、线程参数、超频策略、重试间隔、备用切换条件都可能不同。真正会影响收益的，往往不是软件包版本，而是运行配置版本。
所以我们后来把“版本”拆成两层看：一层是程序版本，另一层是配置版本。程序没变，不代表现场没变；配置一变，收益口径就可能变。
配置账本不能只记结果，还要记来源和理由
这次复盘后，我们做的第一件事，不是马上换软件，也不是把所有脚本禁掉，而是补一套配置账本。
配置账本不是简单的操作日志。普通日志只告诉你某个时间发生了更新，配置账本要回答更具体的问题：这次更新的发起人是谁，审批人是谁，目标机器是哪一组，旧配置是什么，新配置是什么，为什么要改，计划观察多久，失败后退回哪个版本。
尤其是“为什么要改”，以前很多人不愿意写，觉得浪费时间。但矿场里真正难查的事故，往往不是技术细节，而是动机丢了。三天后再回看一条配置变更，如果只看到“更新矿池参数”，没人知道当时是为了降低延迟、避开矿池维护、测试新端口，还是单纯复制错了。没有理由，复盘就只能猜。
配置账本还要把机器分组固定下来。比如测试组、灰度组、生产组、保守组，每一组允许接受哪些类型的配置，谁有权限改。不要让“按 IP 段临时筛选”“按备注模糊筛选”成为常态。矿场机器多了以后，备注一定会乱，IP 也可能调整，靠临时筛选做批量推送，迟早出事。
更实用的做法，是让每台机器都有明确标签：机型、区域、功耗策略、矿池策略、钱包归属、风险等级。配置推送时，不是凭感觉选机器，而是按标签和分组匹配。
回滚要按配置回滚，不要只会重启和重装
事故当天，真正节省时间的是我们保留了上一版生产配置。发现问题后，没有逐台改回，也没有重装挖矿软件，而是把生产组直接退回到上一条稳定配置。十分钟内，拒绝率开始回落。
很多矿场的回滚能力其实很弱。大家以为回滚就是降级软件版本，或者把机器重启一遍。可在挖矿现场，更多事故并不是软件包坏了，而是参数错了、分组错了、策略错了。只会重启，最多让错误配置重新加载一次；只会重装，可能还会把现场证据抹掉。
配置回滚至少要做到三件事。
第一，每次发布配置前自动保存上一版，并能清楚看到差异。差异不要只显示一大段文本，最好能把矿池、钱包、端口、强度、重试策略、备用顺序这些关键字段单独列出来，便于值班人员快速判断。
第二，回滚范围要可控。出了问题，不一定全场回退。有时只需要退回某一排、某一机型、某个钱包归属的机器。如果回滚工具只能“一键全场”，它在大事故里有用，在小事故里反而危险。
第三，回滚后要有验证动作。不能点完回滚就结束，至少要看连接矿池是否恢复、拒绝率是否下降、机器是否重新应用参数、收益曲线是否回到正常区间。最好给回滚设置一个观察期，比如十分钟、三十分钟，期间禁止同一批机器再被其他脚本覆盖。
权限边界要收细，不能让脚本拥有最大权力
这次事故最该警惕的，不是某个同事粗心，而是个人脚本权限太大。
脚本本身没有错。矿场运维离不开脚本，尤其是机器数量上来之后，靠手点面板根本扛不住。问题在于，脚本能不能绕开审批、能不能跨分组推配置、能不能直接改生产机器、有没有执行前预览、有没有执行后记录。
工具管理员要做的，不是把所有自动化都关掉，而是给自动化划边界。
比如查询类脚本和变更类脚本要分开。查状态、拉日志、统计拒绝率，可以给更宽权限；改矿池、改钱包、改功耗、改启动参数，必须收紧。测试环境可以允许快速试错，生产环境则必须要求二次确认，最好还要有人审批。
再比如，个人账号不能长期持有全场写权限。很多事故不是黑客攻进来，而是内部账号权限过大。一个账号既能看全场，又能改全场，还能执行脚本，这在小矿场里方便，在大一点的场景里就是风险。
权限还要和班次绑定。夜间值班人员需要处理紧急故障，但不一定需要发布新策略。可以给他回滚到上一版的权限、隔离异常机器的权限、暂停某个任务的权限，但不一定给他创建全新生产配置的权限。这样出事时能救火，又不至于在疲劳状态下做大范围变更。
版本管理要管住三类东西：软件包、配置、脚本
从工具管理员角度看，挖矿软件的版本管理不能只盯安装包。
第一类是软件包版本。不同 miner、不同管理端、不同驱动依赖，都要记录清楚。升级前要知道哪些机型适配，哪些机器曾经在某个版本上出过问题。不要因为一个新版本在测试机上多跑了 1% 算力，就直接推全场。
第二类是配置版本。矿池、钱包、强度、备用策略、超频参数，都应该有版本号。配置版本最好能和收益观察绑定起来：某一版从什么时候启用，覆盖多少机器，平均拒绝率多少，出现过哪些异常。这样以后做调整，不是凭印象说“上次好像还行”，而是有记录可查。
第三类是脚本版本。很多矿场会忽略这一块，脚本散落在个人电脑、聊天记录、临时目录里。今天这个人改一行，明天那个人复制一份，最后没人知道现场执行的是哪版脚本。脚本只要能改配置，就应该纳入版本管理。执行前显示版本，执行后写入记录，改脚本也要说明原因。
更重要的是，软件包、配置、脚本三者要能对应起来。某次异常发生时，要能还原当时的组合：哪个软件包，哪版配置，哪个脚本触发，谁执行，覆盖了哪批机器。只有这样，排查才不会在群里反复问“你刚才是不是改过什么”。
下一步怎么做：把今天能落地的四件事先补上
如果矿场现在还没有完整的配置治理，不建议一上来做很复杂的系统。先把几个最容易减少事故的动作落地。
第一，给所有生产配置编号。不要再用“新版配置”“临时配置”“测试配置 2”这类名字。编号里至少包含用途、适用分组、创建日期。旧配置不要随手删除，保留可回滚版本。
第二，批量推送前必须预览影响范围。面板或脚本都要显示将影响多少台机器、属于哪些分组、是否包含生产机器。超过预设数量，就要求二次确认。这个动作看起来麻烦，但能挡住很多低级错误。
第三，把回滚按钮做成值班人员会用的动作。不要让回滚只掌握在一个管理员手里。值班手册里写清楚：什么情况下可以回滚，回滚到哪一版，回滚后看哪些指标，什么时候升级给负责人。
第四，收回个人脚本的生产写权限。脚本可以保留，但要通过统一执行入口跑，执行记录要进账本。查询脚本和变更脚本分权，测试组和生产组分权，白天发布和夜间应急分权。
挖矿软件以后会越来越自动化，这个方向不会变。但对矿场来说，自动化真正可靠的前提，是每一次变更都能被看见、被限制、被撤回。今天就可以先从一件小事开始：打开你的挖矿管理工具，找出最近七天所有配置变更，逐条补上发起人、影响机器、旧版本和回滚版本。补完这本账，再谈更快的批量操作，心里才有底。
