文章目录
挖矿软件越会自动执行，矿场越需要一本配置账本
凌晨两点十七分，值班群里先跳出来的不是掉线通知，而是一条很普通的算力波动：A 区 36 台机器的平均算力从平时的 102T 降到 87T。按以往经验，夜里温度变化、矿池延迟、风机转速抖一下都可能造成这种波动。值班同事顺手点了“重新下发配置”，想让系统把矿池地址和超频参数再刷一遍。
十分钟后，问题扩大了。A 区没恢复，B 区又有 18 台机器开始反复重启。等我接手看日志，才发现真正的原因不在矿池，也不在机器，而在昨天傍晚上线的一版挖矿软件管理脚本：它把“默认模板”里的一个字段名改了，但老版本客户端仍按旧字段读取。自动化任务没有识别这个差异，夜间巡检时照常把新模板推给了老客户端。
这类事故在矿场里不算惊天动地，却很疼。机器没坏，网络没断，矿池也没出问题，偏偏收益被一点点漏掉。更麻烦的是，出事后大家一开始都以为是现场问题，绕了一圈才回到软件配置本身。
从运维工具管理员的角度看，挖矿软件今天最该补的，不是再加一个批量按钮，而是把配置、版本和权限三件事记清楚、管起来、能倒回去。
发生了什么：一次“看起来正常”的自动下发
这次小事故的链路很典型。
前一天，工具组更新了挖矿软件的配置管理脚本，目标很简单：把不同矿池的参数格式统一，减少人工复制时写错 worker 名称。测试时选了几台新装客户端，跑得没问题，于是把模板标成了“可用”。
问题出在“可用”这两个字太宽了。它对新客户端可用，不代表对老客户端也可用；对单台测试可用，不代表对整片区域夜间自动巡检也可用。
夜间任务执行时，系统按照区域策略给机器补齐配置。它没有先检查客户端版本，也没有确认当前机器使用的是哪一版模板，更没有记录本次下发与上一版配置的差异。于是，一批老客户端拿到了不兼容的配置。部分机器继续跑，但参数读取不完整，算力下降；部分机器检测到配置异常，开始重启挖矿进程。
最糟糕的地方是，自动化任务每隔十五分钟还会再执行一次。也就是说，现场同事手动改回去的配置，很快又被系统覆盖。人在救火，脚本在添柴。
容易误判的地方：把“有记录”当成“能追账”
很多矿场并不是完全没有记录。群里有升级通知，工单里有操作说明，工具后台也能看到任务成功或失败。但这些记录往往只能回答一个问题：谁点过什么按钮。
事故复盘时，我们真正需要的是另一组问题：
这台机器在出事前用的是哪一个配置模板？
模板里具体改了哪几行？
它对应的挖矿软件客户端版本是多少？
下发动作是谁触发的，是人工还是定时任务？
如果要退回去，应该退回到哪个配置，而不是随便找一个“看起来能跑”的旧文件？
这些问题回答不出来，“有记录”就只是流水账，不是配置账本。
配置账本要记的不是漂亮文档，而是能在出事时直接用上的东西。比如模板编号、适用币种、矿池地址、钱包标签、worker 命名规则、超频参数、风扇策略、客户端版本、下发时间、审批人、执行范围、回退文件位置。每一次修改，都应该留下差异，而不是只留一句“优化配置”。
很多事故拖长，不是因为技术难，而是因为没人敢确定哪一份才是正确配置。现场机器越多，越不能靠记忆和聊天记录来判断。
版本管理的坑：只管升级包，不管配置格式
挖矿软件的版本管理，经常只盯安装包：从哪个版本升到哪个版本，修了什么 bug，支持什么算法。可在实际运维里，安装包只是其中一半，另一半是配置格式。
同一个矿工程序，版本差两三个月，参数名、默认值、日志路径、错误处理方式都可能变。管理平台如果只知道“这台机器在线”，却不知道它跑的是哪一版客户端，就很容易把新模板推给老程序。
这也是自动化最容易踩的地方。自动化脚本不会像人一样犹豫，它只会按条件执行。条件写得粗，它就粗暴执行；条件没写版本，它就默认所有机器一样。
比较稳的做法，是给配置模板加上适用范围。比如某一版模板只允许下发给 2.8.5 以上客户端；某些参数只允许在指定型号矿机或指定固件上启用；跨大版本升级必须先跑灰度组，灰度组至少经历一个完整收益结算周期，再扩大范围。
还有一点很重要：配置和软件包要能绑定。不能今天升级客户端，明天才想起来补模板；也不能模板先改了，客户端还没跟上。运维工具里最好能看到一台机器当前的组合状态：客户端版本是什么，配置模板是什么，上一次成功下发是什么时候，下一次定时任务会不会覆盖它。
回滚不该靠临场找文件
矿场里常见一句话：“先回滚。”听起来很稳，但真正执行时，经常发现没人知道回滚到哪。
回滚不是把软件降级这么简单。挖矿软件涉及客户端、配置模板、启动参数、矿池策略、钱包地址、监控规则，有时还包括本地脚本。只退其中一项，可能退不干净；退错一项，可能让问题更乱。
这次事故后，我们把回滚拆成了三类。
第一类是配置回滚。只要模板出错，就把指定机器退回上一版已验证配置，不动客户端。这个动作最快，适合字段写错、矿池参数异常、worker 规则不兼容。
第二类是客户端回滚。新版本程序自身不稳定，才退客户端。退之前要确认配置是否也要同步退，否则老客户端拿着新配置，问题还会重现。
第三类是任务回滚。很多人忽略这一点。就算机器已经改回来了，如果定时任务还在，十五分钟后又会把坏配置推回去。所以回滚时必须先暂停相关自动化任务，确认范围，再执行恢复。
回滚文件也不能散落在个人电脑里。每一个可回滚版本，都应该有固定位置、固定命名、固定说明，最好还能一键比对差异。运维现场最怕“我记得昨天那个文件能用”，这种话一出现，说明流程已经靠人撑着了。
权限边界要按动作拆，不能只按职位拆
挖矿软件管理后台里，权限经常分得很粗：管理员、运维、观察者。看似简单，实际风险很大。
一个能查看算力的人，不一定应该能改矿池地址；一个能重启进程的人，不一定应该能修改钱包标签；一个能给单台机器下发配置的人，不应该默认能对全场批量执行。职位不是问题，动作才是问题。
对于配置治理，权限至少要拆到几个具体动作：创建模板、修改模板、发布模板、下发到单台、下发到批量、暂停自动任务、执行回滚、修改钱包相关字段。尤其是钱包地址、矿池账户、收益归集标签，必须单独限制，最好需要二次确认和双人审批。
自动化任务也要有“主人”。不能只有一个系统账号在后台跑，出事后查不到业务负责人。每个定时任务都应该写明创建人、审批人、执行范围、最近一次修改原因。任务如果长期没人维护，就应该冻结，而不是一直躲在后台执行。
权限边界不是为了增加麻烦，而是为了让事故停在小范围。允许值班同事修单台机器，但不允许他临时改全场模板；允许他暂停某个区域任务，但不允许直接改钱包字段。这样的限制，救火时反而更快，因为大家知道自己能做什么、不能做什么。
下一步怎么做：先把三张清单补起来
如果今天要整理挖矿软件运维，我建议不要一上来就换系统，也不要急着写一堆复杂流程。先补三张清单，能落地就已经能少很多事故。
第一张是配置账本清单。把正在使用的模板逐一列出来，标清适用机器、客户端版本、矿池、钱包标签、最近修改时间、修改原因和回滚版本。过期模板不要留在可选项里，避免有人误用。
第二张是自动化任务清单。把所有定时下发、自动重启、自动切换矿池、自动修复脚本列出来，写清执行频率、触发条件、覆盖范围和负责人。凡是会批量改配置的任务，都要加执行前检查：客户端版本不匹配就停止，目标机器数量异常就停止，涉及钱包字段就停止等待确认。
第三张是回滚演练清单。选一个低风险区域，每月至少演练一次：暂停任务、退回配置、确认算力、恢复任务、记录耗时。演练不需要声势很大，但要真的跑完。只有跑过，才知道文件在哪里、权限够不够、步骤有没有缺口。
挖矿软件的自动化会继续增加，这是好事。机器多了，人工不可能盯住每一次配置变化。但自动化越顺手，越不能让它变成没人负责的黑箱。配置账本要能查，版本差异要能看，回滚路径要能走，权限边界要能拦住误操作。
今天下班前，运维管理员可以先做一个很具体的动作：打开后台，把最近 30 天改过的配置模板导出来，逐个标上适用客户端版本和回滚文件位置。标不出来的模板，先不要再参与批量下发。这个动作不复杂，却能在下一次夜间波动时，帮你少绕很多弯路。
