文章目录
挖矿软件的自动化越顺手，配置账本就越该提前写清
凌晨两点二十七分，值班群里先跳出来的不是掉线告警，而是一排算力曲线同时变平。14 台机器没有断电，风扇转速也正常，矿池端显示的 worker 名称却突然换成了测试标签。后来查下来，原因并不复杂：一条原本只给三台新卡测试的挖矿软件参数，被自动化任务推到了整组机架。执行人以为选的是“测试分组”，系统记录里却只留下了一句“批量应用配置成功”。
这类事故不吓人，却很烦人。它不像电源烧了、网络断了那样一眼能判断损失点，最麻烦的是事后追溯：到底谁改了矿池地址，谁动了抽水设置，哪个版本的挖矿软件和哪个配置文件绑定过，自动化任务有没有继承旧参数？如果这些问题都要靠聊天记录、截图和个人记忆来找答案，矿场越自动化，运维越像猜谜。
我现在越来越明确一个判断：挖矿软件的管理重点，正在从“能不能批量跑起来”，转向“每一次配置变化能不能被记录、解释和撤回”。自动化本身不是问题，问题是自动化如果没有账本、版本和权限边界，就会把一次小误点放大成一排机器的停摆。
这次事故真正发生了什么
复盘当天的操作链，其实只有四步。
第一步，技术员给三台新到的显卡机测试新版挖矿软件。这个版本对某个算法的功耗控制更细，参数里多了几项设备强度和温度阈值。测试机跑了二十分钟，算力表现不错，于是准备再扩大到一个小分组。
第二步，运维面板里有两个名称很像的分组，一个叫“RX-test-3”，另一个叫“RX-east-3”。前者是测试机，后者是东侧三号机架，包含十几台正在生产的机器。值班人员在下拉框里选错了，但由于系统没有二次确认配置差异，也没有显示即将覆盖的 worker 数量，任务直接提交。
第三步，自动化任务不仅推送了新版挖矿软件，还把测试配置里的矿池备用地址、worker 前缀和强度参数一并覆盖了过去。最初几分钟机器还在跑，所以本地状态看起来正常，直到矿池侧统计延迟后，才发现有效算力开始掉。
第四步，回滚时又遇到麻烦。旧版本程序包还在，但旧配置文件并不完整。有几台机器之前做过单独调参，参数没有被归档，只存在本机目录里。批量回退后，其中几台机器虽然恢复了旧版本，却带着不匹配的新参数继续跑，报错日志刷了一屏。
表面看，这是一场“选错分组”的低级失误；实际看，它暴露的是挖矿软件管理里三个常见缺口：配置没有账本，版本没有对应关系，权限没有分层。
最容易误判的是：以为自动化记录等于配置账本
很多运维工具都会留下操作日志，比如谁在几点提交了任务、任务是否成功、目标机器有哪些。问题在于，这些日志只能证明“做过动作”，不能完整说明“改了什么”。
真正有用的配置账本，至少要回答几件事：
这次推送前，每台机器使用的是哪个挖矿软件版本；配置文件的哈希或编号是什么；矿池地址、钱包地址、worker 命名、抽水参数、温控阈值有没有变化；变化来自手动编辑、模板继承，还是自动化脚本生成；如果要退回上一版，应该退到哪一个组合。
很多事故复盘到最后都会卡在“我记得之前是这个参数”上。记得不算数，截图也不可靠。尤其是多算法切换、多矿池备份、不同显卡批次混跑时，同一个软件版本可能配了好几套参数。只记程序版本，不记配置版本，回滚时就会出现“程序退回去了，参数还留在新状态”的情况。
我更倾向于把挖矿软件管理拆成两个独立编号：一个是程序包版本，一个是配置模板版本。比如某台机器今天运行的是 A 软件 2.1.7，加上 ETC-4060-低功耗-v4 这套配置。下次调整强度，哪怕程序包不变，配置模板也要生成新编号。这样查账时不会混在一起。
配置账本不需要一开始就做得很复杂，但必须稳定。哪怕只是每天导出一份配置快照，按机器、分组、软件版本、配置编号存起来，也比事故后翻聊天记录强得多。
另一个误区：只给软件做版本管理，不给脚本和模板做版本管理
挖矿软件更新，大家通常比较谨慎。新版本从哪里下载，校验值对不对，先在哪几台机器跑，跑多久再扩大范围，这些流程大矿场基本都有。但真正容易悄悄变动的，往往不是软件本体，而是围绕它的脚本和模板。
比如启动脚本里加了一段自动重启逻辑；矿池切换脚本里改了超时时间；某个模板默认打开了日志上传；温度达到阈值后的降频策略从保守变成激进。这些改动看似只是“运维优化”，却会直接影响机器行为。
更麻烦的是，脚本经常由不同人改。白班为了减少离线时间，把重启等待从 180 秒改成 60 秒；夜班发现误触发太多，又在另一份脚本里加了排除条件。几周后，面板里看起来都是“自动恢复任务”，实际执行逻辑已经不是同一套。
所以版本管理不能只盯挖矿软件安装包。启动命令、配置模板、环境变量、自动切池脚本、监控探针、定时任务，都应该有版本标记。至少要做到：每次上线前能看到差异，每次上线后能知道影响范围，每次出事时能退回上一份可用组合。
对运维工具管理员来说，这一步不一定非要引入复杂系统。关键是把“随手改文件”的习惯停掉。所有改动先进一个固定目录或管理页面，写清楚改动原因、适用机型、目标分组、回退方式，再由有权限的人发布。这样做会慢一点，但比半夜全员找脚本快得多。
权限边界不能只按职位分，还要按动作风险分
很多矿场的权限设置比较粗：管理员能做所有事，普通运维只能查看或重启。听起来安全，实际很容易形成两个问题。
一个问题是管理员账号被多人共用。为了方便值班，几个人都知道同一个高权限账号密码。事故发生后，只能看到“admin 执行了批量任务”，却不知道具体是谁点的。另一个问题是普通账号权限太少，遇到小故障无法处理，只能找管理员远程操作，时间一长又会诱导大家共用高权限账号。
更合理的做法，是按动作风险拆权限，而不是只按岗位名称拆。
查看算力、查看日志、查看配置，可以放宽；重启单台机器、切换单台配置，可以给一线值班；批量推送软件、覆盖配置模板、修改钱包地址、调整抽水参数、变更自动化规则，就应该单独审批。尤其是钱包地址和矿池账号，必须和普通调参分开，不能让一个“批量配置权限”顺手就能改收益去向。
还要注意临时权限。很多事故不是长期权限设计错了，而是临时开权限后没有收回。比如某个外部技术支持远程帮忙调试，给了他一晚上的管理权限，第二天忘了关。再比如某个新人为了赶进度拿到批量推送权限，培训结束后仍然保留。权限边界如果不定期清理，迟早会变成一堆历史遗留。
我建议至少每周做一次权限核对：谁能批量改配置，谁能改矿池和钱包，谁能发布自动化任务，谁能删除或覆盖历史版本。这个核对不需要写长报告，但要留下记录。权限本身也应该进入账本。
回滚不是“装回旧版本”，而是退回旧状态
事故处理中最常见的一句话是“先回滚”。但在挖矿软件运维里，回滚如果只理解成把程序包换回旧版，往往不够。
一台机器能稳定挖矿，靠的是一组状态：软件版本、驱动版本、配置文件、启动参数、矿池设置、设备编号、风扇策略、系统依赖、脚本任务。只退其中一项，可能会制造新的不匹配。
所以回滚方案要提前写清楚，不要等事故发生后临时拼。
比较实用的做法是给每次正式发布建立一个“可恢复点”。发布前把目标分组的当前状态冻结下来，包括程序包、配置模板、启动命令和关键参数。发布后如果出现异常，回滚按钮或回滚脚本退回的是这一整组状态，而不是只替换某个二进制文件。
同时，回滚也要分层。三台测试机可以自动回滚，十几台生产机最好先回滚一小段，再观察矿池端有效算力、拒绝率和本地错误日志。全量回滚看似果断，但如果旧状态本身已经不适合当前驱动或矿池策略，也可能把问题扩大。
还有一点容易被忽略：回滚动作本身也要留痕。谁触发、回到哪个恢复点、覆盖了哪些机器、有没有跳过离线设备，都要写入记录。否则过几天再看，你只知道机器恢复了，却不知道现场究竟怎么恢复的。
下一步可以先做四件小事
如果矿场规模不大，不必一上来就搭很重的管理体系。挖矿软件的配置治理，可以从四件很具体的事开始。
第一，给每套配置起固定编号。不要再用“新版配置”“稳定版配置”“测试配置”这种模糊名字。名称里至少包含算法、机型或显卡批次、用途和版本号。比如低功耗、满载、测试、备用矿池，都要分清。
第二，批量任务提交前增加差异预览。运维人员在点击执行前，应该看到即将影响多少台机器、哪些关键字段会变化、是否涉及钱包或矿池地址、是否会替换启动脚本。没有差异预览的一键推送，迟早会让人手滑。
第三，把自动化任务分成日常任务和高风险任务。重启掉线机器、拉取日志、刷新状态，可以自动执行；覆盖配置、升级软件、改矿池、改收益地址，必须有人确认，必要时两个人确认。自动化不是越少人参与越好，而是把人放在该判断的地方。
第四，每周做一次恢复演练。选两三台非关键机器，模拟一次软件升级失败，完整执行回滚，检查配置是否真的退回、矿池端是否恢复、日志是否能对应上。不要等真事故发生时，才发现备份文件缺一半。
给运维工具管理员的落地清单
今天如果要动手改，我建议先从管理面板或脚本目录里找三样东西：当前所有挖矿软件版本清单、各分组正在使用的配置文件、拥有批量修改权限的账号列表。
把这三样先对齐，基本就能看出风险在哪里。哪台机器的软件版本说不清，哪个配置模板没人认领，哪个账号权限过大，哪个脚本没有版本记录，都先标出来。接下来再补配置编号、发布记录和回滚点。
挖矿软件越自动化，越不能靠“大家都熟”来维持秩序。真正稳的运维，不是永远不出错，而是出错后能在十分钟内知道改了什么、谁改的、退回哪里。今天发布新版本或新配置前，先别急着点批量执行，把配置账本补一页，把回滚点建好，把能改钱包和矿池的人再核一遍。机器可以自动跑，配置不能糊涂跑。
