文章目录
挖矿软件的自动化会继续加速，但配置账本会先决定矿场能不能稳住
凌晨 1 点 42 分，我值班群里跳出一条消息：3 号机房 B 排有 27 台机器算力掉到平时的六成，风扇转速正常，温度也没冲高。第一反应很容易往矿池波动、网络抖动、显卡老化上猜，但我打开运维面板后发现，真正的问题很小：一个自动化任务把“实验矿组”的挖矿软件参数推到了“稳定矿组”。
这不是大故障，甚至没有造成长时间停机。问题是，谁也说不清这条配置是从哪里来的。脚本记录里只有执行成功，面板上只显示当前参数，群里有人说前一天改过抽水监控，有人说只是更新了矿池备用地址。等我把历史包、定时任务、账号操作记录翻了一遍，已经过去 40 分钟。
这类事故在矿场里越来越常见。挖矿软件越来越自动化，批量部署、矿池切换、温控策略、失败重启、收益对比都能交给工具跑。但只要配置没有账本，版本没有留痕，账号权限没有边界，自动化跑得越快，误操作扩散也越快。
这次事故真正发生在“配置继承”上
复盘那晚的情况，故障表面看是参数推错了，实际是配置继承关系没有写清楚。
我们当时有三类矿组：一类是长期稳定跑的生产矿组，一类是测试新版本挖矿软件的实验矿组，还有一类是低算力机器组成的淘汰观察组。为了省事，管理员把实验矿组的配置模板复制了一份，改名后作为新的“通用模板”。这个模板里保留了两个测试参数：一个是更激进的重连间隔，一个是测试矿池地址的优先级。
白天看不出问题，因为机器在线率正常，收益波动也被行情掩盖了。到了夜里，矿池连接有一次短暂抖动，自动重连机制启动，那批机器就按测试参数跑到了不该去的地址上。算力没有归零，报警阈值也没触发，只是有效份额下降，收益开始漏。
这就是挖矿软件配置治理里最麻烦的地方：错误不一定表现为宕机。更多时候，它表现为少赚一点、慢一点、偏一点。等财务或收益统计发现异常，现场已经很难还原。
最容易误判的是“软件版本没变，所以配置也安全”
很多运维人员会把风险盯在挖矿软件版本上：有没有升级内核、有没有换挖矿程序、有没有下载到被污染的包。这当然重要，但现在更常见的坑，反而出在“版本没动，配置变了”。
同一个挖矿软件版本，搭配不同启动参数，表现可能完全不一样。比如矿池地址顺序、钱包地址、工作名格式、重试次数、功耗限制、风扇策略、双挖开关、开发者抽水检测参数，只要其中一项被改动，就可能影响收益、稳定性，甚至资产归属。
更麻烦的是，配置经常分散在几个地方：面板里一份，脚本里一份，本地配置文件里一份，临时命令里还有一份。某个管理员为了应急在机器上手动改了一行，第二天批量任务又覆盖回去；或者自动化工具从旧模板里拉配置，表面上执行的是新任务，实际带着旧参数。
所以我现在管理挖矿软件，不再只问“现在跑的是什么版本”，还要问三个问题：
这台机器当前配置从哪个模板继承？
最近一次配置变更是谁发起的？
如果要退回昨晚 12 点的状态，能不能在 10 分钟内找到对应版本？
答不上来，就说明矿场其实没有掌握自己的软件状态。
配置账本要记的不是流水账，而是可还原的状态
很多团队也有记录，但记的是群消息、工单备注、截图，真出事时不够用。配置账本不是为了事后甩锅，而是为了能还原现场。
一份真正能用的配置账本，至少要包含几类信息。
第一是配置对象。到底改的是哪个矿组、哪批机器、哪种算法、哪个币种，不能只写“更新参数”。同一个参数在不同机器上含义不同，尤其是混合机型和多算法矿场，必须写清楚作用范围。
第二是配置来源。是从默认模板复制、从实验模板调整，还是临时手写。模板之间如果允许继承，就要能看到父模板是谁，继承了哪些字段，覆盖了哪些字段。不要让“通用模板”变成所有历史参数的垃圾桶。
第三是变更内容。不要只保存最终文件，最好能看到差异。比如矿池地址从 A 改到 B，重试时间从 15 秒改到 5 秒，钱包标签从 worker-01 改到 farm-b-01。差异越具体，排障越快。
第四是执行结果。配置下发成功，不等于业务正常。账本里要记录推送了多少台，成功多少台，失败多少台，失败原因是什么，推送后 5 分钟、15 分钟的算力和拒绝率有没有明显偏离。
第五是责任链。谁提交，谁审批，谁执行，谁确认。小矿场可以简单一点，但不能没有。一个共享管理员账号跑天下，最后一定查不清。
版本管理不能只管安装包，还要管模板和脚本
很多人说到版本管理，只想到挖矿软件的压缩包，比如某个 miner 从 6.2 升到 6.3。但运维工具管理员更应该把“软件包、配置模板、自动化脚本”放在一起看。
因为一次实际变更往往是三件事同时发生：换了挖矿软件版本，改了启动参数，还调整了批量任务的执行顺序。故障出现后，如果只把软件包退回旧版本，但模板还是新的，问题可能继续存在；如果模板退了，脚本仍然按新字段解析，也可能执行失败。
我的做法是给每次上线生成一个组合版本，里面包括：
挖矿软件包的文件校验值；
启动参数模板；
矿池与钱包配置；
自动化任务脚本；
适用矿组和排除矿组；
上线时间和回退版本。
这样做看起来麻烦，但好处很直接。出问题时不用猜“那天到底改了什么”，直接按组合版本回退。回退也不是简单覆盖，而是先在一小组机器验证：是否能启动，是否正常提交份额，拒绝率是否回到原来水平，收益统计是否接上。
尤其是现在挖矿软件更新很频繁，有些版本修复了某个算法的效率问题，却引入新的连接异常；有些版本在某类显卡上表现更好，在另一类机器上反而不稳。没有组合版本记录，矿场只能靠管理员记忆，而人的记忆在凌晨故障面前最不可靠。
自动化任务要有刹车，不要一路推到底
自动化最大的价值，是减少重复劳动；最大的风险，是把小错误放大成全场错误。
挖矿软件的自动化任务，至少要分成几个安全层级。比如只读巡检、单机测试、小批量发布、大批量发布、资产相关配置变更。不同层级对应不同权限，不要让一个普通巡检账号也能改钱包地址和矿池地址。
批量发布也不要一次推完。我的建议是按矿组比例分批：先 3 台，再 5%，再 20%，最后全量。每一批之间要看几个指标：在线率、有效算力、拒绝率、重启次数、矿池连接时长。如果指标没有达标，任务自动停止，不允许继续向后推。
这里还有一个容易被忽视的细节：自动化任务必须有超时和撤销机制。比如某批机器下发配置后 10 分钟内没有恢复到预期算力，就自动标记为异常；如果连续两批异常，就停止发布并提示回退。不要让脚本在无人确认的情况下继续执行。
还有夜间任务。很多矿场喜欢把升级放在夜里，因为电价、人员、业务节奏都更方便。但夜间值班人少，判断慢，所以夜间任务更要保守。可以巡检，可以下载包，可以预热环境，但涉及钱包、矿池、核心参数的大范围变更，最好不要在只有一个人值班时执行。
权限边界要按动作切，不要按人情切
运维工具里最难推的，往往不是技术，而是权限。小团队里大家互相信任，一个账号多人共用，密码放在群公告，谁方便谁操作。平时效率很高，出事时没人说得清。
权限设计不能只看职位，要看动作。查看算力是一类权限，修改矿池是一类权限，改钱包是一类权限，发布软件版本又是一类权限。能够重启机器的人，不一定应该能改收益地址；能调整温控策略的人，也不一定能发布新挖矿软件。
对挖矿软件来说，最敏感的权限有三种：
一是钱包和收款地址修改权。这个权限必须单独审批，最好双人确认，并且变更后自动推送到负责人。
二是全量发布权。能把配置推到全部机器的人，相当于能决定整个矿场当晚的收益状态，不能和日常巡检混在一起。
三是脚本编辑权。脚本看起来只是工具，但它能绕过面板限制，直接影响机器状态。脚本修改后应当先进入待发布状态，而不是保存即生效。
权限边界清楚以后，管理员不是被束缚，反而更轻松。因为每个人都知道自己能做什么，不能做什么，遇到异常该找谁确认。
接下来该做的三件事
如果今天要给矿场的挖矿软件运维补课，我会先做三件具体的事。
第一，把现有配置做一次盘点。不要急着优化，先把正在运行的矿池地址、钱包地址、启动参数、软件版本、脚本任务导出来，按矿组归档。发现来源不明的配置，先标记，不要直接覆盖。
第二，建立最小可用的配置账本。哪怕一开始只是用工单系统或文档，也要记录变更对象、变更内容、执行人、审批人、发布时间、验证结果和可回退版本。重点不是形式漂亮，而是下次故障时能查。
第三，给自动化发布加一道停顿。所有大范围任务先小批量执行，指标正常再继续。涉及钱包、矿池、核心参数的变更，必须有人确认，不能让脚本自己跑完全程。
挖矿软件以后只会更自动化，矿场也不可能退回手工一台台改配置。但自动化要跑得稳，前提是每一次变更都能说清楚、查得到、退得回。对运维工具管理员来说，今天最值得花时间的，不是再加一个炫目的按钮，而是把配置账本、版本包和账号边界整理到能真正救场的程度。
