文章目录
HiveOS 批量指令今天最容易把小故障放大成全场停机
凌晨 2 点 17 分，值班手机连续震了 18 下。第一条是 3 号棚掉线，第二条是同一 Flight Sheet 下的机器算力归零，第三条已经变成矿池侧拒绝率异常。等我远程打开 HiveOS 面板时，现场电工刚把手电筒照到交换机柜，群里却有人回了一句：“我刚才批量重启了一下，应该马上恢复。”
这句话，是那次事故里最刺耳的一句。
机器没有马上恢复。相反，原本只有一个网段里的 40 多台矿机异常，被一次不带筛选的批量操作拖成了 300 多台同时重启。更麻烦的是，其中一部分机器刚更新过驱动，另一部分还是旧镜像，重启后状态不一致，告警开始刷屏，夜班人员根本分不清哪些是真故障，哪些只是重启过程中的正常离线。
从那晚之后，我对 HiveOS 的看法变了。它不是一个“会不会用”的问题，而是矿场有没有把系统操作做成流程的问题。HiveOS 的批量管理很好用，但越好用，越不能让它变成谁都能按、按错了没人知道、出事后只能靠经验补救的遥控器。
夜班批量重启后：能一键执行的动作必须先定义边界
事故复盘时，我们查到最初问题其实很小：3 号棚一台上联交换机端口抖动，导致部分矿机短时间掉线。值班人员看到 HiveOS 面板上红了一片，以为是矿机卡死，于是选中同一标签下所有 Worker，执行批量重启。
问题就在“同一标签”这四个字。
我们之前为了方便，把同型号、同币种、同矿池的机器打了一个统一标签，平时切换配置很省事。但夜间故障发生时，这个标签覆盖了多个机架、多个网段，甚至跨了两个配电区域。值班人员以为自己处理的是一个棚，实际上是在操作半个场。
后来我们把标签重新拆了三层：物理位置、业务配置、风险等级。物理位置只用于定位，业务配置用于批量下发，风险等级用于限制动作。比如“3 号棚-B 排-上层”是一组，“ETHW-某矿池-标准超频”是一组，“禁止夜间批量重启”又是一组。任何需要跨物理区域的操作，都不能由夜班单人直接执行。
HiveOS 的批量功能本身没有错，错的是矿场把“方便管理”的标签，当成了“可以随便执行”的范围。批量操作前必须回答三个问题：这次会影响多少台机器？是否跨网段或跨配电柜？失败后能否在 10 分钟内撤回？答不出来，就不能点执行。
告警刷屏的时候：先降噪再判断，不要让人被红点牵着走
那晚另一个教训，是告警没有分级。
HiveOS 面板、Telegram 机器人、矿池通知、内网监控同时报警。掉线、低算力、GPU 温度异常、矿池拒绝率、重启成功、重启失败混在一起。夜班人员在群里不断转发截图，真正关键的一条“交换机端口 CRC 错误增加”反而被淹没了。
我们后来做了一个很土但有效的改造：告警分成三类，只让该出现的人看到该处理的事。
第一类是“需要立刻停动作”的告警，比如同一网段连续掉线、同一电柜机器大面积离线、批量命令失败率超过设定值。这类告警直接通知运维负责人和值班主管，不再只发普通群。
第二类是“需要现场确认”的告警，比如温度异常、风扇转速异常、单机频繁重启。这类发给现场人员，并要求回传机架号、机器灯态和环境照片。
第三类是“只记录不打扰”的告警，比如短时间内算力波动、单台矿机重连成功、系统更新完成。这类进入日志，不在夜间反复推送。
HiveOS 能提供很多状态，但矿场不能把所有状态都当成同等级警报。告警越多，人越容易只看颜色，不看原因。真正要命的不是没报警，而是报警太吵，导致值班人员在压力下做了最大范围的错误操作。
临时账号接手时：权限不能靠信任，必须靠角色限制
事故当天还有一个细节：执行批量重启的人，是刚接手夜班不到两周的新同事。他不是不负责，恰恰是太想快点解决问题。但他的账号权限和老运维一样，可以改钱包、改矿池、改 Flight Sheet、执行批量重启、下发升级命令。
这在矿场里很常见。为了省事，一个账号从装机用到维护，再从维护用到夜班。刚开始机器少，还能靠口头交代。机器一多，权限就会变成隐患。
我们后面把 HiveOS 账号权限按岗位拆开：
现场巡检账号，只能查看机器状态、标记故障、执行单机重启，不能批量改配置。
夜班运维账号，可以对单个机架做重启和恢复，但不能跨标签批量执行，也不能修改钱包地址。
高级运维账号，可以下发 Flight Sheet 和超频参数，但需要在工单里写明范围、原因和回退方案。
管理员账号只用于新增人员、改权限、处理紧急接管，平时不登录，不挂在任何人的手机浏览器里。
权限管理最怕“大家都方便”。矿场里很多事故不是坏人造成的，而是好人拿着过大的权限，在信息不完整的时候做了过大的动作。HiveOS 支持团队和角色管理，矿场如果不用，等于把防火门拆了，只为了平时走路少绕一步。
版本更新当天：没有回滚包就不要全场推送
那次事故还有一个后续问题：部分机器重启后驱动状态异常，原因是之前做过小范围升级，但没有记录清楚哪些机器已经更新，哪些机器仍在旧版本。批量重启后，差异被放大了。
我们后来把 HiveOS 的系统更新和矿机软件更新改成“灰度三步走”。
第一步，只选 5 到 10 台代表机器。代表机器不能全是状态最好的，要包含不同批次显卡、不同网段、不同供电位置的机器。测试时间至少跑满一个结算周期，看算力、拒绝率、温度、重启次数。
第二步，扩大到一个机架或一个小棚。这个阶段必须安排现场人员在场，不能只靠远程面板。因为有些问题面板看不出来，比如某个机架风道本来就差，更新后功耗曲线变了，温度会慢慢顶上去。
第三步，才允许按业务标签批量推送。推送前必须准备旧 Flight Sheet、旧超频参数、旧矿工版本和镜像记录。回滚按钮不是出事后才找，应该在执行前就知道点哪里、回到哪个版本、谁来确认恢复成功。
我现在判断一套 HiveOS 运维流程是否成熟，不看它能不能一天更新几千台，而看它能不能在 30 分钟内把错误更新撤回到可运行状态。矿场不怕慢一点，怕的是新版本一推，大家才发现旧配置找不到了。
现场断网十分钟：远程系统再强也要留本地处置卡
很多人把 HiveOS 用熟之后，会下意识觉得远程能解决大部分问题。实际矿场里，最难处理的往往是“远程看不到”的十分钟。
比如交换机异常、电源抖动、路由器重启、运营商线路闪断，这些时候 HiveOS 面板可能只显示一片离线。远程人员越急，越容易误判成系统或矿机问题。现场人员如果没有固定检查顺序，也会在机房里来回跑，最后谁都说不清第一现场发生了什么。
我们现在给每个棚都贴了一张处置卡，内容不复杂，但必须照做：
先看上联网络灯，再看配电柜，再看温湿度，再抽查三台矿机灯态，最后才允许对 HiveOS 上的机器执行重启动作。现场人员拍照回传时，也必须带上棚号、机架号、时间和设备灯态，不再只发一句“这边都红了”。
这张纸看起来很笨，但它减少了很多误操作。HiveOS 是远程运维工具，不是现场感知的替代品。面板离线不等于机器坏，算力归零也不一定要马上重启。远程和现场之间必须有固定语言，否则一个红点就能引发一串错误动作。
复盘会议之后：把经验写进按钮前面，而不是写进事故报告里
事故过去后，我们没有只追究某个人。因为如果流程允许一个新同事在夜里一键重启 300 台机器，那问题就不只在他身上。
我们做了几件具体改造：
所有批量操作必须绑定工单编号，工单里写清影响范围、执行人、审批人、预计恢复时间和回滚方式。
超过 50 台机器的批量重启，必须二次确认；超过一个物理区域的配置变更，必须由运维负责人确认。
夜间禁止做非紧急版本升级，除非已经完成白天灰度测试，并且现场有人值守。
所有 HiveOS 标签每月清理一次，废弃标签删除，模糊标签重命名，跨区域标签加限制说明。
每次告警事故后，不只看机器恢复时间，还要看从第一条告警到第一次人工判断用了多久、有没有错误扩大范围、回滚是否按预案执行。
今天矿场用 HiveOS，最该注意的风险不是系统功能不够，而是批量操作太顺手。顺手到让人忘了机器背后有机架、有网段、有电柜、有不同版本，也有不同权限的人。
如果你今天要检查自己的 HiveOS 运维流程，建议先做三件事：把所有能批量执行的账号查一遍，把最大的三个标签点开看实际覆盖范围，再随机找一条告警问值班人员该怎么处置、谁能批准、失败后退回哪里。
这三件事查完，基本就能看出矿场离下一次误操作有多近。
