一、阿里云服务器质量智能管理体系

1、云服务器“硬件质量”面临的挑战

在当前GPT等异构场景大爆发的情况下，开发及各种资源都受到了很大的冲击。服务器是连接虚拟与现实的桥梁，是云计算稳定性的重要基石。本次分享聚焦自研服务器，在纯硬件层面探讨如何把硬件做到极致。

从客户的需求角度，大家对高并行交付的需求越来越强烈。从前可能更多是从计算平台演进，现在有计算的平台下又细分为X86平台、ARM平台、GPU平台、阿里自研的倚天平台。大量的平台同步开发要保证质量和效率是一个重大课题。同时，还要快稳定。当前，几乎可以实现一年一迭代，如何在一年之内把产品做到快速稳定。此外，无批量问题是质量治理的永恒话题。

（1）交互的并行度更高

从前围绕Intel平台三年实现一次迭代，而现在一年内会有多次迭代。如阿里云，有Intel的X86、AMD的X86、倚天的ARM、其他的平台的ARM、GPU等大量的平台进行交付。此外，云服务器与传统的服务器设备厂商不同，云服务器要实现芯片整机云同步交付，而整机厂商只做到芯片跟整机同步发布，如CPU和Intel整机同步发布。云服务器的云和芯片要做到同步发布，难度更大。

（2）稳定性周期更短

随着摩尔定律被打破以及大模型的爆发，平台的迭代非常快的，尤其是GPU平台，基本上一年迭代一次。量产则要求稳定，否则可能上一代产品还未稳定，下一代产品就已发货，会导致资源研发、维护难以释放。

（3）问题发现更早

要做到批量问题的治理，其核心是能更早地发现问题。在问题的萌芽阶段发现，使其不演化成为批量问题，在当前的高并行交付下尤为重要。多个平台并行开发、并行上量，有限的资源要更早地把问题发现、扼杀于萌芽阶段。

（4）修复更快

在更早地识别出问题后，如果线上的存量没有修复，风险仍未解除。而硬件在线上的升级较为困难，除了BMC无感升级之外，升级时的机器轮转成本较高，而且要求从客户层、业务层再到服务器的硬件层互相配合。

基于此，我们可以发现传统服务器的开发和质量管理模式已经无法满足当下的需求。

2、应对策略

基于以上四个挑战，我们也可以通过以下四个方面应对。这四个方面又可以从两个不同的角度出发。

第一，三个重构。传统的设备厂商更关注故障率，阿里云更关注场景，不同的客户对于服务器的质量标准有不同的诉求。基于客户场景及高并发的开发模式，阿里云质量标准有三个重构。其一，质量标准是基于不同场景的客户不同需求重构的质量标准；其二，在高并发模式下，为实现芯片与整机、云同步发布，开发流程进行了重构；其三，关于交付模式，为应对突增的海量上量，实现快速稳定上量，交互模式进行了重构。

第二，六个归一。阿里云磐久服务器实现了全域自研，从架构、硬件、软件、测试、部件、制造全部归一。归一之后，可以把所有的关键变量降到最低，将复杂的问题简化，降低出错的概率。

这两个策略的本质是基于客户需求、减少变量，后两个策略则是阿里云特有的，也是阿里云质量超越业界的核心。

第三，一个全场景。阿里云有百万级的客户，设计各行各业的应用。场景是最难研发测试的，只有上线才会遇到，但阿里云的场景经过了多年的打磨，其测试用例不断完善，很多场景类的问题在研发的用例已经可以测试出，这是阿里云特有的全场景优势。

第四，一个智能体系。阿里云有质量大数据的金矿，将交付链路全部数字化，所有的数据经由智能分析系统、智能修复系统、智能分析和修复系统，在萌芽阶段发现问题，通过无感修复解决问题。同时，数据系统会驱动全链路不断进行优化，精准改进，保证投入产出比达到最佳。

（1）三个重构

①标准重构

传统模式下多基于故障率的套标准，虽然有多项指标，但基本都以故障率为核心。阿里云与之不同，它在传统的故障率的指标之上增加了各类云服务特有的客户体感质量指标。

如弹性计算，它更关心非预期宕机。当硬件故障率达到一定的水平时，非预期宕机不一定能满足客户的要求。因此，弹性计算需要更早的预测，进而通过强大的牵引能力避免客户宕机。但这不适用于当前的大模型，大模型更关心中断次数，减少中断次数和维修时间是核心。要缩短维修时间，我们需要强大的智能监控实现自动诊断。GPU服务器的链路相对复杂，我们需要实时地确定是软件问题或是硬件问题，阿里云在这个方面有强大的智能诊断、软修复系统。不同的云服务有不同的客户体感指标，这也是所有流程和模式重构的最基础的出发点，即真正让每个云服务场景的客户都能感受到质量。

