当训练集群从数百卡走向数万卡，硬件故障不再是偶发的意外，而是一种需要被系统性治理的常态。本文系统梳理阿里云容器服务 ACK 面向异构场景构建的故障自愈体系：它如何将节点故障的发现、诊断、隔离、修复与验收，沉淀为一条可自动执行、可分级授权、可按业务编排的闭环。
这套体系是以 Kubernetes 为统一界面：对下，它把 ECS、EGS、灵骏等异构底层的差异，收敛为节点 Condition、Kubernetes Event 事件、自定义资源等 Kubernetes 原生语义；对上，它以这些原生对象作为唯一的交互界面——运维人员、各类 Operator、乃至训练平台，都能以熟悉的、声明式的 Kubernetes 语义方式与自愈体系协作。本文将重点展开它与底层 ECS、EGS、灵骏之间的产品级协同，以及这层"Kubernetes 界面"背后的关键设计与实现细节。
一、规模化异构训练的稳定性之困
大规模模型训练对基础设施的稳定性提出了近乎苛刻的要求。其根源在于分布式训练的强同步特性：成百上千张 GPU 在每一步计算的通信点上彼此等待，任何一张卡、一个节点的异常，都会让整个作业在同步屏障前停滞。单点故障因此被放大为全局停顿——这与传统在线服务"故障域天然隔离"的假设截然不同。在线服务里坏掉一个实例，流量自动绕行、几乎无感；而训练作业里坏掉一张卡，整个作业停摆。这一根本差异，决定了异构训练的稳定性必须被当作一等公民来对待，而不能沿用在线服务时代的运维直觉。
更严峻的是规模带来的统计规律。随着集群节点数线性增长，整体的平均无故障时间随之下降，而故障造成的成本却因作业规模而加速上升。当集群足够大时，"总有节点正在出问题"会成为一种稳定状态。在这种前提下，依赖人工发现、人工研判、人工处置的传统运维模式面临三重挑战：
- 发现与研判滞后。异构故障的信号深藏在硬件与驱动层，往往需要人工排查内核日志、解读 GPU 错误码，才能判断一个异常究竟是应用问题、需要重启，还是必须硬件维修。研判所依赖的专业经验稀缺，且难以规模化复制。
- 处置链路冗长且易错。从隔离节点、驱逐业务，到发起维修、确认恢复、放回集群、解除隔离，是一条环环相扣的长链路。任一环节的人工疏漏（排水时误伤其他作业、维修后未经验收即放回导致坏卡二次污染）都可能引发新的故障。
- 一致性难以保障。同样的故障，不同的人在不同的时间、不同的疲劳程度下，处置质量参差不齐。而大规模集群最需要的，恰恰是每一次都做对、做快、做标准的一致性。
要衡量这些挑战的代价，需要一个统一的标尺——有效算力吞吐：在集群提供的总算力中，真正转化为有效训练或推理进展的比例。有效算力吞吐之所以比"资源利用率"更本质，是因为它衡量的不是"卡有没有在忙"，而是"卡的忙碌有没有产出有效结果"：一个陷入故障等待、反复重算的集群，资源利用率可能很高，有效算力吞吐却很低。
故障从三个维度侵蚀有效算力——发现与响应的延迟让算力在故障后持续空转，修复过程中的资源闲置让节点在漫长处置期内无法产出，故障导致的进度回滚让已经完成的计算付诸东流。这三个维度并非抽象：发现延迟意味着在无人察觉的时间里整个作业的全部算力都在无效空转；处置期的闲置意味着一个节点从被隔离到修复完成的数小时甚至更久其上算力完全停产；而进度回滚最为隐蔽、也最为昂贵——一次未能保存现场的中断，可能让数千卡时的成果一夜清零。集群规模越大、单作业占用的卡数越多，这三重损失的绝对量就越惊人。这也解释了为什么在超大规模训练中，稳定性哪怕只提升一个百分点，背后对应的都是相当可观的算力与成本节约。
因此，故障自愈的目标可以被清晰地表述为：在这三个维度上系统性地压缩损失，把因故障而流失的有效算力尽可能收回。稳定性不再是可靠性团队的内部指标，而是直接关乎算力投入产出比的商业变量。这正是 ACK 故障自愈体系的出发点。
二、体系总览：一条完整的自愈闭环
ACK 故障自愈体系是把资深工程师处理节点故障的完整心智——发现、诊断、通知、决策、隔离、修复、验收、解除隔离——固化为一条自动化流水线，并在关键环节保留人工兜底。其架构自底向上分为五层，各层职责单一、通过标准 Kubernetes 接口协作。之所以采用分层而非一体化的设计，是因为故障自愈天然横跨多个技术域：底层运维、硬件诊断、Kubernetes 编排、业务协同，每一域都在快速演进。分层让各域可以独立迭代——新增一类检测项、对接一种新的底层平台、调整一套编排策略，都不必牵动全局。这种可演进性，对于一个需要长期承载多种异构形态的体系而言至关重要。
- 运维事件层。灵骏裸金属、EGS、通用 ECS 等底层基础设施在硬件或系统异常时产生的运维事件，是掌握硬件真相的第一手信源。
- 检测与转换层。一方面，节点异常探测组件（ACK NPD）在节点上做精细化的软硬件诊断，同时客户也可能安装自己的节点探测组件；另一方面，事件转换能力将底层运维事件翻译为 Kubernetes 可理解的语义。二者共同把"发生了什么"表达为节点上的标准状态。
- 通知层。所有异常统一沉淀为节点状态（Node Condition）与Kubernetes Event事件，并接入事件报警中心，通过钉钉、短信等渠道触达。
- 决策与编排层。自愈控制器根据用户为节点池配置的自愈规则，将节点当前的故障与一套可编排的修复流程绑定，生成一份修复计划并驱动其执行。
- 执行层。一组执行器承接修复计划中的每个动作——隔离、排水、修复、恢复验收、解除隔离——并对接阿里云底层运维(ECS/灵骏)能力完成实际修复操作。
支撑这套架构的，是三条贯穿始终的设计原则，它们也直接对应着前述有效算力的三个维度：
- 检测、决策与执行相互解耦。检测层只负责如实上报，决策层只负责研判与编排，执行层只负责稳健落地，三者通过标准状态接口通信。解耦带来的直接收益是响应速度——故障一旦以标准状态呈现，决策即可自动触发，无需人工在中间传递，从而压缩"发现与响应的延迟"。
- 第二，自动化与可控性并重。体系默认自动推进，但把"是否动我的节点、何时动"的最终控制权交还用户：每个修复步骤都可以独立配置是否需要授权，而授权通过 Kubernetes 原生的节点标签完成——既能由人工确认，也能被上层业务平台自动接管。这让高危操作可以在业务保存好现场之后再执行，从而抑制"故障导致的进度回滚"。
- 第三，全程可观测、超时必兜底。每一次状态跃迁都有可追溯的事件；每一个等待环节都有超时保护，超时一律转告警、转人工。这保证了自动化不会在异常路径上"带病狂奔"，也让修复过程中的资源闲置始终处于可控与可见之中。
贯穿这三条原则的，是"以 Kubernetes 为操作界面"这一原则。 无论底层是灵骏、ECS 还是 EGS，故障最终都表达为节点状态（Node Condition），授权通过节点标签完成，整个修复过程以Kubernetes Event事件。整套体系没有另起炉灶的私有控制面，而是"长"在 Kubernetes 之上、用的都是原生对象。这带来一个直接结果：在 Kubernetes 上与自愈体系打交道，本质上就是与 Kubernetes 打交道——无论是人工运维、上层 Operator 还是训练平台，都无需学习新的接口，就能读懂状态、参与授权、编排策略。异构底层的复杂性被收敛在界面之下，稳定性能力则以最云原生的方式向上开放。
闭环，是这套设计的目的。检测、转换、决策、执行、观测中任何一环的缺失，都会让自愈退化为半自动的辅助工具——要么发现了却修不了，要么修了却不知有没有修好，要么修好了却无人知晓。只有把五个环节闭合成环，并在每个环节都保留人工可介入的接口，自动化才能既跑得起来，又让平台团队放心地把生产节点的日常运维交给它。
以下各章将沿着"检测—转换—编排—授权—执行—观测"的主线逐层展开。
三、精细化检测：从底层信号到结构化诊断
自愈始于发现，而异构场景的发现难点在于：故障信号往往以内核日志中的错误码、设备计数器的跳变等形式存在，常规的资源监控无法识别其含义。ACK 的节点异常探测组件（NPD）为此在每个节点上以 DaemonSet 形式部署，其中面向异构的 GPU / NVSwitch / NVLink / 显存 / 驱动 / 关键服务诊断。
异构节点的故障面，远比通用节点复杂。它既包括 GPU 芯片本身的硬件错误、显存的 ECC 与行重映射异常，也包括卡间高速互联（NVLink、NVSwitch）的链路故障、GPU 与主机之间的 PCIe 通道退化，还包括驱动与内核版本不匹配、关键管理服务离线、乃至 GPU 资源在调度侧核对不一致等"软故障"。每一类都有独特的信号形态与处置方式，也各自对应着不同的算力风险。把这些原本零散、晦涩、需要专家才能解读的信号，统一收敛为结构化、可直接驱动决策的诊断结论，正是精细化检测存在的意义——它把"发现并读懂故障"这件事，从依赖个人经验变成了平台的标准能力。
能够体现体系专业度的，不是检测项的数量，而是每一类故障都被赋予了结构化的处置语义：它的严重级别、是否需要隔离设备、以及建议的修复方向（重启、硬件维修、开启 ECC 等）。正是这组语义，让"同样是 GPU 报错"能够被区别对待：
NPD 检测出来的每一个具体 GPU 故障[1]，都在 Node Condition 或 Kubernetes Event 里有体现（以 XID 79 为例）：
对异构场景而言，"节点级"的处置粒度有时过粗——一台八卡机仅一张卡异常，整机隔离将浪费其余七张好卡。为此，此体系提供了更细的 GPU 卡级隔离能力：当检测到需要隔离的故障时，NPD 探测组件生成一份异常设备清单，ACK Device Plugin 据此将对应的卡故障以及客户自己配置哪些 XID 列表进行隔离，进而从 Kubernetes 可调度资源中摘除，使坏卡不再被调度，实现快速止血；故障恢复后，隔离自动解除。隔离与恢复均以标准事件呈现，全程可观测。
卡级隔离是按需启用的：用户可以精确选择哪些检测项才触发隔离。需要强调的是，自动隔离并不等于自动修复——隔离只是把坏卡摘出 Kubernetes 调度、避免污染新任务，节点仍按实际持有的资源规格照常计费，硬件问题依然存在。因此，卡级隔离需要与节点级的自愈闭环配合，才能真正把损失止住、把硬件修复。这构成了后文将展开的"级联自愈"的基础。
四、与底层基础设施的深度协同：ECS / EGS / 灵骏
在检测之外，故障自愈还有一个同样关键、却常被忽视的环节：把底层基础设施的运维事件，转换为 Kubernetes 世界的标准语义。
这一转换之所以必要，是因为两个形态的表达方式存在差异。底层运维事件是带状态机、会流转的——一次硬件维修事件会经历问询、执行、完成等多个阶段；而 Kubernetes 的节点状态是声明式的、描述当下事实的。要让上层决策能够读懂底层故障，就必须把一个不断流转的事件状态机，完整而可追溯地映射为节点上的声明式状态。
这层映射看似简单，实则要处理不少边界：同一次故障在其生命周期内可能会多次上报，需要正确地去重与覆盖，避免一次故障被误当作多次、触发重复处置；不同来源、不同资源粒度（如普通节点与超节点）的事件需要各自独立地闭合，互不串扰；而事件从"进行中"走向"终态"的那一刻，又必须被准确识别，才能让上层及时判定"故障已解除"。把这些细节可靠地封装在转换层内部，上层决策才能拿到一份干净、稳定、语义明确的节点状态——这正是"解耦"在工程上的价值：复杂性被收敛在恰当的层次，而不是外溢到每一个消费方。
选择声明式的节点状态作为这层通用语言，是因为声明式状态描述的是"此刻的事实"，而非"发生过的动作序列"，这让整个系统天然具备幂等与自愈的能力：无论中间经历了多少次上报、重试或控制器重启，只要节点当前状态明确，决策就能得出一致的结论。对于一个要在大规模、长周期、随时可能发生组件重启的生产环境中稳定运行的系统而言，这种基于当前状态而非历史轨迹的设计，是可靠性的重要基石。
底层不同来源的事件各有其生命周期与运维接口。事件转换能力将它们统一映射为节点状态：以 Node condition type 标识"是什么故障"，以 Node condition reason 标识"进行到哪一步"，并以 Node condition status 的成立与否标识"故障当前是否进入终态"；当事件进入终态，对应的节点状态随之被判定为已解除。下面分别看 ACK 与两类底层形态的具体协同。
4.1 灵骏 CMS 事件
灵骏裸金属节点的硬件与系统异常以 CMS 事件 的形式发布，其生命周期在"问询中 → 执行中 → 已完成 / 已终止"之间流转。ACK 周期性拉取这些事件，识别其类型（如需维修的 Node.HardwareFault.HOST、需重启的 Node.FaultNeedReboot.HOST 等事件），并转换为节点上对应的 Node Condition。
4.2 ECS/EGS：系统事件与主动诊断
ECS/EGS 节点复用 ECS 系统事件 体系，其生命周期涵盖问询、待执行、执行中、已完成、已避免、已取消、执行失败等状态。ACK 通过调用 ECS 的系统事件接口拉取实例运维事件（如 SystemMaintenance.Reboot、SystemMaintenance.Redeploy 等）并映射为节点状态。
除了被动接收 ECS 系统事件，ACK 还为 EGS 场景内置了 主动深度探测能力：当 ACK 节点池开启托管后，节点 NPD 组件探测出特定 GPU 故障后，ACK 会主动调用 ECS 资源诊断报告能力对 GPU 场景进行深度诊断，若满足 ECS 系统事件触发条件，ECS 则会发送对应的 ECS 系统事件，ACK 也会同步把对应的系统事件转换成对应的 Node Condition 和 K8s Event，把"渐进式劣化"的硬件隐患在其彻底恶化之前捕捉出来，让稳定性治理从"等事件上报"前移到"主动探因"。
4.3 GPU 实例的精细化故障探测与卡级隔离
EGS（GPU 云服务器）/ 灵骏裸金属节点承载了大量推理与训练负载。一方面 ACK 对接了 ECS 的系统事件 / 灵骏 CMS 事件转换成原生 Kubernetes node condition 语义，另一方面与 ACK 的 NPD 异构检测、卡级隔离深度结合：客户可以按需开启 GPU 卡级隔离——当检测到严重的卡级故障时，第一时间将坏卡摘出可分配资源，再交由节点级自愈完成后续处置。对一机多卡的推理场景，这种"坏一张卡不影响其余卡"的细粒度隔离尤为关键。
三类形态的底层机制各异，但经过事件转换这一层，最终都收敛为统一的节点状态语义，被同一套决策与执行引擎消费。下表汇总了三者的交互要点：
这正是"事件源与语义解耦"设计的价值：底层平台可以各不相同、并各自持续演进，而上层的决策与执行逻辑始终面向统一的节点状态——底层的多样性，被 Kubernetes 这层统一界面吸收了。
五、可编排的修复流程：为每类故障定制处置策略
识别故障之后，如何修复？ACK 的设计原则是：不预设唯一路径，而是允许为每一类故障编排属于它自己的处置策略。
一份修复计划由若干个按序编排的步骤构成，典型的完整流程包含四个环节——隔离（从 Kubernetes 调度层面阻止新负载调度到故障节点）、排水（优雅迁出存量业务）、修复（重启、硬件维修<需依赖 IAAS 层能力>或服务恢复）、解除隔离（验收通过后恢复 Kubernetes 节点调度）。但"完整流程"只是一种默认，并非唯一：轻微的软故障也许只需要"修复"一步；对关键在线业务，运维可能希望"只隔离、先不排水"，把后续判断交给人；对某些场景，"隔离加告警"即已足够。换言之，每一类故障都可以拥有一套按需裁剪或者配置的处置剧本。
下表以三类故障为例，展示同一套引擎如何承载截然不同的策略：
*以上编排处置流程只是举例说明，实际生产场景客户需要根据自己的业务属性按需编排处理
这种灵活性来自一套两层配置的协作。上层是用户在控制台定义的自愈规则，它决定宏观编排：针对某个故障走哪几个步骤、以何种顺序、每一步是否需要授权。下层是体系内置的处置知识，它填充微观细节：某个具体故障在"修复"这一步究竟应当重启还是维修、需要静默多久才动手、验收要等待多长时间、以及在多故障并存时的处置优先级。两层协作的效果是：用户表达意图，体系补全专业判断——即便只是简单地选择"修复"，体系也知道对硬件严重错误应当维修、对可复位错误应当重启。
以上表第一行的 GPU 硬件严重错误为例：用户在规则中编排的是"隔离 → 排水 → 修复 → 解除隔离"这条宏观路径，并勾选"隔离前"与"修复前"需要授权；而"修复"这一步具体走硬件维修、维修任务如何发起、需要等待多久才算恢复，则由体系内置的处置知识自动补全。用户无需了解某个错误码对应的底层含义，也能得到专业、稳妥的处置。这种"意图与细节的分工"，让灵活性没有以专业门槛为代价——既照顾了资深团队的定制需求，也让经验有限的团队开箱即得一套合理的默认策略。
当一个节点上同时存在多个故障时，体系会按处置优先级排序，优先处理最严重、最根本的那一个，避免在一块已经损坏的硬件上先去做无谓的软件重启。这种"抓主要矛盾"的仲裁，同样是对算力的节省。
值得强调的是这套设计背后的声明式思想：用户描述的是"期望采取怎样的处置策略"，而非"具体如何一步步操作"。声明式带来的最大好处是确定性与可复用——同一份策略可以被应用到成百上千个节点、成千上万次故障之上，每一次都以完全一致的方式被执行，不因规模扩大而走样、不因人员更替而漂移。对于需要长期、大规模运营的集群而言，这种可复制的一致性本身，就是稳定性的重要来源。
ACK 自愈体系将纳入自愈流程的故障分为三类：节点故障、GPU 故障、系统组件与组件故障。
- 节点故障：底层实例产生的系统事件故障（ECS/EGS 系统事件，灵骏 CMS 事件）
- GPU 故障：NPD 精细化探测出的具体 GPU XID 类故障（只处理重启类）
- 系统与组件故障：k8s 系统组件类故障
ECS 节点池对应的故障检测项举例：
灵骏节点池对应的故障检测项举例：
故障处理的优先级：节点故障 > GPU 故障 > 系统与组件故障。
当一个节点上同时出现多种故障时，ACK 会根据故障优先级优先进行自愈处理。例如：当灵骏节点上同时出现 Node.HardwareFault.HOST CMS 事件这类节点故障和"节点容器运行时不可用"的系统与组件故障时，会优先处理 Node.HardwareFault.HOST CMS 事件故障。
六、分级授权：基于节点标签的可控协同
全自动化最大的风险，是对正在承载关键业务的节点"擅自行动"。任何隔离、排水、重启/维修，都可能中断一个已经运行数天的训练作业。因此，"要不要动、何时动"必须由业务方掌握。ACK 为此提供了精确到每个修复步骤的分级授权能力。这套授权交互，构建在 Kubernetes 最基础的机制—— 节点标签（Label） 之上。
当修复流程推进到一个需要授权的步骤时，ACK 会给目标节点打上一个"询问（Inquiring）"标签（例如隔离步骤对应 intervention.autorepair.node.k8s.aliyun.com/quarantine-node=inquiring），表示"我准备对这个节点隔离，请确认"，随即进入等待；在该标签的值被改为"批准（Approve）"（即 intervention.autorepair.node.k8s.aliyun.com/quarantine-node=approved）之前，流程不会向前推进。
值得注意的是，标签的键本身就带有步骤名——每个需要授权的环节使用各自独立的标签，同时允许用户可配置，这正是"逐步骤授权"在机制上的落地。等待期间，ACK 按固定时间间隔持续推送提醒并附上确认指引，确保通知不会被遗漏；一旦检测到批准标签，便立即继续执行。无需授权的步骤，则直接自动推进。整个"询问—批准"的过程，本质上就是围绕一对节点标签完成的一次明确的状态交接。
选择节点标签作为授权的载体，是一个看似朴素、实则关键的设计。打标签是 Kubernetes 最原生、最通用的操作——任何能够访问集群 API 的主体，无论是运维人员手动执行、还是各类 Kubernetes Operator、还是训练平台自身的控制器，都能以完全一致的方式读到"询问"标签、写下"批准"标签。这意味着 ACK 的自愈体系不必为了被集成而暴露任何私有接口或 SDK：它把授权交互沉淀为一套标准的、声明式的 Kubernetes 协议，天然地向上层业务平台开放。客户既有的运维体系、审批流程，乃至自研的调度框架与训练框架，都可以近乎零成本地接入这套授权闭环——监听标签、做出判断、回写标签，仅此而已。
这一机制有两个重要特性。其一，授权是逐步骤、独立的：可以配置成"隔离前询问、排水自动、修复前问询、解除隔离自动"，每一步的授权互不复用，从机制上避免了"一次放行、全程失控"。其二，等待期间若节点自行恢复，体系会优雅退场：若在等待授权的过程中故障已经消失，体系不会再执着于执行隔离或重启，而是自动跳过、判定该步骤完成——把对业务的打扰降到最低。
以灵骏 Node.FaultNeedReboot.HOST CMS 事件为例，当故障产生时，底层故障和 ACK 故障自愈联动的 timeline 如图所示：
关于在等待期间，节点自行恢复（如客户对节点实例进行了手动重启）这种特殊场景的处理流程，ACK 也会保证自愈流程的优雅退场。
更进一步看，客户对自愈流程的掌控是两个正交、可自由组合的维度。
第一个维度，是处置环节的取舍。隔离、排水、修复、解除隔离这四个环节，以及每个环节是否开启人工授权，客户可以按需逐个开启或关闭，裁剪出与自身业务最契合的处置路径。举例说明：
- 四环节全开：隔离（开启授权）→ 排水 → 修复 → 解除隔离，完整闭环，客户在隔离节点环节开启授权，当客户授权隔离后，后续的流程全程交由 ACK 接管；
- 四环节全开：隔离 → 排水 → 修复 → 解除隔离，完整闭环，全程交由 ACK 自动化处理；
- 仅开启"修复"：不隔离、不排水，直接对故障做最轻量的原地修复，适用于可原地恢复、无需迁移业务的软故障；
- 隔离（开启授权）+ 修复 + 解除隔离：客户收到隔离请求后，自己精细化处理业务排水，授权隔离，后续的修复和解除隔离交由 ACK 自动化完成。适用于业务要精细化管理自己节点排水的场景；
- 隔离 + 修复（解除隔离由客户自理）：ACK 负责止血与修复，最后是否放回集群、何时放回，由客户按自己的验收标准决定。
自愈流程的按需开启或者关闭：
第二个维度，是每个环节的授权开关。在已开启的环节之上，客户可以逐个决定它是否需要"询问—批准"的标签授权：既能给关键环节（如排水、修复）单独设卡、等待放行，也能让另一些环节保持全自动。
两个维度自由组合，覆盖了从"完全托管"到"深度自定义"的全部诉求。一个极端是所有环节都不开启标签授权——整条流程完全自动、无人工介入，处置最快，但前提是上层业务能够容忍随时可能发生的中断（例如已具备完善的检查点与弹性恢复能力）；另一个极端是每个环节都设授权——把每一步都置于人工或上层平台的确认之下，把可控性做到最高。绝大多数场景则落在两者之间，由客户依据业务的中断容忍度自行权衡。
分级授权的深层意义，在于它重新定义了自动化与人的关系。传统认知里，自动化与人工控制往往是非此即彼的取舍：要么全自动、失去掌控，要么全手动、失去效率。分级授权提供了第三条路——让自动化承担绝大部分确定性的、可标准化的工作，同时把少数真正需要人来拍板的高风险决策，以清晰、及时、可编程的方式交还给人。自动化不再是"替代人"，而是"放大人"：它让有限的专家精力，被精准地投放到最需要判断的环节上。
每个自愈环节的按需开启授权和配置授权label 标签：
这套基于标签的授权协议，其能力在与上层业务平台结合时才充分显现。以训练场景为例：当 ACK 准备执行会中断业务的修复步骤时，先给节点打上"询问"标签；客户训练平台的 Operator 监听到这一标签后，从容地对作业触发一次模型 Checkpoint 与数据备份，完成后回写"批准"标签放行；ACK 随即接手修复。整个协同没有任何私有对接——训练平台只是在做它本就擅长的事：监听 Kubernetes 对象的变化并作出响应。这样，一次可能损失数小时进展的"故障硬中断"，就被转化为一次有序的"优雅暂停"，训练作业得以从最近的检查点恢复，进度损失被压缩在一个检查点周期以内。
这正是分级授权最直接的价值：它把"授权等待"这段原本纯粹的开销，转化为保存现场的窗口，从根本上抑制了故障导致的进度回滚。对大规模、高频次的训练场景而言，这一机制在集群维度上累积节省的有效算力相当可观。
要把这份价值发挥到极致，检查点本身的效率同样关键。检查点保存得越快、越频繁，一次中断所能回退的窗口就越小；异步化、多级存储的检查点方案，能够在几乎不打断训练节奏的前提下持续压缩这一窗口。与之相辅相成的，是"弹性训练"的理念——当可用节点规模发生变化时，让作业自动收缩或扩展，而不是整体失败。这两者与故障自愈处在不同层次：故障自愈在基础设施层负责把坏节点快速移出、修好、放回；检查点与弹性训练在作业层负责把每一次中断的代价降到最低。二者协同，才能共同把有效算力维持在高水位。而 ACK 的分级授权，恰是连接这两个层次的关键接口——它为作业层提供了一个明确、可编程的介入时机，让"基础设施即将动手"这件事，变成作业可以从容应对的一次协作，而非猝不及防的一次打断。
注意：GPU 卡级别隔离，需要客户根据自己业务实际情况，按需配置。
七、稳健执行：从隔离到验收的工程保障
决策决定"做什么"，执行决定"会不会出事"。修复过程本身若不够严谨，自动化反而可能成为新的故障源。ACK 的执行层在每个环节都以"不伤害业务"为前提做了保障。
隔离与解除隔离尊重节点的原始意图：若一个节点在自愈开始前本就被用户主动设为不可调度，修复完成后体系不会擅自将其恢复——自愈不改变用户既有的运维决策，只回收由自愈自身引入的变更。
排水是最需要审慎的一步。体系优先使用 Kubernetes 标准的驱逐机制，遵循 PodDisruptionBudget，尽量避免驱逐突破业务声明的最小可用副本数；系统级负载与被显式标记为豁免的关键负载受到保护、不被迁出；每个负载都获得合理的优雅终止时间。同时，排水设有整体超时，同时允许客户配置超时时间——它的目标是尽量优雅地清空节点，但不会因为个别顽固负载而让一个亟待维修的坏节点被无限期阻塞。
修复动作依故障类型对接不同的底层能力——如第四章所述的灵骏审批式维修/重启/备机替换、ECS 实例重启与系统事件处理，以及组件类软故障的节点内重启。执行层在此之上负责统一的任务发起、异步跟踪、重试与超时控制。
这里体现的是 ACK 作为云上容器平台的独特优势：它不仅能在 Kubernetes 层做隔离与调度，更能一路打通到底层基础设施的运维能力。许多自建方案止步于"把坏节点标记出来"，却无法真正发起硬件维修——因为那需要与 IAAS 层深度协同。ACK 把这条从容器到 IAAS 底层硬件修复的链路（EGS 迁移 / 灵骏维修或者备机替换）打通并自动化，让"修复"这一步真正闭环自动化，而不是把修复的责任又退回给人。
验收是"修好了才算数"的最后一道关口。每个修复步骤完成后，体系会反复复检节点是否真正从故障中恢复，直到确认恢复或达到该故障对应的等待上限（硬件维修类最长、软故障类最短）。在此之前，节点不会被恢复调度、放回业务；若最终超时仍未恢复，则转为告警与人工接管。
这些看似琐碎的执行保障指向同一个目标：让自愈本身不要反噬业务。每一处对驱逐边界、优雅终止、恢复验收、超时兜底的审慎，都是在防止"自愈"本身成为新的算力损耗来源。
这种审慎，本质上源于一个朴素的认识：一套自动化系统一旦获得了修改生产节点的权力，它的每一个默认行为都必须是保守而可预期的。宁可在不确定时停下来、转人工，也不要在自动化的名义下做出不可挽回的动作。正是这条底线，让上层平台团队敢于把成千上万个节点的日常运维，真正托付给自动化去承担。
八、限流熔断：为万卡集群自愈装上安全阀
在超大规模异构集群中，自动化修复本身也可能成为风险的放大器。当底层硬件出现批量异常时，无节制的并发修复会引发资源震荡甚至次生灾害；而面对机房断电等系统性风险，盲目的自动重试则可能让集群陷入不可用的死循环。ACK通过引限流与熔断机制，为自动化赋予了“安全意识”，确保每一次修复都在可控的边界内执行。
并发限流：化整为零，平滑冲击。针对突发性批量故障，ACK支持精细化的最大并行修复节点数配置。无论是设定固定的串行数量（如每次仅修复1个节点），还是按集群规模动态计算百分比，其核心逻辑都是将“维修风暴”转化为平稳的有序处理，该机制平滑了修复过程的资源波动，消除了大规模重启带来的雪崩风险，最大程度保障了存量训练任务的连续性与集群算力的稳定产出。
全局熔断：紧急制动，防止雪崩。作为集群的“保险丝”，ACK内置了智能自愈熔断条件。当检测到故障节点数超过预设阈值时，系统将立即触发熔断，停止所有新增的自愈动作。这一机制在面对网络割接或驱动大面积崩溃等极端场景时，能够强制止损，避免自动化操作演变为灾难性事故，为人工介入争取宝贵时间。
防御性设计的严谨闭环。值得注意的是，ACK在产品设计层面实施了严格的逻辑校验约束——自愈熔断阈值必须大于等于最大并行修复节点数。这一看似简单的规则，实则构建了限流与熔断之间的逻辑自洽防线，防止因配置错误导致系统在未达到熔断标准前误判，或在达到熔断标准后仍强行修复。
通过这套“限流+熔断+互锁”的组合拳，ACK将稳定性治理从单纯的“速度竞赛”拉回到了“安全与效率并重”的轨道上。它不仅收回了流失的有效算力，更守住了超大规模智算集群的安全底线。
九、可观测与告警：让自愈过程透明可追溯
自动化系统最忌讳成为黑箱。ACK 故障自愈体系把整个过程做成了全程可观测、关键节点主动告警的闭环。
面向系统，自愈过程中的每一个关键动作——隔离、排水、等待授权、修复、验收、完成或失败——都会产生统一来源的集群事件，可被各类观测工具采集，构成排障时最详尽的时间线。面向人，自愈的开始、成功、失败，以及等待授权、等待恢复等关键节点，会通过事件报警中心经钉钉、短信等渠道推送，消息中附带集群、节点、故障原因等上下文。因此上层平台或者客户在使用 ACK 的自愈能力时，我们会要求客户开启 ACK 事件告警能力，方便客户及时关注自愈的进展和相关异常事件，便于异常问题来临时及时介入，及时止损。
落到实处，运维同学有两种一目了然的方式查看某个节点的自愈进展。
其一，查看节点上的 Kubernetes 事件。对于只想快速确认"这台节点现在自愈到哪了"的场景，一条 kubectl describe node <节点名> 就够了——自愈过程中的关键动作（隔离、排水、等待授权、修复、验收、完成或失败）都会作为 K8s Event 挂在该节点对象上，按时间顺序排列，一眼就能看清流程走到了哪个阶段、是否在等待授权、有没有报错。
其二，启用自愈报警管理。ACK 提供了完善的节点自愈报警管理能力。运维人员需开启集群GPU监控告警规则集、集群节点池运维事件报警规则集和集群节点自愈报警这三类核心报警规则集，并配置钉钉、飞书、企业微信或邮箱等通知渠道。该机制包含四类关键报警项：底层事件转换报警在感知到灵骏 CMS 或 ECS 系统事件时触发，确保硬件与系统异常被即时感知；GPU 监控报警由 NPD 检测到设备故障时发出；自愈整体进度报警实时上报隔离、排水、修复及解除隔离各阶段的执行过程；集群节点池自愈汇总则在每天 10:00 和 18:00 定时发送，重点提示等待审批或处于不可调度状态的节点，并附带可直接执行的查询命令。
ACK 通过"被动查看"与"主动推送"的双轨机制，完美平衡了排障效率与响应速度。Kubernetes Events 以标准化的时间轴呈现自愈全流程，满足运维人员即时定位卡点、追溯历史的操作需求；而自愈报警体系则依托底层事件转换、GPU 监控及进度汇总能力，实现从硬件异常到处置结果的主动触达。这种"平时可查、急时必推"的设计，不仅消除了传统运维的信息盲区，更确保了在数万卡规模的常态化故障中，每一次异常都能被即时感知、快速止损并全程留痕，为稳定性治理提供了坚实的可观测底座。
未来 ACK 也会把节点的自愈进展展示到节点池的控制台中，方便客户白屏化查看节点池下每个节点的自愈进度和结果。
需要提醒的是，"人工兜底"能否真正生效，取决于关键事件能否触达到人。因此，需要启用 ACK 相应的报警规则集、确认通知通道畅通，是让整套体系闭环的必要前提。可观测与告警让自愈链路在阳光下运行——问题第一时间被看见、被响应，正是把故障对有效算力的侵蚀降到最低的前提。
十、典型场景：卡级止血与节点级修复的级联
前述能力组合起来，可以应对对可用性要求极高的训练场景，形成一套级联自愈。
当一张 GPU 出现严重的硬件错误时，处置分为两级。第一级是卡级止血：Device Plugin 依据检测结果，第一时间将坏卡从可分配资源中摘除（若客户显式配置了卡级别隔离），阻止新任务被调度到这张卡上继续受损——这一步快速、局部，把故障的影响半径压缩到单卡。第二级是节点级修复：检测信号转换为节点状态后，决策层生成修复计划，对整个节点执行隔离、排水、修复、验收、解除隔离的完整闭环，把硬件问题真正解决。
两级各司其职：卡级的"快"负责即时止血、控制爆炸半径；节点级的"稳"负责彻底修复、并在验收通过后才放回。二者都可按需裁剪——用户可以只对最严重的几类故障启用卡级隔离，也可以为不同节点池配置不同力度的节点级修复流程。这种分级处置，把故障对有效算力的冲击，在时间与空间两个维度上都降到了最小。
十一、产品化：开箱即用的多平台自愈
再完备的能力，若使用成本过高，也难以规模化落地。ACK 将上述体系沉淀为控制台上开箱即用的产品能力，对平台团队而言，有三点尤其值得关注。
其一，处置策略可编排。用户可以为不同故障分别定义修复流程——隔离、排水、修复、解除隔离等环节按需组合，每个环节是否需要人工授权也逐一配置。并将以上能力抽象出自愈规则，自愈规则与节点池解耦，一次定义、多处复用，不同节点池可绑定不同力度的策略。
节点池绑定自愈规则
针对不同节点池类型创建对应自愈规则：
按需选择不同故障检测项：
针对故障检测项配置对应的自愈流程：
其二，零改造接入，多形态一致。规则定义完成后，在节点池的托管配置中开启节点自愈、关联一条规则即可生效，存量与新建节点池均支持，无需改动任何业务代码。灵骏托管节点池、ECS 托管节点池享有一致的体验；ECS 节点池还可额外开启主动探测，满足故障探测条件，会触发对应的 ECS 系统事件，若客户配置对应系统事件的自愈流程，ACK 会根据自愈流程的配置对客户节点进行自愈操作。
其三，全程可控、可观测、可兜底。命中自愈后，流程状态通过消息中心与事件报警中心持续推送；配置了人工介入的环节会等待授权；一旦自愈失败，第一时间告警并转人工。产品化的意义，在于把守护有效算力的能力，从依赖少数专家的经验与值守，变成一个可信、可控、人人可开的开关。
构建一套完整的故障自愈体系——覆盖异构检测、事件转换、流程编排、分级授权、稳健执行与全链路观测——本身是一项需要长期投入的系统工程。把它作为平台能力沉淀下来、开箱即用，意味着每一个使用 ACK 的团队都能直接站在这套积累之上，把精力投向自己的模型与业务，而不是重复建设一套底层的稳定性设施。
创建告警联系人：
创建联系人分组并绑定联系人：
开启自愈相关告警规则集并编辑通知对象：
十二、落地实践建议
体系的灵活也意味着配置需要章法。结合前述机制，对正在规划落地的团队给出几点建议。
以故障的可逆性决定授权策略。一个简明的准则是：客户业务能容忍排水或者中断，可以配置全自动自愈流程。若客户业务越重要，业务中断前需要有自己的业务逻辑，越应设置授权关卡，让客户授权处理，建议在隔离前或修复前设置授权，为业务留出保存现场的窗口。
确保告警通道畅通。人工兜底能否生效，取决于关键事件能否触达到人。上线前应启用相应的报警规则集并确认通知通道可用，否则等待授权的提醒、修复失败的告警都将无人知晓，可控与兜底也就无从谈起。
善用与训练平台的联动。若已有自研训练平台，投入少量集成成本实现"感知自愈信号—自动 Checkpoint—放行"的协同，往往收益最高：它把授权等待这段开销，转化为保存训练现场的窗口，是有效算力收益最直接的一处。
先观察，后收敛。新接入时可先采用"隔离（授权）+ 排水 + 修复 + 解除隔离（授权）"的保守策略观察一段时间，摸清集群的故障分布与自愈行为以及与上层业务的结合，再逐步将成熟、低风险的处置放开为全自动或者半自动。自愈体系的价值，随信任的建立而逐步释放。
把自愈数据用起来。修复计划的结构化记录是一座金矿：定期回看哪类故障最高频、哪些机型或批次的节点故障率偏高、哪类修复最耗时，能够反哺硬件选型、容量规划与供应商管理。把每一次故障都转化为一次数据积累，稳定性治理才能从被动响应，逐步走向主动优化。
十三、与人工运维的对比
回到最初的场景——一张 GPU 报出严重错误。将人工处置与自愈体系逐环节对照，价值落点便一目了然。
省下的不只是单次的处置工时。真正的价值在于规模与一致性：当集群中每天都有节点出现问题时，自愈体系把每一次处置都压缩到最短、执行到最标准，规避了人工在疲劳与经验差异下的不确定性。一致地做对、做快，正是大规模集群最稀缺的能力——而它最终都会沉淀为更高的有效算力。
更进一步看，这张对照表揭示的是一种运维范式的迁移：从"以人为中心、工具为辅助"，转向"以自动化为中心、人为兜底"。在这种新范式下，工程师的角色不再是逐台节点的救火队员，而是自愈策略的设计者与异常情况的最终裁决者。人的价值被抬升到了更高的层次——去定义"什么该自动、什么该人工、什么算恢复"，而把繁琐、重复、易错的执行交给系统。这既是效率的提升，也是工程师体验的改善。
十四、自愈的边界：明确不做什么
一套值得信赖的自动化系统，不仅要说清楚它能做什么，更要说清楚它不做什么。ACK 故障自愈体系有几条清晰的边界。
- 它不追求"零人工"。对不可逆的高危操作，它默认把决策权交还给人；对无法自动确认恢复的情况，设置超时转人工，不会冒险放回到可调度自愈。自动化的目标，是把人从重复、可标准化的处置中解放出来，而不是把人从关键决策中排除出去。
- 它不替代作业层的容错。故障自愈解决的是"基础设施层的坏节点"，而训练进度的保护、作业的弹性伸缩，仍需检查点、弹性训练等作业层能力配合。自愈为它们提供了明确、可编程的介入时机，但不越俎代庖。
- 它不承诺让所有故障都自动痊愈。硬件维修有其客观耗时，个别复杂故障仍需人工介入。自愈的价值，在于把"能自动的部分尽量自动、该人工的部分及时通知并可控接管"这件事做到极致，而非制造"全自动"的幻觉。
十五、演进方向：走向用户可定义的自愈底座
ACK 故障自愈体系当前已内置一批面向异构场景的检测项与处置策略，覆盖了从卡级隔离到节点级维修的完整链路。检测的精细、转换的严谨、编排的灵活、授权的克制、执行的稳健——这五者共同构成了一套既自动又可控的稳定性底座。
下一步的方向是开放：让用户能够基于自定义的节点状态，定义属于自身业务的故障类型，并复用这套"可编排的处置流程 + 分级授权"的引擎，编排出最贴合业务的自愈策略。届时，故障自愈将不再局限于平台内置的检测项，而成为一个可扩展、可生长的稳定性底座。
这一演进的意义在于：每个业务对"什么是故障"的定义并不相同。有的团队关心特定框架的进程健康，有的关心某类自定义指标的越界，有的关心业务语义上的"卡住"。平台无法穷举所有这些场景，但可以把最难、最通用的那部分——异构检测、事件转换、流程编排、分级授权、稳健执行、全链路观测——沉淀为可复用的引擎，再把"定义什么是故障"的最后一公里交还给最懂业务的人。平台做深通用能力，用户做精业务判断，二者结合，才能让自愈真正贴合千差万别的实际需求。
在规模化异构算力成为 AI 竞争力核心要素的今天，稳定性早已不是幕后指标，而是决定算力投入产出比的关键变量。ACK 故障自愈体系所做的，正是把这份稳定性系统化、自动化、产品化，并以 Kubernetes 为统一界面呈现给用户与生态——让异构底层的复杂性收敛在界面之下，让稳定性能力以最云原生的方式被使用、被集成、被扩展。让每一分算力都尽可能花在有效的产出上，这就是这套体系最终的意义。
结论
ACK 面向异构训练场景的故障自愈体系，所回答的是一道具体的工程命题：当灵骏、ECS、EGS 等形态各异、故障语义彼此不一的底层叠加在同一集群之上，如何沉淀出一条具备自动化闭环能力、同时保留可控介入点的节点稳定性治理链路。
这条链路的起点，是把异构底层的故障信号统一收敛为 k8s Node Condition。看似只是一次语义翻译，实则是一个具有分水岭意义的设计决定——它让检测侧与执行侧不再依赖任何内部协议耦合，而以原生 API 对象作为唯一契约。在统一语义之上，自愈流程被显式拆分为隔离、排水、修复、解除隔离四个阶段，每个阶段均可按业务场景扩展处置动作，关键步骤以节点标签为授权凭据，确认后方才执行。这种"自定义自愈流程"+"关键阶段人工授权"的方式，更贴合国内企业对可控性的要求。
自动化同样需要边界，自愈引擎以节点池为作用域设置两道安全阀：并行修复数上限约束瞬时处置规模，故障节点占比阈值在整池异常比例越限时触发熔断——两道约束共同兜住的，是自愈行为在异常输入下的失控风险——限流为处置动作设置吞吐上限，熔断为整体行为设置紧急刹车，二者合力把底层共性故障、监控误报等异常可能引发的连锁反应，收敛在可控范围之内。
与之匹配的是以 Kubernetes Event 为统一事件总线的全链路可观测能力。状态判定、授权请求、处置动作的每一次发生，都作为事件挂载于对应节点对象，既可被 kubectl 现场检视，也可被上层平台订阅、消费与二次编排。可观测在此不是附加特性，而是前述所有机制可被信任、可被追溯的证据来源。
参考文档
[1] 自定义自愈流程：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/custom-node-auto-repair#ce9c08a57e5l4
