文章目录
挖矿软件自动化越多，配置账本越该写在前面
凌晨 2 点 17 分，值班群里跳出一条算力下滑提醒。不是全场断网，也不是矿池大面积异常，只有 B 区 46 台机器陆续掉到低算力状态。面板上看，矿机还在线，温度也正常，风扇转速没有明显异常。第一反应很容易是矿池连接抖了一下，或者某个批量脚本没跑完。
但查到第三台机器时，我发现问题不在机器，而在配置。前一晚有同事把一组新矿池参数同步到测试组，自动化任务却把“测试组”的标签识别成了“B 区混合组”。更麻烦的是，其中一部分矿机刚升级了挖矿软件小版本，参数字段的解释和旧版本不完全一致。结果就是：同一份配置，在不同版本上跑出了不同结果。
这类事故不大，通常不会上新闻，也不会让矿场一夜归零。但对运维工具管理员来说，它很刺眼。因为它暴露的不是某个按钮点错了，而是我们太相信自动化，却没有把配置变更、版本差异和操作权限放进同一本账里。
发生了什么：自动同步把“小改动”放大成了批量问题
这次操作的起点很普通：矿池临时调整，运维需要把备用地址提前写入配置，防止主地址波动时人工切换太慢。按以前的流程，管理员会选中一组矿机，套用模板，检查回传状态，然后观察 10 到 15 分钟算力曲线。
问题出在“组”的定义变了。
B 区最近做过一次整理，几台新机器、几台老机器、还有两台测试机器被临时放在同一个机架下。为了方便看板显示，有人给它们打了一个共同标签。自动化工具执行任务时，调用的是标签，不是机架号，也不是单独设备清单。于是，原本只该落到测试机上的模板，扩散到了混合组。
如果只是模板发错，回滚还算简单。麻烦的是版本不一致。
同一款挖矿软件，旧版本对某个参数留空会使用默认值，新版本则会把它识别成显式关闭。测试机上没问题，是因为测试机已经升级；B 区里还有一批机器停留在上一个稳定版本。配置一推，表现就分裂了：有的机器正常切换备用池，有的机器反复重连，有的算力掉到一半后不再恢复。
很多矿场现在都在上自动化：自动切矿池、自动调功耗、自动重启进程、自动分发脚本。方向没有错，人工一台台改配置确实撑不住。但自动化最怕的就是“看起来只是改一行”，实际落到不同机器、不同版本、不同权限环境里，结果变成几十种。
容易误判的地方：面板绿色不代表配置正确
事故刚发生时，最容易被面板骗。
矿机在线，进程存在，温度正常，甚至部分机器还能回传少量算力。看板上没有大片红色，值班人员很容易判断为矿池波动，或者网络不稳。这种判断会拖慢排查，因为大家会先去查交换机、矿池延迟、DNS、外网出口，最后才回到配置本身。
挖矿软件的配置问题有个特点：它不一定让机器立刻死掉，而是让机器“半活着”。
比如地址写对了，但用户名后缀错了，矿池会拒绝部分提交；比如强度参数不适配当前显卡驱动，机器能跑，但拒绝率异常；比如新版本改了参数含义，旧模板还能被读取，却不是你以为的意思。面板上看到的是算力下降，真正的问题可能藏在配置文件的某个字段里。
还有一个误判，是把“自动化日志”等同于“配置账本”。
很多工具会记录任务执行成功、下发成功、设备响应成功。可这不等于你知道当时到底改了什么。执行成功只说明工具把东西发出去了，不说明新旧配置差异清楚，不说明谁批准了这次变更，也不说明机器收到后实际运行的是哪一版。
这次复盘里，我们翻自动化记录时能看到任务编号、执行人、时间和目标标签，但无法直接看到完整差异。想还原现场，只能去比对模板历史、设备当前文件、聊天记录和版本列表。这个过程花了 40 多分钟。对矿场来说，40 分钟可能不算灾难；但如果碰上行情剧烈波动、矿池拥堵或者更多机器被波及，这 40 分钟就会变成很贵的学费。
配置账本要记什么：别只记“改过”，要记“为什么这样改”
配置账本不是为了写漂亮文档，而是为了事故发生时能马上回答几个问题：谁改的，改了哪几台，改前是什么，改后是什么，依据是什么，预计影响是什么，能不能撤回。
真正有用的账本，至少要覆盖四类信息。
第一类是设备范围。不能只写“B 区”或“测试组”，要能落到具体矿机编号、IP、机架位置、设备类型。标签可以用，但标签不能是唯一依据。标签太容易因为临时调整而变脏，尤其是测试机、维修机、临时替换机混在一起时。
第二类是配置差异。不要只保存最终配置，要保留改动前后的差异。矿池地址、钱包名、工作名、功耗参数、算法选择、重启策略，这些都要能看出来。只知道“应用了模板 A”意义不够，因为模板 A 自己也可能被改过。
第三类是适用版本。每一份配置都应该标明它验证过的挖矿软件版本、驱动版本、系统镜像版本。不要默认“同一软件的小版本都兼容”。很多坑就出在小版本调整：参数名没变，默认行为变了；报错文本没变，实际处理方式变了。
第四类是变更理由。为什么要改？矿池通知、收益策略调整、测试新版本、修复拒绝率，还是临时绕过故障？理由写清楚，后面回滚时才知道该回到哪里。如果只是为了临时救火，后续就要有过期时间，不能让临时配置长期躺在生产机器上。
配置账本最好和自动化工具绑定，而不是散在群聊和个人笔记里。群聊适合沟通，不适合追责；个人笔记适合经验，不适合协作。真正要落地，变更前生成记录，变更后自动补状态，失败和回滚也写进去。
版本回滚别等出事才找包：每个稳定版本都要能拿回来
很多矿场升级挖矿软件时只关心新版本收益有没有提升、支持哪些新算法、是否修了某个已知问题。但运维管理员更关心另一件事：这个版本能不能退回去。
回滚不是简单地把旧安装包找出来。完整回滚至少包括软件包、配置模板、启动参数、依赖文件、驱动兼容说明和验证结果。少一块，都可能退不干净。
这次事故里，有几台机器本来已经升级到新版本，回滚时却遇到启动参数残留。旧版本能启动，但读到了新版本留下的字段，日志里一直报不明显的警告，算力恢复慢。后来只能重新套用旧模板，再清理一次残留参数。这个问题如果事先有回滚包和清理清单，十分钟就能处理完。
建议把版本分成三层管理。
一层是当前生产稳定版。这个版本不一定最新，但必须是矿场验证过、能连续跑、异常可解释的版本。
一层是灰度测试版。只放少量机器，最好机型、显卡、网络环境都覆盖一点，但不要混到正式生产标签里。灰度机器要有明显标识，自动化任务默认不能把灰度配置推到生产组。
还有一层是保底回退版。它可能不是收益最高的版本，但一定要启动快、参数少、兼容性好。遇到大面积异常时，先让机器稳定跑起来，再慢慢查细节。
版本管理最怕“只有最新版，没有退路”。软件更新越频繁，矿场越不能把包随便放在共享盘里就算完事。每一次升级，都应该配套一份回滚说明，至少写清楚：回哪个版本、用哪份配置、哪些字段要删除、回滚后看哪几个指标确认恢复。
权限边界要收窄：自动化按钮不能谁顺手谁点
配置事故还有一个常见原因：权限太宽。
有些矿场为了方便，把自动化平台的操作权限开得很大。值班人员能改模板，测试人员能推配置，管理员能批量重启，甚至临时协助的人也能拿到生产权限。平时看起来效率高，出事时就会发现没有边界：到底谁能改生产配置，谁能改测试模板，谁能批准跨区域执行，谁能紧急回滚，都说不清。
权限边界不是为了卡人，而是为了减少误操作扩散。
生产配置模板和测试配置模板要分开。能编辑模板的人，不一定能下发到生产；能下发单台的人，不一定能批量下发；能执行回滚的人，不一定能修改回滚包。尤其是自动切换、批量重启、批量升级这类动作，应该有二次确认和范围预览。
这里的关键不是审批流程做多复杂，而是让高风险动作多一秒停顿。下发前必须看到目标设备数量、设备列表、当前版本分布、预计改动字段。数量异常时要拦住，比如平时只改 5 台测试机，突然命中 46 台，就应该要求更高级别确认。
临时权限也要有有效期。很多事故不是当天授权造成的，而是几周前为了修一个问题临时开了权限，后来没人收回。工具管理员要定期查权限清单，把不再需要的账号、令牌、脚本权限收掉。
下一步怎么做：把自动化从“能跑”改成“可核对”
这次复盘后，我会优先改三件事。
第一，把配置下发改成带差异预览。任何批量任务执行前，平台必须显示设备清单、版本分布和关键字段变化。只显示“将应用模板”不够，必须能看到模板和当前配置到底差在哪里。
第二，给每个版本配一份回滚包。包括安装包、旧配置、启动参数、清理项和验证指标。以后升级前不问“新版本能不能跑”，先问“退回去要几步”。如果退不清楚，就不能扩大范围。
第三，重新划权限。测试组、生产组、灰度组分开；模板编辑、任务执行、批量发布、紧急回滚分开；临时权限设置到期时间。自动化工具越好用，越不能让一个账号包打天下。
挖矿软件这几年变化很快，自动化肯定会继续加深。矿场不可能退回手工时代，也不该因为一次配置事故就拒绝工具。但从运维工具管理员的角度看，真正该补上的不是更多按钮，而是每一次配置变化都有记录，每一个版本都有退路，每一个批量动作都有清楚边界。
今天就可以先做一个小动作：拉出最近 30 天的配置变更记录，随机挑 5 次批量操作，看能不能在 5 分钟内说清楚改了什么、改到哪些机器、当时运行什么版本、如果出错该退到哪里。说不清楚的地方，就是下一次事故最可能发生的地方。
