一、弹性计算稳定性技术基础能力研究

为大家介绍弹性计算稳定性技术基础能力研究。

弹性计算是大部分云产品的基础。我会从技术角度讲讲在稳定性基础方面所做的工作，重点是今年的成果。

1.稳定性底座

首先，所有与稳定性相关的内容，大多遵循事前、事中和事后的逻辑。从弹性计算稳定性本身来看，事前主要是针对弹性计算实例的，这些实例都属于用户。实例异常检测主要是检测服务器基础设施稳定性异常情况的能力，简单来说，就是对实例底座的事前检测能力。事中是指当异常不可避免地发生时，如何运用我们的能力规避风险，以及为客户提供相应的能力来避免这类问题。事后则是针对线上数以百万计的服务器，如何评估其异常和受损情况，以及具备怎样的快速响应能力。所以，异常处理或稳定性的整体逻辑就是事前检测、事中规避、事后止损与处置。

阿里云在领先的ECS维度的SLA方面（相比友商）可能做得比较好，每年云栖大会都会提及。下面讲讲我们所支撑的场景，包括通用计算、异构计算、容器和超算，后续相关同事会对这些内容展开介绍。还有我们支持的基础设施规模。对于实例异常检测，简单来讲，事前的底座是大家熟知的CIPU或者神龙卡，在其之上支持的是Hypervisor和容器相关的底座，再往上是运行用户服务的部分，接着是调度逻辑，更上面是我们呈现给用户的能力。今天我重点讲的是如何建设整体稳定性这部分。右边有些比较抽象的案例。可以理解为，这些虚拟机是多租户的，这意味着很多资源存在一些情况，特别是存在争抢性的实例或者共享类资源。熟悉操作系统的人都知道，像内存带宽、功耗这些，都存在竞争关系，所以需要一套逻辑来持续进行性能治理，这是其中一个方面。

2.实例异常检测能力

今年我们重点开展了一些工作。由于账户泄露问题在今年和近两年形势严峻，我们联合安全团队，依据特定逻辑开展相关工作。当有隐患的账号在虚拟机环境中进行恶意操作时，我们借助安全方面的账号标识，结合账号运行行为和用户画像来识别风险，判断异常行为是否是黑产或其他作恶行为。通过两三个月的数据积累，我们封禁了大量账号。封禁手段多种多样，包括主动通知安全部门封禁、主动抑制资源以及限制访问等。因为这种恶意行为危害极大，短时间内可能消耗大量资金和资源。所以这几个月我们重点建设这方面的能力。

自诊断方面，就像当前 GPU 很热门，大家看过比如 Lambda 3.0 的论文，它提到在 16000 张卡、约 53 天的训练过程中，出现过 400 多次问题，但真正中断只有 3 次。这主要是通过其自身软件能力和监控诊断能力，尽可能将问题前置处理，避免训练完全失败。在 GPU 场景下，诊断能力非常重要。据我所知，在 H100 或 A100 的场景下，GPU 的故障率占整机故障率的比例，其利用率基本能达到 50%或更高。在大模型训练和推理场景大热的当下，GPU 的稳定性至关重要。

3.变更异常检测能力

变更异常检测能力在构建稳定性系统时值得借鉴。简单来说，就是要考虑底座变更对业务的影响。当对底座进行变更时，如果对用户有损害，可能需要结合用户画像向用户通知。这其中的难点在于，不同用户画像对稳定性的认知差异很大。例如，运行radis系统时，对毫秒级的延迟容忍度很低；但如果是执行教学或离线任务，对延迟的容忍度可能就没那么高。所以针对不同场景和变更行为，需要采用不同的策略。

再有就是阻断，简单来说，这是一种在实践中被证明非常有效的措施。我们团队拥有异常诊断专家和算法库，结合变更平台的变更识别，利用整体的异常库和变更行为，及时阻断变更，效果十分显著。基本上，在软件类变更方面，这一两年来大规模故障很少发生。我们每周都会有阻断情况不断出现，应对全球网络引发的各种变动。

