今天最该防的是 HiveOS 批量指令越权把整排矿机带停

凌晨 1 点 47 分，A3 货架最上层的交换机灯还在闪，风机声却突然低了一截。值班同事在手机上看到 HiveOS 里一排矿机从绿色变成灰色，第一反应是网络抖动，第二反应才是去翻操作记录。结果记录里明明白白写着：有人对 86 台矿机推送了同一套飞行表，矿池地址没错，钱包也没错，错在显卡参数套到了另一批不同型号的机器上。

这不是设备老化，也不是矿池抽风，是一次典型的矿场系统操作事故。问题看起来发生在 HiveOS 面板上，根子却在我们的流程里：谁能批量改、改之前有没有确认、失败后能不能一键退回、告警有没有把真正危险的动作拎出来。

我今天写这篇，不是为了讨论 HiveOS 好不好用。矿场规模一上来，系统越好用，误操作的杀伤范围越大。作为运维负责人，我现在最在意的不是某个按钮多方便，而是这个按钮在错误时间、错误账号、错误对象上被点下去时，矿场能不能拦住一次。

凌晨整排掉线：能批量操作就必须先假设会批量出错

那次事故发生前，我们一直把 HiveOS 的批量管理当成效率工具。上百台机器改飞行表、重启挖矿程序、调整超频参数，以前靠人一台台点，现在几分钟能做完。效率确实高，但我们忽略了一件事：批量管理不是把单机操作放大，而是把单机风险放大。

事故当天，值班同事原本只想处理一组掉算力的机器。他在 worker 筛选时按了一个标签，标签名和另一组测试机很像，页面上数量显示 86 台，他以为是正常范围。飞行表推下去后，部分机器驱动异常，部分矿机直接重启循环。现场人员赶到机房时，最麻烦的不是机器停了，而是不知道哪几台已经成功执行，哪几台执行了一半，哪几台还没收到命令。

复盘后我们改了三条规矩。第一，所有批量操作必须先按货架、机型、显卡型号做二次筛选，不能只靠一个自定义标签。第二，超过 20 台的变更不允许直接执行，必须先选 3 台同型号机器跑 10 分钟。第三，HiveOS 里的标签命名重新整理，测试组、生产组、维修组不能用相似缩写，宁愿名字长一点，也不能让人半夜看错。

矿场运维最怕“差不多”。一台机器差不多，最多损失一台；一批机器差不多，可能就是一晚收益和一堆维修单。

告警连响十分钟：消息多不代表风险被看见

事故刚开始时，HiveOS 告警其实已经发了。问题是它和温度告警、离线告警、低算力告警混在一起，值班群里一页刷过去，全是红色提示。真正关键的那条“批量飞行表变更完成”，反而被淹没了。

这件事让我意识到，矿场告警不能只按“有没有异常”来分级，还要按“异常会不会继续扩散”来分级。温度高、算力低、单机离线，都很重要，但它们通常影响局部。批量改配置、批量重启、批量升级、批量执行 shell，这类动作一旦出错，会把问题从一台机扩成一排机，甚至一个矿场。

我们后来把告警分成两类处理。一类是状态告警，比如温度、算力、离线、风扇异常，走普通值班通道。另一类是动作告警，只要有人在 HiveOS 里做了批量配置、批量升级、批量重启、批量改钱包，就单独推送到运维负责人和当班主管手机上，并要求 5 分钟内确认。

还有一个小改动很有用：告警内容不再只写“执行成功”或“执行失败”，而是必须带上操作者账号、机器数量、目标标签、变更内容摘要。晚上值班时，人最怕看不清上下文。告警如果只告诉你“有事发生”，它只能算噪音；告警能告诉你“谁对哪些机器做了什么”，它才有处置价值。

账号共用的那一刻：权限宽一点事故就近一点

这次事故还有一个刺眼的问题：执行批量操作的账号不是个人账号，而是值班共用账号。表面上看，共用账号方便交接，谁值班谁登录，密码放在内部文档里。真出事时，麻烦来了，系统日志只能显示这个账号操作过，无法确认是哪个人在哪台电脑上点的。

