文章目录
今天最容易让矿场停成一片的是 HiveOS 批量操作没设刹车
凌晨两点十七分，我在值班群里看到第一条截图：A 区 3 排的 28 台机器算力同时掉到零，风扇转速还在，温度没有异常。值班员第一反应是矿池抖动，准备全区重启。我让他先别动，打开 HiveOS 的活动记录，时间往前拉了八分钟，看到一个批量 Flight Sheet 切换任务，目标原本是 12 台测试机，实际勾选了整个 A 区 worker 组。
这类事故在矿场里并不新鲜，但每次都很贵。它不像单台矿机掉线，拔插网线、换电源、重刷系统还能慢慢修；批量操作一旦打到错误范围，几十台、几百台机器会在同一时间进入错误状态。更麻烦的是，面板上看起来只是“离线”“无算力”“重启中”，真正的原因藏在谁点了按钮、选了哪个组、系统有没有保留旧配置、告警有没有及时分级。
今天写 HiveOS，我不想再从功能介绍讲起。作为矿场运维负责人，我更关心一件事：系统越方便，越要给误操作留刹车。批量管理、告警、权限、回滚这些东西，平时看着像管理细节，出事时就是矿场能不能少停两个小时的差别。
夜班改配置误选整组，判断是批量权限没有边界
这次事故的直接动作很简单：夜班值班员要把 12 台新换显卡的机器切到测试矿池，验证驱动和超频参数。HiveOS 里 worker 组命名比较相近，一个叫 A3-Test，一个叫 A3-All。值班员在手机上操作，屏幕小，点进批量修改时没有二次确认目标数量，最终把整个 A3-All 切了过去。
从日志看，系统并没有坏，HiveOS 也没有执行错。问题在我们自己的权限设置：夜班账号拥有整个矿场分组的批量修改权，但他的值班职责只需要处理单机重启、查看告警、执行预设脚本。换句话说，他本来不该有“给一整排机器换配置”的能力。
事故复盘会上，我没有追着问“为什么你点错了”。人一定会点错，尤其是夜里、手机、小屏、告警同时响的时候。更该问的是：为什么点错以后能直接生效？为什么目标从 12 台变成 86 台时，没有任何拦截？为什么测试组和生产组的命名靠肉眼区分？
后来我们把 HiveOS 账号重新拆了四类。
第一类是只读账号，给老板、财务、外部合作方看算力和在线率，不允许改钱包、不允许改 Flight Sheet、不允许重启。
第二类是值班账号，可以处理单台机器的 reboot、miner restart、查看日志、标记故障，但不能跨组批量改矿池、钱包、超频模板。
第三类是班长账号，可以对指定区域做批量动作，但必须使用提前保存好的模板，不能临时新建钱包地址和矿池配置。
第四类才是管理员账号，只有两个人持有，用硬件密钥和独立邮箱登录，平时不在值班电脑上使用。
这件事改完后，操作效率确实慢了一点。以前夜班一个人可以干很多事，现在有些动作要找班长确认。但矿场运维不能只看“点几下能完成”，还要看“点错一下会损失多少”。HiveOS 的批量管理很适合规模化矿场，前提是批量权限不能发给所有人。
告警群半小时刷屏，判断是通知太多反而没人接单
事故发生时，微信群里一共跳了 217 条消息。掉线告警、低算力告警、矿池拒绝率告警、温度恢复告警混在一起，值班员看到的是一团红字。最关键的那条“批量任务已执行完成”反而没人注意，因为它不是异常告警，只是一条普通操作记录。
很多矿场把告警理解成“有消息就行”，这是不够的。真正能救命的告警，要让人一眼知道三件事：影响范围多大，优先级多高，谁负责处理。
我们后来把 HiveOS 告警重新分层。单台机器 5 分钟无算力，只推到区域值班员；同一分组超过 10% 机器同时掉算力，推到班长和运维负责人；同一区域在 3 分钟内出现批量配置变更，再叠加算力下跌，直接触发事故级通知，不再和普通温度告警混在一个频道。
还有一个细节很重要：告警不能只说“掉线”，要带上最近一次变更。比如机器掉算力前 10 分钟内是否换过 Flight Sheet，是否执行过 Shell 命令，是否改过超频，是否更新过 miner 版本。否则值班员只能按老习惯从网络、电源、矿池一路猜，时间全浪费在错误方向上。
我们现在的值班要求是，看到 HiveOS 大面积告警后，不允许第一步就重启全区。必须先看三项记录：最近批量任务、最近账号登录、最近模板修改。如果这三项里有动作，优先按“人为变更事故”处理；如果没有，再去查网络、矿池、供电和机房环境。
告警的价值不在于吵醒多少人，而在于把第一个正确动作推到人面前。矿场夜班最怕的不是没人看手机，而是大家都在看手机，却不知道该先做什么。
测试机正常生产机翻车，判断是灰度范围没有写死
这次切换事故还有一个被忽略的前因：测试机确实跑正常了。白班在 12 台机器上测试过新版 miner，半小时内算力稳定，拒绝率也低，于是夜班才敢继续扩大。可问题在于，新版 miner 对不同批次显卡的表现差异很大，测试组刚好是同一批卡，生产组里混了三种显存颗粒和两版 BIOS。
HiveOS 做批量部署很方便，方便到有时候会让人忘记“测试通过”到底通过了什么。12 台测试机通过，只能说明这 12 台通过，不能证明整排机器都适合。
复盘后，我们给灰度发布设了硬规则。任何 miner 版本、驱动版本、超频模板、矿池策略变更，都必须按 5 台、20 台、一个小组、一个区域的顺序推进。每一档至少跑满两个统计周期，一个看短时算力，一个看拒绝率和重启次数。没有记录截图和日志编号，不能进入下一档。
更具体一点，我们要求测试组里必须包含老卡、新卡、高温位、弱网位和历史故障机。以前大家喜欢拿“最干净”的机器做测试，跑出来的数据很好看，但对生产环境帮助不大。矿场里最容易出事的，恰恰是那些风道差一点、网线接头松一点、电源老一点的机器。测试不覆盖这些位置，批量上线就是撞运气。
HiveOS 的标签功能可以派上用场。我们把机器按显卡批次、机架位置、网络交换机、历史故障类型打标签。以后做批量修改，不再只按“一区、二区”这种大分组来选，而是先用标签筛一遍，确认这批机器硬件条件相近，再执行模板。这样做麻烦一些，但能减少“测试没问题，一放大就崩”的情况。
回滚文件找不到，判断是恢复动作没有提前演练
事故最难看的部分，发生在恢复阶段。我们想把 A 区机器切回旧配置，结果发现旧 Flight Sheet 有两个版本，名字都叫 ETH-Backup，其中一个钱包地址还是去年淘汰的结算地址。超频模板也有类似问题，A3-OC-old、A3-OC-final、A3-OC-final2 放在一起，没人敢马上判断哪个才是事故前版本。
最后我们靠活动记录一台台对，比预期多花了四十多分钟。四十分钟在矿场里很长，尤其是行情波动大的时候，机器空转、电费照跑，矿工的心态也会跟着坏。
这件事之后，我把“回滚”从一个口头动作改成了固定流程。每次批量变更前，必须做三件事。
第一，导出或截图当前 Flight Sheet、钱包、矿池、超频模板和 miner 版本，保存到当天工单里。
第二，提前准备一个明确命名的回滚模板，名称里写日期、区域、负责人，例如 0428-A3-Rollback-Li，不再使用 old、final 这类模糊词。
第三，指定回滚触发条件，比如 15 分钟内算力低于变更前 92%，拒绝率高于 3%，同组重启超过 5 台，就停止继续扩大并执行回滚。
我们还每周做一次小规模演练，选 3 到 5 台非关键机器，模拟错误配置上线，再按工单把它们切回来。演练的目的不是证明大家会点 HiveOS，而是确认文档里的步骤真的能用，账号权限够不够，模板有没有过期，值班员能不能在十分钟内找到正确文件。
很多矿场把回滚当成“出事再说”。但出事时人会紧张，群里会催，老板会问损失，机器还在掉算力。那时候再去找旧配置，基本就是拿时间换教训。回滚要在变更前完成，变更后才想起来，已经晚了半拍。
外包协助临时登录，判断是账号借用留下了盲区
事故排查时，还有一个小插曲。活动记录里出现过一次陌生 IP 登录，时间在事故前一天晚上。后来查清楚，是外包技术协助处理一批驱动问题，现场同事把自己的账号密码发给了对方。对方没有参与这次误操作，但这件事暴露的问题更严重：如果以后真的发生恶意修改，我们可能连责任人都对不上。
HiveOS 在矿场里常常不只运维团队使用。老板要看，财务要核算，外包要维护，矿池商务有时也会协助排查。账号一旦共用，所有操作记录都会失去意义。日志显示“张三修改了配置”，实际可能是外包、夜班、甚至离职员工在用张三账号。
我们现在禁止账号借用。外包进场必须单独开临时账号，只开放指定 worker，只保留当天有效期，只允许执行约定动作。处理完毕后，班长检查活动记录，确认没有改钱包、矿池和批量模板，再关闭账号。
同时，所有管理员账号都开启二次验证，登录邮箱不和日常聊天软件共用。离职、换岗、外包项目结束，当天必须回收权限。这个要求听起来像公司制度，但对矿场来说就是资产安全。矿机硬件摆在机架上，看得见；HiveOS 账号藏在浏览器里，出问题时影响范围可能更大。
权限管理的核心不是不信任谁，而是不把任何一个人的失误放大成全场事故。每个人只拿自己班次、自己区域、自己职责需要的权限，出了问题也能把损失圈住。
白班复盘只看损失，判断是流程不改还会再犯
事故当天上午，我们统计了三组数字：A 区平均停算力 54 分钟，错误配置影响 86 台机器，恢复后仍有 7 台需要人工处理。按当日电价和收益估算，直接损失不算夸张，但它提醒我们，矿场真正危险的事故，往往不是设备坏了，而是流程让错误一路畅通。
复盘会我要求只谈事实，不谈情绪。谁在几点登录，点了什么，系统怎么提示，告警什么时候发出，谁接手，回滚用了多久，每一步都写清楚。最后形成了六条改造动作，今天也可以给正在用 HiveOS 的矿场做参考：
批量操作前，必须截图目标 worker 数量，超过 20 台需要班长确认。
测试组和生产组命名拉开差异，不再使用容易混淆的缩写。
夜班账号取消跨区域批量修改权限，只保留单机处置和预设脚本。
告警分频道，普通故障、批量变更、事故通知分开推送。
每次变更前创建回滚模板，工单里写清触发条件。
每周抽一次回滚演练，记录完成时间和卡点。
HiveOS 本身能提供很多工具，但工具不会替矿场承担管理责任。批量管理可以省人，告警可以提速，权限可以收口，回滚可以止损；这些东西只有写进班次流程、账号规则和工单记录里，才真的有用。
今天如果只做一个动作，我建议矿场负责人马上打开 HiveOS，检查夜班账号和外包账号的权限范围，再随机找一条最近的批量操作记录，看能不能在五分钟内找到对应的回滚模板。找不到，就别等下一次事故来提醒你。
