文章目录
今天别让一个批量重启指令把整排矿机带偏
凌晨两点十七分，值班室的手机同时响了三次。第一条是 HiveOS 的离线告警，第二条是矿池算力下滑，第三条来自配电房同事：“A3 排风机声音不对，你们是不是又批量重启了？”我打开面板一看，问题比想象中更难看：同一个 farm 下面 186 台机器，有 74 台刚执行过 reboot，另有 19 台卡在加载配置，算力曲线像被人用刀削了一截。
这不是第一次遇到批量操作出事，但这一次让我下决心改流程。因为事故原因并不复杂：一个夜班同事原本只想重启 A3-12 到 A3-18 这几台频繁掉线的机器，结果在 HiveOS 批量筛选时没有锁定 worker 标签，直接对整个 A3 组下了命令。更糟的是，告警虽然响了，但没人第一时间知道“谁动了什么、动了多少、还能不能退回去”。
矿场运维最怕的不是机器坏，机器坏有备件、有维修单；最怕的是系统操作把小故障放大成一片停机。今天写 HiveOS，我不想再讲面板怎么好看、装机怎么省事，而是站在矿场运维负责人角度，把这次事故复盘清楚：批量管理、告警、权限、回滚，如果没有流程兜住，越方便的系统越容易放大错误。
夜班只想重启几台机器，我判断真正的风险在批量范围没被锁住
事故当天，A3 区有几台机器连续出现掉算力。值班同事按过去习惯，先看 HiveOS 面板，发现温度和风扇转速没有明显异常，就准备重启试一下。问题出在筛选动作上。
我们原本给机器做了命名，比如 A3-12-01、A3-12-02，也做了部分标签。但实际使用时，标签并不完整，有些新换上来的机器还沿用旧名称，有些只归到了 A3 分组，没有细分到机架。夜班同事在 Workers 页面里按 A3 搜索，以为选中的是某一小段，实际勾上的是整排里更多机器。HiveOS 的批量执行很快，确认按钮点下去，几十台同时开始重启。
复盘时我没有先追问“为什么手滑”。在矿场里，把事故归结成个人手滑，基本等于等下一次再发生。真正要问的是：为什么一个普通值班账号能对这么大范围机器下重启命令？为什么批量操作前没有二次确认数量？为什么高风险操作没有自动拆成小批次？
后来我们把批量范围做了三条硬规则。
第一，所有 worker 必须按矿区、排、架、层四级命名，名称不合格不允许进入正式分组。临时机可以上线，但只能进隔离组，不能混到生产组。
第二，批量操作前，值班人员必须在工单里写明目标范围，比如 A3-12 架 1 至 8 号，而不是写“处理 A3 掉线”。HiveOS 面板上的勾选截图要附在工单里，至少让另一个人看一眼数量是否合理。
第三，超过 20 台的 reboot、upgrade、flight sheet 切换，不允许夜班单人执行。确实要做，也必须拆批，第一批不超过 5 台，观察 10 分钟后再继续。
HiveOS 的批量管理本身没问题，问题是矿场经常把它当成“省事按钮”。对运维负责人来说，批量功能要先被限制，再被使用。没有边界的效率，其实就是事故加速器。
告警响了三轮才有人接，我判断告警不是越多越安全
那天凌晨，HiveOS 告警、矿池告警、网络监控告警都响了。听起来系统很完整，但现场结果并不好。原因很尴尬：告警太多，值班人员已经麻木。
我们复盘了一周告警记录，发现 70% 以上都是低价值提醒，比如单机短时掉线、短暂温度波动、矿池延迟偶发升高。这些消息一多，真正重要的“批量重启后算力快速下滑”反而被淹没了。夜班同事看到手机震动，第一反应不是立刻处理，而是先判断“是不是又误报”。
这说明告警系统不能只看有没有，而要看能不能把人推到正确动作上。
我们后来把 HiveOS 告警分成三层：
第一层是提示类，只进入面板和日报，不打电话、不群里刷屏。比如单机 3 分钟内恢复的掉线，单卡温度短时抖动，只记录，不惊动所有人。
第二层是处置类，必须推送到值班群，并要求在 5 分钟内认领。比如同一机架超过 5 台离线，或同一 flight sheet 下机器集体掉算力。认领后要写一句处理动作，不允许只回复“收到”。
第三层是事故类，直接电话和值班群同时触发。比如 10 分钟内全场算力下滑超过 8%，或者同一用户账号执行了超过阈值的批量操作。这类告警不讨论是不是误报，先冻结后续批量操作，再确认现场状态。
尤其是批量操作告警，我们加了一条以前没做的：只要同一账号在 3 分钟内对超过 20 台 worker 执行重启、升级、配置切换，系统侧立即通知运维负责人和值班主管。不是等机器掉线了再报，而是在动作发生时就报。
矿场告警的价值，不在于让手机更吵，而在于把异常和责任人、下一步动作绑在一起。没人认领的告警，只是噪音；能让人立刻停手、查范围、保算力的告警，才算有用。
临时账号能改配置，我判断权限问题比机器故障更危险
事故里还有一个细节：执行批量重启的是夜班账号，但这个账号本来不该有这么大的权限。它是之前赶工扩容时临时开的，为了方便调机，给了较高权限。扩容结束后没人回收，久而久之就成了“大家都能用”的账号。
这类问题在矿场很常见。刚上新机器时，现场忙，老板催，工程师要效率，于是账号权限先放开；等机器跑起来，大家注意力转到收益和故障，权限清理就被忘掉。直到某天一个误操作发生，才发现系统里有好几个账号能改钱包、改矿池、改超频、改 flight sheet。
HiveOS 这种系统用得越深，权限越不能粗放。因为它管的不是几台电脑，而是一整片能直接影响收益的设备。对矿场来说，权限设计至少要分清四类人。
值班人员可以查看状态、重启单台或少量机器、切换已批准的预案配置，但不能新增钱包地址，不能改全场 flight sheet，不能批量升级系统。
维修人员可以查看单机日志、标记机器状态、执行单机维护动作，但不能动矿池配置和批量任务。
运维主管可以审批批量操作、执行回滚、调整分组，但关键动作必须留下记录。
管理员账号只用于系统设置、权限调整和紧急接管，平时不登录，不共享，不放在值班电脑浏览器里自动保存。
我们还做了一个很土但有效的动作：每周一上午导出账号清单，逐个确认最近登录时间、权限范围、是否还在岗位。离职人员当天回收，临时账号设置到期日期。账号名字也不允许叫 admin1、test、night 这种看不出责任人的名称，必须对应到人或岗位。
权限收紧之后，现场一开始会抱怨“不方便”。但运维负责人要想清楚，矿场系统不是给大家图省事的，而是给机器稳定赚钱用的。多花 30 秒申请权限，比凌晨损失几十台机器算力强得多。
配置升级后卡住一片，我判断回滚不能靠临时记忆
这次事故最难处理的并不是重启，而是重启后有一批机器没有正常恢复。有些机器加载了旧 flight sheet，有些机器因为驱动和内核版本不匹配，卡在异常状态。值班同事想回滚，但发现不知道这些机器上一版稳定配置是什么。
这就是很多矿场忽略的地方：大家都知道 HiveOS 可以批量升级、批量切换配置，却没有把“退回上一版”当成正式流程。平时小范围操作，靠老员工记忆还能糊过去；一旦半夜大范围出问题，谁也记不清哪一批机器用的是哪个镜像、哪个超频模板、哪个矿池参数。
事故后，我们把回滚流程写得很死。
每次改 flight sheet，必须保留上一版名称，不能覆盖原配置。命名里要写日期、币种、矿池、适用机型，比如某型号显卡用哪个矿池、哪个钱包、哪个超频参数，一眼能看明白。
每次系统升级，先选 3 到 5 台同型号机器做灰度测试，跑满至少 2 小时，观察算力、拒绝率、温度、功耗和日志错误。测试通过后，才允许扩大到一个机架，再扩大到一排。中间任何一批异常，就停止继续推送。
每次大范围调整前，必须导出当前 worker 列表和关键配置。不要嫌麻烦，真出事时，这份记录就是救命绳。知道“出事前是什么样”，才谈得上回去。
回滚还要有时间要求。我们现在规定，普通配置错误 15 分钟内要能回到上一版；系统升级异常 30 分钟内要能让机器恢复挖矿，哪怕先用保守参数跑起来。运维不是追求每次都完美，而是在事故里先把损失止住。
老员工凭经验救场，我判断流程必须让新人也能照着做
这次凌晨救场，最后还是靠两个老员工远程连上来，一个查操作记录，一个分批恢复配置。事情解决了，但我并不满意。因为如果矿场的安全依赖几个老员工半夜接电话，那说明流程还没长出来。
事故复盘会我要求每个人只回答三个问题：当时看到了什么？做了什么？为什么这么做？不要先讲情绪，也不要先推责任。我们把时间线拉出来，从第一台机器掉算力，到批量命令发出，到告警触发，到现场反馈，到恢复第一批机器，再到全场算力回到正常区间，每一步都写清楚。
写完之后，问题比想象中直观：
没有操作前检查清单；
没有批量数量阈值；
没有高风险动作审批；
没有回滚版本记录；
没有告警认领机制；
没有事故期间的统一指挥。
这些东西听起来像管理话术，但落到矿场就是很具体的动作。谁能点按钮，点之前看哪三项，超过多少台要找谁，出问题先停哪个任务，回滚用哪份配置，恢复后谁去核对矿池算力。写清楚，新人也能少犯错；不写清楚，老员工也会在半夜犯迷糊。
现在我们的值班台旁边贴了一张纸，不高级，但有效：批量操作前确认范围、数量、配置、回滚版本、审批人；执行后 5 分钟看 HiveOS 在线率，10 分钟看矿池算力，15 分钟看拒绝率和温度。任何一项异常，停止下一批。
这张纸比群里喊一百次“大家小心点”有用。
今天要改的不是面板习惯，我判断先把六个动作落下去
如果你也在用 HiveOS 管矿场，今天最该注意的风险点就是：不要让一个批量指令在没人复核、没人限权、没人准备回滚的情况下发出去。行情好坏我们控制不了，矿池波动也不完全由我们决定，但系统操作造成的损失，很多是可以提前挡住的。
我建议今天就做六件事，不用等下次事故。
第一，检查 worker 命名和标签，把矿区、排、架、层补齐。命名混乱的机器先放进单独分组，不参与批量任务。
第二，给 HiveOS 账号重新分权。值班账号、维修账号、主管账号、管理员账号分开，临时账号设有效期，共享账号立即停用。
第三，设置批量操作阈值。超过固定数量的重启、升级、配置切换，必须二次确认，夜班禁止单人执行大范围动作。
第四，整理 flight sheet 和超频模板，保留上一版稳定配置。不要覆盖旧配置，不要靠聊天记录找参数。
第五，重做告警分级。把短时小波动降噪，把批量操作、集体离线、算力快速下滑设为强提醒，并要求有人认领。
第六，做一次小型回滚演练。选 5 台机器，模拟配置异常，从发现问题到退回上一版，记录耗时和卡点。演练中暴露的问题，比真实事故里暴露便宜得多。
矿场运维不是把 HiveOS 用熟就够了，而是要把“谁能动、动多少、出事怎么退”写成日常规则。机器少掉一次大面积停机，流程就已经赚回来了。今天下班前，先把批量操作权限和回滚配置查一遍，这件事比多看几次算力曲线更重要。
