文章目录
今天最容易出事的不是掉算力，而是 HiveOS 批量命令被错发到整场机器
凌晨两点四十七分，值班室的告警屏突然从绿色跳成一片橙色。不是一台矿机离线，也不是某个机柜温度偏高，而是 3 号仓、5 号仓、7 号仓同时出现算力下滑。最早发现问题的不是系统，而是巡检员老周，他在通道里听到风扇声变了：原本整齐的高转速噪音，突然像被人按低了一档。
我第一反应是矿池异常，第二反应是网络抖动。等登录 HiveOS 后才发现，问题更尴尬：一条本来只准备发给 60 台测试机的批量配置，被发到了 1800 多台机器上。配置内容并不复杂，只是切换内核参数和矿池模板，但足够让部分机型降频、部分机器重启、部分机器进入不稳定状态。
这类事故最难受的地方在于，它不像电闸跳了那样一眼能看明白。面板上还有算力，矿机也没全掉线，可收益已经在流失。更要命的是，出错发生在系统里、命令来自我们自己、执行过程还有记录。复盘时谁都不好推给外部原因。
今天写 HiveOS，我不想再讲“它能批量管理多少机器”。对矿场运维来说，批量管理真正危险的地方，恰恰是它太方便了。一条命令能救场，也能把一个小失误放大成全场事故。
夜班误选整场机器：批量操作必须默认有刹车
这次事故的直接原因很简单：夜班同事在 HiveOS 里选择 worker 时，本来按标签筛选测试组，结果页面刷新后筛选条件没有被再次确认，操作对象变成了整个 farm 下的在线机器。
从人的角度看，这是一个低级错误；从流程角度看，这是我们给了低级错误太大的破坏半径。
以前我们对批量操作的管理，主要靠经验：谁熟悉机器，谁就有权限；谁值夜班，谁就能处理紧急问题。平时这样效率很高，尤其是矿池切换、钱包配置、重启矿机、更新系统这些动作，用 HiveOS 点几下就能完成。可一旦忙、困、网络卡、页面没加载完整，错误也会被放大。
复盘后我改的第一条流程，是把“批量操作”从普通维护里单独拎出来。现在我们把操作分成三类：
第一类是只读动作，看算力、看温度、看离线状态，夜班可以随时做。
第二类是低风险动作，比如单台重启、单机备注、少量机器切池，允许值班人员在规定数量内处理。
第三类是高风险动作，只要涉及批量套用飞行表、批量更新、批量重启、批量修改钱包或矿池模板，就必须二次确认，而且必须截图留档。
更重要的是，HiveOS 里的标签不能只当分类工具，而要当风险隔离工具。测试机、低收益机、同型号机、同机柜、同电力回路，必须有清楚标签。没有标签的机器，默认不进入批量操作范围。过去我们觉得补标签是文书活，现在看，这就是事故闸门。
告警同时响成一片：通知多不等于发现早
事故发生后，Telegram、邮箱、手机推送都响了。听起来我们告警很完善，但真正有用的信息很少。大部分告警只告诉我们“算力下降”“机器重启”“温度变化”，却没有马上指出：这些异常来自同一条批量命令之后。
这也是很多矿场容易踩的坑：告警越接越多，值班员反而越麻木。HiveOS 能给出很多状态变化，可如果没有分层，告警就会像噪音。尤其在大矿场里，一天几十条小告警很正常，风扇、网络、电源、矿池延迟都会触发提醒。久而久之，大家只看红色，不看橙色；只看离线，不看降频；只看数量，不看时间线。
这次之后，我们把告警规则改成了“按事故形态看”，不再只按单台机器看。
比如，同一时间段内，如果多个矿场分组同时出现算力下降，就不再当普通掉线处理，而是直接标记为“疑似批量操作影响”。
如果单台机器重启，是设备问题；如果同一标签下大量机器重启，就优先查 HiveOS 操作记录。
如果温度下降但算力也下降，不要先庆幸散热变好了，可能是频率被降了。
值班员现在接到告警后，第一步不是去重启机器，而是查三件事：最近 30 分钟有没有批量命令、有没有飞行表变更、有没有系统更新或脚本执行。只有确认没有人为操作，才进入网络、电力、矿池排查。
告警的价值不在于响得快，而在于能把人带到正确的排查方向。否则凌晨三点被一堆消息叫醒，最后还是靠猜，系统就只是吵闹的看板。
老账号还在值班群里：权限混乱迟早会变成事故
复盘时还翻出一个更糟糕的问题：有两个离职人员的 HiveOS 子账号仍在系统里，只是很久没登录。还有一个外包维修账号，权限比实际需要大得多，能看到不该看的分组，也能执行不该执行的操作。
这次误操作不是这些账号造成的，但它提醒我们，权限问题不能等到被盗号、误删配置、钱包被改之后才处理。
矿场系统里最常见的权限混乱，有三种。
一种是“人人都是管理员”。早期机器少，几个人一起搭场，大家都用高权限账号，方便是真的方便，后患也是真的大。
一种是“按人情给权限”。某个师傅懂机型，就多给一点；某个夜班反应快，也多给一点。时间一长，没有人说得清谁为什么有这个权限。
还有一种是“账号不随岗位走”。人调岗了、离职了、外包结束了，系统里还留着账号。平时没人注意，出事时才发现门一直没关。
我们现在的做法很笨，但有效：每月固定一天做账号盘点。不是简单看名单，而是逐个核对三件事：这个人现在是否还在岗位上；他负责哪些机器；他是否需要批量执行权限。
夜班账号不再拥有全场批量修改权限，只保留应急范围内的操作能力。需要扩大范围，必须找值班负责人授权。外包维修只给临时账号，到期自动停用。钱包、矿池模板、系统升级这三类操作，单独收紧，不能和普通巡检权限混在一起。
HiveOS 的权限配置如果只是为了“防坏人”，那理解就窄了。更多时候，它是在防正常人犯正常错误。越是熟手，越容易相信自己的操作；越是常做的动作，越容易少看一眼确认页面。
回滚找不到上一版配置：备份不能只靠记忆
事故处理过程中，最耽误时间的一段，是确认上一版稳定配置到底是什么。
有人说昨天用的是 A 飞行表，有人说前天已经改过 B 参数；测试组记录在群聊天里，正式组记录在另一个文档里；个别机型临时调过超频配置，但没有同步备注。最后我们花了二十多分钟才确定可回退版本，又花时间分批恢复。
二十多分钟听起来不长，但对上千台机器来说，就是实打实的收益损失。更重要的是，在压力很大的时候，如果回滚版本不清楚，运维人员可能会二次误操作，把本来能救回来的机器继续折腾坏。
所以流程改造里，我最强调的一点是：每一次批量变更，都必须有可回退对象。
这里说的回滚，不只是“出事了再改回去”。它应该在操作前就准备好：
今天要推哪个飞行表，上一版稳定飞行表叫什么；
涉及哪些机型，哪些机型不参与；
修改前抽样机器的算力、温度、拒绝率是多少；
如果 10 分钟内异常超过多少台，按什么顺序撤回；
谁有权决定停止继续推送。
这些内容不需要写成很漂亮的报告，但必须在操作前能被值班人员看见。我们现在要求，批量动作前先生成一条操作记录，里面写清楚目标、范围、回退方式和负责人。没有回退方式，不允许执行。
HiveOS 本身能帮助矿场快速切换配置，但它不会替你判断哪个版本更稳，也不会替你记住每一次临时改动背后的原因。运维团队如果只会往前推，不会往回撤，系统越自动化，风险越集中。
测试机跑得好：不代表整场都能照抄
这次误发配置为什么没有立刻被发现？还有一个原因：测试组跑得确实不错。60 台机器连续几个小时看起来稳定，算力略有提升，拒绝率也正常。于是大家对这套配置有了信心，误发到大范围后，第一时间没有意识到是配置问题。
但测试机和全场机器从来不是一回事。
同型号矿机也可能有不同批次，不同电源状态，不同风道位置，不同网线质量。靠近进风口的机器能稳定跑，不代表角落里的机器也能扛住。白天温度下没问题，不代表凌晨负载变化、矿池延迟变化时也没问题。
我们现在给批量推送加了三道阶梯。
第一阶梯，测试组，只选状态干净、故障少、便于观察的机器。
第二阶梯，小范围生产组，必须覆盖不同仓、不同机柜、不同电力回路，不能只挑最好管的那一排。
第三阶梯，扩大推送，但每次扩大都有时间间隔，不允许一口气全场执行。
每一步都要看具体指标，不只看平均算力。拒绝率、重启次数、温度变化、离线数量、单机波动都要看。如果平均算力好看，但重启次数增加，这不是成功；如果收益略升，但告警明显变多，也不能算稳定。
矿场运维最怕“看起来没事”。很多事故不是突然炸开的，而是先用几个小异常提醒你，只是你没停手。
复盘开完就散：流程不落到系统里等于没改
事故当天上午，我们开了一个多小时复盘会。以前这种会很容易变成三件事：批评当事人、强调以后小心、群里发一份会议纪要。过几天大家忙起来，旧习惯又回来了。
这次我要求所有结论都必须落到 HiveOS 使用流程和权限设置里，不能只写在文档里。
能用权限限制的，不靠口头提醒。
能用标签隔离的，不靠人工记忆。
能用告警规则触发的，不靠值班员猜。
能提前写回滚方案的，不等事故时现场编。
同时，我们把事故复盘改成固定格式，但不是为了好看，而是为了下次能用。每次复盘必须回答五个问题：谁触发了操作，操作对象为什么会扩大，告警为什么没有第一时间指向原因，权限为什么允许这个动作，回滚为什么没有更快执行。
只要这五个问题有一个答不清，就说明流程还没补上。
对矿场来说，HiveOS 的价值不只是把机器管起来，而是让每一次操作都留下痕迹，让每一次错误都能被缩小范围。真正成熟的运维，不是从不出错，而是出错时知道谁动了哪里、影响了多少、怎么撤回来、下次如何挡住同类问题。
今天如果你负责矿场运维，我建议马上做一个很具体的检查：打开 HiveOS，查看最近一周的批量操作记录，再对照当前账号权限和机器标签。把能全场执行批量命令的人列出来，把没有清晰标签的机器单独标记，把钱包、矿池、飞行表、系统更新这四类动作设成高风险操作。
然后选 20 台机器做一次回滚演练，不为升级，只为确认团队能不能在 10 分钟内找到上一版配置并恢复。演练通过之前，不要轻易做全场批量变更。矿机少跑几分钟测试不心疼，整场机器被一条错命令拖下去，才是真的贵。