②流程重构

传统的设备厂商只进行到芯片和整机同步发布即可，而阿里云要进行到芯片、整机和云实例同步发布。从开发流程的角度，传统厂商在DVT后量产基础，而阿里云从EVT开始发货，与业务联调，和所有的业务场景适配。在最终CPU和GPU发布时，阿里云已经完成了所有的业务场景，包括服务器自身硬件的测试、业务场景的适配，实现芯片、整机、云实例同步发布。

③模式重构

早期的阿里云以JDM模式为主，但在后期，我们要求快速复制、减少关键变量、快速上量后产能无缝互补，因此，交付模式也发生了很大改变。

通过三个重构，阿里云构建了芯片、整机和云同步发布。阿里云服务器的开发流程与交互模式核心是灰度治理。在与业务适配、研发测试过程中，早期发货机型的灰度和各个场景的灰度接入了智能的分析系统。初期，智能的分析系统发现萌芽阶段的问题并进行智能修复，然后在平台发布和稳定。

（2）全域自研归一

即把所有的变量减少到最小。

①架构归一

2017年之前，阿里云直接采购各家的服务器，仅统一了标准规格，每个厂商按照阿里的规格设计服务器。这样，基于一代产品，阿里云要管理n个新产品。每个厂商所有的架构用例、BOM都不同，这表明早期阿里云只能以规格验收行形成一个通用的测试用例，但需要控制的变量十分庞大，管理成本非常高，也很难保证质量。2017年以后，阿里服务器开始全域自研，逐步从整机到部件、芯片，如倚天芯片大幅减少变量，各领域的质量也在持续提升。阿里云架构归一到方升架构。

②硬件归一

无论是哪个厂商生产的原理图和BOM，最后都归于一份。

③软件归一

即使用一个平台、一套代码。

④测试归一

包括阿里自研的测试工具、全场景前移的测试用例。

⑤部件归一

包括大量的自研部件，某些没有资源的部件也实现了白盒化，把PSU、风扇、线缆进行白盒化管理。

⑥制造归一

所有的制造均只有一套DFM，所有厂商都可以平滑复制，把关键变量降到最低。

（3）全场景

阿里云有全场景持续迭代的层次化测试体系。阿里云从芯片到板级，到整机，一直到机房和业务的前置都有完整的层次化测试体系。且阿里云有全场景打磨的测试用例，百万级客户的各类应用场景持续打磨是测试中很重要的输入。此外，超级大规模的极端大策压测演练，也是研发场景不具备的。

（4）智能管理

重点在于“智能”在哪里以及如何构建大数据驱动的云服务器质量管理体系。即使是非常完善的开发、测试体系，也只能是尽可能地减少问题的发生，但无法彻底杜绝问题。因此，我们还要构建快速发现问题和快速修复问题的能力。

服务器的稳定性治理有两个痛点，一是批量问题，二是是新产品早期故障率高的问题。传统的故障率治理模式是基于对故障率的监控，而对故障率的监控存在缺陷，只有当故障率出现异常才会发现、治理，这段时间会超过SLA的管控。另一个是场景类的问题，通过故障率的监控模式是失效的，这也是传统模式很难及时发现问题、治理的原因。理想的模式是在萌芽阶段发现相关的问题，快速修复。即在不影响SLA的情况下，彻底解决问题。

传统的自建IDC，要达到上述的理想状态，有两个关键要素。第一，要有全场景的数据；第二，要有强大的分析体系，通过该体系智能地进行7×24小时的分析，维护资源是无限的。而传统的自建IDC模式无法解决这两个痛点。第一，其数据不完整，各个厂商的接口、数据格式不同，很难拿到全链路的数据。从研发到生产、运输、上架、后期应用，包括机房环境尤其是租用的机房，这些精细的数据很难获取。此外，海量的数据分析很难实现，很难使用算法分析出批量问题。

第二，修复慢。系统级的无感修复需要从产品的设计开始规划，包括软件和平台的建设，且各厂商的修复、升级能力千差万别。传统的自建IDC由于缺乏系统级的无感修复，因此很难实现在萌芽阶段的问题发现和治理。

