挖矿软件越自动化，配置账本越该放在按钮前面

昨晚 23:40，我收到值班群里一条截图：一排矿机算力曲线突然齐刷刷往下掉，掉得不狠，但很整齐。第一反应不是断网，也不像矿池挂了，因为同一机房里另一批机器还在正常提交份额。再看操作记录，问题出在一个“自动切换配置”的任务上：夜班同事想把 96 台机器从 A 矿池临时切到 B 矿池，顺手勾了一个“同步最新模板”，结果模板里带着上周测试用的强度参数，矿机没死机，却开始大量低效运行。

这类事故在今天的矿场里越来越常见。过去挖矿软件出问题，多半是程序崩了、驱动不认、矿池连不上；现在更麻烦的是，软件本身能跑，自动化也在执行，但执行的是一份没人确认过的配置。机器没有红灯，面板也不一定报警，等到收益报表对不上，几个小时已经过去了。

从运维工具管理员的角度看，挖矿软件的变化很清楚：按钮越来越多，策略越来越细，批量动作越来越快。真正需要补上的，不是再加一个自动脚本，而是把每一次配置变动、版本切换、权限调用都记清楚，出错时能倒回去，追查时能说得明白。

发生了什么：一次“同步模板”把测试参数带进生产

这次事故的表面原因很简单：夜班账号有批量配置权限，执行了一个矿池切换任务；任务同时调用了最新配置模板；模板里包含测试机组上周留下的核心频率、风扇策略和重连间隔；这些参数被下发到生产机组后，矿机没有掉线，但有效算力下降，拒绝率上升。

如果只看面板，很容易把它误判成矿池波动。因为矿池地址确实换了，连接也成功，软件进程没有异常退出，矿机温度没有明显失控。最容易被忽略的是“配置来源”：到底是切矿池时只改了矿池地址，还是顺手把整份模板都覆盖了？

后面翻日志才发现，挖矿软件的操作记录只写了“执行批量切换成功”，没有把变动字段展开。也就是说，系统知道有人按了按钮，却没有清楚记录这个按钮改了哪些参数。对于小矿工来说，这可能只是几台机器多跑一会儿低效参数；对于几百台、上千台机器的场景，就是一笔很现实的损耗。

更麻烦的是，当时值班同事尝试手动改回矿池地址，但低效问题没消失。因为真正的问题不在矿池地址，而在模板里附带的算力参数。没有配置账本，就只能靠人回忆：“之前是不是这样设的？”这句话在夜班里基本等于继续试错。

容易误判的地方：自动化成功不等于配置正确

很多矿场上自动化之后，会有一个错觉：只要任务显示成功，事情就完成了。可挖矿软件的自动化分两层，一层是任务有没有执行，另一层是执行后的状态是不是符合预期。前者是流程问题，后者才关系到收益。

这次事故里，任务队列没有失败，矿机在线率也没明显下降，所以常规告警没响。但实际配置已经偏离了生产标准。这里有三个容易误判的点。

第一，把“版本最新”当成“版本安全”。挖矿软件、驱动组件、插件脚本经常更新，最新版本可能修了问题，也可能改了默认参数。尤其是一些第三方优化脚本，更新说明写得很短，实际却调整了重试间隔、日志级别、矿池优先级。没有版本标记和灰度范围，直接全量推送，就等于拿生产机组做现场测试。

第二，把“模板复用”当成“模板可信”。模板确实能省时间，但模板也会带脏东西。测试参数、临时钱包、备用矿池、某个矿工单独调过的风扇策略，都可能藏在里面。只要模板没有字段级审查，批量下发时就可能把旧问题复制一遍。

第三，把“管理员账号”当成“万能账号”。很多矿场为了方便，夜班、维修、财务查看、远程协助都共用几个高权限账号。短期看省事，长期看就是查不清。出了问题之后，只知道某个账号执行了任务，却不知道是谁、因为什么工单、经过谁确认。运维工具越自动，越不能把权限边界糊成一团。

配置账本要记什么：别只留一行操作成功

我更愿意把配置账本理解成矿场的软件出入库记录。硬件换风扇、换电源、换板子会登记，软件配置也应该登记。尤其是今天的挖矿软件已经不只是启动程序，它还管矿池、钱包、超频、功耗策略、重连逻辑、告警阈值、脚本调用，任何一项改错都会影响收益。

一份能用的配置账本，至少要记清五类信息。

第一，改了什么字段。不能只写“更新配置”，要能看到矿池地址、钱包地址、工作名、频率参数、功耗上限、重启策略、备用池顺序分别有没有变化。字段越清楚，回滚时越少猜。

第二，配置从哪里来。是生产模板、测试模板、某台机器导出的配置，还是人工临时编辑？来源不清，后面就无法判断这份配置该不该被信任。

第三，影响哪些机器。不要只写“批量下发”，要能定位到机房、货架、矿机分组，最好能看到机器清单和数量。很多事故不是全场事故，而是某一批机器用了错误参数，范围越快圈定，损失越容易压住。

第四，谁发起、谁批准。不是每次改动都要走复杂流程，但涉及钱包地址、矿池地址、算力参数、版本升级的动作，至少要有发起人和确认人。夜班可以执行预案，但不应该随便创造预案。

第五，改动前后的快照。账本最重要的价值不是事后追责，而是能回到上一份能赚钱的配置。没有快照，回滚就只是重新配置；有快照，回滚才是恢复现场。