还有左移能力相关的逻辑。当要发布非常大规模的内容时，发布策略就变得极为关键。这和 100 台、1000 台机器不同，当涉及 100 万台机器时，需要将发布前置化。这就相当于需要诸如灰度发布策略之类的方法，因为线上硬件、软件、操作系统等百万级的变更，不同的排列组合会有不同的隐患。针对不同的发布组件，要有不同的前置策略。

整体总结一下，变更异常检测、有损通知、阻断和左移策略，我们认为这些都是非常有效的手段。

4.风险规避能力

就风险规避这部分而言，要有一个强大的底层，同时需要有故障预测和调度体系，也要有故障规避手段和考虑客户相关情况。从数据上看，用户能感知到的问题只占 1.8%，也就是明确有异常且用户受到非预期行为影响的情况只占这么多。大部分场景下，问题会通过一些规避手段和应急手段解决。如果无法规避，就会进入有损通知环节，用户可能在几天内主动进行调整，真正出现严重问题的情况很少。

5.故障处置能力

接着讲风险处置。我觉得值得分享的是左边这部分。左边存在的一个问题是，每天都会有各种各样的问题，比如宕机、断网、掉电等。我们要识别出哪些是风险问题，是需要集中处理的问题，而不是常态化问题。常态化问题可以通过故障规避手段解决，但如果是批量问题，就需要人工介入。简单来说，是基于自身的异常库结合场景，快速对问题进行聚合并找到根源，然后迅速流转。在找到根源后，我们通过一些手段，比如从探测维度、下钻分析以及风险评估等方面，对批量问题进行分级，比如是通知到产品线，还是内部预警，或是发给风控团队、GOC 团队等不同场景，针对聚合出来的不同根源要有不同的响应机制。

后面是故障处置的逻辑。之前我们新增了很多风险预警，风险预警并非简单依据某个比率超标来判定，其种类繁多，可能有上百种。今年又增加了一些新风险类型，比如在某个维度的过度运维、特定场景下共享资源的过度使用、存在安全隐患的流量风险等都属于风险范畴。故障处置中的演练并非针对单个组件，而是要结合管控、存储、计算、网络等基础设施进行联合演练。

 

二、ECS稳定性产品介绍

接下来阿里云智能集团弹性计算的产品专家苏中黄介绍ECS稳定性。

1.ECS侧稳定性和用户业务稳定性之间的鸿沟

以前讲了我们通过各种手段对故障进行预警、识别和治理，也提供了ECS比如99.975以及多可用区99.95的成功率（可用性）。但在这方面，我们面临一个问题，就是阿里云ECS视角的可用性和用户业务视角的可用性之间存在很大差距。比如，从ECS角度看，我们觉得稳定性已经做到了业内领先水平，但对用户而言，由于CPU性能问题、镜像Bug等原因，会导致业务出现异常。简单对比这两块一个月的数据，差距接近300倍以上。所以从产品层面，我们要考虑如何更好地将ECS底层的稳定性传递给用户。

因此，我们重新思考ECS的稳定性应该如何构建。

2.从软件生命周期视角，保障应用的可靠性

借助云上社区的理念，我们把应用交付分成三个阶段。比如在第一阶段即规划阶段，我们要为应用设计可靠性方案。到了第二阶段即交付阶段，整个应用完成后，我们需要进行业务测试或演练，确保在业务引流之前能够真正承载实际业务场景。再到第三阶段即持续运行阶段，当发现异常后，我们要以最快速度规避风险，保证业务在云上持续高效运行。

（1）Day0规划阶段:基础设施高可用架构设计

下面将简要介绍ECS提供了哪些产品能力来保障云业务的稳定。

在规划阶段，如今 ECS 提供了部署级能力。例如，原本两个实例部署在一台物理机上，当这台物理机出现故障时，业务应用不可避免地会出现单点故障问题。而通过部署级的高可用模式，可以保证物理机与ECS一一对应，从底层保障业务的高可用性。

