文章目录
今天最该防的是 HiveOS 批量操作被一个误勾选放大
凌晨两点十七分，值班手机连续震了 43 下。第一眼看 HiveOS 面板，我以为是某一排机位掉线，结果往下拉才发现，两个机房的算力曲线几乎同时塌了一截。现场同事在微信群里发了一张照片：A 区交换机灯还亮，风扇声也正常，机器没有大面积断电。真正的问题藏在后台操作记录里——夜班人员把原本只给 38 台测试机下发的 Flight Sheet，点成了整个 Farm。
这类事故不吓人，吓人的是它看起来很“正常”。没有黑客，没有硬件烧毁，也没有矿池大故障，只是一次批量管理里的误选。可在矿场里，批量操作一旦没有护栏，人的一个手滑就能变成几百台机器的停产。
我现在对 HiveOS 运维的看法很简单：别只问它能不能批量管机器，要问它能不能把错误限制在小范围里。矿场规模越大，这个问题越现实。
夜班全选下发，判断不是人不细心而是操作范围没被限制
事故复盘时，很多人第一反应是追问值班员为什么不看清楚。这个问题当然要问，但如果流程只停在“下次注意”，那下次还会出事。
那天夜班要处理的是一批新上架显卡机，原计划把测试用的矿池配置、钱包地址、超频参数下发到新建的 Worker 组。HiveOS 的批量管理本身没问题，问题在于我们的 Farm 分组命名太像：A-test、A-temp、A-all 三个组挨在一起，值班员在手机端操作，页面缩放后只看到了前半截。更糟糕的是，他的账号有全场下发权限。
这件事给我的第一个判断是：批量操作不能靠“看仔细”来保障。矿场后台里，凡是会影响算力、钱包、矿池、超频、电源策略的动作，都应该默认缩小范围。测试组和生产组不能只靠名字区分，必须有权限边界。夜班账号只允许动测试组和故障组，不能碰全场；临时工单账号到点自动失效；跨机房操作必须二次确认，并且要在工单里写明机器数量。
后来我们把 HiveOS 里的 Worker 分组重新拆了一遍。不是为了好看，而是为了让误操作没那么容易跨区扩散。每个机房、每个机架、每批测试机器都有固定命名，生产组不允许叫 all、main 这种容易误解的名字。批量下发前，值班员必须截图确认目标数量，群里第二个人回复后才能执行。听上去麻烦，但比凌晨全场救火便宜太多。
告警刷屏半小时，判断不是提醒太少而是没有分级
事故发生后，HiveOS 告警一直在推：掉线、低算力、矿池连接失败、无效份额增加、温度异常。手机震得很勤，但对值班员并没有帮助，因为所有提醒看起来都一样急。
矿场最怕的不是没有告警，而是告警太多却分不出轻重。单台机器离线和一个机架算力同时下跌，不该用同一种声音提醒；矿池短暂拒绝连接和钱包地址被改，也不是同一个级别的问题。
复盘之后，我们把告警分成三层。
第一层是必须立刻叫醒人的，比如同一 Flight Sheet 在 5 分钟内被下发到超过设定数量的机器，多个机架算力同步下降，钱包地址发生变化，生产组被修改超频参数。这类告警直接打电话，不只发消息。
第二层是需要值班员在 15 分钟内确认的，比如单机离线、温度过高、风扇异常、无效份额超过阈值。这些问题要处理，但不该把所有管理人员都吵醒。
第三层是记录类提醒，比如短时间掉线后自动恢复、单台机器重启成功、矿池延迟轻微波动。它们进入日报，不占用夜间注意力。
这里有个细节很关键：告警内容必须带上“变化前后”。只提示“Flight Sheet changed”意义不大，值班员需要立刻看到原配置、目标配置、影响机器数量、执行账号和时间。没有这些信息，告警只是噪音；有了这些信息，告警才是处置线索。
共用管理员账号，判断风险不在密码泄露才出现
我们以前也犯过一个常见错误：为了方便，多个值班人员共用一个管理员账号。理由听起来很充分——夜班人少、换班频繁、临时处理快。但事故一出，后台记录里只显示同一个账号，谁点的、谁确认的、谁改过第二次，追起来全靠聊天记录。
共用账号最大的问题，不是密码一定会泄露，而是责任被抹平。矿场运维不是为了抓人，而是为了在出事时能迅速还原过程。谁在几点登录，改了哪一组机器，执行前有没有审批，执行后有没有复查，这些都要能看见。
我们后来调整了 HiveOS 权限：管理员账号只留给两个人，日常不直接使用；值班员按班次开独立账号；实习和外包只给只读或指定 Worker 组权限；涉及钱包、矿池地址、批量超频、系统升级的操作，一律需要负责人批准。更重要的是，账号离职、调岗、换班后当天处理，不再拖到月底统一清理。
权限收紧之后，刚开始有人抱怨效率低。我的回答也很直接：矿场真正慢的不是审批，而是出事后不知道谁动过。一次误下发导致几百台机器低效运行几个小时，损失足够覆盖很多次正常审批的时间成本。
回滚找不到旧配置，判断预案不能存在脑子里
那次事故最尴尬的环节，不是误操作本身，而是回滚。我们知道配置错了，也知道要改回去，但现场没人能马上确认上一版 Flight Sheet 的完整内容。有人在聊天记录里翻截图，有人找本地文档，有人问白班同事有没有保存过模板。机器还在跑低收益配置，大家却在找“原来是什么”。
这说明我们的回滚预案只是口头预案。真正可用的回滚，必须做到三件事。
第一，关键配置要留版本。Flight Sheet、钱包地址、矿池地址、超频模板、系统镜像版本，都要按日期保存，不允许只保留最新一份。每次修改前先复制旧版本，命名里写清楚用途、机器范围和负责人。
第二，回滚动作要演练。不能等事故来了才第一次尝试。我们现在每周抽 10 台测试机做一次完整流程：下发新配置、触发告警、回退旧配置、确认算力恢复、记录耗时。演练不是表演，重点是看哪个环节卡人。
第三，回滚权限要比变更权限更清楚。谁能回滚、回滚到哪一版、什么情况下允许先回滚后补审批，都要写出来。夜间如果出现大面积掉算力，值班员不能一边等负责人醒来一边看机器空转；但他也不能随便把全场回到一个过期模板。这里需要明确的红线和授权范围。
HiveOS 提供了集中管理的便利，但便利不等于自动安全。矿场要自己把版本、记录、审批、演练补齐，否则系统再好，也挡不住混乱流程。
手机端临时处理，判断方便操作必须配套慢一步确认
很多误操作发生在手机上。不是手机不好，而是矿场现场经常逼着人用手机：人在机房、网络不好、电脑不在身边、负责人催着看结果。小屏幕、弱光、戴手套、页面卡顿，这些细节都会放大误点概率。
我们没有禁止手机端操作，因为不现实。但我们给手机端加了规矩：手机可以查看、重启单台、标记故障；手机不允许直接做跨组批量下发；如果确实要临时处理，必须先在工单里写目标机器编号和数量，再由电脑端账号执行。夜班紧急情况可以例外，但第二天必须复盘，不能把例外变成习惯。
这条规定落地后，现场处理速度没有明显变慢，反而少了很多“先点了再说”的动作。运维系统越方便，越要给高风险按钮多加一道停顿。矿场不是办公室软件，点错一次可能就是几个小时的收益损失。
事故复盘到流程改造，判断今天要先改三张清单
这次事故之后，我没有要求团队写长篇检讨，而是把 HiveOS 运维流程改成三张清单。
第一张是批量操作清单：目标组、机器数量、配置名称、影响项目、执行账号、确认人、回滚版本。缺一项不执行。
第二张是告警分级清单：哪些告警叫醒负责人，哪些由值班员处理，哪些只进日报。告警里必须出现影响范围和最近一次变更记录。
第三张是权限清单：谁能看、谁能改单机、谁能改批量、谁能动钱包和矿池、谁能回滚。每周检查一次账号，每次人员变动当天更新。
如果今天矿场只做一件事，我建议先打开 HiveOS 后台，把所有能批量修改生产机器的账号列出来，再看它们是否真的需要这个权限。然后挑一个常用 Flight Sheet，保存上一版，找 5 到 10 台测试机做一次回滚演练。不要等到凌晨告警刷屏时，才发现你们唯一的预案是“问一下谁知道原配置”。
今天最该防的是 HiveOS 批量操作把一台小故障放大成整排停机
凌晨 2 点 17 分，值班手机只震了三下就安静了。A3 排有 18 台矿机算力掉到 0，HiveOS 面板上先是红了一片，随后又恢复成“在线”。当班同事以为是矿池短暂抖动，按惯例在群里发了一句“观察中”。到 3 点 40 分，我被电话叫醒时，A3 排已经扩散到 A4、B1 两排，合计 67 台机器在反复重启，真正稳定出算力的只剩三分之一。
这次事故后来查清楚了：起因并不复杂，一台机器风扇转速异常，触发了温度告警；值班人员想批量套用一份保守配置，把同型号机器先降频保住运行。但他点选矿工组时多勾了一个标签，配置被推到了另一批不同显存、不同超频参数的机器上。更糟的是，告警规则之前被调得太松，连续重启没有及时升级到电话通知，直到矿池端收益曲线明显断崖，才有人意识到问题变大了。
我写这篇不是为了说 HiveOS 不好用。恰恰相反，矿场离不开这类系统。问题在于，批量管理越方便，事故放大的速度也越快。今天矿场运维最该盯紧的风险，不是面板上有没有红点，而是有没有一套流程能限制“一个误操作”扩散成“整排停机”。
夜班只看到在线：在线状态不能当作机器健康
这次复盘里，最容易被忽略的细节是：大部分机器在 HiveOS 里显示“在线”。
值班人员看到在线，就会本能地觉得机器还活着，问题不大。但矿场真正关心的不是机器有没有连上系统，而是它有没有稳定提交有效份额。事故发生时，有些机器每隔几分钟重启一次，HiveOS agent 会短暂上线，面板看起来并没有彻底失联；矿池端却已经几乎收不到正常 share。
后来我们把夜班检查口径改了。在线率只能排第三，前两项是矿池有效算力和最近 15 分钟拒绝率。如果有效算力低于本地显示算力太多，或者拒绝率突然抬头，即使 HiveOS 仍然显示在线，也要按异常处理。
这条规则听起来简单，但很管用。以前值班喜欢盯着总算力曲线看，现在要求按矿机组看，尤其是同一排、同一电箱、同一批显卡的变化。因为矿场里的事故很少平均发生，通常都是一组先出问题。早发现一组，就能少拖一小时。
批量推配置前多勾一个标签：方便操作必须配限制
HiveOS 的批量管理是矿场效率的来源，也是误操作最容易扩散的地方。
事故当天，值班人员原本只想处理 A3 排同型号机器，但标签命名太随意：A3-3060、A3-old、temp-safe、night-group 混在一起。有人为了方便，给部分机器临时加过标签，后来没删。结果一批本不该接收新参数的机器，被一起推了配置。
复盘会上我没有只追究“谁点错了”。点错当然要承担责任，但更大的问题是系统允许他在夜班一个人完成这种操作。
现在我们把批量操作拆成了三个等级。
第一类是低风险操作，比如重启单台矿机、刷新状态、调整告警备注，值班可以独立完成。
第二类是中风险操作，比如批量重启、切换矿池备用地址、调整轻微超频参数，需要在运维群里发操作截图，另一个人确认机器数量、标签和目标配置。
第三类是高风险操作，包括批量刷系统、批量升级镜像、推送新 flight sheet、修改大范围超频模板，夜间默认禁止。除非出现明确的收益损失或安全风险，必须由负责人电话确认，并留下操作前后截图。
这不是为了把流程搞复杂，而是为了让系统别把人的手滑变成矿场的停机。HiveOS 可以一键推送，我们就必须给“一键”加上刹车。
告警没有升级到电话：消息太多等于没人听见
这次事故里，告警其实发出来了，但没有变成有效提醒。
原因很现实：过去一段时间，矿场温度波动、单卡掉线、矿池短时拒绝都很多，群里每天几十条告警。值班人员慢慢形成习惯，只看红色持续多久，不看每条含义。为了减少打扰，我们还把部分告警的电话通知关掉了，只保留 App 推送和群消息。结果真正该叫醒人的时候，它没有叫醒。
后来我们重新整理了 HiveOS 告警规则，重点不是“多报警”，而是分清楚什么必须升级。
单台矿机掉线 5 分钟，只发群消息；同一机架 3 台以上同时掉算力，发给值班手机；同一矿工组有效算力 10 分钟内下降超过设定比例，直接电话通知；连续重启超过两次，不再当普通离线处理，而是进入事故检查。
还有一条很关键：告警必须绑定动作。比如“温度过高”后面写清楚先看风扇转速、再看环境温度、再决定是否降频；“批量拒绝率升高”后面写清楚先查矿池连接，再查最近配置变更。告警如果只告诉你“出事了”，它很快就会变成噪音。告警如果能告诉你“先查哪三件事”，夜班才有机会稳住局面。
临时账号能改全场：权限松一次就会留下隐患
事故后查操作记录，我们发现一个更危险的问题：当晚执行批量配置的人，用的是一个临时提升过权限的账号。
这个账号原本是为了白天协助新机上架，给过较高权限。按规定当天应该收回，但因为忙，没人处理。到了夜里，它还可以改矿工组、推配置、重启多台机器。也就是说，即使这次没有误操作，权限本身也已经埋了雷。
矿场里最怕这种“临时方便”。临时给权限、临时建标签、临时改模板、临时关告警，单看每一步都有理由，累计起来就会让系统变得不可控。
现在我们的做法是把 HiveOS 账号按岗位拆开。巡检人员只能看状态和备注；夜班可以处理单台机器和低风险动作；组长可以发起批量操作，但需要二次确认；管理员账号只在固定电脑上使用，不再给个人长期登录。临时权限必须写明截止时间，到点就撤，不靠人记。
还有一点我们要求很死：共享账号停用。以前为了方便，几个人共用一个账号，出事后只能知道“这个账号做了操作”，不知道是谁做的。现在每个人单独账号，操作记录能对应到人。不是为了事后甩锅，而是为了让每个人在点确认前多看一眼。
回滚文件找不到：没有退路的升级就是赌博
很多矿场在 HiveOS 上做升级，喜欢盯着新版本能不能提升稳定性、识别新卡、修复驱动问题，却容易忽略一个问题：失败了怎么退？
这次事故虽然不是系统升级引起的，但回滚混乱把处理时间拉长了。我们想把受影响机器恢复到事故前配置，却发现模板版本没有统一备份。有的机器用的是上周参数，有的机器临时改过风扇策略，有的机器备注里写了“勿动”，但原因没人记得。最后只能一台一台比对，越急越慢。
复盘后，我们给 HiveOS 运维加了一条硬规则：任何批量操作前，必须留下可恢复的状态。
具体包括三件事。第一，批量改配置前，先导出或截图当前 flight sheet、超频参数、矿工组名单。第二，新参数不直接推全场，先选 3 到 5 台同型号机器跑满一个观察周期。第三，每次批量操作都要写回滚方案，哪怕只有两句话：回到哪个模板、影响哪些机器、谁负责确认恢复。
回滚不是出了事才想的动作，而是操作前就该准备好的退路。矿场运维里，最值钱的不是你能多快把新配置推下去，而是推错之后能不能在 15 分钟内拉回来。
事故复盘只骂人：流程不改，下次还会换个人出错
事故处理完那天早上，我把当晚所有记录拉出来看：告警时间、操作时间、矿池曲线、重启日志、账号记录、群消息。看完之后很明显，这不是一个人的问题，而是一串小漏洞连在一起。
标签没有清理，权限没有回收，告警没有升级，回滚没有备份，夜班没有二次确认。任何一个环节拦住了，损失都不会那么大。
所以复盘会最后没有停在“以后注意”。“以后注意”在矿场里基本没用，夜里困、机器多、行情波动、老板催收益，人一定会犯错。能防住事故的，是把容易犯错的地方提前堵住。
我们当天就改了四件事：清理所有临时标签；收回超过岗位需要的权限；重写告警升级规则；建立批量操作前后的截图归档。第二天又补了一件：每周随机抽一次回滚演练，挑一组机器模拟配置推错，看值班能不能按文档恢复。
HiveOS 给矿场带来的效率很明显，但效率不能只体现在批量开机、批量换池、批量调参上。真正成熟的运维，是批量动作有边界，告警能叫醒对的人，权限不会越放越大，回滚不是靠记忆。
今天如果你负责一个矿场，建议先别急着研究新版本功能，先打开自己的 HiveOS 后台做六个检查：有没有长期不用的高权限账号；有没有含义不清的机器标签；告警是否能区分单台故障和成组异常；批量操作是否需要二次确认；关键模板有没有备份；最近一次回滚演练是什么时候做的。
这六项查完，可能不会让今天收益立刻变高，但它能减少一次深夜大面积停机。对矿场来说，少一次这种事故，就是实打实的利润。
