文章目录
今天给 HiveOS 批量下发前先查权限，夜班账号最容易把全场带偏
凌晨 2 点 17 分，值班手机连续震了 6 次。第一条是 3 号仓 GPU 掉算力，第二条是温度告警，第三条开始变成整组矿机离线。等我打开 HiveOS 面板时，值班员已经在群里发了一句：“我刚才只改了一个飞行表，怎么全场都在重启？”
这句话我太熟了。矿场出事故，很多时候不是机器突然坏了，也不是系统完全失控，而是一个本来只该影响 20 台机器的动作，被账号权限、批量选择和告警噪音放大成了几百台机器一起波动。
今天写 HiveOS，我不想再从“好不好用”讲起。站在运维负责人角度，最该盯住的是：谁能批量改配置，谁能绕过复核，谁能在半夜把一个错误推到全场。
夜班改飞行表：能点全选的账号就不该随便发
这次事故的起点很小。
夜班发现一个矿池延迟变高，原计划把 3 号仓其中一排机器切到备用矿池。HiveOS 里批量操作很方便，勾选矿机、换飞行表、应用，几分钟就能完成。但值班员选机器时用了标签筛选，标签命名又不干净：3 号仓、3 号仓测试、3 号仓待调、3 号仓旧卡混在一起。
他以为选中的是 48 台，实际勾上了 312 台。
从面板上看，这只是一次普通下发；从现场看，就是三百多台机器开始停挖、重启矿工程序、重新连矿池。更麻烦的是，其中一批卡本来就在降压测试，切换后参数不匹配，出现掉卡和假死。
事故复盘时，我没有先追问“为什么手抖”。因为只要系统允许一个夜班账号对全场做不可逆批量操作，手抖迟早会发生。
后面我们把 HiveOS 账号分成三类：只看面板的巡检账号，只能处理指定农场和指定标签的值班账号，以及需要双人确认的管理员账号。夜班账号保留重启单机、重启矿工、查看日志、处理离线的权限，但不能改钱包、不能改全场飞行表、不能批量刷系统镜像。
这不是不信任人，而是承认人会累、会急、会在凌晨看错一行字。
告警刷屏：同一类消息超过三次就要合并看
事故发生前，其实 HiveOS 已经报警了。
先是几台机器算力掉到 0，然后是矿工重启，再然后是温度异常。问题是我们的群里本来就有太多消息：掉线、恢复、风扇转速、矿池拒绝率、温度跳变，每天几百条。值班员看到告警时，第一反应不是“出事了”，而是“又来了”。
这是很多矿场的通病。告警开得很多，看起来很安全，实际上一旦消息太密，人会自动把它当背景噪音。
后来我们改了两件事。
第一，同一仓、同一标签、同一时间段内的告警不再逐条处理，而是按事件看。比如 5 分钟内同一标签超过 10 台矿机算力归零，就不再把它当单机故障，而是直接升级为批量配置或网络问题。
第二，告警必须带处置动作。以前消息只写“某矿机离线”，现在值班流程要求先看最近 10 分钟有没有批量操作记录，再看网络交换机，再看矿工日志。不是每条都马上重启，尤其不能在原因没查清时连续下发重启。
HiveOS 的告警能力本身够用，关键是矿场要把它翻译成值班员能执行的判断。告警不是为了让群更热闹，而是为了让人更早停手。
管理员在线：权限越大越不能用来救急
事故当天，我远程登录后发现另一个问题：管理员账号一直保持在线，而且多人共用。
这在矿场里很常见。为了方便，老板、技术、夜班组长都知道一个高权限账号。谁都能上去看，谁都能改，出了问题却很难确认是谁动的。
HiveOS 里很多动作都很快，换钱包、换矿池、改飞行表、执行命令、批量重启，真正危险的不是功能本身，而是它们集中在一个没有边界的账号里。
我们复盘后把管理员账号从日常值班里拿掉，改成临时授权。需要大范围操作时，值班员先在工单里写清楚：影响哪些机器、为什么改、预计多久恢复、失败后怎么退回。负责人确认后，再开放对应权限，操作完成就收回。
还有一个细节很重要：不要把“会 HiveOS”当成“可以管全场”。一个熟悉面板的新员工，可能很会看温度、算力和日志，但未必知道哪些机器用的是特殊超频模板，哪些卡不能重启太频繁，哪些矿池切换后会影响结算口径。权限应该跟责任范围走，不应该跟熟练程度走。
这次之后，我们要求每个账号都用个人身份，不再共用；所有批量动作必须能追到具体人；跨仓操作默认禁止。真正需要跨仓时，先建临时分组，做完马上删除。
回滚找不到旧配置：没有留底的升级就是赌运气
最耽误恢复的，不是发现错误，而是回滚时找不到干净版本。
那天错误飞行表下发后，我们想把机器切回原来的配置。结果发现有些标签前一天刚改过钱包备注，有些机器用的是临时矿池，有些测试卡用的是单独超频模板。面板上能看到当前状态，却没人能马上说清楚“事故前每一组到底是什么配置”。
这就让回滚变成了猜谜。
后来我们给 HiveOS 运维加了一条硬规则：任何批量改动之前，必须先留三样东西。
第一，改动前的机器清单。不是一句“3 号仓部分机器”，而是具体到标签、数量、矿机名范围。
第二，改动前的飞行表、钱包、矿池、超频模板截图或导出记录。截图虽然土，但现场好用，尤其是在网络不稳、多人协同时，比口头描述可靠。
第三，回退路径。比如失败后是恢复旧飞行表，还是只切回旧矿池；是全部回退，还是先回退测试组；超过几分钟没恢复算力，就停止继续下发。
我不建议矿场把每次调整都做得像大型变更会，但只要涉及批量，就必须有留底。HiveOS 让批量管理变得很轻，矿场就更要给批量动作加重量。
小范围试跑：10 台机器稳定不代表 300 台没问题
事故后，很多人第一反应是“以后别半夜改”。这句话有道理，但不够。
矿场不可能永远等白天。有时候矿池异常、收益切换、驱动问题、网络波动，确实需要夜间处理。真正要改的是试跑范围。
我们现在规定，任何涉及飞行表、矿池、钱包、超频模板、系统版本的调整，都不能直接打到整组。先选 5 到 10 台代表机器：新卡、老卡、混合卡、温度偏高的机器都要覆盖一点。观察至少一个结算周期或固定时间，再决定扩大到一排、一仓，最后才是全场。
这里的关键不是数量，而是代表性。只挑最稳定的机器试跑，意义不大；只看 HiveOS 面板上算力恢复，也不够，还要看拒绝率、温度、功耗、重启次数和矿池侧显示。
回滚演练也要跟试跑绑在一起。每次测试调整，都顺手做一次撤回。能顺利退回，才说明这次变更真的可控。只会往前推，不会往后退，是矿场运维最危险的状态。
复盘落地：今天先改三张清单
这次事故最终没有造成太大损失，主要因为发现得还算快。但如果发生在行情剧烈波动、矿池结算切换、或者大面积网络不稳的时候，损失会被放大很多。
所以今天如果你也在用 HiveOS 管矿场，我建议先别急着研究新功能，先做三件具体的事。
第一，查账号。把所有能批量操作、能改钱包、能改飞行表、能执行命令的账号列出来，停掉共用账号，夜班账号只保留处理日常故障所需权限。
第二，查告警。把最近 7 天告警翻一遍，看看哪些是真问题，哪些是噪音。对同仓多机同时掉算力、批量重启、矿池拒绝率异常这几类，单独设成高优先级。
第三，查回滚。挑一个正在运行的标签组，模拟一次飞行表调整前的留底：机器清单、旧配置记录、失败后撤回步骤。不要真等事故来了才问“原来怎么配的”。
HiveOS 的优势就是能把几百上千台机器放到一个面板里管，但同样因为太方便，一个错误也能被放大得很快。矿场运维负责人要做的，不是让每个人都更紧张，而是让错误发生时，影响范围被权限挡住，被告警识别出来，被回滚流程接住。今天先从夜班账号开始查，往往比多看十次算力曲线更有用。