其次单可用区故障的异常情况。如今在 ECS 的 ROS 能力方面，我们可以快速将 A 可用区的部署架构平迁到 B 可用区和 C 可用区，这种部署编排能力能有效发挥作用，降低实现高可用的门槛。并且，ROS 还引入了模板生成功能和格式化布置，降低用户在配置多可用区能力方面的难度。实际上，回到可用区加固设计层面，ECS 会持续提升单实例可用性的 SLA，从当前的 99.975 不断向前演进。第二个逻辑是持续降低高可用功能的使用门槛，比如将部署级使用方式与创新的实例方式更好地结合，还有弹性相关内容的结合，以及如何让多可用区能力更快地部署和应用，以此解决单可用区因非异常原因导致的整体故障问题，保证整体业务的可用性。

（2）Day1交付阶段:通过故障演练验证应用高可用

当基础设施具备高可用性后，我们要确认业务是否具备高可用性。在这个过程中，需要进行业务测试。对于常见的业务可用性而言，一是要解决服务可用性问题，比如业务集群出现单点故障后，是否具备单点隔离能力，会不会出现脑裂问题，这需要充分验证，这样才能确定可以应对单点问题。二是故障之后，ECS 一般会提供常见的快速恢复能力，实例启动恢复正常后，它能否重新加入业务集群，能否保证业务数据的一致性，不会出现数据丢失或错乱问题。在这方面，如今 ECS 内测提供了故障注入能力，使用户能够在非生产环境模拟相关故障，锤炼业务的高可用能力。

（3）Day2持续运行阶段:持续的稳定性阶段

第三阶段更多的是持续运行的逻辑。持续运行需要采集更多指标，识别更多潜在异常，并且结合已有的自动化运维能力，保障线上业务平稳运行。简单来说，就是将云上运维能力和当前业务运行情况很好地有机结合，保证业务运行流畅。

3.相关能力

（1）快速识别ECS实例常见问题

接下来介绍提供的功能。我们有 ECS 实例问题排查工具，它可以对常见问题进行诊断。比如用户输入一个具体实例后，该工具可以进行性能问题分析、连接问题分析，以及网络和资源配额问题分析，具备常见问题的快速诊断能力。

假如用户对 ECS 比较了解，他们可以基于原始指标进行业务判断和分析，这有助于更好地与上层业务应用集成。

4.ECS Lens

接下来介绍一款新产品，预计在十月份左右，我们会对底层观测能力进行整体升级。这次升级主要针对两个方面：一是实例稳定性问题，我们会推出实例状态检查指标，帮助用户更快地发现操作系统层面的异常。之前我们更多关注一些阈值和异常，对于用户异常处理相对保守，可能要等用户的ECS持续异常3 - 5分钟才推送高级事件，现在单指标异常在分钟级就会推送给用户。另一个方面是我们目前已经做到的85%以上的隐患异常识别能力，这能很好地规避潜在风险。

今天我重点提及的是实例性能问题。ECS 的规格文档虽写明了规格具备的性能，但用户在实际使用时查看规格操作性不佳。我们会加强这方面的指导建设，告知用户各个性能维度的利用率，并推出性能分析页，用户可通过页面快速查看实例存在的风险，以及实例是否需要升级或进行规格调整，后续我们会逐步优化相关推荐意见。

（1）构建更多自动化恢复场景能力

下面讲讲后续对接的一些场景。当有了指标和事件后，基于迎接后的逻辑，可以很好地进行运维触发。我们目前提供的运维自愈能力就是ECS运维事件和ECS维护属性，比如遇到隐患故障风险，可以在特定时间重启实例，或者将ECS实例迁移到正常物理机上规避风险。我们还提供基于系统运维编排的服务流程能力，比如定义了 CPU 使用率高的流程后，可以逐步对业务进行服务重启操作，规避业务风险。这里大概提到了一些典型水位变化以及这款产品新增能力的变化，核心是通过两个方面为用户提供更多运维能力，保障线上业务稳定性。

简单回顾一下核心内容，我们想向用户传达的是，我们已经从 ECS 视角开始向用户应用视角关注稳定性。从 ECS 视角来看，我们已经处于行业领先，但这对用户的意义可能在减小，但在用户层面的稳定性上还有大量工作要做。所以我们会在规划阶段和交付阶段逐步完善产品体验，确保用户能够真正理解我们云上相关程序和机制的价值。关于第三阶段，我们会持续建设更多相关内容。

 

