文章目录
挖矿软件越自动，配置账本越要比脚本先落地
凌晨两点十七分，值班群里先跳出来的不是算力告警，而是一条很短的留言：“三号架有 46 台机器切到备用矿池了，谁动的？”
我打开运维面板，第一眼看到的是总算力还在，掉得不明显；第二眼看拒绝率，才发现有一批机器的提交延迟变高。再去翻任务记录，确实有一条批量配置下发，目标标签写着“三号架-测试”，执行范围却覆盖到了“三号架-全量”。动作不大，事故也不算惨，但麻烦的是，没人能马上说清楚：这份配置从哪来、谁改过、为什么自动任务会在夜里执行、当前版本还能不能直接退回去。
这类事在矿场里很常见。挖矿软件越来越会自动切矿池、自动调参数、自动重启、自动套用配置模板，平时看起来省人，真出错时也会把错误放大得很快。作为运维工具管理员，我现在最怕的不是软件功能不够，而是配置没有账本、版本没有边界、权限没有分层。机器坏了可以换，脚本错了可以改，可一旦不知道哪一行配置在什么时候被谁推下去，排查就会变成猜谜。
发生了什么：一次“测试配置”被自动任务放大
这次问题的起因很简单。白班同事想测试备用矿池的延迟，准备在三号架抽 5 台机器跑 20 分钟。为了方便，他复制了一份旧模板，把主矿池地址改成备用矿池，把钱包地址保持不变，又把重连间隔从 30 秒调成 10 秒。按理说，这只是一个小范围测试。
问题出在两个地方。
第一，测试标签和正式标签命名太像。系统里原来有“三号架-测试”和“三号架-全量”两个标签，页面选择时靠下拉框，肉眼看起来差不多。白班同事创建任务时选了测试标签，保存后又被一个自动同步规则重新匹配了一遍。同步规则按机架编号抓取，结果把三号架整排机器都纳入了任务范围。
第二，版本说明写得太随意。那份配置的备注只有四个字：“备用测试”。没有写改了哪个矿池，没有写预计执行多久，没有写影响范围，也没有写回退版本。夜班看到异常时，只能翻聊天记录问人。人没醒，机器已经切过去了。
如果只看算力面板，这次事故甚至不容易被立刻发现。因为备用矿池也能出算力，总数并没有断崖式下跌。真正暴露问题的是拒绝率和延迟变高，部分机器收益变差。也就是说，自动化没有把矿场打停，但悄悄把收益效率拉低了。
这比直接宕机更烦。直接掉线，大家会立刻处理；慢性损耗，可能拖几个小时才被发现。
容易误判的地方：以为“能跑”就等于“没改坏”
很多矿场在评估挖矿软件时，喜欢问三个问题：支持多少币种，批量操作快不快，自动切换灵不灵。这些当然重要，但从日常运维看，真正决定稳定性的往往是另外几个细节。
一个常见误判是，把配置文件当成临时文本，而不是生产资产。矿池地址、钱包地址、内核参数、重启条件、降频策略、风扇策略、代理地址，这些内容一旦下发，就会直接影响收入。它们不是“随手改一下”的东西，而应该像财务凭证一样有记录、有版本、有审批、有失效时间。
另一个误判是，以为自动化任务只会照着人的意图执行。实际上，自动化最擅长的是快速执行，不擅长判断你是不是选错了范围。人手动改 5 台，错了也就 5 台；脚本批量推送，错了可能是 500 台。挖矿软件的自动化能力越强，越要给它加限制：哪些任务可以夜间跑，哪些配置必须二次确认，哪些机器永远不能被测试标签覆盖。
还有一个很隐蔽的问题：版本号只记录软件版本，不记录配置版本。很多人会记得自己用的是哪一版挖矿内核，却不记得这批机器现在跑的是第几版配置。软件升级失败，还能降级；配置改坏了，如果没有留存上一版，就只能靠记忆还原。夜里出事时，人的记忆通常最不可靠。
配置账本要记什么：不只记“改了”，还要记“为什么改”
我们后来复盘这次事故，第一件事不是改脚本，而是补配置账本。所谓配置账本，不一定非要上很重的系统，核心是把每次变更记录成可追踪的条目，让后面的人能看懂。
至少要记清楚六件事。
第一，配置对象。是某个矿机、某个机架、某个矿池策略组，还是某个币种模板。不要只写“三号架”，要写清楚机器数量和识别方式，比如按 IP 段、SN 列表还是标签组。
第二，变更内容。不能只写“优化参数”。要写从什么改到什么，比如主矿池地址、备用矿池优先级、重连间隔、重启阈值、超频档位、钱包地址校验结果。涉及钱包的配置尤其要单独标记，避免把测试钱包混进正式收益路径。
第三，变更原因。是矿池延迟变高、币种收益切换、软件版本适配，还是单纯测试。原因写清楚，后面才知道这条配置有没有继续保留的必要。
第四，执行时间和有效期。有些测试配置应该自动过期，不能长期留在系统里。比如“20 分钟延迟测试”就应该到点还原，而不是靠人记得撤销。
第五，关联版本。配置版本要和挖矿软件版本绑定。某个参数在 A 版本有效，在 B 版本可能含义变了。只存配置不存软件版本，回滚时容易出现“配置退回去了，软件没退”的错位。
第六，操作人和审批人。这里不是为了甩锅，而是为了快速找到上下文。谁提的需求，谁确认范围，谁批准执行，夜班才知道该问谁。
配置账本的价值，平时不明显，出事时非常明显。它能把排查从“谁记得”变成“查记录”。
版本管理别只盯升级：回退路径要提前验证
很多矿场对版本管理的理解还停留在“有新版就测一下”。但挖矿软件的版本管理，不只是升级管理，更重要的是回退管理。
我们这次最尴尬的地方是，虽然系统里保存了上一版配置，但没有做过回退演练。夜班同事点回滚前犹豫了十分钟：退回去会不会覆盖当前钱包？会不会把其他机架也带回旧参数？正在提交份额的机器会不会集体重启？这些问题如果平时没验证，事故现场就没人敢拍板。
后来我们把回退拆成三层。
第一层是配置回退。只恢复矿池地址、参数和策略，不动软件二进制，不动钱包映射，不动机器标签。适合误改配置、策略测试失败这类情况。
第二层是软件版本回退。挖矿内核升级后出现拒绝率升高、驱动兼容异常、某些机型算力不稳时使用。这里必须保存安装包来源、校验值和适配机型，不能临时从群文件里翻。
第三层是整组回退。包括软件版本、配置版本、启动参数一起退回到某个稳定快照。这个动作影响大，不能随便给普通值班账号权限，必须有明确审批。
回退最怕“看起来能退，实际退不了”。所以每个月至少要找一小组机器做一次演练：从当前版本切到测试版本，再退回稳定版本，记录耗时、掉线时间、收益恢复时间。演练规模不用大，5 到 10 台就够，但一定要覆盖不同机型、不同矿池、不同网络环境。
权限边界要细到动作：能看、能改、能下发不是一回事
挖矿软件后台常见一个问题：账号权限分得太粗。要么只能看，要么就是管理员。这样省事，但风险很高。
实际运维里，权限应该按动作拆开。
能查看算力的人，不一定能修改配置。
能编辑模板的人，不一定能批量下发。
能下发测试组的人，不一定能碰正式组。
能重启单台机器的人，不一定能重启整排机器。
能上传新版本的人，不一定能设为默认版本。
尤其是自动化任务，权限要比手动操作更严。因为自动任务经常跨时间执行，创建人和执行时间不在一起，风险更难被及时发现。比如夜间任务最好限制执行范围，超过一定机器数量必须二次确认；涉及钱包地址、矿池地址、代理地址的变更，应当要求另一名管理员确认；测试标签不能通过自动规则扩展成正式标签。
这里还有一个细节：临时权限必须自动收回。很多事故不是当天授权错了，而是上个月给某个同事开的临时权限一直没关。等他再登录时，自己都忘了手里还有批量下发能力。权限清理不应该靠人想起来，应该每周出一份账号清单，标出长期未登录账号、临时权限到期账号、拥有高危动作的账号。
下一步怎么做：把自动化从“直接执行”改成“带护栏执行”
这次复盘后，我们没有停掉自动化。矿场机器多，靠人工逐台处理不现实。真正要改的是自动化的执行方式。
第一，所有配置模板都加唯一编号。不要再用“新版”“测试版”“备用版”这种模糊名字。编号里要包含日期、适用机型、矿池策略和创建人，看到名字就能大致判断用途。
第二，批量任务下发前做影响预览。系统必须显示将影响多少台机器、分布在哪些机架、是否包含正式收益组、是否涉及钱包或矿池变更。预览结果要保存进账本，不能只在页面闪一下。
第三，给测试配置设置自动失效。凡是测试矿池、测试参数、临时代理，都要写到期时间。到期后要么自动还原，要么进入待确认状态，不能静默保留。
第四，回滚按钮要分级。普通值班可以回退小范围配置，高级管理员才能回退整组版本。回滚前同样要显示差异，告诉操作者会改哪些字段、会不会重启、预计影响多少台。
第五，每次软件升级都绑定配置兼容说明。升级记录里要写清楚：哪些旧参数继续有效，哪些参数被废弃，哪些机型不建议升级。否则版本一多，后面的人根本不知道某个异常是配置问题还是软件问题。
第六，保留操作日志但别只存日志。日志是流水，账本是结论。日志告诉你发生过什么，账本告诉你为什么这么做、现在是否还有效。两者都要有，缺一个都不够。
挖矿软件越自动，运维越不能只靠“熟人经验”。今天发布新配置前，建议矿场先做一个很具体的动作：选出最近一个月所有矿池、钱包、重启策略相关的变更，补成一份配置账本；再挑 5 台机器演练一次配置回退，确认上一版能在 10 分钟内恢复。这个动作不花哨，但能在下一次误下发时，少损失一整晚的收益。
