文章目录
挖矿软件的自动化正在变成一套变更系统
凌晨两点十七分，值班群里跳出一条截图：同一排 36 台机器，算力没有全掉，但有 11 台开始跑到备用矿池，另外 7 台风扇转速突然拉高。第一眼看，很像网络抖动或者矿池拒绝率异常。值班同事按老习惯准备批量重启，我拦了一下，让他先把那一批机器的配置变更记录拉出来。
结果问题不在矿池，也不在机器。白天有人改了一条自动切换规则，本来只想把两台测试机的挖矿软件版本从 5.8.2 提到 5.8.4，顺手把“适用标签”选成了整组。更麻烦的是，更新包里默认配置带了一个旧矿池地址，自动化任务执行时覆盖了原来的配置文件。机器没全停，所以问题一开始不明显；等到收益面板出现差异，已经过了好几个结算周期。
这类事故不算大，却很典型。现在很多矿场已经不靠人工一台台改软件，挖矿软件、脚本、矿池地址、抽水检测、故障重启、收益切换都被写进了自动化规则。效率确实高了，但只要配置没有账本、版本没有边界、执行权限没有分层，自动化就会从省事工具变成放大器：一个小勾选，能影响一排机器；一个默认参数，能改掉一批收益路径。
发生了什么：一次小版本更新拖出了三本糊涂账
复盘那次事故时，我们发现现场同时存在三本账，但没有一本完整。
第一本是软件版本账。后台能看到当前运行版本，却看不到每台机器是从哪个版本升上来的，也看不到升级时用了哪个安装包。有人说“昨天已经全量升过”，另一个人说“只升了测试组”，两边都不是故意糊弄，而是系统里确实缺少一条连续记录。
第二本是配置账。矿池地址、钱包地址、矿工名、超频参数、失败切换条件，都散在不同页面和脚本里。某些配置是面板下发的，某些是脚本启动时覆盖的，还有少量是现场维护时直接在机器上改的。事故发生后，我们想确认“到底哪一刻被改了”，只能翻聊天记录、任务记录和几台机器的本地文件时间。
第三本是权限账。谁能改测试组，谁能改整组，谁能把测试包推成正式包，谁能编辑自动切换策略，当时没有清楚拆开。管理员账号太方便，大家遇到急事就借用；借用多了，操作人就变成了一个共同账号。出问题时不是追责困难，而是定位困难：不知道该找谁补上下文，也不知道这个动作是否经过确认。
挖矿软件管理最怕的不是出错，而是出错后看不到链条。机器挂了可以重启，软件坏了可以换包，矿池异常可以切走。真正耗时间的是大家围着一堆面板猜：这个参数是谁改的？这个版本什么时候推的？为什么只有一半机器生效？自动化任务有没有二次执行？
容易误判的地方：把“能批量执行”当成“可控”
很多矿场上自动化时，第一反应是追求快：批量升级、批量下发、批量切矿池、批量改参数。快当然重要，尤其行情波动、矿池收益变化、软件修复漏洞时，慢半小时可能就是真金白银。但从运维工具管理员的角度看，自动化的核心不该只是“点一下全场生效”，而是“点错了能不能拦住，改坏了能不能退回，退回后能不能确认恢复”。
最常见的误判有三个。
一是认为测试机通过就可以推全场。问题在于测试机往往太干净，网络、温度、显卡混搭、驱动版本、矿机批次都比生产环境简单。挖矿软件小版本改动，有时不是功能变化，而是依赖库、设备识别、日志格式、矿池连接方式变了。两台测试机稳定，不代表混合机型的一整排也稳定。
二是认为配置文件有备份就够了。备份只解决“文件还在不在”，不解决“这份配置对应哪个软件版本、哪个矿池策略、哪个执行任务”。如果一个配置是给 5.8.2 用的，拿去套 5.8.4，字段名或默认值变了，机器可能照样启动，但跑出来的结果不对。配置账本要记录的不只是内容，还要记录它依附的版本和生效范围。
三是认为管理员少就安全。很多小团队只有两三个运维，觉得没必要做复杂权限。实际恰恰相反，人少时更容易把所有操作塞进一个账号里，因为“大家都熟”。可矿场运维不是写群公告，动作一旦下发到机器，就会带来收益影响。权限边界不是为了摆架子，而是为了让高风险动作必须多停一秒。
配置账本怎么建：不要只存最终状态，要存变更理由
配置账本不是把所有配置复制一份到文档里，那样很快就会过期。真正有用的账本，至少要回答五个问题：谁改的，改了什么，为什么改，影响哪些机器，如何撤回。
以矿池地址为例，账本里不能只写当前主矿池和备用矿池。还要记录这次调整是因为主矿池拒绝率升高、结算方式变化，还是只是临时测试延迟；影响范围是某个机架、某种显卡、某个币种，还是全场；预计观察多久；如果收益低于哪个阈值，退回哪一版配置。
再比如自动重启策略。很多人只记录“连续掉算力 5 分钟重启软件”，但没有记录为什么从 10 分钟改成 5 分钟。等到网络不稳时，机器可能频繁重启，反而损失更多有效运行时间。账本里留下变更理由，后面的人才知道这是为了处理某个历史问题，还是长期策略。
我更建议把配置分成三类管理。
一类是收益相关配置，比如矿池、钱包、币种、抽水检测、收益切换条件。这类配置必须有审批和复核，因为改错直接影响钱。
一类是稳定性配置，比如重启阈值、风扇策略、超频参数、温度保护、日志级别。这类配置要按机型和环境分组，不能拿一套参数打天下。
一类是辅助配置，比如日志上传、监控标签、巡检频率、通知方式。这类可以放宽一些，但也要记录，避免排查时发现机器标签乱了、日志断了。
账本越清楚，自动化越敢用。没有账本时，自动化越强，越像在黑箱里按按钮。
版本回滚要提前写好，不要等事故时临时找包
很多挖矿软件事故，最后卡在“回滚”两个字上。大家知道要退回旧版本，却找不到当时的安装包；找到了安装包，又不确定对应的配置；配置找到了，机器上还有残留文件；机器退回后，面板显示版本旧了，但实际进程还是新二进制。
版本管理要在更新前就设计好，而不是出事后补救。每一个准备推送的挖矿软件版本，都应该有三样东西一起入库：安装包、默认配置、回滚说明。安装包要标明来源和校验信息，避免下载站、群文件、临时链接混用。默认配置要注明适配哪些币种、哪些矿池、哪些设备。回滚说明要写清楚哪些文件需要保留，哪些缓存需要清掉，服务如何停止和启动。
更关键的是，回滚要演练。不是在文档里写“可回滚”，而是在少量机器上真的执行一次：从旧版升到新版，再退回旧版，看算力、拒绝率、日志、矿池连接是否恢复。演练时最好不要只选最稳定的机器，应该挑一台普通机器、一台历史上掉线多的机器、一台驱动版本偏旧的机器。因为事故往往发生在边角环境，不发生在样板机上。
版本还要分层发布。测试组、小批量、半场、全场，每一步之间留观察时间。这里的观察不是只看算力有没有回来，还要看拒绝率、重连次数、矿池提交延迟、软件日志里的异常数量。有些版本刚启动很好，跑两个小时后才暴露内存占用或连接抖动。发布节奏太密，问题会叠在一起，最后分不清是哪一步造成的。
权限边界怎么划：让每个人只拿到该用的按钮
挖矿软件管理里，权限最容易被低估。很多事故不是技术能力不足，而是按钮给得太大。
现场至少要把四类权限拆开。
第一类是查看权限。巡检人员和值班人员需要看算力、在线状态、日志、当前版本，但不一定需要修改配置。很多夜间误操作，就是因为查看账号顺手也能执行批量任务。
第二类是配置编辑权限。能改矿池、钱包、参数的人，必须留下个人账号记录。共同账号要尽量取消，实在要保留，也只能用于应急，并且应急后补登记。
第三类是发布权限。能把测试配置推到生产组的人，最好和编辑配置的人分开。一个人写规则，另一个人确认范围和时间，这不是拖慢效率，而是减少“手滑扩大范围”。
第四类是自动化任务权限。脚本执行、定时切换、批量重启、版本升级，都属于高影响动作。尤其是定时任务，很多时候当天看不出问题，凌晨自动执行才出事。任何定时任务都应该有有效期，不应该永远挂着。
权限边界还有一个细节：按机器组授权，不要只按功能授权。一个人可以管理测试架，不代表可以管理全场；可以维护某种显卡，不代表可以碰 ASIC 组；可以改日志上传，不代表可以改钱包地址。矿场规模越大，越要把“能做什么”和“能对谁做”拆开。
下一步怎么做：把自动化从脚本堆成流程
如果今天要整理一套挖矿软件运维规则，我会从几个具体动作开始，不建议一上来就买一堆新工具。
第一，给所有正在运行的挖矿软件做一次版本盘点。按机器组导出当前版本、启动路径、配置路径、矿池地址、钱包标识、自动任务绑定情况。盘点后不要只留截图，要形成可检索记录。
第二，给配置改动加编号。哪怕只是简单编号，也比群里一句“我改一下”强。每次改动都写清影响范围、原因、执行人、计划观察时间、回退配置。没有编号的配置，不允许推全场。
第三，建立版本包库。正式用过的安装包不要随手删，也不要只存在个人电脑里。每个版本配一份说明：来源、校验、适配设备、已知问题、配套配置、回滚办法。
第四，把自动化任务分成低风险和高风险。日志采集、状态标记、普通巡检可以自动跑；改矿池、改钱包、升级软件、批量重启必须多一道确认。夜间自动任务尤其要少，除非已经演练过。
第五，做一次回滚演练。选 5 到 10 台不同类型机器，模拟新版本升级失败，按文档退回旧版本。演练后记录耗时、失败点、遗漏文件、恢复确认口径。这个动作比写十页制度更有用。
第六，收紧管理员账号。每个人用自己的账号操作，高风险动作保留二次确认。离职、换岗、外包维护结束后，账号立即停用。矿场最怕“没人知道这个账号还在”。
挖矿软件的自动化还会继续加深，这是确定的。以后软件会更频繁更新，矿池策略会更细，收益切换会更依赖规则。运维工具管理员真正要守住的，不是每一次都不出错，而是让每一次改动都有账可查、有版可退、有边界可拦。今天就可以从一件小事开始：把当前全场挖矿软件版本和配置导出来，补上变更编号，再挑一组机器跑一次回滚演练。自动化只有被记录和约束住，才是真的省人。