三、Confidential AI 最佳实践

接下来有请阿里云智能集团高级技术专家张佳带来主题：《Confidential AI 最佳实践》分享。

在正式演讲前，我想大家可能对这个词组有些陌生，这也是我这次演讲创新主题的一个体现。我先和大家讲一个小故事。大概一年多前，那时候阿里云有个战队叫“公有云 + AI”。我的一个朋友问我，你们这个战队是不错，但是当用户要把耗费大量成本训练的模型放到云上时，你们的安全能力是否能保障用户模型、数据存储、计算、处理过程等一系列安全问题。我刚想回答，他紧接着又问，现在 AI 应用广泛，比如律师事务所提供的提示词可能包含名人敏感信息，这些信息交给阿里云的推理服务，怎么能保证不会被用于训练甚至被滥用。他问完这个问题后，我陷入了沉默，因为当时阿里云的一套基础设施确实无法完全解决这个问题。而今天，一年之后，我来交付一份关于这个问题的答案，下面开始介绍具体产品相关内容。

本次分享分为三部分。第一是经典的提出问题、分析问题、解决问题；第二是我们在解决问题方面实际做了哪些工作；第三是实践环节，大家可以亲身体验看看这个产品到底能解决什么问题。

1.大模型场景挑战用户和云计算传统系统安全观念

首先是问题阐述。从最左边视角看，传统云计算基础设施是云厂商的视角。我们传统的观念是利用虚拟机和虚拟化技术隔离用户工作负载，但它在某些情况下可能突破虚拟化安全防护平台，进而横向攻入云平台，窃取其他用户的数据和模型。也就是说，传统云安全模型主要是依靠虚拟化隔离来保障用户的模型和数据安全，这间接要求用户相信阿里提供的数据安全保障数据能力。但用户的想法其实很单纯，他们只是希望把模型或数据放在云平台的执行环境中时，平台能提供可靠的安全防护能力，避免隐私泄露。尤其在今天，数据和模型已经发生了从量变到质变的过程，其价值极高，和传统信息不同。所以综合来看，在 AI 时代，我们需要将云计算安全可证、隔避能力和用户信赖的可信执行环境结合起来，为用户提供能依赖云厂商的安全可信能力。

（1）信任问题来源

安全背后其实是信任这个词。那这个信任问题是怎么产生的呢？我们对整个云计算基础设施做一个高度抽象的模型，简单来说可以分为三层，即数据层、平台层和应用层，这三层都有各自的所有者或者提供者。从传统安全威胁模型能够看出，所有的安全问题都出现在相邻两层之间。而且不管是传统场景还是AI场景，出现问题的点都是在相邻两层的所有者不同，也就是角色不同的时候，就会产生安全或者信任问题。比如说，传统上的溢出或者漏洞攻击，就是畸形数据去攻击平台的代码，进而深入平台内部。再比如在AI私有云私有部署的一个场景中，数据属于用户，而模型输出给用户赋能时，我们会认为模型代码是敏感的，需要额外的保护。但如果我们不信任平台提供者，就会出现问题。

（2）系统级AI安全的重要性

综上所述，我们能看到安全领域发展很快，但是AI安全技术发展相对滞后。从整个行业来看，更多的学术研究和成果主要围绕业务层面的数据安全算法展开。但我们认为，作为弹性计算和计算机组织的一方，我们应该提供系统层面的安全兜底能力。只有系统安全能力落实到位，业务安全才能有真正的依据，才能有底气说安全能够被切实保障，否则安全就无从谈起。

（3）大模型场景下的典型系统级安全风险

我们来聚焦一下实际业务场景中的典型安全风险。首先在推理方面，看右下角模型提供者这个用户的情况，它的模型上传到云存储平台上，无论采用何种形式，可能都会通过所谓终端的方式，但实际本质是加密和解密的密钥问题。谁拥有密钥，模型的归属权就会发生变化，可能就从用户手中转移了。