阿里云通过阿里云的智能预警、分析和修复系统实现萌芽阶段问题的发现和快速修复。它主要分为两个系统，一是沧海系统，它是对数据层的分析，包括智能预警和智能分析；一是啄木鸟修复系统，发现问题后通过智能的修复平台自动修复轮转。所有智能预警的首要核心是数据，所以，阿里云从生产到发货，所有的部件的温度、环境、性能、功耗、业务、机房等各个维度都实现了数字化。这些数字化的数据在定位问题尤其是定位场景问题时极为关键。当有了全链路的数据之后，多平台的并行开发对所有厂商的开发、维护人力提出了挑战。但在智能分析系统之后，我们有了无限的维护资源，可以24小时实时分析数据。

对于数据的分析，阿里有批量问题的算法、基于趋势的算法、基于传统故障率的算法、基于故障特征的算法、基于定位思路（把研发的定位问题的思路转化成算法）的算法，还可以对采集的所有数据进行交互式分析，快速定位到场景下异常的规律，进而缩小到精细的场景。如果使用定位思路算法可能它会直接告知答案并触发预警。有一个案例，某租用的机房，冬天较为干燥需要加湿，但用于加湿的水存在问题，一般而言会导致大量机器被腐蚀。但在没有大量机器损坏的情况下，通过监控风扇和PSU的故障率，发现了精确到柜列的某个机器，其风扇和PSU的故障率与其他排的机器不同，就此精确地找到了问题所在，提前治理，及时阻止了批量掉电情况的发生。该案例中，对于问题的定位精细到了机柜，按机型、产品、代次、厂商等所有相关的数据从各个维度进行分析，超越了人的能力。

该过程非常重要，可以保证所有的问题在萌芽阶段被发现、解决，其中完善的数据决定了发现时间的粒度和分析的准确性。有了这些数据，就有了7×24小时的自动分析，可以很快地给出解决方案。从前，问题发生后可能要和客户沟通，获取相应的日志，再进行沟通，需要经历几天的时间才能找到问题所在，但复现又是一个难点。但阿里的预警分析可以找到精确的异常点，包括研发，可以很容易找到该场景复现。此外，问题定位、公关时间也会大幅缩短。这一系列质量问题的治理都在传统的基础上有了极大的效率提升。

在给出解决方案后，啄木鸟的智能修复平台可以实现解决方案的灰度。而灰度有其独立的算法，即使发生异常也不会触发集群的SLA。通过灰度后，它会通过大规模的智能调度，与业务上层的机器互动，自动轮转升级。因为升级是无感的，而有感的升级会根据业务的预埋轮转与自动轮转对接，此外，还有的升级以后借助业务正常重启升级，无需人为干预。

几百万存量数据实时处理的服务器已经超过了人类的处理极限，所以必须依靠靠AI。

前文所述的数据分析、数据修复仅是数据智能分析价值的一小部分，它更大的价值在于质量大数据的智能分析。质量大数据的智能分析会驱动三层循环，进行到全链路的持续改进。第一层循环就是前文所述的那一部分智能分析；第二层循环是驱动所有流程的源头，这些问题不停打磨设计标准，包括流程、规格、用例，都以数据为驱动；第三层循环是还是驱动，无感升级能力不断提升，包括微码、软修复、固件、热插拔、预埋管理等都以数据为核心，驱动全链路的持续优化。

纵观业界的质量管理方法，最早是以产品产出后的检测为基础，当今使用的是以质量规划和防错的重点的过程管理模式，而在云场景下，逐渐过渡到以大数据为支撑的预测性的质量管理模式。这种以大数据为预测、驱动的管理模式可使得投入更精准，可以围绕数据预警得到的信息精准解决问题，减少了人力资源的浪费。

3、优秀实践

（1）“智能预警、分析、修复”系统，让硬件快速迭代，新平台发布即稳定

阿里的第一代自研平台基于Purley，使用JDM模式和智能分析。2017年开发的1.0版本，它和阿里云采购的其他一线服务器处于同一水平线。随着业务场景下上量的爬坡，经历18个月达到故障率的顶峰，该顶峰值持续14个月后逐渐下降。因为当时的修复能力和问题的发现能力都相对较弱。

在Whitley平台，使用的是EDM 1.0模式，所有的硬件、软件、架构设计开始归一，智能分析和预警修复系统也迭代到2.0。这是因为当时的发货量已经相对较大，可达几十万。爬坡的时间大幅缩短，前10个月是在CPU发布之前和业务进行联调灰度，从客户开始售卖到峰值仅有不到半年的时间，且故障率的下降没有明显的峰值，仅在3个月内即可完成问题的修复、收编、线上机器的轮转，进而下降到极低的水平。

