文章目录
今天批量改配置前先确认谁能一键推全场
凌晨两点十七分，值班室的门被推开时，手机告警还在连续震。屏幕上不是一台矿机掉线，而是两个货架的算力曲线同时往下折，像被人用刀切了一下。现场同事第一反应是看交换机，第二反应是问电工有没有跳闸，第三反应才打开 HiveOS 的操作记录。结果很快出来：有人把一组测试用的 Flight Sheet 推到了生产标签下，覆盖了 180 多台机器。
这不是我们矿场第一次遇到批量操作失误，但这次最刺眼的地方在于，它没有任何“惊天动地”的技术问题。没有黑客，没有矿池大面积故障，也没有系统崩溃。只是一个账号权限过大、一个标签命名含糊、一次夜间操作没有二次确认，最后变成了一场持续 46 分钟的停算事故。
我是矿场运维负责人。复盘这件事以后，我对 HiveOS 的看法变了不少。以前我们总把它当成提高效率的工具，批量部署、统一监控、远程重启，能少跑机房就少跑机房。现在看，效率越高，误操作的放大速度也越快。今天矿场最该注意的风险，不是 HiveOS 会不会用，而是谁有能力把错误一键推到全场。
夜班改矿池配置：能批量执行就必须能批量止损
这次事故发生在夜班切换备用矿池测试时。
我们原本只准备抽 12 台机器做测试，验证一个新矿池在高延迟网络下的拒绝率。值班同事在 HiveOS 里选了一个自定义标签，标签名字叫 test-rig，按流程应该只包含测试机。但因为前一周有新机上架，临时把部分生产机也挂到了这个标签下面，方便做温度对比。标签没有清理，测试配置就这么被推了出去。
HiveOS 的批量管理很方便，问题也在这里。它不会替你判断“这批机器是不是该被改”，它只执行你给出的范围。对于小矿场来说，点错十几台还能靠人工救；到了几百台、上千台规模，批量操作必须默认带风险。
这次我们把流程改成三条。
第一，测试标签只能由运维负责人创建，普通值班账号不能新建生产相关标签。第二，任何矿池地址、钱包地址、超频模板的批量变更，必须先推到固定 5 台灰度机，观察 15 分钟。第三，HiveOS 里所有带有“全场、生产、主矿池”含义的标签，统一改成带编号和区域的名字，比如 A1-生产-不可测试、B2-灰度-可切换，减少夜间误认。
很多人把批量管理理解成“少点几次鼠标”，在矿场里不够。真正可控的批量管理，应该包含批量前的范围确认、批量中的告警观察、批量后的回退准备。只要缺一段，系统越好用，事故越容易变大。
告警群一直响：消息多不等于有人在处理
事故当天，HiveOS 告警其实很早就提醒了。
两点十九分开始，掉线、低算力、矿池连接失败的消息陆续进入 Telegram 群。问题是同一个群里平时也有风扇转速、温度波动、单卡掉算力等提醒，一晚上几十条很正常。值班同事看到告警时，先按常规判断成网络波动，去看机房交换机和光猫，耽误了十几分钟。
复盘时我们把告警记录拉出来看，最关键的一条不是“某台机器低算力”，而是“同一标签下多台机器在 3 分钟内同时切换异常”。但这个信号在普通消息流里被淹没了。
所以我们没有简单地增加告警，而是砍掉了一部分告警。
现在告警分三类：第一类是单机告警，只进值班群，不打电话；第二类是区域告警，比如同一货架 10% 以上机器掉算力，推送到值班主管；第三类是操作后告警，只要某个账号在 30 分钟内做过批量变更，随后出现大面积低算力，就直接触发电话和短信。
这个改动很实用。以前我们盯的是机器状态，现在同时盯“机器状态”和“刚刚有人做了什么”。HiveOS 里的状态面板能告诉你哪里不正常，操作日志能告诉你不正常之前发生了什么。两者分开看，容易误判；合在一起看，定位速度会快很多。
矿场告警最怕变成背景音。群里一天响几百次，最后谁都不觉得它重要。告警不是越密越安全，而是要让最该被叫醒的人，在最该醒的时候醒过来。
临时账号帮忙上架：权限给出去就要有到期时间
还有一个细节，复盘时让人后背发凉。
执行误操作的账号不是外部人员，而是我们自己给临时上架组开的账号。那段时间新机到货多，白班人手不够，就让夜班协助录入机器、绑定标签、检查在线状态。为了省事，账号权限开得比较宽，能改 Flight Sheet，也能改 Overclocking Profile。
临时账号最容易被低估。大家觉得都是自己人，不会故意乱来。但运维事故多数不是恶意造成的，而是“他以为自己可以这么做”。HiveOS 的权限如果只按人来分，不按任务来分，很快就会变成谁都能碰关键配置。
我们后来把账号分成四层。
巡检账号只能看状态、看温度、看算力，不能重启、不能改配置。上架账号可以添加机器、分配到待验收标签，但不能绑定生产矿池。值班账号可以重启单机、切换指定区域的备用配置，但不能跨区域批量推送。管理员账号只保留给两个人，所有全场级操作必须由管理员执行，并且需要在工单里留下截图和原因。
更重要的是，临时账号必须有到期时间。上架任务结束后，当天关闭；外部维护人员接入时，只给指定时间段；密码不允许多人共用。以前我们也知道这些原则，但没有写进流程，就会在忙的时候被绕过。事故之后，我们把 HiveOS 账号清单固定在每周一检查，谁创建、谁使用、什么时候关闭，都要能查到。
权限管理听起来像办公室制度，其实是矿场停机成本的一部分。少给一个不该有的按钮，可能就少一次半夜救火。
回滚找不到旧模板：没有备份的配置不算配置
事故中最耽误时间的不是发现问题，而是回滚。
当我们确认 Flight Sheet 推错后，第一反应是恢复原配置。但原来的生产模板被改过几次，几个相似名称摆在面板上：prod-main、prod-main-new、main-0415、A区正式。没人敢立刻点，怕再错一次。最后只能找当天白班负责人确认，翻聊天记录、查截图，才把正确模板恢复。
这件事说明一个很简单的问题：如果回滚方案要靠人记忆，那就不叫方案。
现在我们对 HiveOS 配置做了版本化管理，虽然没有搞得很复杂，但足够现场使用。每次修改 Flight Sheet、钱包地址、矿池地址、超频参数前，都要先保存当前版本截图，并在备注里写清楚日期、适用区域、修改人和修改原因。模板命名统一用日期加区域加用途，例如 0428-A区-主矿池-稳定版，测试模板必须带 TEST 字样，并且不能挂到生产标签。
回滚也不再等事故发生才想。每个区域都保留一个“可立即恢复”的稳定配置，只用于应急，不做日常测试。值班手册里写明：如果批量操作后 10 分钟内算力下降超过设定比例，先回滚到该稳定配置，再继续排查原因。先把机器拉回来，再讨论谁的问题。
这条流程救过我们第二次。后来有一次矿池端短时异常，备用配置切换后拒绝率反而升高，值班同事没有继续试参数，而是直接按手册回滚，损失被压在十几分钟内。回滚的价值不在于显得专业，而是在压力最大的时候减少选择。
机房里有人等指令：事故复盘不能只骂最后点按钮的人
很多运维复盘容易走偏，最后变成追责会。谁点错了，谁没看清，谁没及时回消息。这样做短期解气，长期没用，因为下一次还会换一个人犯同样的错。
这次我在复盘会上没有先问“为什么你点错”，而是把事故按时间线拆开：标签什么时候混入生产机，临时账号什么时候开权限，告警什么时候出现，谁第一次看到异常，回滚为什么犹豫。拆完以后大家都清楚，最后点按钮的人只是把前面几个漏洞串起来了。
流程改造要从现场动作开始，而不是写一堆没人看的制度。
我们把夜间变更分成了一个很短的清单：变更前确认机器数量，截图发群；确认标签里是否包含生产机；确认当前稳定模板名称；变更后 5 分钟看在线率，10 分钟看算力，15 分钟看拒绝率；任何一项异常，停止继续扩大范围。清单贴在值班室显示器旁边，也放进手机备忘录。每次操作不用写长报告，但必须按顺序走完。
同时，我们规定凌晨零点到六点不做非必要批量变更。确实要做，必须有两个人在线，一个操作，一个盯面板和告警。矿场最怕“一个人半夜觉得顺手处理一下”，因为这时候人最困、沟通最慢、外部响应也最差。
HiveOS 能把很多事情远程化，但矿场管理不能因此变得随意。越是不用进机房，越要把操作边界写清楚。
今天就能改的三件事：先从账号、标签、回滚名开始
如果你的矿场也在用 HiveOS，今天不一定要大改系统，先做三件小事就够。
第一，打开账号权限看一遍，把能批量修改矿池、钱包、超频配置的人列出来。凡是说不清用途的账号，先停用；凡是临时账号，补上到期时间。
第二，清理标签。测试标签和生产标签不能混用，名字不要靠感觉猜。尤其是那些叫 test、new、temp、A区这种模糊名称的标签，越早整理越好。
第三，给每个区域准备一个明确的回滚配置，名字写到值班手册里。不要等出事时再从十几个模板里猜哪个是旧版本。
矿场运维真正怕的不是系统功能少，而是系统把人的一次疏忽放大到几百台机器。HiveOS 是好工具，但好工具需要配上清楚的权限、克制的告警和能立刻执行的回滚流程。今天下班前，先查一下谁能一键推全场，这件事比多看几次算力曲线更要紧。