第二步，工作负载提供者。比如在整个执行活动中存在一些问题，作为消费模型数据的代码，它有可能被截获、篡改。而且，消费模型的相关代码在计算过程中有可能被用于对用户不利的用途，滥用模型数据。

第三步，在部署和启动网络服务时也存在风险。因为部署及其运行环境（执行环境）存在问题，相对于主机安全而言，其内存等都是可变的。如果主机有特权，从这个平台的特权角度来看，就算在计算过程中有更多安全措施，内存安全方面也可能存在漏洞。

在图中的第四步，对于模型提供者的实验服务（这里图标虽是一个 app，但类似 Https 的情况），在使用过程中，尽管使用 Https 能保证传输安全，但不可避免的是，模型提供者访问的是一个端点（URL），对其来说这是一个匿名服务。除了 Apps 里的一些证书能表明服务器身份外，这个服务本身对用户来说是“黑盒”，用户不清楚其内部情况。所以这里面很多情况对用户来说是不透明的，这就产生了信任问题。

2.Confidential AI产品能力规划与阿里云机密计算产品

（1）Intel TDX机密虚拟机和GPU TEE

下面进入微观层面，看看我们在阿里云上是如何一步步解决这些问题的。

首先从计算资源角度来看，阿里云在 Q4 会推出资源型的EGS -ACS服务实例。这个服务实例的目标是支持混跑，比如普通工作负载利用vm在普通GPU驱动，或者利用Intel Tdx的TD VM以及一集多卡的V-link模式。这些都会在这个架构服务器上得到支持。相较于普通产品的工作场景，普通工作负载场景没有安全的设备隔离，执行本身也不可信，因为存在特权篡改、明文内存等问题，而且传输链路也可能有风险。而使用了机密计算或使用异构服务器能力后，我们可以在这些方面增强安全性。

（2）Confidential AI技术方案

下面具体介绍一下Confident AI技术方案的详细技术细节。首先，我们推出了一个在平台上一键部署的一站式机密推理层 ECS 服务。这是在PAI平台上实现的，底层用ACS EGS分别位于IS和MAS层的机密运算实例分别在虚拟机和机密容器实例来提供机密安全的寄存资源。在此基础上，我们把它们叫Confidential Ai Runtime trustiflux组件。这些组件配合推理服务，形成了一个无需推理服务做大量修改的模式。我们通过部署cinika，实现自动完成模型的解密OSI、加载、启动以及处理等流程。在运行过程中，配合辅助客户观测部署和监管环节，会实现一个通用、透明的安全模式。这种模式不受中间人影响，而且对用户来说是可以证明的可性安全通道。通过两侧的可行网关向用户证明，用户的推理提示词交给远端推理服务时，我们能够保证这个过程是安全可信的。对于模型提供者来说，其数据在上传到云平台之前，是先加密再传输的，这区别于传统的落盘和servel加密上传方式。

（3）阿里云机密计算产品

最后是阿里云计算产品的发布相关内容。简单说明一下，从最底层的异构服务器，到我们的Iaas, Paas两种典型计算形态结合精密计算再到计算技术合约分配到机密虚拟机和机密容器，再依托我们资源相关的ins操作系统，形成了 ECS 的Iaas和 PaaS 级产品。如果在部署上，我们可以利用周边的ConfidentialAi服务和软件，为用户实现可定制的、高度定制化的 Iaas方案，也可以用V-EIS进行集成部署。用户可以开箱即用相关的机密服务。

（4）Confidential AI产品能力

这个产品能力本身底层主要依赖于机密计算技术，由于时间有限，我们很难对其细节展开阐述。主要记住几个重要产品能力。首先CPU，GPU的内存加密和硬件隔离，这些都是基于硬件来实现的，另外CPU，GPU的通信链路也是硬件加密的，其次做了这么多安全能力最后我们需要要向用户展示证明技术上的环境是真实可信的，需要加上CPU，GPU的Testiflux能力。

