文章目录
挖矿软件的运维重心正在从会自动跑转向每次改动都能查清楚
凌晨 1 点 17 分，值班手机连续震了 6 次。面板上看，A 区 43 台机器算力从正常区间掉到一半，风扇转速没异常，矿池也没有大面积拒绝。最开始大家以为是网络抖动，重启了两台做样本，结果算力没有恢复，反而又多了几台显示“配置已更新”。最后查到原因很简单：一个自动切换脚本拿到了错误的配置模板，把备用矿池地址推给了本不该切换的机器，同时把部分机器的显存参数也带着改了。
这类事故不大，却很烦。它不会像断电那样一眼看明白，也不会像矿池宕机那样全场一起掉。它更像一条细线，从几台机器开始，把收益、排障、责任归属都拖慢。作为运维工具管理员，我现在越来越觉得，挖矿软件真正难管的地方，已经不是能不能自动启动、自动切池、自动重启，而是每一次自动动作背后有没有账本、有没有版本、有没有边界。
发生了什么：自动化脚本把“临时策略”当成了正式配置
这次问题发生前，运维组做过一次小调整：因为某个币种收益短时抬高，计划让少量测试机器在夜间切到另一套矿池组合，观察 6 小时后再决定是否扩大范围。按流程，这应该只影响测试分组。
问题出在配置模板的命名和权限上。
当时系统里有两套模板，一套叫 A 区日常配置，一套叫 A 区测试配置。脚本读取配置时，按照标签匹配了 A 区，但没有继续校验“测试组”这个条件。更麻烦的是，测试模板里为了压功耗，显存、功耗限制和重启阈值都和日常配置不同。脚本推送以后，机器没有立刻全部掉线，只是逐步出现拒绝率升高、算力波动、部分设备自重启。
从面板上看，这不像一次配置事故。因为温度正常、在线率正常、矿池连接也通。真正暴露线索的是日志里那句“配置已更新”，但这句日志没有显示是谁触发、用了哪个模板、模板相比上一个版本改了哪些字段。
这就是挖矿软件自动化最常见的坑：它把动作做得很快，却没有把动作说明白。
如果矿场只有十几台机器，人可以靠记忆补上细节。可一旦机器规模上来，配置模板、矿池地址、钱包标签、算法参数、重启规则、超频曲线都开始变多，靠群消息和个人习惯来管理，迟早会遇到这种“没人说不清到底改了什么”的时刻。
容易误判的地方：算力掉了，不一定先查硬件和矿池
很多一线值班遇到算力下滑，会按老路径排查：看温度、看网络、看矿池、看电源、看机器日志。这些都没错，但在自动化工具越来越多之后，还要把“配置变更”提前放进排查顺序。
这次事故里，最耽误时间的判断有三个。
第一个误判，是把局部掉算力当成机器老化。A 区本来就有几台机器风扇噪音偏大，值班同事看到它们先掉，就自然联想到硬件问题。但真正原因是它们所在的小组刚好先被脚本扫描到。
第二个误判，是只看当前配置，不看配置来源。面板里能看到矿池地址、算法、功耗限制，却看不到这些值是手工改的、脚本推的，还是继承自某个模板。当前值正确不代表过程正确，当前值错误也不代表是最后一个操作人造成的。
第三个误判，是把回滚当成重新推一遍旧参数。很多人说“恢复到昨天那套配置”，实际操作时却是从聊天记录里复制矿池地址，再手动填一些参数。这种回滚不是真回滚，只是凭印象重建。只要漏掉一个字段，比如重启阈值、设备分组、备用矿池优先级，就可能埋下下一次问题。
挖矿软件管理到今天，最大的变化是：配置本身已经变成资产。它和矿机、机架、电价一样，会直接影响收益。既然是资产，就不能只存在某个人的脑子里，也不能只存在一个可编辑页面里。
配置账本要记什么：不是多写日志，而是能还原现场
很多工具都有日志，但日志和账本不是一回事。日志常常是系统自己说“我做了什么”，账本则要回答运维最关心的几个问题：谁批准的、谁执行的、改了哪里、影响哪些机器、能不能退回去。
一套能用的配置账本，至少要记录五类信息。
第一类是配置版本。每个模板都要有版本号，不能只靠“最新版”“测试版”这种名字。比如 A 区日常配置 2026-04-28-01，看到名字就知道日期和序号。版本号不一定复杂，但必须唯一。
第二类是字段差异。矿池地址改了、钱包地址改了、算法参数改了、功耗限制改了、重启策略改了，都要能一眼看出差别。只记录“配置已更新”没有意义，排障时没人知道更新了什么。
第三类是影响范围。配置推给了哪一组、哪几台机器、是否包含离线机器、离线机器上线后会不会补推，这些都要写清楚。很多事故不是当场爆发，而是离线机器第二天上线后继续接收旧指令。
第四类是触发来源。手工点的、定时任务跑的、收益策略触发的、API 调用的，都要分开记。自动化越多，越不能把所有动作都写成“系统执行”。
第五类是审批记录。不是所有改动都要层层审批，但涉及钱包地址、矿池切换、大范围功耗参数、批量重启的动作，至少要有二次确认。哪怕是两个人在工具里点确认，也比在群里回一句“可以”清楚得多。
配置账本的价值，不在于平时看起来多规范，而在于出事后十分钟内能判断：这是硬件问题、矿池问题，还是我们自己推错了。
版本回滚要练：能退回上一版，才算敢自动化
自动化最怕只有前进按钮，没有后退按钮。很多挖矿软件功能做得很满，能按收益切矿池，能按温度调参数，能按掉线次数重启，但一旦推错配置，回滚就变成临时手工活。
真正可用的版本回滚，至少要满足三个条件。
第一，回滚对象要明确。是回滚整套模板，还是只回滚矿池地址？是回滚某个分组，还是回滚全部机器？如果工具只能“一键恢复默认”，那对矿场来说往往不够用，因为默认配置未必是昨天能赚钱的配置。
第二，回滚前要做影响预览。比如将有 43 台机器从版本 04-28-02 回到 04-27-05，其中 5 台当前离线，12 台正在执行收益切换策略。没有预览，回滚也可能变成二次事故。
第三，回滚后要验收。不能只看命令发出去了，还要看机器是否应用成功、算力是否恢复、拒绝率是否下降、矿池端是否看到正确 worker。尤其是混合机型或多算法矿场，同一套配置在不同机器上的表现可能不一样。
我建议矿场每周做一次小范围回滚演练。选 5 到 10 台非核心机器，先推一版无风险配置，比如调整备注、切换备用矿池顺序，再按流程回滚。重点不是折腾机器，而是确认工具能不能完整记录、能不能预览影响、能不能验证结果。
如果一次演练都做不顺，行情剧烈波动时就不要轻易把自动切换范围放大。
权限边界要收窄：能看面板的人，不该都能推配置
挖矿软件的账号权限，经常被低估。很多矿场为了方便，让值班、财务、外包维护、老板账号都能进同一个面板。早期机器少时问题不明显，等脚本、API、批量任务接进来以后，一个权限过大的账号就可能改动全场。
权限边界不需要搞得很复杂，但要分清几种角色。
值班人员可以看状态、重启单台、暂停异常任务，但不应直接批量修改钱包和矿池地址。
策略人员可以创建收益切换方案，但方案生效前需要另一个角色确认范围。
工具管理员负责模板、脚本、API 密钥和版本管理，但日常不直接改钱包收款信息。
财务或资产负责人可以查看收益地址和结算记录，但不应该拥有批量推送运行参数的权限。
外包维护如果必须接入，只给临时权限、限定机器组、限定时间，到期自动失效。不要把长期管理员账号发给外部人员，也不要让一个 API 密钥拥有所有操作能力。
尤其要注意脚本权限。很多事故不是人点错，而是脚本拿到的权限太大。一个只负责读取算力数据的脚本，不应该能推配置；一个只负责重启异常机器的脚本，不应该能改钱包地址。权限收窄以后，即使脚本写错，影响范围也会小很多。
下一步怎么做：把今天能补的三件事先落地
如果现在就要改进挖矿软件运维，我不建议一上来更换整套系统，也不建议把所有流程写成几十页文档。更现实的做法，是先补三个最容易落地的动作。
第一，清理配置模板。把所有正在使用的模板列出来，删掉过期测试模板，改掉含糊命名。凡是名字里只有“新配置”“临时”“备用”的，都要改成能看懂用途、区域、日期的名称。模板越乱，自动化越容易误伤。
第二，开启或自建配置账本。工具支持差异记录就直接用；工具不支持，就先用工单或协作文档补一层。每次改动必须写版本、范围、原因、执行人和回滚版本。不要嫌麻烦，真正出一次事故，这些记录能省下半夜排查。
第三，做一次权限体检。把账号列表、API 密钥、脚本任务全部过一遍，看看谁能批量改配置，谁能改钱包，谁能执行重启。离职人员、外包旧账号、没人认领的密钥，今天就该停掉。权限不是等被盗以后才收，是平时就应该够用但不过量。
挖矿软件会继续自动化，这是趋势，没人愿意回到一台台手工改参数的日子。但自动化跑得越快，越要让配置有账、版本能退、权限有边。对运维工具管理员来说，今天最该做的不是再加一个脚本，而是打开后台，把最近 30 天的配置改动导出来，看看能不能说清楚每一次是谁改的、改了什么、能不能退回去。能说清楚，自动化才是真的省事；说不清楚，它只是把事故发生的速度变快了。
