今天最该防的是 HiveOS 一键批量操作把小故障放大全场

凌晨 2 点 17 分，值班群里第一条消息不是告警机器人发的，是机房巡检员拍的一张照片：A 区第三排的交换机灯还在闪，但那一排矿机风扇声音明显降了下来。几分钟后，HiveOS 面板上算力曲线开始掉，先是 36 台，再到 112 台，最后牵到 400 多台。最麻烦的是，告警并没有第一时间把问题说清楚，群里只看到一串离线、低算力、重启失败混在一起。

这类事故，我们以前也遇到过。单台机器出问题不可怕，矿场每天都有坏板、掉网、温度异常。真正可怕的是，原本只该影响几十台的操作，被 HiveOS 的批量管理能力放大成全场事故。系统越方便，越要管住手；按钮越集中，越要把流程拆细。今天写这篇，不是讲 HiveOS 有多强，而是站在矿场运维负责人的角度，把一次事故复盘和后续流程改造讲清楚。

夜班执行飞行表：能批量不代表能全量

那次事故的起点，是一个很普通的飞行表调整。

当天我们计划把一批机器从保守参数切到新参数，目标是降低拒绝率，同时把功耗压下来一点。白班已经在 20 台样机上跑了 6 个小时，算力看起来没问题，温度也稳定。夜班接手时，按原计划应该先推 A 区 80 台，再看 30 分钟，确认矿池连接和拒绝率正常后，再推下一组。

问题出在交接单写得不够硬。夜班同事看到样机数据稳定，又想赶在低电价时段完成调整，直接把同一飞行表推到了整个机型分组。HiveOS 的批量操作很快，几百台机器几乎同时切换。前 5 分钟面板还好看，10 分钟后开始有机器掉算力，15 分钟后矿池侧拒绝率上升，部分机器重启后没有回到原参数。

复盘时我们把责任拆开看：操作人确实急了，但流程也给了他犯错空间。只要一个账号有全量权限，只要飞行表命名没有清楚标出试运行范围，只要推送前没有强制二次确认，那么类似事故迟早会发生。

后来我们改了三条规则。第一，任何新飞行表不允许直接挂到全场分组，必须先经过样机组、小批量组、生产组三个层级。第二，HiveOS 里的分组名称要带上用途和风险级别，比如测试、灰度、稳定，不再用含糊的 A1、B2。第三，夜班只允许执行已审批的分批任务，不能临时扩大范围。

批量管理是 HiveOS 的优势，但矿场运维不能把“省事”当成“安全”。一键推送之前，先问一句：这次操作失败时，最多会影响多少台？

告警刷屏那一刻：先分辨噪音还是事故

很多矿场把 HiveOS 告警接到 Telegram、邮箱或者企业微信，设置一堆离线、低算力、高温、风扇异常。看起来很完整，真出事时却可能变成噪音。

那晚告警刷屏时，值班同事最初判断是网络波动，因为离线告警和低算力告警几乎同时出现。巡检员去看交换机，网络没有大面积断开；再看温度，机房环境也正常。十几分钟就这样过去了。后来查操作记录，才发现同一时间段有批量飞行表变更。

这说明告警缺的不是数量，而是排序。矿场最怕的不是没告警，而是告警没有告诉你先查什么。离线、低算力、重启失败只是结果，批量任务、参数变更、驱动更新、矿池切换才可能是原因。

我们后来把告警分成三层。第一层是设备状态，比如离线、温度、风扇、算力下滑；第二层是操作事件，比如飞行表变更、钱包变更、矿池变更、系统升级；第三层是业务影响，比如某矿池算力下降超过多少、某区域收益偏离多少。

真正需要值班负责人立刻处理的，不是单条低算力，而是“批量操作后 15 分钟内，同分组出现连续异常”。这类告警必须置顶，不能淹没在几百条普通消息里。

HiveOS 面板能看到很多信息，但矿场要自己定义判断顺序。告警不是越多越安全，告警如果不能把“谁动了什么”和“机器现在怎么了”连起来，就只能让人更慌。

临时账号借出去：权限宽一点，事故就近一点

事故复盘里还有一个细节，最开始没人愿意提：执行批量操作的账号，不是那位夜班同事自己的账号，而是白班负责人临时借给他的。

理由很常见：他的账号没有权限改某个分组，现场又着急，就先用一下主管账号。矿场里这种事太容易发生，尤其是夜班、节假日、远程协作时。大家都觉得“先把机器跑起来”，权限管理就往后放。

但从运维负责人的角度看，借账号比误操作更危险。误操作至少还能查到人，借账号会把责任链打断。HiveOS 里谁改了飞行表、谁重启了机器、谁调了钱包、谁改了矿池，如果最后都落在一个主管账号名下，复盘就会变成猜。

