文章目录
挖矿软件的自动化正在从会执行变成会留账
昨晚 1 点 18 分，值班群里跳出一条很短的消息：“B 区 47 台机器算力掉到 0，矿池还在线。”
第一反应当然是查网络，第二反应是查矿池延迟。等我远程进去看，发现问题不在网，也不在矿池，而是一条自动下发的配置把矿工名里的后缀改错了。机器还在跑，风扇也正常转，面板上甚至有本地算力，但矿池侧识别不到正确账号，收益直接断了 26 分钟。
这类事故过去常被归到“手滑”或者“脚本写错”。但站在运维工具管理员的角度看，它暴露的是另一件事：挖矿软件越来越会自动执行，配置治理却没有跟上。自动化本身没有错，错的是它跑得太快，而账本、版本和权限还停在人工记忆里。
今天再看挖矿软件，不能只问它能不能批量改参数、能不能自动切矿池、能不能按温度调功耗。更该问三件事：这次改了什么、谁允许它改、出错后能不能按分钟级退回去。
事故复盘：一条配置为什么能影响几十台机器
这次问题的起点很普通。夜班同事收到矿池延迟波动提醒后，准备把 B 区一组机器临时切到备用地址。我们的挖矿软件支持按标签批量下发配置，机器原本按机架、币种、矿池、功耗档位打了几组标签。
问题出在标签选择上。
B 区这批机器里，有一部分使用的是新命名规则，矿工名由“区域编号+机架号+机器序号”组成；另一部分还沿用旧规则，矿工名后缀包含维修批次。自动化模板在生成配置时默认覆盖了矿工名字段，没有保留旧规则后缀。结果是：矿机端配置看起来完整，矿池地址也正确，但矿池侧无法把提交的份额归到原账号下。
这类问题最烦的一点是，面板不会立刻红成一片。机器还在运行，本地有算力，温度也稳定。只有对矿池侧的有效份额和账号识别做核对，才会发现收益没有进来。
后来我们翻记录，发现当晚实际发生了三次动作：
第一次是测试组切换，影响 5 台；
第二次是批量扩展到整排，影响 47 台；
第三次是值班同事手动把部分机器改回。
真正拉长停损时间的不是第二次误下发，而是第三次手动修复没有完整记录。等白班接手时，已经分不清哪些机器回到了旧配置，哪些只是矿池地址改回来了，哪些矿工名仍然不对。
容易误判的地方：面板正常，不等于配置正确
很多矿场在用挖矿软件时，最容易把“在线”和“正确”混为一谈。机器在线，只说明进程还活着；算力显示正常，只说明本地计算还在跑；矿池能连上，也不代表收益路径没有偏。
配置问题往往藏在几个很细的字段里。
比如矿工名、钱包地址、矿池备用顺序、抽水地址识别、SSL 开关、代理端口、超频档位、重启策略。这些字段中任何一个被模板覆盖，都可能让矿机继续工作，但收益、稳定性或后续维护出现偏差。
更麻烦的是，自动化系统通常会把“执行成功”当成“任务成功”。脚本下发到位，服务重启完成，软件就显示绿色；但它并不会天然知道矿池侧是否收到有效份额，也不会自动判断收益是否进入正确账户。
所以，运维工具管理员不能只盯任务状态，而要把配置结果和外部结果对上。对挖矿软件来说，真正有效的检查至少要跨过三层：机器本地配置、挖矿进程日志、矿池侧统计。少看一层，就可能把问题放过。
这也是很多小事故会拖成大事故的原因。大家以为是网络抖动，反复重启；以为是矿池异常，频繁切换；以为是单机故障，逐台排查。最后才发现，源头是一条配置模板把几十台机器带偏了。
配置账本要记什么：别只留“谁点了按钮”
过去做运维记录，很多团队会写一句“某某在 1 点 20 分切换备用矿池”。这句话看似有记录，其实不够用。真正排障时，需要的是一份能还原现场的配置账本。
这本账至少要包含六类信息。
第一，变更前的完整配置。不是只记矿池地址，而是把钱包、矿工名、端口、协议、备用池顺序、功耗档位、重启策略都留下来。
第二，变更后的目标配置。自动化模板生成了什么，就要留什么。不要只保存模板名，因为模板后续可能被改，回头再查时已经不是当晚那一版。
第三，影响范围。具体到机器编号、标签组、机架位置，而不是只写“B 区一批”。如果标签是动态的，还要记录执行时标签下包含哪些机器。
第四，触发来源。是人工点击、定时任务、告警联动，还是外部脚本调用。很多事故不是人手动造成的，而是规则在某个条件下自动触发。
第五，校验结果。包括机器端配置读取结果、进程启动结果、矿池侧有效份额是否恢复。只写“下发成功”没有意义。
第六，撤回记录。什么时候回滚，回到哪个版本，哪些机器回滚成功，哪些失败，失败原因是什么。
配置账本不是为了事后追责好看，而是为了缩短下一次排障时间。没有账本，运维只能靠聊天记录、截图和个人记忆拼现场；有账本，至少能快速回答“现在这台机器到底跑的是哪一版配置”。
版本管理的重点：能回到昨天晚上那一版
很多人一听版本管理，会想到代码仓库。矿场未必需要把流程做得很复杂，但挖矿软件的配置版本一定要能保存、对比、回退。
尤其是批量自动化越多，版本颗粒度就不能太粗。只给整套配置起一个名字，比如“B 区稳定版”“ETHW 备用版”，实际用处有限。因为出问题时，往往只想撤回某一个字段，而不是把所有参数都打回旧状态。
比较实用的做法是把配置拆成几层管理。
矿池和钱包是一层，决定收益路径；
矿工名规则是一层，决定账号识别；
功耗和风扇策略是一层，决定机器状态；
重启和故障处理是一层，决定自动化动作；
代理、端口和协议是一层，决定连接方式。
这样回滚时就不会一刀切。比如昨晚的问题，只需要把矿工名规则回到上一版，不必把矿池地址和功耗档位全部撤掉。否则机器刚恢复，又因为功耗档位变化引发温度波动，排障会更乱。
版本管理还有一个容易被忽略的点：回滚也要演练。
很多软件都写着支持回滚，但真正出事时才发现，回滚只能回到上一条任务，不能回到某个具体时间点；或者只能回滚模板，不能回滚已经被人工改过的单机配置；再或者回滚后没有校验，表面成功，实际还有几台机器没吃到配置。
运维工具管理员应该定期做小范围回滚测试。选 3 到 5 台非关键机器，模拟一次矿池切换、一次矿工名变更、一次功耗档位调整，再分别回到旧版。测试不需要多花哨，关键是确认三件事：旧配置拿得到、回滚范围控得住、结果查得到。
权限边界：自动化不能谁都能一键放大
这次事故还有一个管理问题：夜班同事有权限把测试动作扩展到整排机器。这个权限在平时看起来提高效率，但在凌晨排障时，它会把一个小错误放大。
挖矿软件的权限不能只分“管理员”和“普通用户”。更合理的方式，是按动作风险拆开。
查看配置是一类权限；
修改单机配置是一类权限；
批量下发是一类权限；
修改模板是一类权限；
触发自动化规则是一类权限；
回滚和强制重启又是另一类权限。
其中，批量下发和模板修改最好不要落在同一个人手里。一个人可以创建模板，但批量应用到 20 台以上时，需要另一个人确认；夜间值班可以处理单机异常，但跨区域批量操作要有数量上限；自动化规则可以触发切换，但涉及钱包和矿工名字段时必须停下来等待确认。
有人会觉得这样慢。问题是，矿场真正怕的不是慢几分钟，而是快错半小时。尤其在行情波动、矿池拥堵或大规模切换时，错误配置造成的损失往往比人工确认的成本高得多。
权限边界还要包括脚本和接口。很多矿场会把挖矿软件接到自写脚本、监控平台或聊天机器人上。只要这些外部工具能调用配置接口，它们就等于拥有运维权限。接口密钥能改哪些字段、能影响多少机器、有没有过期时间，都应该写清楚，而不是长期放在某台办公电脑里。
下一步怎么做：把自动化改成可核验的流程
如果今天要给矿场的挖矿软件做一次整理，我建议从四个动作开始，不要一上来就大改系统。
第一，把现有配置导出一份基准账本。
按区域、机架、机器编号，把当前矿池、钱包、矿工名、功耗档位、重启策略导出来。先别急着优化，先确认“现在到底是什么样”。这份基准最好每天自动留一份，至少保留 7 到 14 天。
第二，给高风险字段加保护。
钱包地址、矿工名规则、矿池地址、批量重启、自动切换条件，这几类字段不要允许普通批量任务直接覆盖。哪怕软件暂时不支持细权限，也可以用流程补上：涉及这些字段的模板单独命名、单独审批、单独复核。
第三，建立小范围发布习惯。
任何新模板、新脚本、新规则，不要直接上整区。先跑 3 台，再跑 10 台，确认矿池侧有效份额、拒绝率、收益账户都正常，再扩展。自动化不是为了省掉验证，而是为了让验证后的动作更快。
第四，准备两套回滚方案。
一套是软件内的一键回滚，适合模板问题；另一套是离线配置包，适合面板异常、接口失效或软件服务出问题。离线包要标明适用机型、矿池、钱包和日期，别等事故发生后再翻旧文件。
挖矿软件接下来会继续自动化，这是挡不住的。矿场也确实需要自动切换、批量调参、异常自愈来降低人力成本。但从运维工具管理员的角度看，自动化越强，越要把配置账本、版本回滚和权限边界做细。
今天就可以做一个最小动作：随机抽 20 台机器，对照软件面板、实际配置文件和矿池侧账号，查一遍是否一致。查完以后，把这 20 台的配置保存成一版可回退记录。这个动作不复杂，却能很快暴露矿场最常见的问题：机器在跑，但你并不知道它到底按哪一版规则在跑。