在Eagle Stream平台，它使用是SPR的CPU，收敛更快，但由于目前发货量仍旧较低，说服力可能有一定欠缺。

可以发现，客户的体感峰值提前了八个月。关于批量问题的数量，Whitley平台减少了90%以上的批量问题，量产以后除了来料的问题，几乎没有涉及客户体感的批量问题。对于故障率的峰值，Whitley降低了50%以上，持续的峰值缩短了80%以上，几乎没有峰值，维修成本降低了50%以上，非预期宕机率也大幅降低，且故障率峰值和持续时间都在前移。

（2）通过质量大数据智能分析挖掘深层次问题，精益求精，实现双赢

通过质量大数据的分析，阿里云率先在业界发现了很多深层次的风险，而这些问题都在正常故障率监控之下，必须基于场景才能发现的问题，甚至研发厂商都尚未发现。阿里在发现这些问题之后，联合供应商一起进行治理。比如器件、芯片、内存、Retimer（GPU掉卡业界痛点）、CPU和硬盘。

在早期，CPU与Intel深度合作，进行深度的数据互动，在平台发布时一起解决了15个软硬件问题，发布后迅速实现稳定交付。

在电容上，某一线大牌的电容在高温区域失效率高，在监控大盘下很难发现，但在阿里监控体系下，发现在主板固定的温度高的位置失率效高。在阿里熔断之后，厂商也分析了自身产品与友商的差异，形成了工艺的突破，与阿里联合完成改进，其故障率达到了业界的先进水平。

在内存条上，某一线大厂在一年以后发现其某些批次内存条上的电容厂商失效率高，及时熔断。在有了海量的采集数据后，硬件的质量改进发生了变革。在这个方面，阿里云与合作伙伴实现了共赢。阿里云可以在问题解决的基础上快速稳定，达到超过业界的质量水平，供应商的新器件可以在阿里云丰富的场景下快速催熟。同时，还推动了技术和工程领域的突破。

4、展望未来

AI包括云计算的场景、数据，为质量改进开辟了一条快速通道，期待服务器更多的生态合作伙伴，能够一起基于大数据驱动的质量智能管理体系进行更深度的合作，持续提升云服务器行业的硬件质量水平。

 

二、阿里云服务器故障监控诊断和预测实践

1、云服务器故障处理带来的挑战

该部分介绍在当前海量的服务器上网的情况下硬件服务器常见的故障。首先，质量上要观测硬件的数据行为，要进行监控。而要进行监控，常见的手段是把工具部署在带内的服务器中。但如果是裸金属场景，则无法部署工具，也无法抓取机器上的日志。

其次，阿里云上除了传统的Intel X86服务器，也有AMD、ARM服务器，各种CPU的架构不同，这决定了其诊断方式不同，收集数据的格式也不同。这给硬件诊断带了很大的挑战。同时，当业务正在运行时，如果发现业务故障，要停止业务运行，进行迁移的代价非常大。所以，我们希望能在业务没有感知的情况进行。

此外，随着AI大模型时代的到来，我们需要采购很多与AI相关的GPU、网卡等硬件器件，而这些资源非常昂贵。如果训练时产生故障，通常情况下最快速的方法是更换硬件，但需要准备多少备件是一个问题。如有100台机器在训练，假设故障率是5%，是否需要准备5台备件？若准备数量偏多，则会造成成本的浪费，反之，则可能会导致业务无法衔接。因此，我们需要一种较为精确的预测能力。

2、监控、诊断、预测各自领域架构与实践

基于上面提到的服务器故障模型，该部分介绍统一处理硬件的运维架构，并介绍每一种架构的实践。

服务器硬件运维的大图包含了监控、诊断、预警、测试、维修等内容，整个硬件运维是一个完整的闭环，甚至有自己的运行逻辑，它分为五层：

最下面是产品的硬件层，包括磐久系列的X86 ARM服务器，常见的硬件组件其中。为衔接上层的软件和硬件，中间会有一层标准规范层，也就是阿里云服务器的所有动作都基于标准规范，如果不是标准规范，则将其改为标准规范，满足各种标准规范的应用接口。再上层是技术通道层，对于类似于巡洋舰的采集监控预测软件平台，它需要带内的信息，包括Agent、Tool等，如果在裸金属无法安装，则通过带外的欧盟BMC、Redfish等接口进行交互采集信息给巡洋舰。同时，还有阿里云自研的诊断方案、业界的FA给到诊断平台金轮。再上层是运维服务层，包括测试系统、预警系统、维修系统服务于ECS运维。最上层是业务层。