我们后续做了权限拆分。普通值班账号可以查看全场状态，可以重启单台或小组机器，但不能改全场飞行表。区域负责人可以调整自己区域，但不能碰钱包和全局矿池。只有两个人共同确认后，才允许做全场参数变更、系统升级和钱包相关操作。

更重要的是，临时授权必须有时间限制。比如给某个账号开放 A 区飞行表调整权限，只能开 2 小时，到点自动收回。权限一旦长期挂着，就会变成新的隐患。

HiveOS 的团队管理功能要真正用起来，不能所有人共用一个管理员账号。矿场越大，越不能靠“大家自觉”。权限不是为了防同事，而是为了让每次操作都能还原。

回滚按钮找不到：预案没演过就等于没有

那晚最让人着急的不是发现错误，而是回退时卡住了。

理论上，把飞行表切回旧版本就行。但实际操作时，旧飞行表有两个相似名称，一个是上周稳定版，一个是维修组临时版；部分机器已经重启，部分还在执行新参数；有几台因为驱动状态异常，回切后没有正常恢复。值班群里一边问“切哪个”，一边有人建议“先全场重启”。

这就是典型的回滚预案没演过。文档里写了“异常时回退至旧配置”，但旧配置是哪一个、谁来按、按完看哪几个指标、多久没恢复要转人工，并没有说清楚。

后来我们把 HiveOS 回滚流程做得很死板。每一次飞行表变更前，必须确认回退版本，并把名称写清楚，不能用“旧版”“稳定版”这种模糊叫法。变更前截图保留当前配置，包括矿池、钱包、超频参数、驱动版本。执行后 10 分钟、30 分钟、60 分钟分别看算力、拒绝率、离线数和功耗偏差。

如果触发回滚，不允许现场临时讨论方案，直接按预案走。先回退小组，确认恢复，再扩大到受影响分组。除非明确是系统级故障，否则不允许一上来全场重启。全场重启看似干脆，实际可能把本来还能跑的机器也拖进故障里。

回滚能力不是有个旧配置就算具备。真正能救场的回滚，必须在平时演过，最好每个月挑一组机器做一次完整演练。

系统升级提醒弹出：今天不要随手点确认

HiveOS 经常会有系统、驱动、矿工软件的更新提醒。很多时候更新确实能修问题，也能提升兼容性。但从矿场运维角度看，今天最该提醒所有值班人员的一件事，就是不要看到更新提示就顺手确认。

尤其是批量环境里，升级不是单台电脑装软件。不同批次矿机、不同显卡、不同网卡、不同矿工程序，对同一个版本的反应可能完全不同。白天一台样机能跑，不代表夜里几百台能稳定。矿池策略、网络线路、温度变化叠加起来，结果就更难预估。

我们现在对升级采取固定节奏。非紧急安全问题，不在夜班升级；行情剧烈波动、矿池切换频繁、机房正在检修时，不做大规模升级；新版本先放测试组跑满一个完整电价周期，再进小批量生产组。升级前必须能回到上一版本，升级后必须有人盯至少一小时，不允许点完就走。

HiveOS 运维的核心不在于把所有机器都保持最新，而在于知道哪些机器该稳，哪些机器可以试。矿场赚钱靠持续出块和持续结算，不靠版本号好看。

复盘会开完以后：把经验写进系统而不是写进群聊

事故结束后，最容易出现的假象是大家都记住了教训。群里有人道歉，有人总结，有人说下次注意。过几天一忙，老问题又回来。

作为运维负责人，我现在更看重事故后有没有改系统、改权限、改告警、改模板。只靠提醒人的流程，迟早会失效。能在 HiveOS 里限制的，就不要靠口头约定；能写进值班单的，就不要留在聊天记录；能自动记录的，就不要靠人回忆。

今天如果你的矿场也在用 HiveOS，可以先做 6 个动作。

第一，检查所有管理员账号，停用共用账号，给每个值班人员单独建账号。第二，把全场机器按测试、小批量、稳定生产重新分组，不要只按机房位置分。第三，梳理最近一个月的飞行表，删掉名字相似、用途不明的旧配置。第四，把告警和操作事件放在一起看，重点盯批量变更后的连续异常。第五，为每类批量操作写一个回滚版本和回滚负责人。第六，安排一次小范围演练，故意把一组机器切到测试配置，再按流程退回来。

HiveOS 能让矿场管理更快，但快不等于稳。今天最该防的风险，不是某一台机器掉线，而是一个未经分批、未经限权、未经演练的批量动作，把原本可控的小问题推成全场停摆。运维负责人要做的，就是把这个风险提前关在流程里。