文章目录
挖矿软件会越做越自动，但矿场更需要一本文字清楚的配置账
凌晨两点十七分，我被值班群里一条截图叫醒：同一机架的 24 台机器算力还在跳，但矿池侧显示有效份额突然少了一截。现场同事第一反应是网络抖动，准备重启交换机。我让他先别动，打开运维工具的操作记录，才发现十分钟前有人把一组挖矿软件参数批量同步到了“测试组”，但测试组标签早在上周临时扩大过，里面混进了半排正式机器。
这不是很大的事故。没有钱包被改，没有大面积掉线，半小时后也恢复了。但它很典型：挖矿软件越来越会自动切换、自动拉起、自动更新，真正把人绊倒的，反而是“这条配置到底从哪来、给了谁、现在能不能退回去”。
站在运维工具管理员的角度看，今天矿场用挖矿软件，已经不能只问好不好用、跑得快不快。更现实的问题是：每一条配置有没有账，每一次版本变更有没有退路，每一个账号有没有边界。
发生了什么：一条参数被同步到了不该去的机器
那天的问题并不复杂。
我们原本要在 6 台机器上测试新版挖矿软件，主要看三个变量：矿池连接稳定性、开发费逻辑是否变化、GPU 温度曲线有没有异常。为了方便，管理员在工具里建了一个“测试组”，把配置文件、启动参数和矿池地址一起打包成模板。
问题出在标签。
前一周夜班为了排查另一个币种的收益波动，临时把部分正式机器也放进了“测试组”，当时只是为了统一看监控，没有真正改配置。排查结束后，标签没有清掉。到了这次批量同步，系统按组执行，操作人看到的是“测试组”，实际命中的却不只是测试机。
更麻烦的是，挖矿软件本身没有立刻报错。机器还能跑，面板也有算力，只有矿池侧有效份额变低。现场看到“机器在线、算力不为零”，就容易往网络、矿池、显卡状态上猜。等我们对比配置摘要时，才发现部分机器的难度参数、备用矿池顺序和重连间隔被换掉了。
这类事故不吓人，但最耗时间。因为它不是硬故障，而是配置漂移：机器还活着，但跑的已经不是你以为的那套规则。
第一个误判：把自动化当成“少管一点”
很多矿场上自动化工具时，心里想的是省人。批量下发、自动切池、异常重启、脚本修复，这些功能当然有价值。问题是，自动化并不会自动变安全。它只是把人的一次点击放大到了几十台、几百台机器上。
手动改一台机器，错了也就错一台。自动化改一组机器，错的范围取决于分组、权限和审批。工具越顺手，越容易让人忽略执行前的核对。
运维工具管理员最怕的不是有人不会用，而是大家都觉得自己会用。比如：
测试组和生产组长期混用；
临时标签没有过期时间；
配置模板名字相似，只差一个后缀；
脚本里写了默认矿池，却没人记得；
新版本上线后，旧版本安装包被随手删掉；
普通值班账号也能改全场参数。
这些问题平时看不出风险，直到某一次批量操作打到错误对象上，才会暴露出来。
所以，挖矿软件自动化要先回答一个问题：如果这次自动执行错了，我们能不能在五分钟内说清楚它改了什么、改了多少台、由谁批准、怎么退回去？
说不清楚，就不能算成熟。
第二个误判：只备份文件，不记录配置账本
很多人会说，我们有备份。可运维里常见的备份，只是把配置文件放在某个目录，或者在云盘里存一份压缩包。真到复盘时，备份文件往往回答不了关键问题。
同一个文件，什么时候生成的？
对应哪一批矿机？
当时跑的是哪个挖矿软件版本？
参数是为了修复什么问题改的？
有没有同步修改启动脚本？
谁验证过收益和拒绝率？
这份配置现在还能不能直接用？
如果这些问题靠聊天记录、个人记忆和群里截图拼起来，那就不是配置管理，而是考古。
配置账本不是为了写得好看，而是为了让每一次变更可查。对挖矿软件来说，至少要把几类信息固定下来：
第一，软件版本。包括主程序版本、下载来源、校验值、发布时间，以及是否为矿场内部验证过的版本。
第二，运行参数。包括币种、算法、矿池地址、钱包地址、工人名规则、重连时间、强度参数、温控相关参数。
第三，适用范围。写清楚是测试机、某个机架、某个区域，还是全场。不要只写“部分机器”，要能对应到机器编号或资产标签。
第四，变更原因。是矿池维护、收益切换、旧版本崩溃、驱动兼容，还是临时压低功耗。
第五，验证结果。至少记录上线后 10 分钟、30 分钟、2 小时的有效份额、拒绝率、温度和掉线情况。
这本账不一定非要复杂系统，刚开始用文档也行。关键是每次改动都有编号、有时间、有责任人，配置文件和操作记录能对得上。
第三个误判：版本回滚等出事时再想
挖矿软件升级最容易被低估的，是回滚。
很多团队上线新版本时，会做下载、安装、启动，却没有认真做“退回旧版本”的演练。等问题发生后才发现：旧安装包找不到了，旧参数不兼容，新版本改过目录结构，守护脚本还在自动拉起新版，甚至有的机器回退后权限不对，程序启动不起来。
版本回滚不是一句“换回去”这么简单。它应该是一套事先验证过的动作。
比如，新版本上线前，先把旧版本完整归档，包含程序文件、配置、启动脚本、依赖库和校验信息。不要只留一个可执行文件，因为真实环境里出问题的常常不是主程序，而是它旁边的文件。
再比如，测试回滚时不能只在一台空闲机器上试。最好选一台和生产环境一致的机器，先升级，再回滚，看它能不能恢复到原来的矿池、原来的参数、原来的监控状态。回滚成功的标准也要写清楚：不是程序能启动就算成功，而是矿池侧有效份额恢复、拒绝率正常、温度曲线回到预期。
还有一点很容易被忘记：回滚权限必须提前安排。夜里出事故时，如果只有白天主管账号能执行回滚，值班人员只能在群里等授权，那自动化工具再强也没意义。正确做法是给值班角色保留有限回滚权限，只能退回已批准版本，不能上传新程序，不能改钱包地址，不能改全场配置。
这样既能救急，也不会把风险放大。
权限边界要按动作拆，不要按人情给
矿场里最常见的权限问题，是“这个人懂技术，给他全权限吧”。短期看省事，长期看一定会出事。
挖矿软件相关权限，最好按动作拆开，而不是按职位粗分。能看监控，不等于能改配置；能重启程序，不等于能换版本；能调整矿池，不等于能改钱包；能对测试组操作，不等于能碰生产机器。
作为运维工具管理员，我更倾向于把权限拆成几层。
值班人员可以查看状态、重启单机、执行已批准的回滚方案，但不能新建全场任务。
班组负责人可以对自己负责的区域做批量操作，但必须选择已有模板，不能临时粘贴未经审核的脚本。
软件管理员可以维护版本库和配置模板，但不能单独把新模板推到生产组。
资产或财务相关人员只需要核对钱包、收益路径和矿池账号，不应该拥有程序下发权限。
最高权限账号不参与日常操作，只在建规则、授权和紧急接管时使用，并且所有登录都要留下记录。
这听起来麻烦，但它解决的是另一个更大的问题：出了事以后，不会所有人都说“我只是点了一下”。权限边界清楚，责任链才清楚。
下一步怎么做：先把三件小事固定下来
如果今天要给矿场的挖矿软件运维补课，我不建议一上来就换一整套系统。最先该做的，是把三件小事固定下来。
第一，建立配置账本，并且从今天的现有配置开始补。不要等下一次升级。把当前正在跑的版本、矿池、参数、适用机器、负责人先记录下来。哪怕内容不完美，也比只有群聊截图强。
第二，给每一个配置模板设有效范围。测试模板只能命中测试机器，临时标签必须有到期时间。任何批量任务执行前，工具里要显示实际命中的机器数量和清单，而不是只显示一个组名。
第三，做一次真实回滚演练。选一小组机器，从当前版本升级到待测版本，再退回旧版本。把每一步耗时、失败点、需要的权限都记下来。演练结束后，把回滚包和操作说明放到值班人员能找到的位置。
此外，挖矿软件版本库也要收紧。下载来源、文件校验、发布时间、测试结果，都要跟版本号绑定。不要让“最新版”三个字直接进入生产环境。矿场需要的不是最新，而是可解释、可恢复、可追踪。
今天的挖矿软件确实会越来越自动。自动切换、自动修复、自动部署都会继续加强。但在真实矿场里，最有价值的运维能力不是让工具替人点按钮，而是让每一次点击都有账可查、有路可退、有权限边界。
今天发布前，可以先做一个很具体的动作：打开现有挖矿软件管理后台，导出当前所有机器的版本和配置，给它生成一条日期明确的基准记录。然后再检查测试组、生产组和临时标签有没有混在一起。这个动作不花哨，却能在下一次半夜异常时，帮你少猜很多路。
