文章目录
挖矿软件的自动化越跑越快，矿场配置必须像账本一样管起来
凌晨两点半，值班群里先是跳出一条“算力波动 18%”的截图，紧接着是矿池侧拒绝率飙高。现场同事以为是某一排机器网络抖动，先重启了交换机，又重启了几台矿机。十几分钟后才发现，问题不在网，也不在矿池，而是一条自动化脚本把一组矿机的挖矿软件参数覆盖了。
更麻烦的是，没人能立刻说清楚这条配置从哪里来。面板里看到的是最新状态，脚本目录里有三个版本，群里还有一份临时改过的参数截图。最后靠翻聊天记录、查服务器操作日志、对比矿机本地文件，才把错误范围缩到 64 台机器。损失不算大，但这件事给运维工具管理员提了个醒：挖矿软件一旦接上自动化，配置就不能再靠“谁记得、谁改过、谁截图了”来管理。
今天很多矿场已经不缺自动化工具。批量下发、自动切池、异常重启、定时更新、收益策略切换，这些功能越来越成熟。真正容易出事故的地方，反而是配置治理、版本管理和操作边界没跟上。软件跑得越快，账越要记清楚。
事故发生时，问题并没有出现在“软件不能用”
这次小事故的起点，是前一天晚班做过一次收益策略调整。某个币种短时收益变高，运维同事准备把部分显卡矿机切到新的挖矿软件版本，同时修改矿池地址、钱包备注和部分内核参数。为了省时间，他没有在生产面板里逐项改，而是调用已有脚本批量覆盖。
脚本本身不是新东西，过去用过很多次。但这次有两个变量被忽略了。
第一，脚本引用的配置模板不是最新确认版，而是上周测试时留下的版本。模板里的强度参数偏激进，在测试机上能跑，但不适合大批量机器。第二，自动化任务的目标分组用的是旧标签。原本只想覆盖测试组，结果把一部分稳定生产组也带上了。
从表面看，这是一次“误操作”。但从工具管理员视角看，它暴露的不是某个人手滑，而是配置没有账本、版本没有边界、自动化缺少确认关口。
如果每一份配置都有编号、来源、适用机器、修改人、审批人、发布时间和撤销方式，排查会很快。如果每次脚本运行前能明确显示差异：哪些机器会被改、哪些字段会变化、是否触碰钱包和矿池地址，错误也很难扩散到几十台机器。
问题不在自动化本身，而在自动化拿到的配置不够可信。
最容易误判的是：面板显示正常，就以为配置可控
很多矿场管理挖矿软件，习惯看三个结果：算力、温度、拒绝率。只要这三个数没有明显异常，就认为配置没问题。这个习惯在单机或小规模阶段还凑合，一旦机器数量上来，风险会被隐藏。
配置可控和机器正在跑，是两回事。
一台机器当前有算力，不代表它跑的是预期版本；矿池能收到份额，不代表钱包地址没有被临时替换；软件没有报错，不代表启动参数没有被旧模板覆盖。尤其是挖矿软件现在常常混着多种组件：主程序、驱动依赖、调参文件、矿池配置、监控插件、重启脚本、收益切换规则。只看最终算力，很容易忽略中间哪一层已经偏了。
运维工具管理员要关心的，不只是“现在能不能跑”，还要能回答四个问题：
这台机器当前配置来自哪一份模板？
这份模板上一次是谁改的，改了哪几个字段？
当前版本如果出问题，能不能在十分钟内退回上一版？
谁有权限修改矿池地址、钱包地址和自动切换规则？
如果这些问题回答不上来，矿场其实是在用感觉管理配置。平时没事，是因为变量少；行情波动、软件升级、矿池切换、驱动调整同时出现时，感觉就不够用了。
配置账本要记录“差异”，不能只保存一堆文件
不少团队也会说，我们有备份，配置文件都在服务器里。但真正出事时，经常发现备份只是一堆文件夹，文件名叫 final、new、test、old2，谁也说不清哪个能用。
配置账本不是简单备份。它要记录的是配置从哪里来、为什么改、改了什么、用到哪里、出了事怎么撤。
以挖矿软件为例，一份合格的配置账本至少要把这些内容写清楚：软件名称和版本号、适用机型、显卡或 ASIC 型号、驱动版本、矿池地址、钱包地址、启动参数、调参项、自动重启规则、收益切换条件、发布时间、发布范围、操作人、复核人、上一版编号。
更重要的是，账本要能看差异。比如这次更新只改矿池地址，没有改钱包；只升级主程序，没有动强度参数；只对 20 台测试机生效，没有覆盖生产组。差异清楚，审批才有意义。否则审批人面对一整份配置，只能点头，根本看不出风险在哪。
对于中小矿场，不一定一上来就买复杂系统。哪怕先用一个固定格式的配置登记文档，再配合文件版本管理，也比群里发截图强得多。关键是形成规矩：生产配置不得无编号下发，临时配置不得直接覆盖正式配置，测试配置必须标明失效时间。
配置账本的价值，在平时不明显；一旦半夜掉算力，它就是缩短排查时间的工具。
版本回退不能靠“把旧文件复制回去”
挖矿软件升级频繁，有的是修复内核，有的是优化某类显卡，有的是适配新矿池协议。升级本身没有错，但很多矿场的版本管理还停留在“下载新包、覆盖旧包、跑起来看看”的阶段。
这种做法最大的问题是，回退并不可靠。
挖矿软件的版本不只是一个可执行文件。它可能对应特定驱动、特定参数格式、特定监控输出、特定脚本调用方式。新版本改了字段名，旧脚本还按原格式读取，就会出错；新版本支持某个参数，退回旧版本后参数失效，机器可能不断重启；有些软件还会生成本地缓存或状态文件，简单复制旧文件并不能恢复到升级前状态。
所以版本回退要提前设计，而不是事故发生后临时拼。
比较稳妥的做法是，每次升级前冻结一个完整快照，包括软件包、配置文件、启动脚本、依赖说明、目标机器列表和验证结果。升级后观察周期也要写清楚，比如测试组跑满 6 小时，拒绝率、功耗、温度、重启次数达到要求后，再扩大范围。
回退动作也要可演练。不是写一句“必要时回退”，而是明确谁触发、退到哪个版本、影响哪些机器、是否同时恢复矿池配置、是否暂停自动切换规则。最好每个月挑一小组机器做一次回退演练，确认旧版本确实能拉起来，而不是躺在硬盘里当心理安慰。
真正成熟的版本管理，不是永远不出错，而是出错后知道退到哪里。
自动化任务要加护栏，尤其是会改收益路径的动作
挖矿软件的自动化很诱人。收益高了自动切，掉线了自动拉，版本旧了自动更，参数异常了自动修。问题是，自动化一旦写错，执行速度也比人工快得多。
从工具管理员角度看，自动化任务至少要分层。
第一类是低风险动作，比如重启监控进程、采集日志、查询软件版本、读取算力状态。这类可以放宽一些，但也要留下记录。
第二类是中风险动作，比如重启挖矿软件、调整运行参数、切换到备用矿池。这类动作要限制执行范围，最好默认只对小组机器生效，扩大范围前必须二次确认。
第三类是高风险动作，包括修改钱包地址、修改收益账户、批量升级软件、覆盖生产配置、改变自动切换策略。这类动作不能只靠一个管理员账号直接执行，至少要有复核、白名单和时间限制。
很多事故不是因为没有权限系统，而是所有人共用一个高权限账号。现场为了方便，把账号密码放在群公告、浏览器自动保存、远程桌面里。短期省事，长期就是隐患。尤其是挖矿软件涉及收益路径，钱包和矿池账号的修改权限必须单独拆出来，不能和普通重启、查看日志混在一起。
权限边界越清楚，自动化越敢用。否则所有脚本最后都会变成一把万能钥匙，谁拿到都能开全场的门。
复盘之后，下一步要把三件事落地
这次事故复盘后，我们没有先讨论换哪个挖矿软件，也没有急着禁用自动化。工具本身不是敌人，松散流程才是。接下来最该做的，是把配置、版本和权限收成日常动作。
第一，建立生产配置清单。把当前正在运行的挖矿软件版本、矿池、钱包、启动参数和自动化规则逐台或逐组登记出来。不要等升级前才整理，先把现状摸清。清单里发现来源不明的配置，要标出来，不能继续当默认配置使用。
第二，给配置变更加编号。每次修改都生成一个变更号，写明原因、范围、差异、验证办法和回退版本。哪怕只是改一个矿池地址，也要留下记录。以后排查时，不再问“昨晚谁动过”，而是查“昨晚哪个变更发布了”。
第三，拆分自动化权限。查看、重启、调参、升级、改钱包、改矿池，不能都放在一个账号里。值班人员可以有处理故障的权限，但不一定要有改收益地址的权限；脚本可以自动重启软件，但不应该自动覆盖钱包配置；测试组可以快速试新版本，生产组必须经过复核。
第四，准备一份可执行的回退包。不要只保存旧软件安装包，还要保存对应配置、依赖说明和执行步骤。回退包最好放在固定位置，命名清楚，值班同事不用翻群聊也能找到。
第五，每周抽查一次配置漂移。选几组机器，把实际运行配置和账本记录对一遍。发现不一致，不要先责怪谁，先查是手工改动、脚本覆盖，还是软件自动更新造成的。配置漂移越早发现，事故越小。
挖矿软件以后只会更自动，矿场也不可能退回全靠人工的老办法。对运维工具管理员来说，今天该补的不是再多一个按钮，而是让每一次配置变化都有记录、每一次升级都有退路、每一个账号都有边界。今晚就可以先做一件小事：把当前生产环境的挖矿软件版本和配置导出来，给它们编上第一批编号。下一次半夜出问题时，这本账会比任何口头经验都管用。
