文章目录
今天最容易出事的不是矿机离线，而是 HiveOS 批量操作没人拦一下
凌晨两点十七分，我在值班群里看到第一条截图：A 区 3 号架一整排算力从 92% 掉到 41%，HiveOS 面板上红点连成一片。值班员第一反应是网络抖动，准备重启交换机。可我看了一眼操作记录，心里就知道不是网的问题——十分钟前，有人把一组新的 Flight Sheet 推到了“同名标签”的 186 台机器上，本来只该动测试架的 12 台。
这不是 HiveOS 不好用，也不是矿机突然娇气。真正的问题是，我们把“批量管理”当成省事工具，却没有给它配上刹车。
这篇文章不讲概念，只复盘一次矿场里很常见、也很容易被低估的事故：HiveOS 批量操作触发配置错误，告警被淹没，权限边界太宽，最后靠人工回滚救场。站在矿场运维负责人的角度，我现在最想提醒的是：今天如果还没有检查 HiveOS 的权限、告警和回滚流程，出事时掉的可能不是几台机，而是一整片算力。
夜班批量下发配置，判断是标签管理比脚本更危险
这次事故的起点很小。
夜班同事要把一批 GPU 机从原矿池切到备用矿池，原因是主矿池连接延迟偏高。流程上，他应该只选择“测试-备用矿池”标签下的 12 台机器，先跑 30 分钟，看拒绝率、功耗和温度，再扩大到同型号机器。
问题出在标签。
我们之前为了方便分组，把机器按区域、机型、矿池、测试状态都打了标签。A 区的一批机器同时拥有“A区”“3060Ti”“备用池测试”几个标签。夜班同事在 HiveOS 里筛选时，选中了一个看起来很像的标签组，界面上显示数量较多，他以为是包含了多个测试架，没有再二次核对。结果新的 Flight Sheet 直接推到 186 台机器。
很多矿场喜欢把 HiveOS 的标签做得很细，觉得越细越方便。但我的教训是，标签一旦没有命名规范，危险程度不亚于脚本误执行。尤其是夜班、行情波动、矿池不稳定时，人会倾向于快速处理，看到相似名字就点确认。
后来我们做了三条改造：
第一，所有能触发批量配置变更的标签，必须带机器数量上限，例如“测试架-12台-勿扩散”。标签名里不写清楚数量，就不允许用于批量下发。
第二，区域标签和动作标签分开。A 区、B 区只能用于查看和统计，不能直接作为推送对象；“可切池”“可调参”“可重启”这类动作标签必须单独维护。
第三，每次大于 30 台的批量操作，必须在工单里贴出筛选结果截图，包括总台数、机型、当前矿池、目标矿池。没有截图，就算操作成功，也算流程违规。
HiveOS 的批量能力很强，强到足以把一次小错误放大成事故。所以批量管理的第一道防线，不是写更复杂的自动化，而是让每个标签都经得起夜班人员在疲劳状态下使用。
算力告警同时爆发，判断是告警分级没做好
配置下发后，HiveOS 很快开始报警。
我们值班群里先是掉算力提醒，然后是温度异常、矿池连接失败、无效份额升高、离线提醒。几分钟内几十条消息刷屏，看上去很热闹，但真正有用的信息反而被盖住了。
最早出现的告警其实是“矿池认证失败”和“钱包地址异常”，如果当时能第一时间看到，就能立刻判断是配置问题，不必去查交换机、电源和矿机硬件。可告警没有分级，所有消息都用同一个机器人推到同一个群，值班员自然会被最显眼的“离线”和“算力掉”带偏。
事故复盘时，我把告警分成了三类。
第一类是结果告警，比如算力下降、离线、温度升高。这类告警说明已经出问题，但不一定说明原因。
第二类是原因告警，比如矿池拒绝连接、认证失败、钱包字段为空、Flight Sheet 变更后无效份额升高。这类告警必须优先显示，因为它能帮助人快速定位。
第三类是噪音告警，比如单台机器短暂掉线、风扇瞬时波动、短时间内恢复的网络延迟。这类告警不能没有，但不应该在事故初期抢占注意力。
我们现在的做法是：HiveOS 里涉及配置变更后的告警，单独进入“变更观察群”；普通硬件波动进“日常巡检群”；连续 5 分钟以上的区域性算力下跌，才推到“负责人群”。同时规定，只要 10 分钟内同一批机器出现三种以上告警，值班员不能逐台处理，必须先看最近一次批量操作记录。
这条规则救过我们好几次。
矿场最怕的不是报警少，而是报警太多却没有顺序。告警如果不能告诉你先看哪里，它就只是噪音。HiveOS 能提供很多状态，但矿场要自己决定哪些状态该叫醒负责人，哪些只需要留在日报里。
临时账号能改全场配置，判断是权限给得太顺手
事故里还有一个更难看的问题：夜班同事本不该拥有这么大的操作权限。
他是临时顶班，平时主要负责巡检、换线、重启单机。但因为前一周我们人手紧，给他开了较高权限，方便他处理矿池切换。权限开完后没人收回，也没有设定有效期。于是到了这次，他能直接改 Flight Sheet、批量重启、批量应用配置。
很多矿场的 HiveOS 权限问题都不是故意放松，而是忙出来的。今天有人顶班，先给权限；明天有人出差，先共享账号；后天要赶收益，先让大家都能操作。短期看效率高，长期看等于把矿场的命交给每一次点击。
复盘后，我们把权限拆得更细：
巡检人员只能看面板、标记故障、重启单台机器，不能改钱包、矿池和批量配置。
班长可以对小范围测试组执行切池和重启，但超过固定台数必须由负责人确认。
负责人账号才允许修改钱包地址、全场 Flight Sheet 和大规模调参。
临时账号必须设置到期时间，默认 24 小时失效；超过一天需要重新申请。
还有一条很重要：禁止共用账号。以前有些同事觉得共用账号方便，反正都是一个班组的人。出了事故才发现，共用账号最大的问题不是安全，而是无法复盘。你不知道到底是谁点了确认，也不知道他当时依据什么判断。没有责任链，流程就无法改。
HiveOS 不是简单的监控面板，它连接的是矿池、钱包、超频、重启、批量执行。账号权限如果不收紧，就相当于把配电室钥匙、财务章和维修工具放在同一个抽屉里。
回滚靠人翻聊天记录，判断是预案没有真正落地
这次事故花了 38 分钟恢复主要算力，其中最浪费时间的环节是找旧配置。
当时值班员发现配置推错后，想把机器切回原来的 Flight Sheet，却不确定原来每组机器对应哪套配置。群里有人发过截图，工单里有过描述，HiveOS 里也能看到部分历史，但没有一份“当前可用回滚清单”。
于是几个人开始翻聊天记录、查日报、问白班同事。等找到正确配置，已经过去十几分钟。
从那以后，我们把回滚当成每次变更的一部分，而不是事故发生后的临时动作。现在任何 HiveOS 批量变更，工单里必须写四项内容：
要改什么。
影响多少台机器。
失败后回到哪一个 Flight Sheet 或哪一组参数。
谁有权执行回滚。
这四项不齐，变更不允许开始。
同时，我们保留一套“稳定配置库”。它不追求收益最高，只要求能稳定连接矿池、拒绝率低、功耗保守、适用于大多数同型号机器。行情好的时候，大家都想压榨一点收益，但事故发生时，最值钱的不是多 1% 算力，而是能在 5 分钟内把机器拉回能工作的状态。
回滚还有一个细节：不要只回滚软件配置，也要考虑机器状态。有些机器在错误配置下反复重启，回滚后可能不会马上恢复，需要安排分批重启，而不是全场一起重启。我们现在要求，超过 50 台机器的回滚必须分批，每批观察 5 到 10 分钟，看矿池连接、拒绝率和温度，再继续下一批。
这看起来慢，其实比一口气全推更快。因为一旦第二次推错，现场会彻底乱掉。
白班接手时信息断层，判断是交接记录不能只写“已处理”
事故恢复后，早班同事接手，第一句话问的是：“现在到底哪些机器动过？”
值班记录里写着“已回滚，大部分恢复”，这句话对管理者几乎没有用。大部分是多少？哪些没恢复？哪些机器重启过？哪些机器还在备用矿池？有没有钱包地址被改过？这些不写清楚，白班就只能重新查一遍。
矿场运维最怕这种“看起来处理完了”的事故。因为它会留下尾巴：有几台机器仍在错误矿池，有一组参数没有恢复，有些告警被静音后忘了打开。当天看不出来，月底对账时才发现收益少了一截。
所以我们把交接模板改了，不再允许只写结论，而是必须写清楚五个点：
事故开始时间和第一次异常指标。
最后一次批量操作的账号、对象和内容。
已恢复机器数量和未恢复机器清单。
是否涉及钱包、矿池、超频参数变化。
下一班必须继续观察的指标。
这份记录不需要写成长报告，但必须能让下一班在 3 分钟内知道现场状态。HiveOS 的面板能显示当前数据，却不能替你解释刚才发生了什么。交接记录补的就是这块空白。
对矿场负责人来说，事故复盘不是为了追责某个人，而是为了减少下一次同类错误。只要交接模糊，复盘就会变成猜测；只要复盘靠猜，流程就不会真正变好。
今天能马上做的三件事，判断是先把刹车装上
如果你今天也在用 HiveOS 管几十台、几百台甚至更多矿机，我建议先别急着优化参数，先做三件很具体的事。
第一，检查所有能批量操作的标签。把名字相似、用途不清、数量不明的标签清掉，给测试组、生产组、观察组重新命名。凡是会触发切池、调参、重启的标签，都要让夜班人员一眼看懂。
第二，查一遍账号权限。临时账号有没有过期？离职或换岗人员是否还能登录？巡检人员是否能修改钱包和 Flight Sheet？如果答案含糊，今天就该收权限。权限收紧会让操作慢一点，但事故会少很多。
第三，做一次小规模回滚演练。选 5 到 10 台机器，模拟错误配置下发，再按工单执行回滚。重点不是演给老板看，而是验证旧配置找不找得到、谁能执行、告警会不会刷屏、恢复后数据是否正常。
矿场运维不能只靠经验顶着。HiveOS 越好用，越要把批量操作、告警分级、权限控制和回滚流程写死。真正成熟的矿场，不是没人犯错，而是一个人点错时，系统和流程能及时拦住，拦不住也能快速退回来。
今天最该注意的风险点就在这里：不要让一次“顺手批量操作”，变成整场矿机的停机复盘。
