挖矿软件的自动化越深，配置版本越要像账目一样逐笔留痕

凌晨 2 点 17 分，一名值班人员准备给 12 台测试机下发新的功耗参数。他在运维工具里选择了“测试组”，确认页面显示 12 台，随后点击执行。两分钟后，184 台机器陆续重启，矿池侧有效算力快速下滑，拒绝率也开始抬头。

问题出在一个不起眼的标签条件：测试组原本按“机型+机架”筛选，当晚有人修改资产标签时漏填了机架字段，软件便把同机型设备全部纳入目标范围。自动化任务忠实执行，没有报错，也没有中断。

值班人员想恢复上一版配置，却发现所谓“上一版”只保存了参数文件，没有保存对应的挖矿软件版本和启动参数。旧配置加载到新版本后，两个字段无法识别，部分机器因此陷入反复拉起、退出、再拉起的循环。

这次事故没有损坏硬件，损失也只持续了十几分钟，但它暴露了一个越来越常见的问题：矿场自动化做得越快，越不能靠聊天记录、文件名和个人记忆管理配置。

发生了什么：一次小改动为何扩散到整批设备

从执行记录看，自动化系统的每一步都符合预设逻辑：读取标签、生成设备列表、写入参数、重启进程、检查在线状态。真正的缺口出现在执行之前。

第一，目标设备列表是动态生成的。操作人员在确认页面看到 12 台，但提交任务时系统重新计算了一次标签，范围已经发生变化。页面预览与实际执行使用的并非同一份清单。

第二，任务只设置了“执行成功率”，没有设置影响数量上限。184 台设备同时接受命令时，系统没有要求二次确认，也没有因为数量异常自动暂停。

第三，自动恢复策略只检查挖矿进程是否在线。进程能够启动，就被视为恢复成功；矿池是否收到有效份额、拒绝率是否异常、机器是否反复重启，都没有被纳入判断。

事故表面看像标签填错，实际是配置、版本和执行范围之间缺少固定关系。只要其中一个对象可以在任务提交后继续变化，批量自动化就可能把一处小失误迅速放大。

容易误判的地方：面板显示正常，配置未必真的生效

运维工具管理员最容易踩的坑，是把“命令已完成”当成“生产已恢复”。

挖矿软件返回运行状态，只能说明进程还活着。配置是否按预期加载，需要继续核对启动日志、实际功耗、频率、矿池连接、有效份额以及拒绝率。尤其在版本升级之后，字段改名、默认值变化和参数弃用都可能造成静默偏差。

例如，旧版中的功耗限制字段在新版里被拆成两个选项。软件没有直接退出，只是采用默认值运行。面板上的机器仍显示在线，电表侧却出现明显波动。若运维只盯在线率，这类问题可能持续几个小时才被发现。

因此，每次配置发布都应留下生效证据。至少要记录抽样设备的启动摘要、发布前后功耗差值、十分钟有效算力和矿池拒绝率。恢复判断也要有明确口径：进程在线只是第一项，不能单独作为结束事故的依据。

“恢复上一版”常常靠不住，因为上一版没有被完整保存

不少矿场的版本管理仍停留在文件命名上，比如“稳定版”“稳定版2”“最终版修复”。这些名字无法回答三个关键问题：它当时运行在哪个软件版本上，使用了哪套启动参数，又覆盖过哪些机器。

可用的回退版本应当是一组相互匹配的对象，包括：

• 挖矿软件安装包及文件校验值；
• 配置文件和配置格式版本；
• 启动命令、环境变量与插件版本；
• 驱动或运行镜像版本；
• 适用机型、设备清单和矿池地址；
• 发布后的验证结果。

任何一项缺失，都可能出现“文件回去了，运行环境没回去”的情况。尤其是配置格式升级后，简单覆盖旧文件很容易触发字段不兼容。

版本回退也不能在事故发生时才第一次尝试。运维工具管理员应定期挑选少量机器演练，确认旧安装包仍可获取、校验值一致、启动脚本可执行，矿池能够正常接收份额。一次真实演练，比保存十份压缩包更有价值。

配置账本该记什么：重点是能回答谁改了哪一台

配置账本不需要做得复杂，但每次变更必须形成不可覆盖的记录。建议给每次发布生成独立编号，例如 C-日期-序号，并绑定以下内容：

• 申请人、审核人和实际执行账号；
• 变更原因及对应工单；
• 固定设备清单，不能只保存动态标签；
• 修改前后的字段差异；
• 软件包版本、校验值和配置格式；
• 计划执行时间、实际开始时间与结束时间；
• 分批结果、异常设备和处置动作；
• 可回退的目标版本编号。

钱包、矿池密码和接口密钥不应直接写进账本，可以记录密钥引用编号。这样既能追踪当时调用了哪项凭据，也不会让查看变更记录的人顺手获得敏感信息。

账本还要禁止事后覆盖。发现填写错误时，应追加更正记录，并保留原内容。否则复盘时看到的只是被修饰过的结果，无法还原当时的真实判断。

权限边界要落到按钮和设备范围上

共享管理员账号是配置治理中最危险的省事做法。它让操作速度变快，却让责任、审批和执行范围全部混在一起。

比较稳妥的做法是拆分角色：配置人员可以创建草稿和查看差异，但不能直接发布；值班负责人可以批准指定机房的小批量任务，却无权修改钱包地址；应急账号能够暂停任务和恢复已批准版本，但不能上传新软件包。

自动化接口同样需要限权。负责读取状态的令牌不应拥有重启权限，用于测试组的令牌不能操作生产组。临时应急权限应设置较短有效期，启用多因素验证，并完整记录调用来源和执行对象。

尤其要限制三个高风险动作：修改收益地址、更换矿池端点、向大批设备下发自定义脚本。这些操作应强制双人确认，且不能由同一账号同时提交和批准。

下一步怎么做：给自动化加上可停止的条件

自动化的价值在于减少重复劳动，但批量任务必须有明确的刹车条件。

发布时可以按 3 台、20 台、20%设备、全部设备的顺序推进。每一批完成后观察固定时间，核对进程退出次数、有效算力、拒绝率和功耗偏差。任一指标越过阈值，任务应自动暂停，等待人工判断，不能默认继续扩散。

系统还应在提交时锁定设备清单。若预览数量和执行数量不一致，直接拒绝任务。超过日常批量规模时，要求再次输入设备数量确认，而不是只弹出一个容易被顺手点掉的提示框。

对版本升级，则应把软件包、配置和启动方式作为同一个发布单元。哪怕只改一个参数，也要生成新版本号和差异记录，避免出现多人同时编辑同一份“当前配置”。

今天就可以完成四个动作：导出生产设备的实际配置并生成一份基准版本；冻结所有共享管理员账号；给批量任务设置设备数量上限；选 3 台非关键机器做一次完整回退演练。演练结束后，把耗时、失败点和人工步骤写进配置账本。

挖矿软件可以自动切池、自动调参、自动重启，但每一次自动执行都应能查清来源、锁定范围，并在几分钟内退回经过验证的版本。做到这一点，自动化才是在减少值班压力，而不是把一次误点变成全场事故。