AI 集群的运维组织：SRE 与 OnCall 体系

单台服务器坏了重启就好，几千卡的集群坏了什么都要命。此前的 GPU 故障工程文章讲了故障的机理与自愈手段，但工具再自动，最终按按钮的还是人；组织与值班体系决定故障的平均处理速度。这篇讲人的部分：AI 集群的运维组织怎么搭，值班体系怎么转，事故怎么复盘，知识怎么沉淀。

规模决定形态：AI 集群运维的对象

故障频率的日常化

AI 集群与传统 IT 集群最大的差别是故障的基数。几千张卡的集群里，掉卡、显存报错、网络抖动、存储迟滞每天都会发生若干起，故障不是意外事件而是日常天气。这个基数改变了运维的全部假设：不能指望消灭故障，只能指望快速发现、快速隔离、快速恢复；告警系统如果按传统阈值设计，上线第一天就会被告警风暴淹没。运维组织的所有设计，都建立在「故障是常态」这个前提上。组织规模、流程颗粒度、工具投入，全都从这个前提推导出来。

运维对象的三层结构

AI 集群的运维对象可以分三层：硬件层（卡、机、柜、网络与机房侧设施），平台层（调度器、存储、镜像、监控与任务系统），业务层（训练任务与推理服务本身）。三层的故障表现与处理人不同：硬件故障找集群组，平台故障找平台组，任务失败先归因再路由。很多组织的混乱源于三层没有清晰的归属：任务失败了平台组查半天发现是用户代码的问题，训练变慢了业务组抱怨半天其实链路里有个交换机在丢包。把归属说清楚，是把混乱变成流程的第一步。归属清晰之外，三层还要有共享的语境：统一的故障工单系统、统一的事件分级口径、统一的名词表——「掉卡」「任务失败」「服务降级」在不同组嘴里应该是同一个意思。语言不统一，流程再好也会在翻译中走样。

SRE 的三个组

平台组：让任务跑得起来

平台组负责任务运行的公共底座：调度与队列、存储与数据管道、镜像与依赖管理、监控与日志平台。平台组的产出是所有业务团队共享的服务，衡量它的指标是平台可用性与任务的平均等待时长。平台组最容易犯的错误是只做功能不做可观测性：任务卡在队列里不知道为什么，存储变慢了没有指标线索，最后每次排障都靠登录机器翻日志，代价是每个故障的处理时间都被拉长。

集群组：让硬件活着

集群组负责硬件与基础设施：服务器与网络的巡检维修、机房协调、扩容施工、固件与驱动的版本管理。这是 AI 集群特有的重人力岗位，日常是处理掉卡换卡、交换机端口故障、配合机房检修。集群组与平台组的接口是资源交付：硬件修好、点亮、验收、入池，这条流水线越顺，故障恢复与扩容交付越快，此前的交付链文章讲的外部交付，在这里变成内部交付。

业务组与组间接口

业务侧的工程师负责任务与模型本身，但他们也需要懂故障归因的基本功：区分代码问题、数据问题与资源问题。组织上要有清晰的故障路由规则：任务失败先看自动归因标签，硬件类转集群组，平台类转平台组，自身类留业务组。组间接口的质量决定整体效率：一个模糊的故障工单在三组之间踢来踢去，消耗的是所有人的时间。归因自动化做得越好，路由越准，三个组的无效沟通越少。

供应商与外部协作

AI 集群的运维从来不是关起门来的事：硬件厂商的保修与备件承诺、机房方的电力制冷配合、网络运营商的线路保障，都是恢复链上的环节。厂商的服务承诺要在采购时谈清响应时限与备件库位置，几个小时响应的承诺如果没有本地备件库，实际恢复时间以天计；机房侧的配合流程——进出机房审批、带机操作规范——要提前演练，第一次真实掉卡时才知道预约流程要多久。把外部环节纳入自己的值班演练，恢复时间目标才有意义。

OnCall 体系设计

值班轮换与承受度

值班体系的第一设计约束是可持续。轮换周期以周为单位，一人主值一人备份，避免连续值班造成疲劳累积；值班负载要有量化监控，每周的告警数量与夜间唤醒次数超过阈值就说明告警治理欠债，需要专门排期清理而不是让值班员默默吸收。值班不该是英雄主义舞台，该是平淡的例行运转——大多数夜晚应该无事发生，如果每个夜晚都有事故，说明系统性的问题被值班人力掩盖了，这是组织病症而非个人能力问题。值班补偿与轮换公平也要显性设计：夜间唤醒的调休、节假日的值班倾斜、告警高发时段的支援机制，这些小事处理不好，值班体系会在半年内被抱怨拖垮；轮换表公开透明，谁值过多少次一目了然，公平感是值班体系能长期转下去的润滑剂。

告警分级与升级路径

告警要分级：紧急级（集群不可用、大面积任务失败）电话唤醒，重要级（单机故障、容量越过水位）工作时间处理，提示级（趋势异常）进日报不进夜间。每条紧急告警必须有对应的处置文档链接与明确的升级路径：一线处理多少分钟无进展就升级到下一层，硬件问题何时拉机房供应商，大面积事故何时拉起应急响应。升级路径的价值在于把「要不要叫醒更资深的人」从值班员的个人判断变成制度规定，既保护故障恢复速度，也保护值班员的心理负担。

值班工具与自动化