我们的基础安全产品也有本地安全能力，用户可以使用该能力，如过往使用基础设施资源一样使用异构型的可信计算机构产品。如果你使用PRO版本，加上confidentialAI上层端到端全链路安全计算能力，产品的要测时间是Q4。长期来看Confidential AI不仅包括软件还包括底层硬件，机密计算硬件能力。所以我们对于ConfidentAi长期的产品定位本身是能力级别，当前Confidential AI 1. 0版本只达到了L2和L3，后续会跟新型硬件移入和技术成熟，我们会在2.0版本向L3Plus到L4。

我们处于L3这个层次，大家也能看到存在一些性能损失。这个性能损失是因为安全因素导致的，所以肯定会有性能损耗。不过具体的性能损耗，其实和使用的模型框架、参数、模型规模、计算算力等都有关系，需要根据用户要求的体验来具体评估。如果有自己定制的模型和框架，要实际运行一下，看看性能损失有多大。

未来我们希望随着硬件技术成熟，硬件能直接实现性能无损的加密安全特性。基于这样的硬件产品，我们获得的防护能力将是性能无损的。最终我们希望ConfidentialAI隐私保护和用户之间不是安全与可用性的矛盾关系，而是让隐私保护能力无缝、默认地融入产品中。

3.Confidential AI Demo与动手实践

此外，我们除了阐述技术和产品方面的内容，还联合了国内成员机构。之后我们会有一个关于隐私保护的白皮书技术发布。在这个发布会上，我们主要是向大家介绍Confidential AI所做的工作及其价值，还有在数据要素方面是如何保障用户权益的。如云上的数据能实现数据价值和经济价值，让固定数据核心流通，并且利用隐私保护技术，在风险管理上可以做到极限规避，也能满足未来的合规性要求。

最后，我们希望ConfidentialAI生态不只是阿里云自己的技术和产品，这个技术和理念很好，希望能拓展整个业务。

这里打个广告，现在2号馆计算馆那边有一个优云服务站台，我们在那里会提供ConfidentialAI相关内容、演示和动手实践环节。现场还有一线研发工程师，如果大家有技术问题或者想实际体验、操作一下，都可以去体验。

4. ACK 容器服务稳定性产品演进

（1）开原K8S集群面临的挑战

随着 K8S 日益成为事实标准，很多企业将其投入生产使用。但一个开源的 K8S 投入企业生产会面临诸多挑战，今天我们聚焦稳定性、安全、版本升级以及 K8S运维 复杂度这四个方面的挑战。

（2）ACK高可用架构

首先，在ACK看来，高可用架构是系统稳定性的基石。如果您选用阿里云的 ACK 服务，我们会帮您实现托管面的高可用部署。整个控制平面是多副本且跨区打散的。其次，在客户负责的数据面方面，我们可以基于节点部署级以及AC，客户可以选择通过 K8S 的拓扑进行打散。同时，ACK 中关联使用的存储，比如云盘和 LB，都可以通过 ACK 进行高可用打散。

其次，架构。在 Master 这边是我们托管的，Master 中运行了大量管控组件。这些管控组件基于我们长期积累的大规模稳定性实践做了很多优化。比如，APIServer 和Etcd 会基于访问压力进行实时动态扩容，也做了一些优化。例如 APIServer 可能在某些时候出现负载不均衡问题，我们进行了优化以整体降低 OOM 的概率。还有一些其他管控方面的组件，我们都会进行高效的状态、数据状态同步，并提升整个访问控制面的速度。

（3）ACK托管节点池

接下来聊一下数据面。我们非常建议客户直接选用我们托管的节点池，这样客户可以聚焦于节点池上层应用的部署。节点池的基础运维交给 ACK 来负责，我们会做以下事情。比如节点的诊断自愈、OS 的升级、CVE 漏洞的自动修复、Kubelet 小版本的自动升级等，这些事情都可以由我们来处理。在我们看来，数据面、控制面和云资源是有机结合的整体，任何一个环节出现问题都可能引发稳定性问题。

（4）容器供应链安全能力

