可靠性服务与故障闭环

大规模AI系统的可靠性取决于故障从发现到恢复的整个链路。一个被纠正的内存错误可能只需记录趋势，一次PCIe不可恢复错误可能需要立即隔离设备，一次泵失效则要求备用路径先维持流量，再执行维修。平台需要同时表达故障、身份、动作、执行结果和恢复后的服务能力。

OCP RAS API 0.9为硬件故障管理提供跨组件抽象：以CPER记录错误，以CPAD描述动作，通过独立队列连接硬件、带内或带外管理与分析器。Redfish服务基线补充事件和任务生命周期，设施参考设计则把同样的闭环落实到冗余切换、可维护性和验证试验。S067 pp. 8–15 S034 pp. 13–15, 26 S099 pp. 25–26, 96

统一故障接口先统一可管理对象#

RAS API将参与者分为Initiator与Endpoint。Endpoint提供发现、配置、错误、动作及事件能力，Initiator发起交互；CPU、GPU、加速器与其他组件均可实现这种抽象。协议本身独立于底层传输，可用于带内或带外场景。S067 pp. 8–10

两层拓扑允许上级采集器通过带外管理代理连接片上Endpoint：上级将记录交给分析工具，再把动作送回。这样新增硬件代际时，机队平台可以保留共同采集与路由框架，供应商通过设备类型和扩展记录表达自身故障细节。具体传输映射与产品能力仍要由平台选型确定。S067 pp. 10–11

下面的原图重点看左右两组接口及中间的独立队列。带内与带外消费者拥有各自的错误、动作和事件队列，可以分别收集和处理；它们共享硬件对象身份，同时保持消费状态独立，避免一个消费者清队列后另一个消费者丢失证据。

原图：OCP RAS API 0.9，Figure 3，物理第12页。S067 pp. 11–14

每组错误队列按CPER Header中的最高严重性分成Fatal、Recoverable、Corrected及Informational。Fatal服务于严重故障根因分析，Recoverable往往需要立即干预，Corrected为预测分析保留高频证据，Informational承载可能需要后续维修的信息。它们拥有不同的频率和处置时效，队列大小及中断策略应分别配置。S067 pp. 13–14

错误风暴时，持续对每条记录产生中断可能放大主机负担。规范允许队列在中断和轮询间切换，并可提供首条、半满或90%满等阈值。错误记录还须跨warm reset保留，使重启后的采集器能够提取故障前后证据。队列溢出、采集延迟和复位后保留能力因此都属于接入验收。S067 p. 14

故障身份决定证据能否跟随设备#

同一块物理FRU在不同插槽、主机和软件视图中可能出现不同名称。RAS API使用一组身份字段将记录固定到真实对象：PlatformID唯一标识平台；PartitionID标识该平台内Endpoint，并在带内与带外接口间一致；CreatorID标识产生记录的设备类型，用于路由到正确分析器；FruID标识具体可更换件实例；FruText给现场人员提供能与丝印、标签对应的位置。S067 pp. 16–18

这套身份同时解决历史归因和错误动作投递。以一条DIMM维修建议为例，记录收集时的DIMM可能已被更换。如果动作只指向“某主机的某插槽”，迟到的维修请求会作用于新部件；保留FruID并在执行前核对，可以识别这一变化。动作头中的平台与Endpoint身份也必须匹配，避免错误路由到另一主机。S067 pp. 19, 22–23

时间戳需要表达采集语义。CPER的timestamp可表示系统软件收集错误信息的时间，未必等于物理错误发生的时刻。因此关联一次网络拥塞、供电波动和硬件错误时，要同时保存事件时间、采集时间及已知采集延迟。统一时间同步与测量有助于跨主机排序，准确的字段语义决定排序结果是否可用。S067 p. 17

从错误分析到动作结果形成闭环#

CPAD沿用类似CPER的头、section descriptor和section body结构，每个section表达一个动作及参数。其Urgency描述服务中断紧迫性，Confidence表达分析器提出动作的置信程度，支持运营方制定策略；它们与错误Severity具有不同含义。S067 pp. 18–23

自动化决策可以分成两步：分析器给出动作建议及依据，运营策略再决定是否立即执行、先迁移负载、等待维护窗口或转人工。一个高置信度且紧迫的隔离动作与一个低置信度的预防性换件建议，应该经过不同路径。CPAD提供共同容器，供应商定义的section body保留设备特有能力。S067 pp. 19–23

动作请求进入Action Queue，执行结果通过Event Queue返回，并能关联到原CPAD。若自修复失败，分析器据此改为其他动作或建议更换部件，避免反复提交同一个失败动作。Event Queue主要承载这类故障管理结果，普通电源状态等高频非错误变化可以走其他事件机制。S067 pp. 14–15

