文章目录
今天别让 HiveOS 批量命令越过审批
凌晨 2 点 17 分，我在矿场通道里听到的不是机器变安静，而是一排机架的风扇同时拉满。手机上 HiveOS 的告警一条接一条刷出来，先是离线，再是算力掉零，紧接着温度异常。值班同事第一反应是网络抖动，我看了一眼面板，发现问题不在交换机，而在 6 分钟前执行过的一条批量配置命令。
这次事故不算大，停了 43 台机器，最久的一组掉线 28 分钟。但它给我提了个醒：矿场用 HiveOS 最怕的不是某台矿机坏掉，而是一个人、一次批量操作、一个没确认清楚的目标组，把几十台甚至几百台机器同时带偏。
矿场规模上来以后，HiveOS 的价值很明显：批量部署、统一看板、远程调参、异常告警、权限管理，都能减少人跑机房的次数。但工具越顺手，越容易让人忽略流程。我们这次复盘后改的不是某个参数，而是整个运维动作的顺序。
夜班误点批量配置：能一键完成的动作也能一键放大错误
事故当天，夜班同事原本只要调整 B 区 12 台新上架机器的 flight sheet，把矿池地址从测试池切到正式池。HiveOS 里标签打得不够细，B 区新机器和 B 区部分老机器共用了一个临时标签。操作时目标组没二次确认，配置被推到了 55 台机器上。
推送后，有 43 台机器出现异常。原因很简单：这批老机器用的是另一套超频参数和驱动组合，新 flight sheet 里矿工版本和原参数不匹配，部分机器还能跑但算力抖动，部分直接掉线重启。HiveOS 面板上看起来只是“一批机器异常”，现场却是风扇狂转、功耗波动、电工和值班运维一起找原因。
这件事说明一个问题：批量管理不是把单机操作复制很多次，而是把错误的影响范围扩大很多倍。
以前我们总觉得 HiveOS 的标签、分组、批量执行很方便，谁负责哪个区域就自己建组、自己操作。现在看，这种习惯在小矿场还凑合，机器一多就很危险。标签如果没有命名规则，临时组如果不定期清理，批量操作就会越来越像“凭感觉点按钮”。
事故后我们把分组重新梳理了一遍：按物理位置、机器型号、系统版本、矿工软件、用途分别建标签。临时标签必须带日期，超过 7 天自动检查，确认无用就删。更关键的是，批量操作前不再只看机器数量，还要看目标清单里有没有混入不同型号、不同版本、不同矿池策略的设备。
这一步很烦，但比半夜救火轻松得多。
告警刷屏没人接：消息多不等于发现得早
这次事故还有一个细节让我很不满意：HiveOS 其实早就发了告警，但值班群里没人第一时间判断出是批量配置问题。
当时告警内容包括掉线、低算力、重启、温度异常。消息很多，但没有一个明确告诉值班人员：“刚刚执行过批量变更，异常机器与变更目标高度重合。”所以夜班同事先查网络，再查电力，再看矿池，绕了一圈才回到 HiveOS 操作记录。
告警如果只是把异常扔到群里，矿场人越多、机器越多，越容易麻木。尤其是 HiveOS 这种系统，正常情况下也会有少量掉线、单卡报错、矿池延迟。真正要命的是批量异常，但它在消息流里经常被淹没。
我们后来把告警分成三类。
第一类是单机告警，比如某台机器掉卡、温度高、算力低。这类允许值班人员按常规流程处理，不必惊动所有人。
第二类是区域告警，比如同一机架、同一交换机、同一电柜下面的机器集中异常。这个要同步电工和网络负责人。
第三类是变更后告警，只要 HiveOS 里执行过批量命令，接下来 30 分钟内出现的离线、低算力、重启，都必须和这次变更挂钩查看。值班人员先看变更记录，再看现场环境。
我们还加了一个很土但很有效的动作：批量操作完成后，执行人要在值班群里发一句固定格式的话，包含操作对象、机器数量、操作内容、预期现象、观察时间。比如“B 区新机 12 台切正式矿池，预计 5 分钟内算力恢复，30 分钟内不应出现大面积重启”。这样后面一旦告警出现，接班人不会从零开始猜。
HiveOS 的告警本身很有用，但矿场不能只把它当铃声。告警要和操作记录连起来，才有判断价值。
账号权限给得太宽：会操作的人不一定该拥有全部按钮
复盘时我问了一个问题：为什么夜班同事能直接对几十台机器推送配置？
不是他技术不行，而是账号权限给得太宽。过去为了省事，我们给几个运维账号都开了较高权限，理由是夜里出问题要能处理，不能等主管起床。听起来合理，但实际结果是，任何一个账号在疲劳、赶时间、信息不完整的情况下，都可能执行高影响操作。
HiveOS 支持团队协作和权限管理，矿场不能把所有人都当超级管理员用。我们现在把账号拆成四类。
值班账号可以查看状态、重启单机、处理明确的单机故障，但不能批量改 flight sheet，不能批量升级系统，不能大范围修改超频参数。
区域负责人可以对自己负责的区域做有限批量操作，但必须限定标签范围，不能跨区执行。
高级运维可以发起大范围变更，但需要另一个人确认。这个确认不只是口头说“可以”，而是要对机器数量、目标标签、回滚方案都看一遍。
管理员账号只用于权限调整、关键配置和应急接管，平时不登录日常机器，不在普通电脑上保存密码。
这套做法刚开始有人嫌麻烦，觉得矿场又不是银行，没必要这么细。我的回答很直接：一台机器误操作，是维修问题；一百台机器误操作，就是管理问题。权限不是不信任人，而是不让一个人的失误变成全场事故。
尤其是外包维修、临时夜班、新人培训期间，更不能为了方便给全权限。HiveOS 的批量能力越强，账号边界越要清楚。
回滚找不到旧版本：没有退路的升级就是赌博
这次事故真正拖时间的地方，是回滚不够快。
按理说，配置推错了，把旧 flight sheet 切回来就行。但现场遇到两个问题：一是旧配置命名不规范，几个版本看起来都像正式配置；二是部分机器在重启后状态不稳定，单纯切回配置并不能马上恢复，还要确认矿工版本、超频参数、驱动状态。
以前我们做变更，重点放在“怎么推上去”，很少认真写“怎么退回来”。HiveOS 里历史记录能帮忙，但不能替代矿场自己的版本管理。特别是矿工软件升级、系统更新、显卡驱动变化、不同币种策略切换，这些动作一旦混在一起，回滚就会变得很难判断。
现在我们要求每一次批量变更都要有对应的回滚包，至少包含四样东西：原 flight sheet 名称、原超频模板、适用机器标签、回滚后观察指标。不是写在聊天记录里，而是放到固定文档，变更前就准备好。
另外，我们把版本命名改得更直白。以前叫“正式版1”“正式版2”“优化版”，现在改成“B区3060Ti-正式池-20260625”“A区5700XT-低功耗-20260620”这类名字。看起来长一点，但半夜出事时不会猜错。
对于系统升级，我们也不再全场推。先选 3 台同型号机器跑 24 小时，再扩到 10 台，确认算力、拒绝率、温度、重启次数都正常，再考虑按区域推进。HiveOS 批量升级很方便，但方便不代表要一次推完。
回滚不是事故发生后的补救，而是变更开始前就该准备好的刹车。
交接只说“都正常”：这种正常没有任何用
矿场事故经常不是一个动作造成的，而是多个小疏忽叠在一起。我们这次也是：标签没清理、权限太宽、告警没分类、回滚文档不清楚，最后在夜班一次操作里爆出来。
复盘后我把交接班记录也改了。以前交接常见一句话：“机器基本正常，B 区有几台低算力。”这种话听起来省事，实际没有任何运维价值。接班的人不知道哪台机器、什么原因、处理到哪一步、还能不能动配置。
现在交接必须写清楚四件事。
第一，过去 12 小时有没有批量操作，操作对象是谁，影响多少台机器。
第二，当前未恢复告警有哪些，是否与变更有关。
第三，哪些机器不允许继续操作，比如正在观察升级效果、刚换过电源、刚调整过超频。
第四，如果出现同类异常，优先执行哪套回滚或排查流程。
这些内容不复杂，关键是每天坚持。HiveOS 能记录很多状态，但状态要变成判断，还得靠人把上下文补上。矿场运维最怕“我以为你知道”，事故往往就藏在这句话里。
今天就该改的三件小事：先把大事故的机会降下来
如果你现在也在用 HiveOS 管矿场，今天不用急着上复杂系统，先做三件事。
第一，检查所有高权限账号。把不该拥有批量修改、系统升级、权限管理的人先降下来。夜班需要处理问题，但不代表夜班必须能改全场配置。
第二，清理标签和 flight sheet。临时标签、旧配置、名字相近的版本，今天就删一批或改名。以后批量操作前，目标机器清单必须有人复核。
第三，给每个批量变更配回滚说明。哪怕只有十几台机器，也要写清楚原配置是什么，回滚后看哪些指标，多久不恢复就升级处理。
HiveOS 是好工具，但矿场不能把稳定性全部交给工具。真正稳的运维，是每一次点击之前都知道影响谁，每一次告警出现后都知道先查什么，每一次推错以后都能退得回来。今天最该注意的风险点，就是别让批量命令越过审批，带着整排机器一起犯错。
