文章目录
挖矿软件的自动化正在从“会执行”转向“每次改动都能查清”
凌晨 2 点 17 分，值班群里先跳出来的不是算力告警，而是一条很短的备注：“A3 区 46 台机器份额下降，矿池显示连接正常。”我打开运维面板看了一眼，温度没异常，网关也没掉，矿池延迟在正常范围内。真正不对劲的是配置页：同一批机器里，有 19 台已经切到新参数，另外 27 台还停在前一个版本，中间还夹着 3 台被临时写入了测试钱包地址。
这类事故不算大，十几分钟能把机器拉回来。但作为挖矿软件的运维工具管理员，我更怕的是另一件事：事后说不清到底是谁改的、改了哪几项、为什么有的机器生效、有的机器没生效。如果配置变更只靠聊天记录、截图和管理员记忆，自动化越强，出错时越难还原现场。
今天矿场用挖矿软件，已经不是装好程序、填矿池、填钱包、批量启动这么简单。自动化脚本、远程升级、策略切换、参数模板、权限分组都在往同一个面板里塞。看起来方便，实际对配置治理提出了更硬的要求：每一次改动都要留下账，每一个版本都能退回去，每一个账号都不能越界。
这次故障发生在一次“很普通”的参数更新里
当天的变更本来很小，只是把部分机型的强度参数下调一点，避免夜间温度波动导致拒绝率上升。计划里写得也很清楚：先选 A3 区 10 台机器观察 30 分钟，再扩到整个 A3 区，确认份额稳定后第二天再推到 B 区。
问题出在第二步。值班同事在挖矿软件的批量配置页面里选择了“A3 区”，但页面上当时有一个旧筛选条件没有清掉：机型、固件版本和标签被同时带入。于是系统只给一部分机器下发了新参数。更麻烦的是，另一个管理员之前做过矿池切换测试，在 3 台机器上留下了临时配置，没有被纳入统一模板覆盖。
从面板上看，所有机器都显示“任务已下发”；从矿池看，大部分机器也没有断连。只有等份额曲线往下走，才发现同一区域里跑着三套不同配置。
这不是某个同事粗心那么简单。真正的问题是，挖矿软件把“执行结果”显示出来了，却没有把“配置状态”说清楚。任务有没有发出是一回事，机器最后跑的到底是哪一版配置，是另一回事。
最容易误判的是把自动化当成确定性
很多矿场上自动化工具后，第一反应是减少人工操作：批量下发、自动重启、掉线自恢复、收益策略切换。方向没错，但如果没有配置账本，自动化只是把人工错误放大得更快。
比如同一个“钱包地址”字段，在不同场景下含义并不一样。长期收益地址、临时测试地址、第三方托管地址、矿池子账户地址，如果都允许管理员直接填，短期看省事，长期看很危险。事故发生后，谁也不愿意承认自己改过，因为他们可能真的记不清。
再比如“版本号”。不少挖矿软件只显示程序版本，不显示配置版本。矿工能看到 miner 是 6.8.1，驱动是某个版本，却看不到当前模板是 A3-20260719-02 还是 A3-test-heat-01。程序没变，不代表配置没变；算力下降，也不一定是软件升级造成的。
还有一种误判更隐蔽：把“批量成功率”当成治理能力。任务下发 100 台，成功 98 台，看起来很漂亮。但剩下 2 台为什么没改？是离线、权限不足、磁盘只读，还是本地文件被人工改过？如果没有差异报告，后面巡检时就会遇到“同一批机器表现不同”的问题。
运维工具管理员不能只盯按钮好不好用，更要盯系统能不能回答三个问题：当前配置是什么，从哪里来的，和标准模板差在哪里。
配置账本要记字段，不是只记一句“已修改”
我们后来把挖矿软件的变更记录重新拆了一遍。以前的日志里常见的是“管理员张三修改 A3 区配置”，这种记录在审计时几乎没用。真正有用的账本，至少要记清楚几类东西。
第一类是对象。到底改的是哪一组机器，选择条件是什么，最终命中的机器清单是什么。不能只写“A3 区”，因为标签可能变，分组也可能被调整。账本里要保留当时的机器 ID、IP、机型、所在机架、原配置版本。
第二类是字段。矿池地址、钱包地址、worker 命名规则、强度参数、温控策略、重启条件、备用矿池顺序，哪些变了，变前是什么，变后是什么，都要逐项记录。只要字段被改动，就不要藏在一整份配置文件里让人事后慢慢比对。
第三类是动作来源。是人工在页面上改的，还是脚本调用接口改的？是定时任务触发，还是告警联动触发？如果是接口调用，调用方的账号、IP、任务编号要写进去。很多误操作不是发生在面板，而是发生在脚本里。
第四类是生效状态。配置下发成功不等于生效成功。机器是否拉取到新配置，挖矿进程是否重载，重载后是否按新参数运行，矿池端是否看到对应 worker，都应该分开标记。这样排查时才知道问题卡在哪一层。
配置账本不是为了事后找人背锅，而是为了让矿场少靠猜。尤其是多班次、多管理员、多脚本并行的环境里，没有账本，就没有稳定的运维交接。
版本回滚不能临时拼，必须在发布前就准备好
这次事故能控制住，是因为我们保留了前一个可用模板。但过程并不优雅：先暂停当前批量任务，再导出受影响机器清单，手动筛出已经生效的 19 台，把它们回退到上一版配置，然后重启挖矿进程。中间每一步都需要人确认，夜间值班压力很大。
后来我们给挖矿软件配置了更明确的版本规则。每个模板都必须有版本号、适用机型、适用区域、创建人、审批人和失效时间。测试模板不能直接覆盖生产模板，临时模板超过约定时间自动标红，不能被误选为默认配置。
回滚也不能只做“恢复上一版”。有时候上一版本身就有问题，或者上一版只适合某个区域。更稳妥的做法是保留最近几个确认过的版本，并标注它们的使用范围。例如某个版本适合低温夜间，某个版本适合高温白天，某个版本用于矿池维护期间的备用策略。
还有一点常被忽略：回滚动作本身也要走账本。谁发起回滚，为什么回滚，回滚了哪些机器，有没有自动重启，重启后观察多久，这些信息要和发布记录连在一起。否则两天后再看日志，只知道配置来回变过，却看不出当时的判断依据。
自动化发布越快，回滚按钮越不能只是一个补救工具。它应该和发布流程绑在一起：每一次发布前，系统先确认可回退版本存在；每一次扩大范围前，系统先确认前一批机器已经稳定。
权限边界要按动作拆，不要按职位粗分
矿场里常见的权限设计是“管理员”和“普通用户”。这对小规模矿机还勉强够用，一旦上了多套挖矿软件、多条收益策略、多个人轮班，就会出问题。
值班人员需要重启进程，但不一定应该能改钱包地址；收益负责人需要切矿池策略，但不一定应该能升级二进制文件；脚本账号需要读取机器状态和下发限定模板，但不应该拥有任意写配置的权限。权限边界如果不拆细，最后就会变成所有人共用一个高权限账号。
更实际的做法，是把权限按动作拆开：查看、下发已审批模板、创建模板、修改敏感字段、执行重启、执行升级、发起回滚、管理账号。钱包地址、矿池主地址、升级源、自动重启条件这几类字段，应该单独加审批或双人确认。
脚本账号尤其要管住。很多矿场为了方便，把 API 密钥写进巡检脚本、告警脚本、批量维护脚本里。脚本一多，谁都不知道哪个脚本还在跑，哪个脚本有权限改配置。建议给每个脚本单独账号，命名写清用途，权限只给到必要动作，并设置有效期。过期脚本不应该还能在夜里悄悄改机器。
权限不是为了增加流程，而是为了减少“一个账号出错，全场跟着出错”的概率。真正好的权限设计，是让一线同事能快速处理常见问题，同时把高风险动作挡在明确边界外。
下一步要做的不是换软件，而是先把三张清单补齐
很多人遇到这类事故，第一反应是换一套更强的挖矿软件。工具当然重要，但如果配置治理没有补上，换软件只是换了一个面板继续踩坑。对矿场来说，接下来更该先做三件具体事。
第一，建立配置基准清单。按机型、区域、矿池、钱包、强度参数、温控策略列出当前标准配置，并给每个标准配置编号。不要只保存在某个人电脑里，也不要只放在聊天群文件中，最好能和挖矿软件里的模板一一对应。
第二，做一次版本回滚演练。选一小组机器，完整走一遍发布、观察、回滚、复核流程，记录每一步耗时和卡点。重点不是演练成功，而是看系统能不能清楚显示哪些机器回到了哪个版本，矿池端份额是否恢复。
第三，清理权限和脚本账号。把共用管理员账号停掉或降权，把长期不用的 API 密钥撤掉，把能修改钱包、矿池、升级源的权限单独列出来。之后每次新增脚本，都要写清它能做什么、不能做什么、什么时候失效。
挖矿软件的自动化能力还会继续增强，机器数量越多，人越不可能靠手工逐台盯住。但越是这样，越要把配置账本、版本回滚和权限边界做细。今天可以先从一个小动作开始：导出当前所有矿机的配置快照，给它编号，保存为可回退版本。等下一次夜间告警响起时，你需要的不是更多猜测，而是一条能查清、能退回、能限制风险的运维记录。