（1）监控系统——巡洋舰

①监控架构

如果无法发现故障，诊断、维修、预测更是无法企及。因此，巡洋舰是所有运维平台的开端，负责发现问题。巡洋舰软件架构分三部分介绍：

平台层最接近维修系统和业务管控，主要负责制定规则（如故障码、日志抓取选择的机器范围），以及制定规则的方案（包含范围匹配、频率计算），最终把规则制定匹配行为的错误上报。中间是调用的集团公共组件。最下面是端侧的工具层，包含了标准工具和自研的工具，带内的会部署在host主机、BMC上，进行OEM以及Nvme。与传统的监控最大的区别在于，传统的监控基本上是轮询的，即上层发出命令，下层抓取数据响应，而近几年添加了触发模式，在出现硬件故障时，除进行轮询之外，还可以中断触发上报。收集的类型也比较齐全，包含本身的日志以及Metric指标性的数字（如占用率）以及打包的package。覆盖场景包含Rack机型和复合机型。最终发现，核心指标故障发现率可以达到95%，准确率也达到95%以上，这也是阿里云多年百万级服务器运维经验的总结。

②带外化实践

前文中提到，有些工具无法在带内部署，需要在带外进行。在支撑AI的业务上发现，如果走带内途径非常的复杂，不仅是工具的部署问题，且容器内的工具也无法处理。经过探索，我们发现了比较简洁的访问方式，即通过BMC带外直采数据即可绕过复杂的流程拿到所需的指标和日志，进行后续的维修、告警等活动。近几年在带外监控的加成下，监控覆盖率从7%提升到了80%，且逐步完善。这一重大进步中要求阿里与硬件厂家讨论、适配合适的参数，通过带外的手段获取。这一设想已有成功案例，如阿里云与CPU厂家对PECI接口进行了定制，从厂家获取了CPU关键性的数据作为硬件的监控。

面对带外化的挑战，阿里云完成了三项任务：

第一，我们把部件的属性进行了拓展，如传统的CPU内存到GPU的卡、网卡、电源，都进行了扩展；第二，监控协议由传统的IPMI发展到Redfish，增加了很多标准规范和功能的扩展。虽然IPMI已经发展了近20年，如今几乎已经没有更新，但Redfish一直在持续更新，阿里云也是Redfish的主要的贡献者；第三，支持带外日志秒级上报，这意味着所有的监控发生的问题不再依赖于轮巡。轮巡可能会隔5分钟或20分钟采集，一旦发生故障则无法修复的，如果使用秒级上报，在提升故障发现速度的同时，对后续的预测工作也有很大帮助。

（2）诊断系统——金轮

当巡洋舰监控发现问题后，会把问题交给金轮，产出相应的解决办法。

①诊断架构

金轮分为专家模式（在线模式）和深度模式（离线模式）。简而言之，在线模式不影响业务，而离线模式已经确定了故障，必须要诊断、维修，会把业务迁移，进行离线处理。

当巡洋舰把错误给发给金轮之后，金轮会触发一次采集判断，判断机型、参数以及白名单，这是为了避免在线的业务抓取数据时导致未死机的机器宕机。因此，我们要遵循最小匹配原则抓取数据，再经过自研的诊断方案或行业和厂家的通用方案进行特征匹配，同时还有AI辅助诊断。如果专家诊断结果和AI诊断结果一致，则说明该次诊断有效命中了发现的问题。如果判断是误报，则可以对其拦截，直接返回巡洋舰，告知本次误报的情况，说明系统不受影响。如果专家系统诊断出了问题，则产品需要再次确认，迁移业务，再进行深度诊断。或再次运行所有功能，或运行所有的存储介质，因为其中受到了有损诊断，会对数据产生影响，因此会把业务迁离。修复建议常见的是换内存、换CPU，当然软修复（重启后故障消失）的价值也很高，可以避免进行下一步的处理。因为下一步的处理会带来较高的代价，如停运业务、更换机器，耗时耗能。

②线上部署实践

