文章目录
HiveOS 批量下发前多看一眼，选错范围可能让整座矿场同时掉算力
凌晨 2 点 17 分，值班室里的 Telegram 连续弹出 186 条告警。A3 机房先出现 GPU 过热，紧接着是算力下降、矿工离线、矿池拒绝率升高。现场人员以为冷风机停了，拿着测温枪跑进机房后才发现，进风温度没有变化，机器风扇却几乎全部拉满。
我打开 HiveOS 后看到一个更麻烦的细节：刚才调整超频参数时，夜班同事选中的不是测试标签，而是整个 Farm。原本只准备下发给 12 台机器的配置，被推到了 600 多台矿机上。
从点击确认到全场告警，前后不到四分钟。
这次事故没有烧卡，但造成两批机器反复重启，部分矿机掉出矿池近半小时。真正暴露的问题也很明确：我们把 HiveOS 的批量管理当成了省时间的工具，却没有按生产变更来约束它。
夜班四分钟全场抖动：批量操作会同步放大人为失误
事故发生前，A3 机房有一批同型号显卡近期功耗偏高。我们计划用新超频模板做小范围测试，目标是降低核心电压，同时调整显存频率。按照原方案，值班人员应该先筛选带有 A3-test 标签的 12 台 Worker，再应用测试配置。
实际操作中，他从搜索结果返回 Farm 页面后，没有重新确认选中对象。HiveOS 保留了更大的操作范围，而他看到机器列表仍在页面上，误以为测试组筛选还有效，随后执行了批量下发。
错误参数落到不同型号的显卡上，结果并不一致：
- 同型号机器可以启动，但算力波动明显；
- 另一批显卡开始报 GPU driver error；
- 少数机器因功耗限制与超频参数冲突，触发看门狗重启；
- 部分矿机在重启后再次加载错误模板，形成“上线—报错—重启”的循环。
当时大家首先处理告警，重启矿机、调整风扇、检查网络，十多分钟后才确认根因是一次错误的批量变更。这里最值得警惕的判断是：矿场规模越大，批量功能节省的时间越多，但误操作造成的影响范围也越大。
点击动作本身没有技术难度，危险在于系统可以忠实、快速地执行一个错误决定。
告警一口气刷满屏幕：消息多不等于问题看得清
这次事故发生后，HiveOS 相关通知迅速涌入值班群。温度、掉卡、低算力、离线、重启等消息混在一起，同一台机器在短时间内重复触发多个异常。值班人员忙着确认设备状态，却没有人第一时间回答三个关键问题：
1. 最早发生变化的是哪一组机器？
2. 异常前是否执行过批量操作？
3. 多类告警是否来自同一个变更？
过去我们按“有异常就发消息”的思路设置告警，优点是不容易漏，缺点是一旦出现群体故障，消息会迅速失去层次。现场人员看到几十条低算力通知，很容易把注意力放在矿池、网络或温度上，而不是查最近一次配置变更。
复盘后，我们重新调整了告警规则。
单台机器短时波动，不立即升级为全场事件；同一标签下多台矿机在五分钟内出现相同问题，则直接提升优先级。低算力与掉卡同时发生时，以掉卡作为主要事件，其余信息合并。看门狗连续触发两次后，不再无限重启，而是进入隔离状态，等待人工确认。
我们还增加了一条很简单但很有效的要求：任何批量下发后的十五分钟内，值班页面必须同时观察在线率、总算力、拒绝率和异常重启数。只看单机是否上线，无法判断配置是否真正稳定。
告警的价值不在于把所有异常都推给人，而在于帮助值班人员尽快找到第一处变化。
共用管理员账号执行变更：查得到记录也未必分得清责任
事故复盘时，我们遇到一个尴尬问题：HiveOS 中能看到相关操作和时间，但夜班几个人长期共用一个高权限账号。究竟是谁选择了范围、谁下发了参数、谁又执行了后续重启，需要靠聊天记录和口头回忆拼接。
共用账号看似方便，交接班时不用申请权限，临时处理也更快。但从矿场运维角度看，它至少带来三类风险。
第一，所有人都能做高影响操作。查看状态的人，也能改钱包、矿池、Flight Sheet、超频模板和整组机器配置。
第二，操作记录无法直接对应到个人。出了问题，只能知道账号做过什么，很难确认当时的执行人和批准人。
第三，账号泄露后的影响过大。浏览器保存密码、远程办公电脑中毒、聊天工具误发凭证，都可能让整个 Farm 暴露。
我们随后取消了夜班共用的所有者账号。日常值班只保留查看状态、处理单机和有限重启所需的权限；批量更换 Flight Sheet、调整大组超频参数、修改钱包地址等操作，必须由更高权限人员执行或复核。
如果现有账号权限粒度无法完全贴合内部岗位，也不能因此继续共享最高权限。可以把审批、身份确认和工单编号放在外部流程中，再用独立账号完成执行。系统功能有边界，管理流程不能跟着放弃。
回滚时只会点重启：恢复动作必须对应错误类型
事故中最耽误时间的动作，是连续重启。
部分矿机因错误超频而不稳定，重启后仍会加载同一份配置。值班人员看到设备重新上线，以为问题已经恢复，几分钟后又收到掉卡告警，于是再次重启。这个循环持续了三轮，既没有消除错误参数，还增加了显卡和系统的反复初始化。
重启只是让设备重新运行，回滚才是让设备回到已验证状态。两者不能混为一谈。
在 HiveOS 运维中，我们现在把可恢复对象拆成几类保存：
- 稳定运行过的 Flight Sheet，包括钱包、币种、矿池和矿工软件组合；
- 按显卡型号、显存类型划分的超频模板；
- 已确认兼容的矿工软件版本与参数；
- 可用的系统镜像或版本记录；
- 每组机器对应的标签、备注和硬件清单。
每次变更前，工单中都要写明“回到哪一版”，不能只写“有问题就恢复”。如果测试的是矿工软件版本，回滚目标就是上一稳定版本；如果调整的是超频参数，就恢复该机型最近一次通过连续运行验证的模板；如果修改了 Flight Sheet，则回到已确认的钱包与矿池组合。
回滚之后也不能以“机器亮了”为结束。至少要检查在线率、实际算力、拒绝率、温度、功耗以及十五分钟内的重启次数。否则设备虽然在线，可能仍在低算力运行，或者已经连到了错误的矿池地址。
十二台测试机没有挡住事故：灰度组必须与生产组真正隔开
我们原来已经设置测试标签，却依然出现全场误下发，说明“有测试组”并不等于“具备灰度能力”。
有效的灰度测试至少要做到三点。
首先，测试组规模要小，但硬件要有代表性。不能只挑状态最好的机器，而要覆盖不同显卡批次、不同显存、不同主板和不同运行时长。否则测试结果很容易过于乐观。
其次，测试组在界面和命名上要足够醒目。我们后来把测试 Worker 单独归组，标签中加入日期与责任人，避免只用 test 这种容易长期遗留的名称。批量执行前，必须截取所选范围和机器数量，交由另一名同事确认。
再次，扩大范围必须分批。12 台稳定运行后，不直接推向 600 台，而是扩大到一个机架，再到一个机房。每一批都要完成规定时长的观察。出现掉卡、拒绝率明显上升或异常重启时，停止扩大发布，并按预设版本回滚。
这会比全场一次下发多花一些时间，但矿场运维追求的从来不是点得快，而是变化可控。十分钟的分批验证，通常比半小时全场停摆便宜得多。
交接班只说“参数调过了”：口头说明无法支撑夜间处置
事故发生前，白班在群里留过一句：“A3 参数今晚可以继续测。”夜班据此认为方案已经确认，却不知道测试数量、停止条件和回滚版本。
这种模糊交接在小矿场里很常见。大家熟悉机器，遇到问题打电话就能问。但规模扩大后，设备型号、人员班次和配置数量都在增加，口头默契迟早会失效。
我们现在要求每个批量变更至少留下以下内容：
- 本次修改什么；
- 涉及哪些 Worker，准确数量是多少；
- 谁提出、谁复核、谁执行；
- 计划开始和结束时间；
- 观察哪些指标；
- 达到什么条件必须停止；
- 使用哪份稳定配置回滚；
- 回滚后由谁确认恢复。
工单不需要写成长报告，但必须让接班人员在没有原执行人在场的情况下，也能判断该继续、暂停还是回退。
今天值班前做一次检查：把全场事故拦在确认按钮之前
这次事故之后，我给班组留下了一份六项检查，直到现在仍要求每次大范围操作前逐项确认：
1. 当前选中的是单机、标签组、机架还是整个 Farm；
2. 页面显示的 Worker 数量是否与工单一致；
3. 配置是否已经在代表性机器上稳定运行；
4. 当前账号是否具备本次操作所需权限，是否超出岗位职责；
5. 告警群里是否已通知变更时间和影响范围；
6. 稳定版本、回滚负责人和停止条件是否已经写清。
矿场使用 HiveOS，真正容易造成大损失的往往不是某台矿机报错，而是一次操作同时作用到几百台设备。今天如果只能改一件事，就先取消共用高权限账号，再给所有批量下发增加双人确认。随后把现有 Worker 按机型和机房补齐标签，选出一组固定测试机，并为正在运行的 Flight Sheet、超频参数和矿工软件版本各保存一份可核验的稳定记录。
这些动作并不复杂，却能把“发现异常后全员救火”，改成“错误扩大前及时停手”。对于每天都要处理批量任务的矿场，这比再增加一块监控大屏更有用。
