文章目录
今天矿场最该防的一件事 HiveOS 批量指令别直接全场下发
凌晨两点二十七分，值班室里只有一盏屏幕灯。北区 3 号架先掉了 18 台，HiveOS 面板上的红点一排排冒出来，值班同事以为是矿池连接抖动，顺手把之前保存的飞行表重新套了一遍。问题就出在这一下：他点的不是 3 号架，而是整个北区分组。
十分钟后，电话开始响。风机声没变小，但面板上的有效算力掉得很快，部分机器重启后没有正常回到原矿池，另一些机器超频参数被覆盖。早班到场时，故障已经从 18 台扩大到 400 多台。真正的损失不是那几个小时的币，而是我们发现：系统有批量能力，但流程还停留在“谁熟谁来点”的阶段。
这篇文章，我不想把 HiveOS 写成一个功能清单。站在矿场运维负责人的角度，今天最该盯住的风险，就是批量操作太顺手。一旦告警、权限、回滚没有连在一起，HiveOS 越好用，误操作扩散越快。
凌晨误点全区：批量范围必须先被怀疑
事故复盘第一条，不是问谁点错了，而是问为什么他能点到全区。
HiveOS 的分组管理很方便，矿机按机房、货架、币种、显卡型号、矿池策略拆开后，批量套用飞行表、更新矿工程序、调整超频参数都能省很多时间。问题也在这里：分组如果只按“日常方便”设计，出事时很容易被当成“处置范围”。
我们之前的北区分组，就是按机房划的。平时查看很顺，但夜间处理故障时，值班人员看到北区异常，就自然选择北区分组操作。他没有恶意，也不是不会用系统，只是在压力下选择了最容易点到的按钮。
后来我们把 HiveOS 分组改成两套逻辑。第一套是查看分组，用来观察算力、温度、在线率；第二套是操作分组，只允许小范围执行。比如 3 号架、4 号架可以作为操作对象，但“北区整区”默认不允许直接执行重启、换飞行表、批量更新这类动作。
这个改动看起来麻烦，但很有用。运维系统里，展示范围可以大，操作范围必须小。尤其是 HiveOS 这种能同时控制几百上千台机器的系统，第一道防线不是技术，而是把“全选”变得不顺手。
现在我们内部有一条硬规则：任何影响矿池、钱包、超频、系统版本的批量动作，默认不得超过一个货架；超过这个范围，必须升级审批。不是不信任值班员，而是不相信人在凌晨两点还能一直保持清醒。
红点一起跳出来：告警先分级再叫人
那次事故里，另一个明显问题是告警太吵。
HiveOS 面板上出现离线、低算力、高温、矿工重启，本来都是有效信息。但如果所有告警都用同一种方式推到群里，最后的结果就是大家看见一堆红字，却不知道哪条该先处理。夜班同事当时就是被连续告警推着走，想尽快让红点消失，于是用了批量套配置。
复盘后，我们把告警分成三类。
第一类是观察告警，比如单台机器短时间掉线、单卡算力轻微波动、矿工进程重启一次。这类告警只记录，不立刻打电话，不要求马上批量处理。
第二类是处置告警，比如同一货架连续多台掉线、同一型号显卡温度同时异常、同一矿池拒绝率快速上升。这类告警要求值班员先截图、标记范围，再按小分组处理。
第三类是升级告警，比如全区算力下降超过预设比例、钱包地址被改动、飞行表大面积变化、系统版本更新失败超过一定数量。这类告警不能只在群里喊一声，必须打到负责人手机，并暂停相关批量操作权限。
HiveOS 本身能提供很多状态信息，但矿场不能把“收到信息”当成“完成告警”。告警的价值在于告诉人下一步怎么做，而不是把人吓得赶紧点按钮。
我们现在要求每条严重告警都带三个口径：影响机器数量、涉及分组、最近一次批量操作记录。这样一看就知道是设备自然故障，还是人为动作造成扩散。以前大家问“怎么又掉了”，现在先问“掉之前谁动过什么”。这句话不好听，但能救命。
临时账号还在用：权限过宽就是事故燃料
矿场里最容易被忽视的，是账号权限。
很多团队刚开始用 HiveOS 时，账号都是老板、技术、值班员共用，或者给每个人都开很高权限，理由是“出事方便处理”。我们以前也这么干过。后来发现，方便处理和方便闯祸，经常是同一件事。
那次北区事故之后，我们查操作记录才发现，夜班同事使用的是一个临时账号。这个账号原本是给外部技术调试用的，后来没有及时收回，权限还保留着批量修改飞行表、批量重启、批量升级。值班员只是拿来登录，真正的问题是这个账号不该还能做这么多事。
权限改造我们做了三步。
第一步，按岗位拆权限。值班员可以查看、重启单台、标记故障、执行已批准的小范围脚本，但不能修改钱包、不能新建飞行表、不能对大分组执行批量操作。现场主管可以批准货架级动作，但不能直接改全场钱包。负责人保留全局权限，但日常不用主账号登录。
第二步，临时账号设置到期时间。外部维修、矿池协助、系统调试需要登录时，只给限定范围、限定时间、限定动作。事情结束后，账号自动停用，不能靠人记。
第三步，重要动作必须留痕。谁改了飞行表，谁更新了矿工，谁调整了超频参数，谁对哪组机器执行了重启，都要能查。不是为了事后甩锅，而是为了复盘时不靠猜。
权限管理有个误区：很多人以为管权限会降低效率。实际运行下来，效率下降最多的是前一周，因为大家要适应。过了这个阶段，沟通反而更清楚。值班员知道自己能做什么，主管知道哪些动作必须过问，负责人也不用半夜被一堆无效问题叫醒。
HiveOS 给了矿场集中控制能力，矿场就必须把账号当成生产设备管理。账号不收紧，批量管理迟早会变成批量风险。
更新后机器不回算力：回滚不能靠现场记忆
事故当天最费时间的，不是发现问题，而是恢复。
有些机器重新套回原飞行表就好了，有些机器因为矿工版本变化，需要清缓存、重启服务，还有几台因为超频参数被覆盖后不稳定，反复重启。现场人员一边翻聊天记录，一边问“这批之前跑的是什么版本”“这张卡原来核心频率多少”。这说明我们没有真正的回滚方案，只有一群有经验的人在硬扛。
后来我们给 HiveOS 运维流程加了回滚清单。每次批量变更前，必须确认四件事：当前飞行表名称、矿工版本、钱包和矿池地址、超频模板。确认不是口头说一遍，而是保存截图或导出记录，能让另一个人按记录恢复。
对于大于一个货架的变更，我们要求先做影子测试。挑同型号、同网络、同矿池的一小组机器，跑够一个观察周期，再扩大范围。这个观察周期不只看面板算力，还要看拒绝率、重启次数、温度曲线和矿池端有效算力。HiveOS 面板显示正常，不代表矿池端已经正常入账。
回滚动作也要分级。轻微异常，可以单台重启矿工；同一货架异常，回退飞行表；跨货架异常，暂停继续下发，恢复上一版配置；涉及钱包地址、矿池地址、系统版本的异常，直接进入负责人接管，不允许值班员继续试。
我们还给常用配置做了命名规范。以前飞行表名字像“ETH 新”“测试 2”“备用”，出了事根本分不清。现在名称必须包含币种、矿池、矿工版本、适用机型和日期。超频模板也一样，不能只叫“稳定版”。稳定是结果，不是名字。
回滚这件事，平时看起来多余，出事时就是速度。没有记录，恢复靠记忆；有记录，恢复靠流程。矿场规模越大，越不能相信某个老师傅刚好在场。
早班交接只说恢复了：复盘要改掉含糊话
很多事故没有真正结束，是因为交接太粗。
以前早班接夜班，常见说法是“北区夜里掉过，已经恢复了”“有几台不稳，白天再看看”。这类话听起来没毛病，但没有任何管理价值。恢复到什么程度？哪些机器还在观察？有没有遗留配置？是否需要继续追矿池端收益？都没说清楚。
我们现在要求 HiveOS 事故交接必须写成固定几项。
第一，开始时间和发现方式。是面板告警、矿池告警，还是现场巡检发现。
第二，影响范围。具体到分组、货架、机器数量，不能只写“部分”。
第三，已执行动作。包括重启、改飞行表、更新版本、调整超频、切换矿池，每一步写清操作者和时间。
第四，当前状态。HiveOS 面板在线率、平均算力、异常机器编号、矿池端有效算力是否恢复。
第五，遗留风险。比如哪些机器暂时降频跑，哪些账号权限已冻结，哪些配置等待白天复核。
这个交接并不复杂，十分钟能写完，但能减少大量扯皮。作为运维负责人，我最怕听到“应该没事了”。矿场系统里没有“应该”，只有已确认、未确认、待观察。
事故复盘也不能只开会骂人。我们每次复盘只追三类问题：系统有没有挡住误操作，流程有没有提示下一步，人有没有超出权限。只要这三类问题没改，下次换个人还会出同样的事。
今天就能做的六个改动：先把扩散速度降下来
如果矿场已经在用 HiveOS，今天不需要等大改版，先做几件小事。
一是检查所有分组，把查看分组和操作分组拆开。全场、整区这类大分组可以保留观察用途，但不要允许直接执行高风险批量动作。
二是把账号过一遍。离职人员、外部技术、临时维护账号立刻停用；值班账号收掉修改钱包、创建飞行表、大范围批量执行权限。
三是给飞行表和超频模板改名。让名字能看懂适用机型、矿池、版本和日期，别再用“测试”“新版”“稳定”这种模糊词。
四是设置严重告警的升级规则。全区算力异常、钱包地址变化、批量更新失败、矿池拒绝率异常，必须打到负责人，不要只靠群消息。
五是建立变更前截图习惯。批量改动前保存当前配置，至少保证另一个人能按截图恢复。
六是做一次小范围回滚演练。不要等真出事才试，选一个低峰时段，用一组机器完整走一遍变更、观察、失败、恢复流程。
HiveOS 的价值在于让矿场少靠人工盯屏幕，但它不会自动替我们建立纪律。批量管理、告警、权限、回滚这几件事，如果平时各管各的，事故时就会一起失灵。
今天最该注意的风险，不是某台机器掉线，而是一个本来很小的故障，被一次过宽的批量操作放大。矿场运维负责人要做的，就是让每个按钮按下去之前，都有范围、有记录、有退路。这样下次凌晨红点再亮起来，值班员不会急着全场下发，而是知道先停在哪一步。
