HiveOS 批量操作最怕范围选错，今天先把整场修改权限收紧

凌晨 2 点 17 分，值班群里连续跳出掉线提醒。现场同事打开 HiveOS，发现原本只准备调整 36 台测试机的 Flight Sheet，被误应用到了同一 Farm 下的 428 台 Worker。十分钟内，大量机器开始重载矿工程序，其中一部分因矿池地址填写错误反复连接，算力曲线像被整齐削掉了一截。

真正让人后背发凉的细节，是执行人并没有越权。他用的是日常维护账号，具备批量修改权限；操作前也看到了确认页面，只是没有再次核对筛选范围。换句话说，系统没坏，账号没被盗，事故来自一次“权限允许、流程也允许”的正常操作。

我是矿场运维负责人。复盘这次事故后，我们没有把责任停在“某个同事粗心”上，而是重做了 HiveOS 的批量管理、告警接收、账号权限和回退流程。因为只要整场操作仍能由一个人在几十秒内完成，下一次出问题的可能是超频参数、钱包地址，也可能是矿工版本。

测试组变成整场范围：批量能力越强，选择范围越要显眼

这次误操作的直接原因，是测试机与生产机长期放在同一个 Farm 中，平时依靠标签筛选。执行人进入 Worker 列表后，以为页面仍保留着测试标签，实际筛选条件已经清空。随后选择全部设备，应用了新的 Flight Sheet。

单机维护时，点错一台通常只是局部损失；批量管理中，范围错误会把一个普通配置问题放大几百倍。HiveOS 提供 Farm、Worker、标签和批量动作，矿场却不能只追求“改得快”，还要让操作对象足够清楚。

我们的改法很直接：

测试机、观察机和稳定生产机拆到不同管理分组，不再只靠临时标签区分。
生产 Worker 的命名加入机房、排位和业务状态，例如 A2-R07-PROD，避免只看编号。
批量变更工单必须写明目标 Worker 数量，操作页面显示数量与工单不一致时立即停止。
超过约定台数的动作，需要第二个人现场核对筛选条件、配置名称和预计影响。
新 Flight Sheet 或新参数先应用于少量固定测试机，观察一个完整周期后再扩大。

最有效的防错方式，往往不是多弹一个确认框，而是让“准备改 36 台，却选中了 428 台”在执行前就显得异常。

算力突然齐降：告警数量多，不代表有人看见事故

事故发生后的三分钟内，HiveOS 已经出现多项异常：Worker 掉线、矿工程序重启、算力下降、矿池连接失败。问题在于，这些提醒混在平时的温度波动、单卡掉线和网络抖动消息中，值班人员一开始把它们当成普通告警。

过去我们的设置偏向“有问题就报”，导致一个故障可能产生几十条重复消息。久而久之，值班人员会先静音，再慢慢排查。对于批量配置事故，这种习惯非常危险，因为损失按照设备数量和持续时间同时扩大。

流程改造后，我们把提醒分成三种：

第一种是单机异常，例如一台 Worker 短时掉算力，进入普通巡检队列。

第二种是同组聚集异常。如果同一机房、同一标签或同一配置组在五分钟内出现多台重启，就提升告警级别，直接通知当班负责人。

第三种是变更后异常。任何批量操作完成后的十五分钟内，只要出现算力集中下降、拒绝连接或大面积重启，就默认与刚才的变更相关，暂停后续扩容。

我们还取消了“告警已发送即算处理”的做法。高等级提醒必须有人确认接单，记录开始排查的时间；超过三分钟没人回应，自动通知第二联系人。告警的价值不在于消息发出去多少条，而在于谁接手、多久接手、接手后采取了什么动作。

夜班账号可以改全场：这类权限配置本身就是隐患

复盘账号时，我们发现值班人员为了方便处理故障，普遍拥有修改 Flight Sheet、调整超频模板、重启 Worker 和执行批量命令的能力。这样的配置白天看起来效率很高，夜间却等于把全场操作集中在一个账号上。

权限改造不能只分“能登录”和“不能登录”。矿场至少要把日常查看、单机处置、小组变更、整场修改和账号管理拆开。