值班体验取决于工具链。告警要先聚合再通知：同一根源的十条告警应该收敛成一条通知，而不是把值班员连续唤醒十次；每条告警带上处置文档链接与责任组路由，减少「收到告警先查这是谁的事」的时间；常见故障的自动诊断辅助——日志摘要、近期变更清单、相关指标快照——能在值班员打开终端前把一半的排查做掉。自动化做得越深，值班越接近「确认与决策」而不是「从头排查」，这是把值班从消耗变成可持续的关键。

事故指挥：大故障时的临时组织

值班体系处理单点事故，大面积故障需要另一套临时组织：事故指挥。指挥者不亲自修，负责定优先级、分派线路、控制节奏；各技术线并行处置——硬件线查设备、平台线查服务、业务线做隔离与降级；对外沟通设单点出口，向管理层与业务方按固定节奏同步进展，避免十分钟一次的追问打断处置节奏；决策与时间点随手记录，为事后复盘留原始材料。事故指挥的价值不在头衔而在分工：它把「一群人围着看」变成「几条线同时跑」。这个角色平时就要指定并演练过，临时指定从未做过的人，效果等于没有指挥。事故分级与指挥的启动条件要预先定义：影响多少任务或多少业务算大面积、哪些信号触发指挥到位，写成硬条件而不是临场判断；小事不启动、大事不犹豫，是分级响应的两条铁律。指挥权的交接也要明确——原指挥处置到一半换了人，交接清单上要有当前状态、已做动作与下一步计划。

常见事故与演练

AI 集群的经典事故谱系相对集中，值得逐一演练。掉卡事故：单卡故障导致任务失败，验证自动隔离与任务重启机制；网络抖动：交换机端口丢包导致训练吞吐下降，验证网络指标的告警灵敏度；存储打满：数据盘写满导致任务集体失败，验证容量告警与清理预案；单机高温：散热异常导致降频，验证温度监控的覆盖与告警阈值。每类事故做一次故障注入演练，跑通从告警到恢复的全流程，记录真实耗时与演练发现的问题。演练的产出不只是验证预案，更是训练值班员——第一次在真实事故里面对系统的值班员，应该在演练里犯过第一次错，而不是在生产事故里。演练的组织细节决定收获：选低峰时段但保持真实告警链路，演练中发现的问题当场记录、当场不改，留给演练后的复盘会统一处理；复盘会上对流程问题对事不对人，发现的文档缺口当场认领补齐。演练结束不等于结束，改进项跟踪到关闭才算闭环。演练场景的选取从事故统计里来：把过去半年的事故类型排个频次，前几名就是演练主题，演练与真实事故谱系对齐，训练的价值最大；凭想象设计的炫技演练场景，练到的技能在实际事故里未必用得上。

Runbook 与知识沉淀

事故处理的知识必须沉淀，否则组织的能力上限就是最资深那个人的记忆容量。处置文档按「告警—诊断—处置—升级」四段写：每条紧急告警对应一篇，写清检查命令、判断标准与处置步骤，新值班员照着就能处理大部分常规事件。事故复盘按时间线还原：何时发生、何时发现、为何延迟、根因是什么、哪些环节可以更早介入，产出改进项并跟踪到关闭。复盘文化决定沉淀质量：对事不对人的复盘才能挖到流程根因，惩罚性复盘只会教会大家隐瞒。知识沉淀的检验标准很朴素：半年后同类事故的首次响应时间是否显著缩短，新值班员能否独立处理上一季度的事故谱系。做不到，说明写下来的东西没人用，知识库变成了坟场；做得到，组织的故障处理能力才真正随时间复利。值班交接与新人上手也要制度化：交接记录写清未关闭事项与风险点，新人上岗先跟班两个轮次再独立值班，第一次独立值班安排备份在岗。这些仪式感的小制度，是值班体系长期不出人祸的保险丝。文档的语言风格也影响使用：处置文档写给深夜被叫醒的值班员看，步骤要短、命令要可复制、判断标准要可执行，文采在事故现场一文不值；写完之后让没参与过该故障的同事照着走一遍，走不通的地方就是文档的缺口。

让运维可度量：指标与例会

运维组织自身的健康度也要有仪表盘。响应维度：平均发现时长与平均恢复时长按月观察，趋势比单次数值重要；告警维度：每周告警总量、夜间唤醒次数、重复告警占比，上升即治理欠债；容量维度：集群水位、存储水位与排队时长进入周报，提前暴露瓶颈；变更维度：每周变更次数与变更引发的故障数，衡量变更纪律。这些数字进入固定节奏的运维周会：数据摆在桌面上，问题认领到人，改进项下周检查。度量不能替代判断，但能让判断有据可依；运维组织的成熟度，从它能不能说出自己的平均恢复时间开始。

小结

AI 集群的运维组织建立在「故障是常态」的前提上：几千卡的基数让掉卡与抖动成为日常天气，组织的任务是快速发现、快速隔离、快速恢复，而非消灭故障。组织形态上，平台组管任务底座，集群组管硬件生死，业务组管任务本身，组间用清晰的故障路由与自动归因缝合。值班体系的设计核心是可持续：轮换避免疲劳，告警分级保护睡眠，升级路径把判断制度化；告警治理欠债要用专门排期偿还，不能让值班员默默吸收。常见事故要逐一演练，故障注入训练的既是预案也是人；处置文档按「告警—诊断—处置—升级」的骨架写，复盘按时间线还原并跟踪改进项，沉淀的质量用响应时间的变化来验收。工具与组织是一体两面：此前的故障工程讲了系统怎么自愈，这篇讲了人怎么协作，两者的乘积才是集群的真实可用性。