0.9版已经清晰定义抽象、记录身份及队列行为，多处发现、配置和队列命令仍待后续版本细化，Action ID也保留。当前技术规划可以据此统一内部事件与动作模型，产品接入则核查设备暴露的命令、传输binding、支持动作与供应商分析器版本。S067 pp. 13–15, 23

服务基线补上事件送达与长任务状态#

Redfish的事件订阅负责向监控者推送条件变化，日志保留记录，OriginOfCondition把消息指向实际资源，ServiceConditions表达当前活动条件。Task资源则通过Running等状态、任务监视入口与Messages跟踪长操作。将这些对象与CPER/CPAD关联，可以统一“硬件发现故障”和“平台完成处置”两端。S034 pp. 13–15, 18–19, 22–26

本文据此建议将一项维护操作记录为有身份的状态转换：检测、确认、保护负载、执行、验证、恢复。每一步保留时间与结果，执行前再次检查FRU和配置版本，执行后回读健康状态及能力。重复通知、采集器重启和超时重试应能回到已有动作记录，而非无条件创建第二次操作。

对于训练作业，设备恢复后还需验证通信和计算性能；对于推理，恢复容量要重新满足延迟与吞吐SLO。硬件Health回到OK是进入功能验证的信号，作业或服务验证才决定何时重新接纳工作负载。资源、拓扑和影响范围之间的对应可延伸到集群组织及数字孪生。

故障注入检验闭环的真实行为#

完整验收需要在Endpoint、采集器、分析器和动作执行端之间注入失效。以纠正错误突发为例，先确认记录进入Corrected队列，再观察中断策略变化、批量采集、分析延迟和历史保留；带内采集器退出后，带外路径应能按其独立队列继续获取证据。通过记录数量与队列状态对账，才能判断数据是否在复位或拥塞期间丢失。S067 pp. 11–14

下一类试验针对动作。先发出可回滚的维护请求并核对CPAD目标，再让执行端返回失败，检查结果是否进入关联Event Queue、分析器是否停止重复相同建议；随后模拟FRU被替换，确认旧动作能被识别为针对旧实例。若动作涉及重置或降级能力，还需验证依赖它的作业和资源管理系统是否得到同步状态。S067 pp. 14–15, 19–23

第三类试验针对服务恢复。监控者失联再连接后，可以从当前ServiceConditions与日志重建现状，再恢复订阅；长任务的结果与任务消息共同保留。若事件收集先恢复、分析器后恢复，系统应能按设备身份和动作记录重新关联，而非依赖消息到达顺序猜测因果。S034 pp. 13–15, 18–19, 22–26

由这些机制推导的评价指标可包括：首次可用错误记录的延迟、采集完整度、错误路由比例、动作完成与验证时长、重复无效动作次数，以及维修后恢复的有效计算能力。指标分别测量采集、决策、执行和服务结果，方便判断改进应该发生在固件、管理链路、分析策略还是现场流程。将失败作业直接重试所消耗的计算时间也纳入记录，可以进一步评价维修优先级与维护窗口的收益。

可维护性将设施冗余转化为可兑现的服务#

Deschutes把CDU输出水视为高可用资源，要求冗余泵在持续运行中可更换，HMI等非关键部件也应支持不中断水流的维护。电气短针、机械互锁、隔离阀、止回阀和无泄漏断接共同控制维护造成的电、压和流量扰动。每一种FRU都要有具体更换过程及净空。S099 pp. 25–26, 39–45

这说明N+1只是初始结构。若备用泵接管时控制器状态错误、阀门无法隔离或拆泵空间被管线占据，冗余就难以兑现。整系统验证要求模拟一台泵失效时的fail-safe响应，并验证电源及电气组件在失效情形下的冗余行为。S099 p. 96

长期可靠性试验进一步把退化纳入测量。Deschutes泵的marathon计划要求至少一年100%转速运行，持续记录压力、流量、转速、功耗和泵温；验收包括仍能维持P/Q设定点、功耗增长不超过5%、拆检无显著内部磨损、软管无退化且无泄漏。这些是资格验证要求，供应商需要提交相应运行和拆检结果。S099 pp. 107–110

机队故障数据与设施资格试验由此形成双向关系：试验定义观察哪些失效模式，现场记录暴露真实频率、部件批次与环境条件；分析结果推动维护策略和下一代设计。未来几年的可靠性能力应围绕可路由的身份、可复核的动作及可度量的恢复建立，才能把服务器、Fabric和设施的故障处理放到同一运营体系中。