普通值班账号只保留查看状态、确认告警和处理指定设备的权限；能够修改生产配置的账号由班组负责人掌握；整场批量变更需要临时授权，任务结束后立即收回。外部维修人员只开放对应机位和限定时段，不能看到钱包相关配置，也不能接触其他客户的 Worker。

我们同时清理了共用账号。以前现场为了交接方便，几个人共用一套登录信息，出了问题只能知道“这个账号执行过”，无法确认具体操作者。现在每个人使用独立账号，开启双重验证，离职、换岗和外包结束当天完成权限回收。

权限收紧会增加一点沟通成本，但它能把一次手滑限制在十几台机器，而不是让错误直接覆盖整个矿场。

回退时找不到旧参数：没有保存现场，就谈不上快速恢复

事故确认后，我们本想立即恢复旧 Flight Sheet，却发现此前的配置名称多次复用，几份内容相近的模板无法快速判断哪一份正在生产环境运行。矿工版本、矿池备用地址和部分超频参数也散落在不同聊天记录里。

最终恢复耗时，比定位原因更久。

从那以后，每次生产变更前，我们都会保存一份回退包，内容包括：

变更前使用的 Flight Sheet 名称及完整配置；
矿工程序版本和主要启动参数；
钱包别名、矿池地址及备用地址；
对应机型的超频模板；
涉及的 Worker 清单；
执行人、审核人和计划时间；
明确的回退触发条件。

其中最关键的是触发条件。不能等执行人凭感觉判断“好像不太对”。例如，测试组算力低于变更前均值一定比例并持续十分钟、拒绝连接数量超过约定值、重启次数异常增加，就停止扩散并恢复旧配置。

回退也要演练。只把旧参数存下来，却从未验证能否重新应用，出事时仍可能遇到版本不兼容、模板对应错误或者账号无权执行。我们现在每月抽一个低风险时段，选择少量测试机走一遍变更与恢复，确认配置可用、权限有效、记录找得到。

行情反弹想临时切换：收益预期不能绕过变更纪律

行情波动时，矿场最容易出现临时任务：更换币种、调整矿池、升级矿工程序，或者为了多挤一点算力修改参数。指令往往来自群聊，一句“先全场切过去看看”，就可能跳过测试和审核。

运维负责人需要顶住这种催促。几分钟的理论收益，无法覆盖几百台设备重启、拒绝连接甚至长时间离线的损失。

我们给紧急变更设了四个最低条件：操作对象明确、旧配置已保存、至少一人复核、现场有人能执行回退。任何一项不满足，都只能先做小规模验证。即使业务方要求马上切换，也必须保留测试组，不允许第一次操作就覆盖全场。

这套规则并不会拖慢真正的紧急处理。相反，当每个人都知道哪些资料必须准备、谁负责批准、何时立即撤回，执行速度通常更快，也不需要在事故发生后翻聊天记录猜测原状态。

复盘只写一句操作失误：同样的问题还会再次发生

事故报告如果只写“员工未认真核对”，下一次无非是换一个人犯错。有效复盘必须继续追问：为什么测试机与生产机混在一起？为什么一个值班账号能改 428 台？为什么批量操作后没有专项观察？为什么旧配置无法立即找到？

我们现在要求每次较大故障都留下四类记录：发生了什么、系统当时显示了什么、人员实际做了什么、哪项规则没能挡住错误。整改项必须对应负责人和完成日期，不能只写“加强培训”。

这次事故后，我们最终完成了六项具体改动：测试与生产分组隔离；生产账号分级；批量操作双人复核；变更后十五分钟专项监控；旧配置统一归档；每月执行一次回退演练。

今天使用 HiveOS 管理矿场，最该检查的并不是面板上还有多少告警，而是日常账号能一次修改多少台 Worker。建议运维负责人立刻做一次权限盘点：列出所有可执行批量动作的账号，删除共用登录，限制外包人员范围，并随机抽取一份生产配置验证能否在十分钟内恢复。能把这四件事做完，下一次误操作就更可能停在测试组，而不会扩散到整场。