文章目录
挖矿软件的自动化正在收紧：每一次配置改动都要留下账本
凌晨 2 点 17 分，值班手机连续响了三次。不是全场掉线，也不是矿池大面积异常，而是 3 号货架里有 26 台机器突然从主矿池切到了备用矿池，算力没有归零，温度也正常，面板上看起来只是“策略生效”。问题在于，备用矿池的钱包地址还是上周测试用的临时地址。
这类事故最麻烦的地方，不是机器停了，而是机器还在跑。它不会像断网那样把问题明晃晃摆出来，收益还在产生，算力曲线也不难看，只有等到对账时才发现收益流向不对。对运维工具管理员来说，这比一排红色告警更让人头疼。
复盘之后，我们发现根因并不复杂：一个自动切换脚本调用了旧配置，一个临时账号有过高权限，一次版本更新没有和配置快照绑定。单看每一步都像小问题，连起来就变成了真实损失。
这也是现在挖矿软件正在发生的变化：自动化越多，配置治理就越重要。以前大家关心软件能不能批量下发、能不能自动重启、能不能按收益切币；现在更该问的是，谁改了配置、改了哪一项、对应哪个版本、出错后能不能退回去。
发生了什么：一次“正常自动切换”暴露三处漏洞
那天的触发条件很普通。主矿池延迟在短时间内抬高，挖矿软件按设定规则判断连接质量下降，于是自动切到备用矿池。这个逻辑本身没有问题，甚至是很多矿场都会启用的保底策略。
真正的问题藏在配置层。
备用矿池地址来自一份旧配置。上周做测试时，工程师为了验证连接，把部分机器临时指向测试钱包。测试完成后，主配置已经改回来了，但备用配置没有同步清理。更糟的是，自动切换脚本读取的不是最新配置，而是脚本目录里一份本地缓存文件。
如果只是这样，损失还可控。偏偏这次软件版本前一天刚升级，升级包里调整了配置读取优先级：当远程配置获取失败时，优先读取本地缓存。这个改动没有被单独标注，也没有进入当天运维交接记录。于是凌晨主矿池一波延迟，就把旧配置重新拉了出来。
从面板上看，事情像是“矿池异常导致自动切换”。但从管理员视角看，这其实是配置账本缺失、版本说明不清、权限边界过宽叠在一起。
容易误判的地方：把自动化当成保险
很多矿场上自动化工具后，会有一种错觉：既然软件能自动判断、自动切换、自动重启，就可以少盯一点。现实正好相反，自动化不是保险，它只是把人的动作变快了。如果动作本身没被约束，错误也会被放大。
挖矿软件里的自动化大致分三类。
第一类是状态修复，比如掉线后重连、进程崩溃后拉起、温度异常后降频。这类动作风险相对低，因为目标是把机器拉回可运行状态。
第二类是策略调整，比如根据收益切换币种、根据矿池延迟切换地址、根据电价时段调整功耗。这类动作已经开始影响收益路径。
第三类是配置下发，比如批量修改钱包、矿池、超频参数、脚本任务、代理节点。这类动作一旦出错，影响往往不是一台机器，而是一组机器，甚至一个场区。
问题在于，很多团队把三类动作放在同一个权限里，只要是运维账号，就能改；只要脚本能跑，就能下发；只要面板显示成功，就默认没问题。这样做在机器少的时候省事，机器一多就会出事。
自动化真正该解决的是重复劳动，不该替代配置审核。矿场越依赖挖矿软件，就越要把自动化关进笼子里：它可以执行，但不能随便决定；它可以切换，但必须知道从哪里切到哪里；它可以回滚，但要有明确版本可退。
配置账本不是文档，是每天都要用的操作记录
很多人听到“配置账本”，第一反应是再建一个文档，把矿池地址、钱包地址、机器分组写进去。这样当然比没有强，但还不够。
配置账本应该回答四个问题。
第一，这次配置是谁改的。不能只显示“管理员”，而要能区分具体账号、登录来源、操作时间。如果所有人共用一个账号，出了问题只能靠聊天记录猜，这就不是运维，是碰运气。
第二，改了哪些字段。矿池地址、钱包地址、币种策略、功耗曲线、风扇策略、代理地址，都要能看到改动前后。只知道“配置已更新”没有意义，必须知道更新在哪里。
第三，影响了哪些机器。配置改动不能只按“全部矿机”来理解，要具体到机架、分组、批次、型号。尤其是混合机型场景，同一套参数可能对 A 型号合适，对 B 型号就是隐患。
第四，对应哪个软件版本。配置和版本必须绑在一起看。因为同一个配置文件，在不同版本挖矿软件里可能有不同解释。今天能跑，不代表升级后还按同样逻辑跑。
账本的价值不是事后甩锅，而是让运维动作可还原。凌晨出问题时，管理员不用在群里问“刚才谁动了配置”，而是直接查到最近一次变更、涉及范围、对应版本，然后决定是局部回退还是停用自动策略。
版本管理的重点不是追新，而是留一条能回去的路
挖矿软件更新频繁并不奇怪。新显卡支持、新算法优化、矿池协议调整、驱动兼容修复，都会推动版本迭代。问题是，很多矿场升级时只看两个结果：算力有没有涨，拒绝率有没有降。
从运维工具管理员角度，版本管理至少要多看三件事。
第一，配置格式有没有变化。有些版本会增加字段，有些会改变默认值，还有些会调整读取顺序。最怕的是更新说明里只写“优化配置加载”，实际却改变了备用配置优先级。
第二，脚本接口有没有变化。很多矿场会用自写脚本联动挖矿软件，比如定时切换矿池、按温度降频、按收益切换任务。如果接口参数变了，脚本未必立刻报错，可能只是执行了错误动作。
第三，回滚后配置能不能兼容。升级失败可以退版本，但如果升级过程中配置被新版本改写，旧版本未必能正常读取。到这一步，回滚就不再是点一下按钮，而是要同时恢复软件包、配置文件和任务状态。
因此，版本管理不能只保留安装包。更稳妥的做法是每次升级前做三份记录：当前软件版本、当前配置快照、当前自动化任务清单。升级后先选一小组机器跑至少一个完整结算周期，再扩大范围。不要在行情波动、矿池不稳、电价切换当天做大规模升级，这些时段本来变量就多，出了问题很难判断根因。
权限边界要拆细：能看、能改、能批量执行不能混在一起
这次事故里，临时测试账号能改备用矿池，是最不该出现的漏洞。
挖矿软件权限经常被低估。很多团队觉得矿机不涉及交易账户，权限松一点问题不大。但矿池地址和钱包地址本身就关系收益流向，自动化脚本关系机器状态，批量任务关系整个场区稳定性。权限一松，损失未必来自黑客，更多来自误操作。
权限至少应该拆成几层。
查看权限，只能看算力、温度、在线状态、当前配置，不能改任何参数。适合值班、财务对账、外部维护人员临时查看。
单机操作权限，只能对指定机器重启进程、查看日志、临时暂停任务，不能批量改矿池和钱包。
分组配置权限，只能改自己负责分组，而且修改后要进入待审核状态，不能直接覆盖生产配置。
批量执行权限，应该收得最紧。能批量下发矿池、钱包、脚本、版本更新的人，必须使用独立账号，并开启二次确认和操作留痕。
紧急权限也要有，但不能长期挂着。比如夜间值班可以申请临时提升权限，限定 30 分钟或 1 小时，到点自动收回。否则“为了方便”留下的高权限账号，迟早会变成事故源头。
下一步怎么做：先把三件小事落地
如果今天要调整挖矿软件管理方式，不建议一上来就做大改造。矿场运维最怕把简单问题改复杂，最后大家绕过流程继续靠私聊下指令。更现实的做法，是先把三件小事落地。
第一，建立配置变更编号。每一次矿池、钱包、功耗、脚本、版本相关改动，都给一个编号。编号下记录操作人、时间、机器范围、改动内容、回退方式。哪怕先用最简单的共享记录，也比只靠群消息强。
第二，把自动化任务和配置快照绑定。脚本执行前，明确读取哪一份配置；配置更新后，自动化任务必须重新确认。不要让脚本自己去目录里找“看起来最新”的文件，更不要让本地缓存长期无人清理。
第三，做一次真实回滚演练。不要只在测试机上点回滚，而是选一个小分组，模拟矿池地址错误、版本升级失败、脚本误触发三种情况，计时看多久能恢复，恢复后收益地址是否正确，日志是否能查清楚。
这三件事做完，挖矿软件的管理会立刻变得不一样。管理员不再只盯面板颜色，而是能知道每一次变化从哪里来、影响谁、怎么退。自动化也不再是一个黑箱，而是被配置账本、版本快照和权限边界框住。
今天发布这篇文章，给矿场运维管理员一个很具体的建议：下班前先查一遍备用矿池配置和自动切换脚本，确认钱包地址、读取路径、账号权限是否一致；然后把最近一次软件升级对应的配置快照补上。别等下一次凌晨告警响起，才发现机器一直在替错误配置认真工作。
