文章目录
今天最该防的是 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 台测试机做一次回滚演练。不要等到凌晨告警刷屏时，才发现你们唯一的预案是“问一下谁知道原配置”。