版本管理别只盯软件包：脚本、模板和依赖也要编号

很多人说版本管理，第一反应是挖矿软件版本号，比如从某个版本升到另一个版本。实际上，矿场里真正容易混乱的，往往是软件包之外的东西。

比如启动脚本改了一行参数，模板改了备用矿池顺序，监控插件改了告警阈值，远程管理工具改了 API 调用方式。这些变化单看都很小，但组合在一起，就可能让矿机表现完全不同。若只记录挖矿软件版本号，却不记录脚本和模板版本，排障时会出现一种很尴尬的情况：大家都说“软件没变”，但现场就是变了。

比较稳妥的做法，是把生产环境里的配置分成几组编号：

挖矿软件本体版本，单独编号，记录发布时间、来源、校验值和适用机型。

启动脚本版本，单独编号，记录启动参数、环境变量、重启逻辑。

配置模板版本，单独编号，记录矿池、钱包、工作名规则和性能参数。

自动化任务版本，单独编号，记录触发条件、执行范围、失败处理方式。

这样做看起来繁琐，但好处很明显。一旦某批机器异常，可以快速回答三个问题：它们用的是哪一个软件包？哪一份模板？哪一个自动任务？如果只有一个总版本号，问题会被揉成一团，最后又回到人工猜测。

版本管理还有一个原则：生产版本不要直接覆盖。新版本先放到候选区，小范围验证，确认有效算力、拒绝率、温度、功耗都正常，再扩大范围。不要因为一条更新说明写着“优化稳定性”，就把它当成全场升级理由。挖矿软件的稳定，不在更新说明里，在机器连续跑出的数据里。

回滚要提前演练：事故现场临时找旧包最耽误事

回滚不是把旧版本再装一遍这么简单。真正出事故时，时间会被几个细节吃掉：旧安装包在哪里？旧配置是哪一份？回滚后钱包地址会不会被覆盖？矿池顺序会不会恢复到上个月？哪些机器已经升级，哪些还没升级？谁有权限执行回滚？

如果这些问题平时没答好，事故现场就会变成多人同时操作。有人找包，有人改模板，有人重启机器，有人盯收益。看似热闹，实际风险更大。

我建议把回滚分成三种预案，而不是只写一句“必要时回退”。

第一种是配置回滚。适用于矿池、钱包、频率、功耗参数改错。要求能按分组恢复到上一份生产配置，并且回滚前提示会变更哪些字段。

第二种是软件版本回滚。适用于新版本崩溃、拒绝率异常、兼容性问题。要求保留旧包、校验值、安装方式和适用机型说明。

第三种是自动化任务暂停。适用于脚本触发条件错误、批量动作反复执行、监控误判导致频繁切换。要求一键停掉任务调度，但不要影响已经正常运行的挖矿进程。

这三种预案要定期演练，最好选一小组非关键机器做测试。演练时不要只看能不能回去，还要记录耗时、需要几个人、是否会清空日志、是否会影响收益统计。回滚能力不是写在文档里的，是靠平时跑过一遍才算数。

权限边界要收细：夜班能执行，不代表能改规则

自动化工具最怕两种权限：一种是所有人都不能动，出事没人处理；另一种是太多人都能动，出事没人说得清。矿场需要的是分层权限，而不是简单地给或不给。

夜班账号应该能执行已经批准的任务，比如切换到预设备用矿池、重启指定分组、暂停异常自动任务。但夜班账号不应随意修改生产模板，不应改钱包地址，不应上传新的脚本，也不应把测试版本推到生产机组。

运维管理员可以维护模板和版本库，但涉及钱包、收益路径、批量升级范围，最好需要第二个人确认。不是不信任人，而是矿场里的很多损失并非恶意造成，都是疲劳、赶时间、误点按钮带来的。

远程协助账号更要控制。厂商、外包、临时技术支持可以查看必要日志，可以在授权时间内操作指定机器，但不应该拥有全场长期管理权限。协助结束后，账号要关闭，令牌要回收，操作记录要归档。

权限边界清楚之后，自动化才真正安全。否则按钮越方便，误操作传播越快。

下一步怎么做：从一周内能落地的三件事开始

如果今天要改挖矿软件的运维方式，不必一上来做大系统。先做三件小而硬的事。

第一，把生产配置做一次盘点。选出当前真正稳定赚钱的一份配置，标成生产基准，记录软件版本、脚本版本、模板版本、适用机型和机器范围。不要让“大家都知道”停留在口头上。

第二，建立配置变动记录。哪怕先用简单文档，也要做到每次改动写清字段、原因、执行人、影响机器、回滚方式。重点盯矿池地址、钱包地址、性能参数、自动任务这几类高风险项。

第三，收紧批量权限。夜班保留执行预案的能力，但取消修改生产模板和上传脚本的权限；测试模板和生产模板分开存放；任何全量推送前，必须先在小分组跑满一段时间，看有效算力、拒绝率和温度曲线。

挖矿软件会继续变得更自动，矿场也会越来越依赖批量工具。但对运维工具管理员来说，按钮多不是安全感，账本清楚、版本可退、权限有边界，才是夜里出事时真正能救场的东西。今天下班前，至少把最近一次生产配置导出来，标好版本，放到只有管理员可改的位置；下一次有人要批量下发时，先问一句：这次改动，账本里能不能查得到、退得回去。