金轮进行了日志的精细化以及带外化进行。故障的机器会把日志分为几部分，一个是BIOS导致的中断触发的SMI，一个是BMC导致的带内本身OS的记录PECI。然后，通过上面触发，以带内或带外的方式采集到相应的日志，送到专家系统进行专家诊断、离线诊断，得到对应的结果。

在这个过程中，支持的硬件范围越来越广，随之支持的部件也越来越多，链路也越来越长（传统的PCIE控制器到端，如今增加了switch，多一次链路的缠绕），日志的范围也越来越广。

金轮故障日志的采集更精细化，如何确定需要采集的日志？哪个日志有帮助？哪些日志不会对系统运行产生危害？这都是长期的经验总结。此外，金轮也有和巡洋舰类似的诉求和应对措施，即通过带外采集，在不影响系统的同时，对core的资源也较少，因为带内采集会使用到带内的资源。

经过一年的运行，金轮在线诊断调用了8800万次，其中7000次拦截是误报，快速进行了软修复，这些有着巨大的价值。

（3）预测系统

预测是把常见的硬件进行了分类，核心是通过Paper、技术手册、专家生成数据和系统日志。目前，行业内已有了相关的预测方法可以直接使用，不成熟的方案可以与厂家进行联合定制。利用定制的数据通过特征工程，对常见的生成的样本进行训练和调优，产生相应的模型部署在业务上。阿里云是一个闭环的系统，在上云之后可以对结果进行验证，产生增量的样本，再重新反馈。根据这套循环的算法会越来越优，系统使用得越久越好。关于定制数据，以前的Nvme盘，业界是没有监控范围，也没有预测手段，加入了定制参数后即可进行预测。

3、小结与展望

无论是监控领域，或是诊断领域，都会全面走向带外化。通过带外化的方式进行采集，同时把日志精细化。预测要与厂家进行深度合作，定制适合自身业务模型的数据，进一步提升准确率和召回率。最后，让故障的数据更好地服务于故障处理，让阿里云进行更精准、更高效。

 

三、阿里云服务器层次化测试体系

1、阿里云服务器稳定性与测试的挑战

（1）业务场景丰富

阿里云的场景非常丰富，这即是优势也是挑战。阿里云自有的业务全面上云，同时，公有云上的其他客户也有各种丰富的业务场景。因此，服务器的的种类和要支撑的场景也非常多。服务器的种类包括计算型、存储型、异构、AI以及网络型，节点有1U、2U、4U、5U、6U等，还有单节点或多节点。针对所有的服务器类型，都需要保证其质量能够满足业务的需求。

（2）先进工艺

服务器的核心部件演进速度非常快。从工艺的角度出发，从之前的14nm到7nm、5nm、3nm。CPU和GPU也是如此，CPU的核数由16、32、64发展至128、192，明年可能会演进至256核。对于功耗，CPU单芯片的功耗已达500W，GPU单芯片的功耗已达1000W。一台服务器中放8、16个，这种功耗密度对整机的散热、功耗电源的设计和测试的质量考验很大。除了功耗以外，还有内存的容量HBM，其制造相对复杂，还有可靠性也需要考虑，之前的容量多为80GB、90GB，现在已发展至192GB。DDR单个内存条约128GB，网卡从25GB、100GB逐步演进到200GB，后续还会快速演进到400GB。核心部件的快速升级，对其功耗密度、来料质量、整机测试、部件测试带来更大的挑战。

（3）AI机型的高可靠要求

从2023年开始，阿里云面对的核心挑战是AI服务器。

①高速链路复杂

AI服务器和传统的计算型、存储型服务器不同。从CPU出来后先经过一些Retimer，再到多个PCIE switch下面，再到Retimer、GPU，再到NV link或NV switch，此外，PCIE switch下还有多张网卡、SSD。整个高速链路非常复杂，同一服务器内部存在高速的PCIE、NV link，PCB和服务器之间的走线导致高速链路非常复杂。这对链路的稳定性要求很高。除走线之外，链路的稳定性还依赖于部件，如CPU的PCIE和Retimer参数，再加上PCIE switch的配合以及下面Retimer。有些Retimer是OAM带的，两个Retimer可能不是同一个厂家，参数的适应性以及双方的配合会带来很多链路上的问题。

②部件种类和数量多

除链路质量，其中涉及的部件类型也很多。服务器内部的部件或核心器相较于以前约有2-4倍的增长。每个部件或其分布二版本出现问题，都可能会导致整机出现问题。

③可靠性要求高