这不是追责情绪，而是运维管理的基本要求。找不到具体操作人，就无法还原当时的判断过程；还原不了判断过程，就只能把事故归结为“注意力不集中”。这种复盘没有意义，下次还会发生。

我们后来把 HiveOS 权限拆细。现场巡检人员只能看状态、重启单台机器，不能改飞行表。夜班值守可以处理单组机器，但不能对全场推送配置。能改钱包、矿池、批量超频参数的账号，只保留给两名主管，并且启用双重验证。临时外包维修人员进系统，只给指定 worker 的临时权限，到期自动收回。

权限管理有个简单原则：一个人平时不需要做的事，就不要给他长期权限。很多矿场事故不是黑客进来了，而是自己人拿着过大的权限，在疲劳、赶时间、沟通不完整的情况下，把系统当成记事本一样操作。

参数推错之后：没有回滚包就只能靠人肉补洞

事故中最拖时间的环节，是回滚。我们当时知道新飞行表推错了，也知道旧配置大概是什么，但“大概”两个字在矿场里很要命。不同机型的超频参数不同，同一机型不同批次也可能略有差异，部分机器还做过单独降频。靠记忆和聊天记录恢复，速度慢，还容易二次出错。

HiveOS 本身提供了不少恢复手段，但前提是你平时就把版本、配置、变更记录存好。事故发生前，我们没有形成固定回滚包，只能现场翻旧工单、找截图、问白班同事。那一晚最尴尬的场面是，运维群里三个人同时发了三个“旧参数”，每个都说自己记得没错。

现在我们要求每一次批量变更前都生成一份回滚记录，至少包括四样东西：原飞行表、原超频参数、目标 worker 清单、执行时间。变更完成后观察 30 分钟，没有异常才把记录归档；如果出现大面积掉线或算力异常，先按回滚记录退回，不允许在现场临时猜参数。

回滚不是出事后的补救心态，而是变更前就该准备好的刹车。没有刹车的批量操作，再熟练也只是赌自己永远不会按错。

白班交给夜班：交接写不清就别让系统替你冒险

很多 HiveOS 事故发生在夜里，不是因为夜里系统更脆弱，而是因为夜里信息最少。白班知道某批机器刚换过显卡，知道某排网线今天抖过，知道某个矿池节点下午不稳定，但这些信息如果只留在口头里，夜班看到的就只剩面板颜色。

我们事故后把交接内容固定成几项：今天动过哪些机器，哪些标签正在测试，哪些 worker 不允许批量重启，哪些飞行表不能改，哪些告警可以观察，哪些告警必须叫人。交接不写“注意 A 区”，要写“A 区 3 架 12 到 18 号机今天换过 riser，低算力先不要批量套参数，先单台看日志”。

HiveOS 的价值在于把很多操作集中起来，但集中操作需要配套的交接纪律。系统面板能显示现在怎么样，却不能自动告诉夜班白天发生过什么。矿场越大，越不能把经验放在人脑里，必须把它写进工单、标签和备注。

事故复盘之后：今天就能改的六个动作

这次事故最后恢复得不算慢，但代价已经够我们长记性。矿场系统运维不能等到大停机后再补流程，尤其是 HiveOS 这种能同时管理大量机器的工具，越早把边界画清楚，越少在夜里被手机铃声叫醒。

今天如果你也负责矿场运维，我建议先做六件具体事。

第一，检查 HiveOS 账号，把共用管理员账号停掉，改成实名账号，并开启双重验证。

第二，整理 worker 标签，删除相似命名，把生产、测试、维修、隔离状态分清楚。

第三，给批量操作设数量门槛，超过固定台数必须先小批测试，再由主管确认。

第四，把批量变更告警单独拉出来，不要和温度、离线、低算力提示混在一个频道里。

第五，每次改飞行表、矿池、钱包、超频参数前，先保存回滚记录，别等出事后翻聊天记录。

第六，夜班交接必须写到机器组和禁止动作，不能只写“多留意”。

HiveOS 能帮矿场省人，但不能替矿场承担流程混乱的后果。真正可靠的运维，不是面板上全是绿色，而是有人按错时，系统和流程能让错误停在第一批机器上。今天最该防的，就是那个看起来很普通的批量按钮。