文章目录
HiveOS 批量更新前先查权限，今天最容易出事的是一键推错机群
凌晨 1 点 37 分，值班室里只剩两台显示器亮着。HiveOS 面板上有一排红色离线提示，我刚把鼠标移到“批量执行”按钮上，手机就响了。现场电工说，3 号棚有一列机器风扇声突然变小，温度还没掉，算力先掉了一半。再看面板，原本只准备给 48 台测试机下发的新飞行表，已经被推到了整个 3 号棚。
这不是第一次有人在 HiveOS 上点错范围，但这次代价更实在：两百多台机器跑了错误配置，部分机器切到备用矿池失败，告警像刷屏一样推到群里，真正需要处理的几台高温机反而被淹没。最后我们花了 42 分钟才把机器拉回原状态，期间少了多少收益，账上能算出来；更麻烦的是，人对系统的信任被打了一折。
我现在越来越觉得，矿场用 HiveOS，最怕的不是功能不够，而是“它太方便”。批量管理、远程重启、统一改矿池、自动告警，这些功能本来是为了省人。但只要权限、告警、回滚没有配套流程，一次误操作就会把方便变成事故放大器。
凌晨值班室的一次误选：批量管理不能靠眼神确认
事故复盘时，我们把当晚的操作记录一条条拉出来看。问题不是值班员不会用 HiveOS，他知道怎么创建 Flight Sheet，也知道怎么按机组筛选 Worker。真正的问题出在最后一步：页面筛选条件没有被二次确认，测试组和生产组的标签命名又太接近，一个是 A3-test，一个是 A3，肉眼一晃就过去了。
过去我们总说“操作前看清楚”，这句话对小矿场还勉强有用。几十台机器时，点错了也能很快发现；几百台、上千台机器时，再靠人盯着一行字确认，就是把矿场安全交给运气。
后来我把批量操作流程改成了三道限制。
第一，所有生产机组禁止用相似标签。测试机必须带日期和用途，比如 test-0428-driver，而不是简单写 test。生产组则只保留棚区、排号、机型，不混用缩写。
第二，批量动作按风险分级。重启、改风扇、切矿池、更新内核、改超频参数，不能放在同一个操作习惯里。低风险动作允许值班员执行，高风险动作必须有人在通讯群里回复确认，确认内容不是“收到”，而是明确写出机组数量、机型、目标配置。
第三，HiveOS 里的 farm、worker、tag 要和现场资产表对应起来。面板里看到 A3-07，就能对应到 3 号棚第 7 排；现场看到机器编号，也能反查 HiveOS 里的 Worker。过去我们也有资产表，但更新不及时，机器搬了位置、换了板卡、重刷系统之后，表还停在上个月。这种表等于没有。
批量管理的好处是节省时间，风险也是节省了犯错时间。以前一个人错改十台，现在一个人可以错改三百台。流程改造的第一步，就是让“点错范围”变得更难发生。
告警群被刷屏的十分钟：报警多不代表发现得快
那晚最混乱的十分钟，不是机器掉算力，而是告警太多。
HiveOS 连续推送离线、低算力、矿工重启、温度异常、风扇异常。微信群、Telegram、短信接口一起响，值班员一开始还逐条看，三分钟后就只看最新消息。真正有危险的是几台温度快速上升的机器，但它们的告警夹在一堆“算力低于阈值”的消息里，没人第一时间点进去。
这件事之后，我给告警重新分了层。
高温、风扇停转、电源异常、连续重启失败，这类告警必须单独通道推送，并且要求有人确认。低算力、短时间离线、矿池延迟升高，可以合并成汇总，每隔几分钟发一次，不要一台机器一条地轰炸。
还有一个细节很关键：告警要带上“该找谁”。以前告警只写 Worker 名称和值，比如温度 82℃、算力下降 30%。值班员看到之后，还要去查这台机器在哪个棚、归哪个班组、要不要现场处理。现在我们把 Worker 命名和备注做得更细，告警里能直接看到棚区、排号、机型、负责人。出现高温，不用在群里问“这台在哪”，直接派人过去。
告警不是越灵敏越好。太灵敏的系统，会让人很快麻木。矿场真正需要的是让最危险的消息先被看见，让最该去现场的人收到，不要让所有人同时被同一堆消息淹没。
账号借给临时工的下午：权限不收口，系统再好也会被用乱
HiveOS 的权限管理，很多矿场平时不太重视。原因很简单：大家觉得自己人不会乱来，临时调机时图方便，把账号一发，事情先办完再说。
我们之前也这样干过。现场有一批新机上架，临时工需要看机器是否上线，班长就把一个有编辑权限的账号发了过去。对方倒不是恶意操作，只是看见有几台机器显示异常，顺手点了重启。结果那几台机器正好在做稳定性观察，重启之后日志断了，前面几小时的数据全废。
这件事不大，但提醒很重：权限不是只防坏人，也是在防好心办坏事。
现在我们把 HiveOS 账号拆成几类。值班员可以看状态、执行低风险重启，但不能改钱包、矿池和全场 Flight Sheet。现场维修人员只能看自己负责区域的 Worker，不能跨棚操作。工程师可以创建配置，但推到生产机组前必须经过二次确认。老板和财务能看收益和在线率，不参与技术操作。
更重要的是，临时权限必须有到期时间。给外包、厂家、远程协助人员开的账号，默认当天失效，不能长期留在系统里。以前有些账号用了半年没人管，谁登录过、什么时候登的，都没人追。等真出事再查，已经很被动。
权限管理看起来麻烦，实际是把责任边界写清楚。谁能看，谁能改，谁能批量改，谁能改钱包地址，这几件事必须分开。矿场一旦规模上来，不能再用一个“全能账号”解决所有问题。
回滚找不到旧配置的夜里：没有备份的更新就是赌博
这次事故里最耽误时间的一段，是找旧配置。
错误 Flight Sheet 推出去后，大家第一反应是“切回之前那个”。可问题来了：之前那个到底是哪一个？同一个机型有三套参数，名字都差不多；有的配置是工程师临时调过的，没有写备注；有的矿池地址更新过，但旧版本没有留说明。最后只能翻聊天记录、看历史截图、问白班同事。
这就是典型的回滚流程缺失。HiveOS 本身可以管理多套 Flight Sheet，也能查看部分操作历史，但如果平时不按规则命名、不记录变更原因，出事时系统也不会替你猜答案。
我们后来做了几个硬规定。
每次改配置前，先复制一份当前稳定版本，命名里写清日期、机型、用途，比如 0428-A3-稳定版-低功耗。新配置只能先推测试组，测试时间至少覆盖一个完整结算周期或一个温度波动明显的时段。测试通过后再扩大到一排，最后才到整棚。
回滚版本必须提前指定。不是出事后再想回哪一版，而是在变更工单里写明：如果算力下降超过多少、重启次数超过多少、温度超过多少，就切回哪一个配置。值班员不需要临场判断“要不要救”，只要指标到了，就按预案执行。
还有一点，回滚动作也要演练。很多矿场把演练当形式，但真正的夜间事故里，人会紧张，网络会卡，群里会吵，现场噪音大。没有练过的流程，到了凌晨基本会变形。我们现在每周找一小组机器做一次小规模回滚演练，确认账号、配置、通知、现场反馈都能走通。
更新不可怕，可怕的是只会往前推，不会往回退。矿场运维里，能安全撤回来，和能快速升级一样重要。
白班交接少写了两行：事故往往断在信息传递
复盘会上，最容易被忽略的是交接。因为它不像批量误操作那么明显，也不像高温告警那么紧急，但很多事故都是从交接不完整开始的。
这次错误推送前，白班其实已经发现测试配置有一台机器重启次数偏多，只是在群里随口提了一句，没有写进交接记录。夜班只看到“测试组基本正常”，就按计划继续扩大。后来回头看，如果那两行记录写清楚，夜班至少会再等一轮数据，不会急着推到整棚。
现在我们的交接不再只写“在线率正常、故障几台”。HiveOS 运维交接至少要写四件事：当天改过哪些配置，哪些机组还在观察，哪些告警需要继续盯，哪些账号或权限有临时开放。没有写清楚，就视为没有交接完成。
我们还要求交接记录和 HiveOS 操作记录能对上。谁在几点改了什么，群里有没有确认，现场有没有反馈，这些不需要写成厚厚的报告，但关键节点要留痕。这样不是为了追责时好看，而是下一班人能接得住。
矿场不是一个人连续盯二十四小时，系统再自动化，也要靠人换班。交接少写一句，夜班可能就会多走半小时弯路。
今天就能改的六个动作：先把事故放大的按钮管住
如果今天只做一件事，我建议先检查 HiveOS 里的批量操作权限。看一看现在有多少账号能改 Flight Sheet、能批量重启、能改钱包和矿池；再看这些账号是不是还属于正在值班的人。很多风险不是系统漏洞，而是旧账号、旧标签、旧习惯留在里面。
接下来可以按顺序做六个动作。
第一，把生产机组和测试机组重新命名，别用容易看错的缩写。
第二，给批量操作加确认要求，确认内容必须包含机组、数量、目标配置。
第三，把告警分级，高温和风扇类告警单独推送，不要和低算力消息混在一起。
第四，给每个账号重新分权限，临时账号设置到期时间。
第五，给所有稳定配置做备份，并写清楚对应机型和回滚条件。
第六，本周内挑一小组机器做一次回滚演练，别等事故来了再第一次操作。
HiveOS 能把矿场管得更省人，也能把一次误操作放大得更快。作为运维负责人，我现在看面板不只看在线率和算力，更先看三个问题：谁有权点，点了会影响多少台，出错后能不能在十分钟内退回来。
这三个问题答不清，今天就别急着批量更新。先把权限、告警和回滚流程补上，比多跑一点参数更值钱。