在AI的集群上部署了千卡、万卡，未来会达十万卡，但无论是多少卡的集群，一旦有一张卡或一条链路、一台机器出现问题，整个训练集群的性能都会急剧下降。我们必须中断之后将其剔除才能继续进行测试。换言之，AI场景下服务器质量对可靠性要求上升了一个数量级。

④交付节奏快

近几年，用户对AI的需求尤其旺盛，因此，研发、测试环节对交付节奏要求非常高。基于此，测试效率和测试质量都面临着挑战。

此外，服务器外部也有很大的挑战。万卡集群都要接入光模块，而光模块本身的可靠性也在测试范围之内。如集群中有几万个光模块。

（4）重点问题分布参考

传统服务器（计算型或存储型服务器）在线上的故障约有40%是由CPU导致的，约有20%来自于电源，18%左右来自于内存。而近年AI服务器的线上故障约有52%来自于GPU卡或OAM模块，少量来自于内存的问题。

在制造端的故障，制造装配（制造装配是从开始配置的，内部的高速线缆很多，工艺比较复杂）带来的问题占比较高，然后是GPU及其本身的模组来料的质量问题，以及高速链路（Retimer、PCIE switch线缆、连接器等）的问题。

因此，传统的CPU服务器重点拦截的是CPU内存、CPU电源的问题，AI服务器重点拦截的是GPU卡、模组、高速链路以及制造装配的问题。

2、阿里云服务器的测试体系

测试是分层的，从芯片测试到板级测试，由于引入了不同的部件，还有部件级的测试，整机测试、生产测试，然后在生产阶段或在出货之前进行业务的前置测试，即业务场景级的测试，还包括机房到货压测和业务的集群测试。经过这一系列的测试之后才会交给业务方，确保交付的服务器的质量。

从整个测试体系来看，测试活动更加丰富。由于阿里云有自研芯片，因此会有芯片的原型验证、样片验证、硬件的研发测试，这三个属于研发测试；在生产线，包括机型测试、实验室测试、业务前置测试、工厂测试、资源池测试、机房压测、业务集群测试等。为了支撑测试，哥斯拉测试平台用于支撑研发测试，金刚测试平台用于支撑生产线测试。这两大测试平台分别支撑服务器的研发测试和生产测试。生产测试之后产线上的所有数据也会收集回进行存储，在存储之前进行性能、有效性、覆盖率以及批量问题漏测、改进分析。同时，改进测试流程、测试规范、测试用例、测试方案、测试资产以及需求基线等。阿里云有自研的工具，包括自研的部件，以及产线上针对不同部件、错误类型的不同的压测工具。测试技术委员会还会统一看护流程规划以及工具。

接下来，重点从技术委员会、平台、工具、数据化几个维度展开讲解测试体系。

（1）技术委员会

测试技术委员会是服务器的虚拟组织，主要负责测试规范的制定、过程（包括测试策略、测试过程、交付件、测试报告的评审、测试的覆盖度、完备性）的看护、漏测分析改进（负向分析）以及公共能力的拉通构建。这个虚拟组织会把所有的部件、整机以及生产的能力工具统一拉起。

（2）工具

①自研测试工具

针对自研芯片和自研部件，在每个领域都有一系列的资源工具。在CPU领域有自研的BareMetal测试系统，该系统不依赖于标准的Linux，启动非常快，同时Linux启动时会锁定中断页表、安全域，而系统启动后页表中断、安全域随意可配，可以确保对CPU达到全面的覆盖。在网卡领域，自研了RDMA测试工具，支持业界标准的ROCE V2协议，也支持阿里自研的RDMA协议。对网卡做到功能、性能协议一致性，可针对特定故障的异常注入，确保网卡的完整覆盖。在SSD领域，阿里云自研了用户态的测试驱动，确保NVME前端协议和命令完整覆盖。

同时，也有自定义的VU命令，确保可以SSD的固件每个功能点都能被测试到。最主要的是有业务pattern的提取和测试回放，会把不同的产品，包括EBS、OSS、数据库对硬盘访问的pattern和特征、模型提取出来，最终在芯片测试或者SSD盘测试时回放，确保SSD盘功能的可靠性。在高速链路接口领域，针对PCIe和CXL有自研的测试卡，可以模拟RC和EP，还可以构造任意的PCIe和CXL的报文，支持各种异常报文和故障的注入，确保在各种场景下卡和CPU都没有问题。

②整机压测工具