除了稳定性，安全也是一个非常重要的问题。K8S 的安全复杂度主要来自两方面：一方面它会给客户带来更频繁快速的迭代；另一方面它管理了大量资源，会带来更广泛的攻击面。关于供应链安全，客户可以结合 ACR、ACK 以及镜像中心实现从代码构件、镜像扫描到应用容器部署和运行的全生命周期保障，我们一直在这方面不断钻研。今年我们也推出了很多新功能，比如 OCSBOM 的依赖收集分析，还有基于核心资源的 K8S删除保护，同时还提出了基于Gate keeper+Ratify 的数字签名。在运行时层面，我们推出了节点闲置风险镜像定时清理和Kubeconfig风险及时发现功能。它有更广泛的攻击面是因为首先 ACK 会帮助客户管理大量云资源，其次它划分的应用容器粒度更小。在下面这一层是控制面，控制面的稳定性和安全由 ACK 全权负责，在上面客户有权限选择的数据面的每一个模块中，我们都提供了非常简单易用的安全功能。

（5）ACK事件体系

在介绍完基础的稳定性和安全之后，我们来谈谈业务的稳定性。K8S是我们告知其期望结果后，它会帮忙执行的系统，它本身会提供一些 KPI 事件。在此基础上，我们可以看到图中的几个方框，这是 ACK 在原生 K8S 体系下进行的多维度事件分析。比如在一个 ACK 集群中发生了 Pod 调度异常的情况，客户可以深入分析，查看是不是有组件问题、OS 是否异常、contained是否有问题，或者是节点（如 ECS 节点）是否有瞬间故障，包括之前同事分享的 ECS 节点事件以及后面可观测的指标，我们都可以透明地呈现给客户。

（6）全链路检测、定位与分析

除了单点分析，客户也可以选择使用我们阿里云的各种可观测服务。如果结合应用ARMS可观测服务和链路追踪，就可以实现端到端的追踪。例如，当发现客户端某个请求变慢时，可以从这一端往前追溯，找到 ACK 集群中哪个应用容器响应有问题，以及对应的应用代码哪一行出现了 Bug，从而实现全链路的最终定位。

（7）Kubernetes版本升级

关于 K8S 集群版本升级问题，这是个让大家比较担忧的问题，也是我们职责范围内需要处理的事。因为 K8S 版本在社区中的维护更新频率非常快，我们为客户提供了自动升级和手动升级两种模式。我们会进行非常全面细致的前置检查，这种前置检查可以实现 100%拦截废弃 API。在控制面升级方面，我们能做到 100%成功。数据面则可以由客户灵活定制，进行分批升级或扩缩容原地升级，整个升级过程可以做到业务无感知、无中断。

（8）成本管理开箱即用

接下来是成本Finops费用问题，现在越来越多人关注这个问题。Finops在容器场景中存在痛点，因为 Pod 是不断漂移的，可能今天在服务器 1，明天在服务器 2，而不同服务器的账单是不一样的。通过客户安装我们 ACK 的Finops套件，可以精细到 Pod 维度进行分账。比如一个ACK集群中可能运行了四五个业务团队的应用，每个业务团队的应用都能进行不同的分账，这种分账可以针对 ACK 直接使用的资源，也可以是关联使用的资源，客户可以自定义。比如一个 ACK 底层可能关联很多 MQ 和数据库，这些都可以由客户自定义分账。我们的产品也是首家通过信通院云成本优化功能要求标准的。Kubernetes在展区有个合作的极客会分享成本优化的情况，他们使用 ACK 后每年可以节省数百万的 IT 成本。

5.更多稳定高校易用的功能

我们在持续提供稳定高效的应用功能。比如在ACK方面除了刚刚提到的几个关键能力，也提供了基于ECS做了很多应用层的弹性，客户可以结合使用HPA以及AHPA，它可以通过业务过去七天的运行情况自动分析推算提前给您进行应用层扩容，平均整体降低20％资源浪费。同时ACK也推出了AI助手今年我们也重点优化了ACK集群异常联动以及现在在单集群多级群应用备份方面设有备份中心供客户使用。今年我们推出了多种不同方案来实现多集群应用容栽。