不同的实现有不同的测试种子。针对CPU、GPU、PPU、vDPU、网卡、内存的测试都有专用的工具部件，也会覆盖基础的指令集、应用库、底层的硬件电路，还会针特定的CPU的静默错误、HBM的ECC、DDR的ECC压测、带宽、极限功耗、散热等进行测试。最终，历史问题产线上发现问题的Golden case也会合入到这一系列的工具集当中，确保整机每个部件压测的压力都足够大。

（3）平台

针对CPU、网卡、XPU、SSD等核心部件，每种核心部件都有几十种不同的型号，它们会进行微架构、基础Benchmark、上层库以及典型业务的性能测试。数据会统一进入性能平台。今天，平台上会收集所有芯片或部件的规格、性能数据，并可以实时拉通、横向对比，也支持在线的一键测试自动生成测试报告等。这些数据会支撑芯片的定制和选型，也是生产测试、研发测试、性能测试的用例性能基线，当厂商发布新的分模版本时，观察其性能是否跌落？在引入新的器件之后，在不同场景下，确保从微架构到业务场景都满足了用户的需求。

（4）全流程云上生产测试系统（金刚）的演进

目前，生产测试平台金刚已迭代到第四代。在最早的1.0时期，仅给出了统一的测试方案、判据，执行测试工具、测试程序是厂家的，阿里云只有离线的数据。到2.0时，所有的测试程序全部自研，并且构建了在线的测试系统，所有的数据和阿里云时打通，但可能效果有限，当时的数据是T+1的，但有了数据就可以构建批量问题的预警能力，进行在线的运维。最近两年，3.0实现了全面的数据化，且数据都实时更新，可以进行精细化的自动预警。目前正在研发的5.0进行了动态测试策略的调整，针不同厂家和不同的机器实时调整测试策略、智能组合、实时的数据问题智能定位。通过平台不同版本的演进，实现了测试效率和测试质量的双重提升。

从云上的测试数据回传、存储，到数据分析和展示以及数据的消费，前面的几个流程之间是打通的，现在数据化的重点在数据消费。目前，已经进行了线上的诊断、部件的预测以及测试用例的优化，但效果不佳的方面也在持续加强。

3、AI服务器的测试挑战与应对

（1）高速链路类问题拦截

由于高速链路非常复杂，所以首先会采用Cycle Resets、SBR Test或Bert Verify模式激发故障，同时收集所有的参数，包括PCIe para和X-link的参数。单独的一个参数可能没有问题，但如果把几十台、几百台，甚至上千台的参数都收集统一分析后，有的参数在协商之后大概率会出现问题。最后是状态监控，包括Link sta、AER sta、Parity Mismatch和Recovery count等。

（2）GPU模组

对GPU模组也有相应的测试。如功耗，从近几代的GPU功耗和EDPp来看，基本上呈现成倍数的提升，这会对OAM带电源的生态负载能力、散热一致性带来很大的风险，因此我们要对其进行拦截。另外，业务模型运行时，负载也会瞬态突增，所以在测试时也会采用类似的手段压载，确保部件在线上应用时不出现问题。

电源类的问题一般会采用温变加EDPp拦截，在拦截时会进行遍历。但有时worst case不一定是高温，也可能是低温，有的GPU在低温模式也会受到较大的影响。对于大模型的压测，厂家给的EDPp工具无法压到最极限的场景。在运行业务时，压力可能会大于比EDPp工具的压力，所以也同时使用大模型压测，比EDPp工具更有效。

在散热一致性方面，在压测时也会监控每个GPU的温度。如同一台机器中有8个文本，其中7个文本的温度基本一致，但另一个模组的温度高出10-20℃度，基本属于散热的不良品，未来在线上很容易出现问题，需要拦截。

4、阿里云服务器测试的未来规划

首先，阿里云会进行新技术的测试储备；其次，未来测试模式也会发生变化，由单机交付转变为机柜级的交付，即从单机测试向机柜级的测试、集群测试演变；同时，安全测试会从芯片安全、固件安全、平台信任根等，服务器的安全测试会更加底层、深入；此外，测试的服务化，从前服务的生产测试全面上云，未来我们的研发测试也会全部上云；接下来是测试数据化，未来会在数据消费方面进行更多的测试数据、日志挖掘和大数据的分析，更好地进行预警和改进的分析；最后，测试智能化，针对测试本身，我们会不断探索，尝试使用AI和机器学习的模式改进测试，包括用例的设计、脚本的开发、结果的分析、报告的生成，目前约已实现30%的自动生成，未来也会在这个方面持续发力。