AI时代下阿里云基础设施的稳定性架构揭秘

本文作者：
李刚—阿里云弹性计算稳定性高级技术专家
闫卫斌—阿里云对象存储资深技术专家
温曙光—阿里云云网络产品运营高级技术专家

前言 - 基础设施稳定性理念（ 十五年磨一剑，稳定性为何是今天的“命门”？）

计算、存储、网络作为云计算基础 IaaS 服务，一直是阿里云的核心产品，承载着百万客户的 IT 基础设施。曾经我们认为应用高可用、服务分布式可以满足客户对 IaaS 所有的稳定性诉求。但是随着数以百万计的客户上云，把业务的身家性命托付给阿里云 IaaS 服务时，我们发现客户对稳定性的诉求是永无止境的，应用高可用并不能保证所有的服务切换对业务无感，事实上，在部分 IaaS 服务异常时，即使应用层高可用，用户的体验也会因为请求被重置等受到影响。另外，也并非所有的客户都具备构建高可用服务架构的条件和能力，例如：游戏业务引擎的单机特性，高速发展的创业客户对 ROI 的考量等，因此试图通过应用层高可用来规避底层 IaaS 服务稳定性的风险，并非解决所有客户问题的银弹。

阿里巴巴集团核心系统敦促 IaaS 稳定性的极致追求，迈向新高度。

阿里云 IaaS 服务除了给外部客户提供服务外，阿里巴巴集团核心 IT 系统也构建于阿里云 IaaS 服务之上，阿里双十一超大规模极端大促场景，以及大促前极限全链路压测、无提前通知的混沌工程等对阿里云 IaaS 服务提出了极大的考验，IaaS 服务的稳定性关系到整个阿里巴巴集团核心 IT 系统的稳定。
在外部客户和阿里巴巴集团内部场景的双轮驱动下，提供稳如磐石的产品稳定性，把困难留给自己，把简单留给客户，成为阿里云 IaaS 服务责无旁贷的使命，也促使阿里云 IaaS 不断去做独一无二的稳定性。

1.1 稳定性共建：云与客户责任共担

云上应用系统的稳定性，既依赖于云基础设施的稳定性又依赖于应用系统本身的稳定性，因此需要阿里云与客户共同承担责任，来保障应用系统的稳定运行。
阿里云责任：提供高可靠的基础设施（包括运行阿里云服务的硬件、软件、网络和机房设施）、确保服务可用性满足 SLA 服务等级协议；并对客户正确使用云服务构建高可用应用系统提供指导。
客户责任：客户选择合适的云产品、进行可用性配置以符合应用稳定性目标；并参考本支柱的设计原则与原理、结合相关设计指南进行高可用应用系统构建。

1.2 阿里云稳定性的衡量和目标

通常使用可用性目标来作为应用系统的稳定性衡量。可用性目标用于衡量应用系统的运行时间和停机时间，其表现形式为应用系统正常运行的时间占总时间（通常是一个月或一年）的百分比（如 99.9%），即：可用性 = 可用时间 / 总时间 * 100%

常见的简单表达方式用“9”的数量或“9”的数量加“5”表示，如“三个9”表示“99.9%”，而“三个9一个5”表示“99.95%”。

为了云上用户能够构建出符合自己定义的可用性目标的应用系统，阿里云售卖的云产品也是按照可用性目标进行承诺，即 SLA（Service Level Agreement）。然而，阿里云作为应用系统的基础设施，其自身的稳定性建设仅仅关注可用性目标或 SLA 是远远不够的，阿里云内部给自己定义了更高的衡量标准和目标。即：围绕着提升稳定性核心本质的 3 个维度：

• 减少故障发生次数
• 缩小故障影响范围
• 降低故障恢复时间

设定目标和衡量，进行全生命周期（设计与研发阶段、发布与上线阶段、故障应急阶段）的稳定性建设。

中断频率：时间维度的衡量

故障发生次数，即中断频率，指在特定时间段内云计算服务发生中断的次数，是衡量系统可靠性的基础指标：

• 高频率的中断通常表明系统存在结构性缺陷或对外部扰动过于敏感。
• 低频率则反映系统具有较强的内在稳定性。

中断时间：恢复能力的衡量

故障恢复时间，即中断时间，指从服务中断发生到完全恢复所需的时间，体现了系统的韧性和恢复能力。它不仅包括技术层面的系统恢复时间，还涵盖故障检测、诊断、决策和验证等全过程，它反映了系统整体的响应效率。

影响范围：波及广度的衡量

故障影响范围，指一次服务中断所波及的用户、云产品实例、应用或数据的广度，反映了系统故障的传播特性和隔离能力。在云计算环境中，由于资源共享和系统互联的特性，单一故障可能迅速蔓延，导致影响范围扩大。影响范围的概念与故障域密切相关，一个设计良好的云平台要能在资源充分共享的情况下将故障限制在最小范围内，避免系统性崩溃。

1.3 设计原则

阿里云从减少故障发生次数、缩小故障影响范围、降低故障恢复时间 3 个维度进行稳定性设计考量，围绕产品全生命周期进行稳定性约束，最终保障稳定性目标的达成。为此，阿里云稳定性建设遵循如下原则：

深度自主可控，消除“故障盲区”

深度自主可控原则强调对核心技术和基础设施的完全掌控，这是构建稳定云计算平台的前提条件。在云计算领域，深度自主可控意味着坚持关键组件的自研路线，避免对第三方技术的过度依赖，从而确保在出现问题时能够快速定位、修复和优化系统避免故障：

• 深度自主可控能力使阿里云能够针对特定场景进行深度优化，例如通过自研调度算法平衡资源利用率与故障隔离需求，或定制化硬件，开发智能网卡提升系统整体性能。
• 深度自主可控还体现在对技术栈的端到端理解上，当故障发生时，拥有完整技术栈控制权的团队能够快速跨越传统组织边界，从应用层直达硬件层进行问题诊断。与之相对，过度依赖黑盒组件的架构可能导致"故障盲区"，当问题超出供应商支持范围时，恢复时间将显著延长。

阿里云通过自研飞天操作系统，AliServer 服务器、神龙计算平台、盘古分布式存储系统、洛神云网络系统等各个云计算组件，实现了云计算平台的深度自主可控。

面向全局的设计，保障架构稳定

稳定性设计的核心在于通过架构设计将韧性内生于系统之中，而非事后补救。

多层次的冗余高可用减少故障频率：

• 多可用区设计实现地理级故障隔离，单个数据中心故障不影响全局服务。
• 集群化架构通过动态负载均衡和自动故障转移，将硬件故障的影响降至最低。

冗余设计不是简单堆砌冗余资源，而是基于故障概率模型的精确计算，在成本与可靠性之间取得最优平衡。阿里云存储实现了 LRS/ZRS 的容灾架构设计，基于 EC 编码高效地实现了 12 个 9 的数据可靠性。网络实现了各组件的集群化，多可用区多活架构。

多层次的隔离缩小故障影响范围：

• 单元化架构将系统划分为相互独立的故障域，单个单元故障不会扩散至全局。
• 水平扩展策略替代传统纵向扩展，避免单点容量瓶颈导致的级联故障。
• 主动式故障域隔离，通过预测性分析和预防性措施，在故障实际扩散前就主动将潜在风险区域隔离，从而防止故障蔓延并最小化服务影响。

在隔离场景下，阿里云 ECS 提供部署集功能，存储建设多维度的 QoS 能力，云网络 Cstar 平台部署了微突发实例动态调控技术。

资源预留避免系统过载：

与弹性相对，良好的资源预留设计可以提供系统在固定资源配额下维持服务连续性的能力，它不依赖资源的动态调整，而是通过精心设计的架构和流程确保基础服务层的可靠性。阿里云资源预留能力的核心在于基础资源的冗余设计，同时还以产品预留资源能力向客户透出。

阿里云计算存储网络等组件均具备对系统容量资源水位进行精细化管理和预留，从而保证整体系统的稳定性。

可控的变更管理，降低人为错误风险

变更管理和运营实践是将稳定性设计原则落地的关键环节。在变更管理方面，严格的变更手册和流程控制是预防人为失误的第一道防线。

实施分级变更制度：

阿里云变更严格按照运行手册执行；对于变更申请设置不同等级，对高风险操作要求多人审批、预演验证和回滚预案。

自动化变更：

阿里云对于变更全面引入自动化，确保操作的一致性和可追溯性，避免"配置漂移"导致的隐性故障。使用完全白屏化的变更管控，杜绝黑屏引入故障。变更前的充分测试同样至关重要，包括单元测试、集成测试、混沌测试和全链路压测，确保新版本在各种极端场景下仍能保持稳定。

阿里云 ECS 建立了精细化灰度探测机制，所有变更按照覆盖硬件环境、软件版本、业务场景类型等维度预先智能定制发布策略。存储产品的灰度机制由 OSSBrain 精细控制，对于涉及数据可靠性的变更，将其应用控制在每个集群 1 个机架，或 LRS 集群的 1 个 AZ 来执行灰度验证。云网络实施定期的配置对账和修复，每小时级别进行管控和转发设备的配置对账。

"Fail-Ops"运营，防患于未然

可恢复性降低故障时间：

• 全面的检测和感知系统实现秒级故障发现。
• 智能降级和熔断机制在部分组件失效时保障核心功能可用。
• 自动化的恢复流程确保平均修复时间最小化。

在可恢复场景下，阿里云 ECS 构建了基于事件的智能化异常调度系统，存储部署了持续数据校验 CC 系统，网络推出的主动式重路由 ZooRoute 技术等实现高精度的异常检测和恢复能力。

自动化实现故障自愈：

阿里云系统的自动化体系，已从简单的脚本执行，发展为涵盖监控、诊断、恢复、优化的完整闭环，形成了"感知-分析-决策-执行-学习"的智能保障链条。在稳定性系统中引入自动化，不仅替代了重复性人工操作，避免人工引入错误，更通过智能决策和快速响应构建了系统内在的"自愈"能力。

“Fail-Ops”，以破坏性测试和故障演练为核心的工程实践：

以破坏性测试为核心的工程实践是一种主动暴露系统弱点、验证系统韧性的方法论，其核心思想是"在可控环境中主动引入故障，以发现并修复潜在问题，从而避免在生产环境中发生灾难性故障"。阿里云以持续的混沌工程和故障演练，把经验“编码”进系统。

故障复盘机制，结构化、系统化的故障分析与学习流程：

阿里云故障复盘将每次真实故障转化为改进机会，形成可执行的改进项，并将关键检查点沉淀为自动化 checklist 或代码化防护规则，避免同类问题重复发生。

智能运维“AI-Ops”，正在变革传统运营模式：

机器学习模型可从海量监控数据中识别异常模式，实现故障的早期预警；大语言模型则能辅助分析复杂日志，快速定位问题根源；自动化修复系统甚至能在人类介入前完成简单故障的修复。

阿里云基于智能运维体系，开发部署了 ECS 智能故障预测体系，存储自动化异常检测系统，智能网络运维系统齐天，增强运维团队的洞察力和响应速度，将稳定性保障从"救火式"转向"预防式"。

计算篇 - 底座坚实、调度智能，构筑 ECS 稳定性工程的核心支撑

2.1 目标和度量

阿里云 ECS 的稳定性目标是“以 x86 的硬件，实现小型机的稳定性”，围绕这一目标， ECS 建立了度量稳定性的指标体系，包括：后端技术指标以及客户侧反馈指标。通过量化指标不断跟踪现状与目标的距离，并牵引驱动稳定性能力的演进迭代。

定义合适的 ECS 稳定性后端技术指标，需要从客户的稳定性体验出发，凡是影响客户稳定性体验的因素，都需要纳入指标计算。影响客户 ECS 稳定性体验的因素众多，总体上可分为两个维度：一是异常类型，包括：实例宕机、夯机、GuestOS panic、性能抖动和主动运维等；二是异常影响程度，包括：异常发生的频率和持续时长。基于此， ECS 定义了度量稳定性的后端技术指标：客户体感异常率，该指标的含义为：ECS 实例单位运行时间内的异常次数，具体定义如下：

针对实例宕机、夯机、GuestOS panic、性能抖动和主动运维各子方向，分别定义了宕机率、夯机率、GuestOS panic 率、性能抖动率以及主动运维事件率子指标。

为了规避后端技术指标对稳定性度量的局限性，ECS 增加了从客户侧反馈进行度量的指标体系。当客户遇到 ECS 稳定性问题时，一般会通过工单或者客诉进行主动反馈，所以稳定性工单率、客诉率可以从客户侧反馈维度对稳定性进行量化。考虑到部分客户不主动反馈的情形，ECS 通过 NPS 调研主动触达客户收集稳定性反馈，量化指标为 NPS 净满意度值。

归纳下来，ECS 稳定性度量指标体系如下图所示：

2.2 稳定性系统工程

为了实现“以 x86 的硬件，实现小型机的稳定性”这一极具挑战的目标，ECS 对稳定性架构和体系提出了极高要求，ECS 每个组件从设计的第一天，稳定性（异常率，可观测，可规避）就是系统设计的核心指标。标准的数据和控制规范连通了所有组件，他们之间相互分工协作，使得整个 ECS 的稳定性螺旋上升，持续提高。ECS 稳定性保障体系整体架构如下图所示：

坚实的基础底座

ECS 乃集大成者，构建于阿里云坚实的基础底座之上，包括数据中心、网络、服务器、飞天操作系统等核心组件。ECS 与这些组件团队紧密协同，通过架构高可用设计和严密的质量控制体系，提升这些组件的内在可靠性，具体包括：

高标准智能化数据中心：环境动力方面，引入双向独立市电，机柜服务器 AB 双路供电，电池后备电源无缝接管，N+1 冗余柴油发电机自动切换接管，保障电力系统高可用。除此之外，阿里云数据中心通过技术创新，实现业界领先的数据中心冷却系统，保障数据中心整体环境温度控制在合适范围内。日常运维能力方面，实现 IDC 内设施的秒级数据采集，实时告警、根因定位和拓扑展示，结合中心运维管理平台和移动 APP，实现了中心 + 本地 7x24 不间断的 IDC 云运维能力。

基于自研交换机的高可用物理网络：实现了 AZ 间低延时高速互联，AZ 内双冗余网络架构，IDC 超过三路由的线路保护，3+N 多线接入 BGP，实现业界领先的 BGP 弹性容量。具备业内领先的健壮性及故障自愈能力，通过网络秒级监控-智能定位-自动恢复的故障自愈体系，网络可实现自动化异常设备隔离、异常流量调度、异常路由自动优化等能力。

自研 Aliserver 服务器：通过深入自研底层硬件和软件，形成了统一的服务器产品— AliServer，包含核心自研部件和定制芯片，从芯片部件级专研匹配业务场景，以实现更强更稳的计算能力。阿里服务器通过严密的实验室及生产全链路硬件测试等方案，做到有效拦截硬件批次质量隐患。借助软硬件结合技术，在故障诊断、容错、隔离等领域持续发力，支撑硬件故障率远低于业界平均水平。

自研飞天操作系统：阿里云服务器操作系统 Alinux 是飞天云平台的底座，依据云计算的业务场景需求，将互联网、云计算与开源技术相结合，经过长期技术积累与实践而成。阿里云服务器操作系统 Alinux 不仅在 RAS (即可靠性、可用性、可服务性上) 做了大量研发工作，而且还提供了强大的运维能力，大幅减少因系统升级、缺陷修复等导致的服务器重启和停机时间；自研神龙计算平台通过自研芯片和 x-dragon hypervisor 系统软件，实现 VPC 云网络、EBS 云存储、管控和安全等分离部署和完全芯片卸载加速，神龙创新性地实现 FPGA 等全系统关键组件的业务无感热升级；洛神系统是阿里云自研的虚拟网络系统，其基于数据驱动的管理平面能够自动分析和定位链路故障，通过冗余链路实施秒级容灾切换。建设软硬一体的高容错系统架构，将软件的高弹性和硬件的高性能相结合，既能支持云网业务的持续演进，又能适配云网流量的快速上涨。自研分布式块存储平台 EBS 作为 ECS 核心依赖，架构设计上注重弹性能力，采取面向错误的设计以确保各种异常场景下的高可用性，在个别机器、交换机异常时能够做到客户无感，其最新发布的 regional ESSD 产品在可用区异常时可以自动恢复。EBS 极其注重数据正确性，通过全链路数据校验、多角度扫描验证等技术确保数据在计算、网络、存储双向流动时的绝对正确性。
智能异常调度平台

1. 全方位监控诊断（全链路监控诊断，实现 ECS 异常秒级感知）
   
   ECS 监控诊断报警体系依托数据中台，构建了从数据采集、异常诊断、实时报警的完整闭环。数据采集覆盖数万监控项，并提供标准输出格式供各方消费；异常诊断基于 ECS 全网统一收集和存储的监控和事件数据，依托全链路定界平台，实现 ECS 全链路异常信息的完整分析和诊断，提升异常的根因定位效率；实时报警基于报警规则，秒级将报警信息发送至相关订阅方。完善的监控诊断体系，极大地缩短了 ECS 异常感知的时长。

2. 精细化灰度探测（以精细化灰度探测，实现发布的“先知”能力）
   
   为持续给客户提供新的功能特性和提升用户体验，ECS会定期进行产品迭代，迭代过程可能涉及从数据中心、网络、服务器、存储、虚拟化到ECS上层业务的各类组件变更，为规避变更对ECS稳定性带来的可能影响，ECS建立了精细化灰度探测机制，依托数据中台，所有变更按照覆盖硬件环境、软件版本、业务场景类型等维度预先智能定制的发布策略，先进行小流量灰度探测，一旦在小流量阶段发现异常，立即熔断拦截变更，配合轮转、热迁移等能力，快速修复小流量问题，并消除潜在变更风险对后续ECS实例的影响。

3. 智能故障预测（稳定性的至高境界，不是故障后修复，而是风险前预防）
   
   治病的最高境界是治病于未病，将问题消弭于萌芽之前。为此，ECS 依托数据和算法中台系统性构建了智能故障预测体系，核心是异常预测数据闭环、预测工程化闭环以及强大的异常预测业务模型。异常预测数据闭环，建立了可应用于云服务器预测的数据清洗标准和完整的异常数据标注体系，包括：异常数据采集汇聚、异常数据清洗、弹性计算特征工程和告警中心、异常根因分析和数据标注；预测工程闭环，核心是建立了异常预测模型循环迭代优化的完整机制，包括：数据清晰与 ECS 特征工程、ECS 异常预测模型、预测结果流入 ECS 异常调度中心、异常服务器压测闭环、压测结果标注、bad case 分析和评价机制；针对异常预测业务模型，构建业务模型管理系统，将所有算法模型进行全生命周期管理，实现模型良性循环迭代。当前，智能故障预测已在 ECS 多个场景大规模应用，准确率和召回率达 90% 以上，提前发现了 70% 以上的故障隐患。

4. 异常调度体系（ 90%+ 潜在稳定性风险，被异常调度体系提前化解）
   
   异常感知后，如何快速提前避险，是异常调度体系所要解决的问题。为此，ECS 构建了基于事件的智能化异常调度系统，核心能力包括三方面：

一是以事件为中心，所有系统间交互以事件驱动，告警作为资源的一个状态事件，经过业务规则判断和加工，形成运维或客户侧事件，供各方消费，系统之间松耦合，可快速扩展；

二是统一的业务规则中心，业务规则统一，可松耦合利用数据和算法中台的计算和机器学习能力，产生额外价值；

三是整体运维和产品调度体系融合。

通过上述核心能力的实现，90% 以上的潜在稳定性异常风险都可以通过异常调度体系来规避。

5. 客户侧事件体系（构建客户协同防线：ECS 通过事件体系实时触达实例风险与状态）
   
   ECS 通过客户侧事件体系构筑 ECS 和客户联动的桥梁，和 ECS 实例相关的稳定性风险或资源状态变化等，ECS 会发送对应的事件通知客户，事件类型可参考 ECS 系统事件概述，客户可以在 ECS 控制台或通过阿里云 CLI 调用阿里云 OpenAPI 对事件进行查询，也可以通过云监控进行个性化的触达订阅，包括配置电话、钉钉通知规则，或发布至 MQ 等供客户侧运维系统消费处理。查询、订阅事件后，客户可对事件进行响应，通过响应事件规避相关风险。更多详细的查询和响应事件说明，请参考官网文档 -ECS 系统事件查询和响应。

6. 故障快恢体系（让快恢能力始终在线：打造持续保鲜的故障应对体系）
   
   即使 ECS 构建了完善的故障预测和异常调度等能力，但故障仍不可 100% 避免。故障发生后，需要快速恢复，尽可能降低 MTTR（Mean Time To Repair），ECS 建立了完整的故障快恢体系，核心思路是对于人（故障处理者）、工具（快恢平台）、流程（故障预案和 SOP）的持续优化，并通过故障演练进行验收，确保故障快恢能力保鲜并持续迭代螺旋上升。

7. 客户稳定性重保（ECS 上线客户级稳定性重保能力，保障敏感期极致稳定）
   
   为了保障单客户的稳定性体验，尤其是客户处于稳定性敏感期的极致体验，ECS 建立了客户稳定性重保能力。技术能力方面：分析可能影响客户 ECS 实例稳定性的风险因素，针对性建设对应的重保原子能力。基于原子能力，面向客户业务场景，建设不同类型的重保套餐，满足客户多样性需求，实现针对性的保驾护航；服务能力方面：ECS 联合服务团队，组建重保标准服务阵型，建立客户联动风险消除能力，实现 ECS 稳定性风险的闭环消除；管理机制方面：建设重保申请标准、重保分级机制、评估审批机制以及配额管理机制，在重保成本和效果上实现更好的平衡。

存储篇 - 多重技术护航：构建高可用的存储稳定性体系

3.1 稳定性风险（稳定性风险的根源何在？）

要做好稳定性，首先要识别稳定性的风险来自哪里。这其中有所有产品相同的部分，比如代码质量，变更风险控制等；也有产品特定的风险，例如，以下一些稳定性风险就是和 OSS 的产品特性高度关联的：

• 数据可靠性：OSS 首先是一个存储产品，面临着所有存储产品都要解决的数据可靠性的问题。从最基本的磁盘/服务器的硬件故障，到发生概率极低但是对一个大规模存储系统来说却是必然发生的磁盘/CPU 的静默错误，以及现实环境中开发工程师的代码 bug，到运维同学的错误操作等等，都可能导致数据安全问题。
• 多租户隔离：OSS 是一个共享型产品，所有租户共享一个巨大的资源池；这带来了极致的弹性和成本优势；付出的代价就是任何用户的异常流量、冲击访问都可能会对其他大量客户造成影响。OSS 通过建设多维度的 QoS 能力来解决多租户隔离的问题。并且在近期开始将多年来打造的 QoS 能力输出给面临同样问题的大型客户。
• 互联网安全：OSS 提供互联网访问能力，为客户带来了便捷的使用体验。这也使得 OSS 暴露在互联网的 DDoS、CC攻击中，事实上 OSS 每年都要面临数万次的 DDoS 攻击。OSS 持续建设的防攻击模块 OSSDefender 有效地抵御了相关的攻击风险，使得个别客户引发的攻击不会影响到其他的租户。同时，OSS 也联合安全推出了和 OSS 紧密集成的“高防”能力，帮助面临类似困扰的客户应对攻击风险。

以上只是一些稳定性风险的例子，类似这样的稳定性风险还有很多。其中每一种风险都需要长期的持续投入来建设相应的稳定性机制。限于篇幅，后文我们将重点介绍 OSS 如何应对“数据可靠性”风险，过程中也会提及一些关联的“可用性”保障机制。

3.2 数据可靠性保障

数据可靠性的风险来自很多方面，大致可以划分为硬件、软件、人。首先，所有的硬件都是可能发生故障的，CPU、内存、磁盘等部件的故障都可能导致数据损坏。软件也是同理，即使我们有最好的程序员、最高标准的软件质量要求、最好的测试团队，我们也没有办法保证上线的代码没有bug，而严重的 bug 是可能导致数据丢失的。最后一个主要的风险就是来自运维人员，恶意的删库跑路、无意的误操作在业界都时有发生。

而应对这些风险，我们能依靠的是数据冗余，持续不断、无处不在的数据校验和修复，以及完善严谨的流程设计。下文，我们通过“容灾架构设计”来介绍 OSS 是如何做数据冗余的，通过数据冗余我们具备了应对硬件故障的基础；然后通过设计优良的“变更管控机制” ，我们可以最大限度地规避新硬件、新软件带来的数据损坏风险；最难以处理的硬件故障是“静默错误”，我们专门用一小节来介绍 OSS 在这方面的工作。

运维能力也是数据可靠性保证的关键一环，数据驱动的、高度自动化的运维系统保障了 OSS 的软硬件架构能够如预期地工作；同时，也最大程度地减少了人工介入的需要，这同时也有效地防范了人员带来的稳定性风险。

最后，就像硬件一定会损坏，软件一定有 bug 一样，精细设计的系统也不能保证万无一失；我们需要提前为灾难做好准备，在意外发生时，能够快速响应，最大限度地修复数据 —— 就像在 2024.09.10 新加坡故障中我们修复 OSS 单 AZ 数据一样。

容灾架构设计

LRS/ZRS 的软件架构

如图是 OSS 软件架构的简单示意；无论是 LRS 还是 ZRS 形态，OSS 的软件都可以大致划分为 3 层；

• 顺着红色箭头和序号示意的流程，首先接收到读写请求的是 OSS 的接入层，这一层由我们的负载均衡服务 AliLB 承接，负载均衡服务至少具备两组独立的部署，通过“大小路由”的方式实现自动故障切换；对于 ZRS 形态，两组独立的部署会分布在 2 个不同的 AZ 中；
• 接下来是 OSS 的协议层，由 Tengine 和 OSS Server 两个核心部件构成，完成 Http(s) 协议、认证鉴权、业务逻辑处理等功能，这一层服务是无状态的，异常的服务器会由 AliLB 的健康检查自动摘除来完成容灾切换；同样地，对于 ZRS 服务，协议层的服务器会分散部署在至少 2 个 AZ 中。
• 最下面则是我们的持久化层，包含负责索引海量小对象的索引服务“有巢”，以及大规模分布式存储服务“盘古”；这两层在容灾机制上类似，都是首先对服务做分区，然后每个分区由一组运行 Raft 一致性协议的成员共同提供服务，对于 ZRS 形态，这些成员均匀分散在多个不同的 AZ 中。

EC 编码和数据可靠性

前面一小节简单介绍了 OSS 的部署方式，各层的软件模块都具备冗余性，根据 LRS/ZRS 形态决定是在 AZ 内分散还是在 AZ 间分散，这保证了我们在机器或者 AZ 故障的时候具备了数据不丢，可用性不受影响的可能；那数据具体又是如何冗余的呢，这就要涉及 EC 编码了。

使用 EC 编码存储数据可以兼顾数据的可靠性和低成本；OSS 使用 EC 编码存储数据已经有 10+ 年的历史；EC 编码的算法也经过了多次优化升级，在冗余比、数据重建速度、数据校验机制等方面都有了长足的进步。

OSS 通过将 EC 编码中的 K 个数据块和 M 个校验块分散存放在实现数据的冗余；对于 LRS 形态，这些块按机架（Rack）分散存储，设计目标是任意 2 个机架故障不影响数据可用性和可靠性；对于 ZRS 形态，这些块按 AZ + 机架分散存储，设计目标是任意 1 个 AZ 故障，同时剩余 AZ 中再故障 1 个机架不影响数据可靠性。

在数据打散存放的基础上，通过数据建模，再带入生产环境的磁盘/机器故障实际概率，以及盘古系统通过复制修复损坏块的速度，确保生产环境的各种参数（单机容量、集群水位、数据修复带宽等）的组合可以保障 12 个 9 的数据可靠性。

在 AZ 故障时保持可用

数据的存储机制确保了 12 个 9 的可靠性，以及对机器和 AZ 故障的容忍能力；但是如果要保障在 AZ 故障时客户的业务正常运行，访问带宽不受故障的影响，还需要对性能容量水位做好冗余设计。以 ZRS 为例，假设数据存放在 3 个 AZ，那么故障后，有1 个 AZ 的数据需要通过计算来重建，这会带来可观的流量以及算力需求的放大，如果不能预留足够的资源，客户的业务访问就可能受到影响。

以 RS 6+6 的编码为例，如下图所示，12 个数据块均匀地分散在 3 个 AZ；当 AZ2 故障时，有 2/3 的数据要通过计算来重建，而可用于对外的机器只剩下了故障前的 2/3，简单的计算可知故障时每台机器要提供的带宽能力为故障前的 (2/3 + 1/36) / (2/3) = 4 倍。这是一个非常夸张的数字，如果按这个比例预留资源，客户要付出的成本就变得难以接受了。


而 OSS 采用了盘古创新的 AZC 编码算法，如上图所示，通过数据块和校验块划分为 AZ 内、AZ 间两个不同的维度，可以在 AZ 故障时，将故障 AZ 数据修复的读放大降低到 2 倍，从而将故障时的单机带宽放大降低到 (2/3 + 1/32) / (2/3) = 2 倍，再配合后台流量临时抑制等方式，基本可以将预留资源导致的成本上升控制在一个可接受的范围。具体的编码算法可参考盘古团队和上海交通大学合作发表的论文 —— “AZ-Code: An Efficient Availability Zone Level Erasure Code to Provide High Fault Tolerance in Cloud Storage Systems”。

以上只是对单机吞吐预留的说明，实际中还需要考虑 AZ 间专线带宽的水位预留，集群剩余存储空间的预留等；只有方方面面都做了充分的准备，才能真正做到从容应对 AZ 故障。过去的三年中，OSS 在香港、新加坡区域的 AZ 故障中，ZRS 产品都做到了持续可用，客户业务 0 影响！

变更管控机制

14 年王牌“老产品” OSS 通过一套成熟健壮的灰度机制，辅助以多维度的自动化的异常检测来确保软件版本中的 bug 被及时发现，不会对产品的可靠性可用性造成影响。

灰度机制

OSS 的灰度机制由 OSS 的运维大脑 OSSBrain 来精细控制；根据场景的不同采用不同的策略：

对于涉及数据可靠性的变更，比如，对数据的存储格式有修改的软件版本的发布，引入了新硬件的存储机型的灰度上线，OSSBrain 会利用 OSS 的数据冗余特性，将其应用控制在每个集群 1 个机架，或者 LRS 集群的 1 个 AZ 来执行灰度验证；在充分验证后再扩大灰度范围。

对于不涉及数据可靠性的变更，则按照分组（不同分组可能有不同的配置）、集群、区域的颗粒度，组成多级的变更灰度流水线来灰度变更；具体流程如下图所示，可以看到，在全球所有地域的发布过程中，任何分组、集群、区域的发布都会有精细的灰度，避免因为特定环境的特殊性引入的异常问题。

自动化异常检测

精细的灰度还要辅以全面的异常检测才是一个安全的发布机制。OSS 的异常检测可以分为两类：常态化运作的，以及针对发布流程的，这两类检测都可以在发现异常时自动阻断发布流程，避免问题扩散。

常态化异常检测：OSS 常态化的异常检测有针对可用性的 5xx 请求监控、SLA 异常监控、流量异常监控等；还有针对数据可靠性的持续数据校验 CC 系统，该系统会在所有的修改操作（上传、修改、删除）发生后自动触发一个数据完整性检测任务，对对象的数据完整性做快速校验，如果新的软件版本引入了数据安全问题，CC 系统可以在第一时间发现。

针对变更流程的检测：这类检测任务用以在变更期间，做更有针对性的、日常难以发现的异常检测；举个例子，OSS 日常有大量的 403 请求，这些请求未必是异常的，也许是由于客户错误的权限配置，也许是由于攻击的恶意嗅探；但是在变更发布过程中，如果我们把 403 请求都认为是正常的，则可能放过了软件变更在权限子系统上引入的问题；OSS 在变更期间，会针对同一个负载均衡分组中的新旧机器的 403 以及其他非 2xx 的请求做精细的比对，任何显著的比例变化都会被检测系统发现，进而阻断变更。

高危变更保障：除了以上机制外，对于重大的软硬件变更，OSS 还有一套全量的数据检查系统，作为以上机制的补充；这套系统针对大规模的数据检查优化，能在数天内完成整集群的对象的数据完整性检查。在高危变更的执行过程中，我们通过暂停数据回收，配合全量数据检查，来发现常态化的检查无法发现的数据异常；从而让 bug 无所遁形。

静默错误应对（明枪易躲，暗箭难防！）

在大规模的分布式系统中，任何低概率的事情最终都会发生！明枪易躲，暗箭难防！相比直接损坏，硬件的“静默错误”更难以处理；如果你没有做好充分的准备，当你发现他们时，问题可能已经大到难以处理的程度了。计算机行业很早就发现了内存的静默错误问题，并且推出了 ECC 内存；稍晚发现了 HDD 磁盘的静默错误问题；而 CPU 的静默错误问题则是近几年才引起重视，Google、Facebook 在 2020 年左右发表了相关问题的研究论文。而 OSS 作为一个大规模的存储系统，也在生产中发现了这些静默错误问题，并研发出了自己的应对处理机制 —— 专项检测机制，以及基于业务的检测发现机制。

静默错误专项检测

Scrub扫描：针对 HDD 磁盘的静默错误问题，盘古团队开发了 Scrub 扫描机制：首先在数据写入到 HDD 磁盘的时候，为每个小块的数据计算 CRC 校验值，将其和数据一起写入磁盘；然后在日常运行过程中，周期性的扫描检查磁盘上的所有数据和 CRC 校验值是否一致，如果不一致则将其磁盘标记为坏盘，并触发系统的数据修复机制，从其他的数据冗余中计算修复坏盘上的数据。Scrub 扫描的周期配合数据的冗余策略可以保证 12 个 9 的数据可靠性。

CPU SDE 检测：对于 CPU 的静默错误，我们有一套专用的 CPU 检测工具，就像一套 UT 测试一样，可以验证 CPU 的所有指令和计算逻辑是否符合预期。这套工具会用于所有服务器上线的准入检查中，并且在服务器的整个生命周期过程中都会持续执行检测，以及时发现损坏的 CPU。

基于业务的检测

写路径 CRC 检测：OSS 在写入路径上实现了全链路的 CRC 检查，从用户的写入开始（用户可以通过 SDK 启动数据完整性校验机制），到 OssServer，到之后的 KV、Pangu，每一层向下一层发送数据时，都会计算数据的校验码并同时发送给下一个模块，同时会核对前一个模块传递来的数据和校验码是否一致；直到 Pangu 的 CS 模块将数据连同其 CRC 值一起写入到磁盘上。这个机制是对前文 CPU SDE 检测机制非常有力的补充，可以防止在多轮 SDE 检测之间 CPU 的 SDE 错误导致数据损坏。同时，CRC 校验错误的信息也会被收集汇总，触发针对校验错误路径上所有服务器的 CPU SDE 检测。

读路径 CRC 检测：类似的，OSS在数据读取的路径上也会对所有数据的 CRC 值进行核验，避免异常损坏的数据返回给客户；同时，读取时 CRC 值的检测异常也会触发对磁盘的健康度检查，以及触发可能的损坏数据的修复。
以上机制在 OSS 的生产过程中多次检测发挥了作用，保护了 OSS 用户数据的 0 丢 0 错！

数据驱动运维

运维对稳定性的重要性不言而喻，这里还是举个例子来说明数据驱动的运维对维持 OSS 高可靠高可用的重要作用。以前面的 ZRS 面临 AZ 故障时的流量放大问题为例，50%的预留只是一个笼统的计算，实际上不同类型的请求对资源的消耗是大相径庭的；并且客户的请求也是频繁变化的，同时集群分组也不是一成不变的，比如有被动的服务器的故障维修，主动的扩缩容等。

OSS 的运维系统通过系统化的收集处理 OSS 生产相关的所有数据，以方便研发（OSS 采用 DevOps 的运维方式）同学编写运维规则，并自动化的调度执行；以 ZRS 的预留吞吐控制为例，运维系统持续统计生产集群的业务压力，根据相关的计算逻辑计算出需要预留的吞吐能力，并与实际的性能水位做比对，并在必要时触发扩容流程；从而保障 OSS 的 ZRS 持续在 AZ 故障时保障所有客户业务稳定运行的能力。

数据修复能力

如前文所述，再完美的系统也不能保证没有意外，存储系统给客户提供的数据可靠性保证不是 100% 正是由于这个逻辑。从另外一个角度，就像在新加坡 AZ 级故障中，OSS 的 LRS 产品受到波及，事后发现有大量的磁盘、服务器损坏情况；虽然从产品设计角度，LRS 形态不承诺可以应对 AZ 故障，但是只要有一线机会，我们仍然会尝试为客户修复数据。所以，数据修复的能力是一个存储产品必须具备的，也是体现一个存储产品技术能力的重要指示器。OSS 也持续在数据修复能力上投入，建设了众多能力。

自描述的格式设计

在类似新加坡故障这样的大规模异常中，可能有大量的数据遭到破坏，对于特定的数据块，我们可能可以根据元数据定位到它的分块存储在哪些磁盘上，但是磁盘上的数据文件可能已经无法读出了，比如磁盘的本地文件系统可能遭到了损坏。这时候，一个定义良好的，自描述的数据结构就体现出其价值了，比如我们可以通过全盘裸扫，找到数据块中的自描述信息，进而判断其属于哪个数据块并尝试拼接出原始的信息。一个大型的存储系统涉及到非常多的层次，对层层的信息都实现良好的自描述是非常有挑战的工作。

清晰明确的故障域

清晰的、细粒度的故障域划分设计，可以让我们在发生严重异常时，尽量降低影响范围，从而简化数据修复的工作量。同时，系统要具备较强的读写调度能力，可以在异常时快速调度业务压力，从而避免数据修复工作和前台业务的互相影响。OSS 在这两方面都有长期的能力建设，比如可以将故障影响面限制在特定的机架，特定的业务分区；可以在分钟级将一个集群的写入压力全部调度到其他集群。

完备的校验码机制

如前文描述，OSS 具备多层次的，全链路的完备的校验码机制，这些机制在数据修复时也可以发挥关键作用；尤其是在我们尝试通过碎片来拼接完整数据时。端到端的校验码可以确认最终拼接出的对象数据是否完整可靠。

对客的数据安全能力

以上数据修复能力是 OSS 储备的应对极端场景的技术底牌，在 OSS 的多维度的数据安全检测机制检测到异常，或者是类似新加坡 AZ 故障的极端场景中能够有效地保障用户的数据安全。但是对于用户自己误删数据的场景，由于 OSS 看起来并没有异常，所以不会拦截数据的回收，也就无从发挥其作用。为此，我们也专门提供了对应的技术能力，来帮助 OSS 的客户应对意想之外的数据风险。

多版本：OSS 支持了多版本功能，开启多版本后，用户的删除/覆盖操作并不会直接删除对象，而只是更新了一个更新版本的对象，之前的对象变为了历史版本。OSS 也有一套完善的生命周期管理机制来帮助客户管理历史版本的生命周期。强烈推荐所有的 OSS 客户开启多版本，并且在历史版本真正删除之前做好数据的检查工作。

同区域复制：虽然 ZRS 将数据冗余在多个 AZ 中，可以应对 AZ 级的物理故障，但是对于客户自身的误操作则无能为例；客户可以使用同区域复制功能将数据冗余到同区域的另一个 bucket 中实现冗余备份。

跨区域复制：跨区域复制从功能上类似于同区域复制，唯一不同的是它可以将数据在不同的区域间备份。

网络篇 - 云网络稳定性建设的范式重构：内生可靠、静态稳定、Fail-Ops

过去我们讨论网络的稳定性建设，是围绕容灾的设计（多链路/多板卡/多设备/多厂商/多机房），故障的检测和快速恢复（光路检测与倒换、BFD、健康检查探测）为中心展开的。云网络作为网络的一种形态，仅仅依赖上述手段是远远不够的，这来源于云计算网络和过去数据中心网络设计和使用的根本性不同：

• 多租户，微突发，资源争抢。云网络的特征是弹性、按需使用、按量付费。因此，云上的 VPC 组网，天然就是多租户共享的。云网络中存在资源争抢和微突发，这个用户使用的带宽大了，理论上另外一个用户能够使用的带宽就变小了。
• 软件处理。传统网络更加强调开放性和标准化，它的每个功能在提出之初就进行了标准化。而云网络天然就集成了云计算弹性灵活的特征，功能也还在不断快速发展中，因此通用软件处理是更合适的。通用软件处理在隔离性、确定性、超高性能等方面，相对于 ASIC 是有很大差异的。

我们需要突破过去稳定性建设的思路，探寻以大规模、多租户为特征的云网络稳定性能力新的方法。

4.1 全栈自研的稳定性红利 - 从内生可靠到破除任何“黑盒”依赖，最短的“经验- 修复”闭环，差异化的稳定性能力

阿里云的云网络技术栈，代号洛神，是阿里云全栈自研的云网络虚拟化平台。从 2014 年写 VPC 控制器的第一行代码开始，阿里云的工程师构建了 VPC、负载均衡、NAT 网关、VPN、GA、CEN、TR 等一系列网络基础服务。以下是云网络的关键技术：

• 全自研的 SDN 管控系统，通过分层、TridentCache、高性能的 ChangeSet 运算，支撑百万级 VPC 实例运行，单 VPC 可支持百万级网络节点。
• 高性能网关系统，阿里云是首个可编程交换芯片大规模落地应用的云厂商，当前已演进至“可编程交换芯片 + 自研网卡芯片 +CPU ”的混合架构，支撑了单实例 100Tbps+ 专线接入。
• 弹性网元平台 CStar，基于 ECS 构建的弹性开放的虚拟化网元平台，基于 ECS 构建意味着资源“无限”，弹性“无限”，解决了依赖传统 X86 物理服务器部署扩容周期长、弹性扩展困难等问题。支撑 NLB 分钟级 0 到 1Tbps 弹性带宽，TR 连接带宽分钟级 50 到 100Gbps 弹性带宽。

云网络全栈自研的技术底座，不仅仅是把云网络的规模、性能、弹性不断推向新的高度，更是稳定性的最根本基础。没有一个优秀的系统设计，就没有好的稳定性结果，稳定性不可能依靠打补丁达到。

破除任何"黑盒"依赖

全栈自研带来的第一个直接效果，让稳定性不再寄托于外部承诺，而是根植于自身可演进、可验证、可迭代的系统基因之中。

以 DPDK 2020 年修复的关于 IPv4 头校验和计算的bug为例：DPDK作为Virtual Switch，负载均衡，NAT，VPN 的基础组件，尽管该缺陷的发生概率低至十万分之二，但还是会给大量用户带来问题。唯有全栈自研，才能实现故障的精准定位，并找到更好的解决方法。源码面前无秘密。

最高效的"经验-修复-沉淀"闭环

面对不可避免的硬件故障、软件缺陷、配置错误和外部攻击，系统的稳定性不再仅仅取决于“不出问题”，而更关键地体现在从问题发生到彻底修复的响应速度与闭环效率上。

“经验-修复-沉淀”闭环，指的是从故障发生 → 问题发现 → 根因定位 → 修复方案制定 → 代码/配置变更 → 验证上线 → 经验沉淀的完整过程。闭环越短，意味着系统从“受伤”到“痊愈”并“获得免疫力”的周期越快。

• 传统模式：依赖外部组件或黑盒系统 → 故障定位难 → 需厂商支持 → 修复周期以“季度”甚至“年”计 → 经验难以沉淀。
• 理想状态：全栈自研、深度可观测 → 秒级告警、分钟级定位、10 分钟级逃逸、小时级修复 → 经验自动编码进系统 → 实现“一次故障，永久免疫”。

差异化的稳定性能力

真正决定云服务商能否支撑关键业务、赢得企业客户长期信任的，是那些超越通用方案、基于深度自研和场景洞察所构建的“差异化稳定性能力”。这些能力不是简单堆叠冗余或引入开源组件所能实现的，而是根植于全栈自研、架构创新、工程文化与大规模实践之上的系统性优势，是云厂商“内生可靠”体系的高阶体现。

• 主动式重路由 ZooRoute。

尽管我们在物理网络层采用了大量传统技术进行优化，但仍面临一个棘手挑战——临界光衰。网络链路的质量并非简单的“通”或“断”，而是一个连续变化的过程。当光纤受到外力挤压、弯折、施工割接、器件老化或外部环境干扰时，可能进入一种“时好时坏”的亚健康状态。

这种抖动具有突发性强、持续时间不一（从几百毫秒到十几分钟）的特点，难以预测且无法通过常规手段主动规避。传统的网络自愈机制（如 BGP 收敛）对此类间歇性故障响应迟缓，通常需数十秒才能完成路径切换，难以有效保障业务连续性。

为此，洛神推出主动式重路由技术 ZooRoute，实现对这类隐性故障的快速识别与精准应对。ZooRoute 具备高精度异常检测、多因子路径决策和秒级路由收敛能力，可将全网路由调整时间控制在1秒以内，相较传统 BGP 优化 90% 以上。通过主动绕行劣化链路，ZooRoute 有效避免物理层抖动对客户业务的影响，提供确定性的网络体验。

• 公网质量调优 NetExpress。

针对复杂以及不可控的 Internet 质量，除了加强公网互联资源建设，同时还需要进行技术创新，过去的公网质量调优更多是针对网段粒度的。但网段粒度很难满足不同客户千人千面的质量优化需求（除非这个网段的所有IP都是属于某个用户的）， NetExpress 的目标是支持单EIP粒度的流量调度。

NetExpress 的关键技术有三点：

• 1）在公网网关入方向封装 SRv6 格式携带相应路径标签进入阿里巴巴骨干网络，实现就近转发；
• 2）广域网链路借助 NetO 技术具备可编程能力，可以根据客户对 SLA 的需求选择相应的路径；
• 3）在公网网关出方向借助自研的 ePF（external peering fabric），选择最佳的运营商出口。借助 NetExpress 的能力，阿里云的公网平均抖动降低 30%，头部运营商平均时延降低 7~20%。
  
  724 主动式遥测 ZooNet。传统的物理网络用于诊断网络问题的方法，如 ping、traceroute 用于解决客户网络的问题效率比较低，这来源于这些方法无法完全覆盖虚拟网络协议栈、缺乏虚拟网络和物理网络的精确映射、旁路中间件、无法覆盖用户粒度的跨 VPC 或者 internet 边界。为此，洛神推出主动式遥测 ZooNet，实现在所有租户 724 的主动式覆盖，实现主动发现问题，发生问题后的快速排查。
  
  

4.2 主动式故障域隔离与爆炸半径控制 - 单元化部署，水平拆分，Shuffle Sharding

爆炸半径（ Blast Radius ）指当某个组件（如交换机、控制节点、软件版本）发生故障时，其影响波及的用户或服务范围，是衡量系统容错能力的重要指标。在大规模系统中，若不加控制，一次局部故障可能引发连锁反应，演变为区域性甚至全局性服务中断。问题在多租户共享资源和超大规模部署的云计算环境中尤为突出。

真正的云原生稳定性建设，应在保留弹性与共享的前提下，通过主动式故障域隔离与爆炸半径控制，实现“既共享又安全”的目标。以下是三个关键的设计策略：

可用区间隔离：单元化部署

目标：控制单机房故障影响，实现可用区级容灾。

实现方式：

• 可用区级别故障隔离，当某可用区内网络节点出现故障时，影响范围被限制在该可用区内，其他可用区单元仍能正常提供服务。支持流量调度和故障逃逸。
• 可用区级别流量调度，基于可用区的单元化架构支持快速的故障切换。当检测到某个AZ故障时，流量可以迅速切换到其他健康可用区的单元，确保业务连续性
• 可用区级别的容量规划，单可用区故障执行流量切换，系统能够根据实时负载情况智能分配请求，避免单个可用区过载以保证网络容量安全。

对爆炸半径的控制价值：

将灾难级故障影响控制在单个可用区内，在产品支持多可用区架构的前提下，用户通过多可用区部署可最大限度保障业务稳定性。

✅ 典型案例：公网出口基于多可用区部署，当某可用区故障时，不影响其他可用区的公网流量。

分区：实例水平拆分

目标：打破单实例容量瓶颈，限制单点故障影响范围。

实现方式：

• 将原本集中式的大规模服务（如 VPC 控制器、DNS 集群、元数据服务）按某种维度（如用户 ID 哈希、VPC ID 区间、地理区域）进行水平拆分，形成多个规模更小、职责独立的子实例（Shard）。
• 每个Shard仅服务一部分用户，彼此之间无共享状态，独立部署、独立扩容、独立故障恢复。

对爆炸半径的控制价值：

• 单个 Shard 故障仅影响其所服务的用户子集（例如 1%），而非全部用户；
• 故障排查和恢复更高效，MTTR（平均修复时间）显著降低；
• 支持精细化容量管理，避免“木桶效应”——某个热点 Shard 拖累整体性能。

✅ 典型案例：专线网关在每个 region 部署多套，SDN 控制器根据用户对 SLA 的需求、实际的水位综合评分，将不同的专线接入实例打散到不同的集群上。

Shuffle Sharding：随机化故障隔离

目标：解决“重复共址”问题，防止系统性风险集中爆发。

问题背景： 在传统分片（Sharding）或固定分组中，多个租户长期绑定在同一组资源上。一旦该组资源（如某台物理机、某个 vSwitch、某个控制节点）发生故障，这些租户将同时受影响，形成“群体性故障”，爆炸半径等于分片数量。

Shuffle Sharding 核心思想：

• 不再将租户长期固定在某一组资源上，而是通过哈希 + 多副本 + 随机映射的方式，将每个租户的请求或资源分配到多个独立的处理单元（Cell）中，并确保不同租户的“故障域组合”高度差异化。
• 即使多个租户共享部分资源，其最大重叠度被严格控制，确保没有两个租户共享全部处理路径。

对爆炸半径的控制价值：

• 单 Cell 故障时，受影响的租户是随机且稀疏分布的，不会形成“群体性中断”；
• 系统整体可用性趋近于“N 个独立系统”的并联可靠性，显著提升整体 SLA；
• 实现“规模免疫”：系统越大，个体租户受故障影响的概率越低。

✅ 典型案例：NLB/GWLB 等基于 Cstar2 的网元是典型的 Shuffle sharding 随机打散的。

4.3 打破控制平面的局限性：资源预留、数据面收敛、恒定性和静态稳定性

弹性是云计算的重要特征。我们也应用弹性来建设云网络，比如齐天（云网络智能运维平台，见后文）的数据中台的大部分分析任务。然而，对于关键服务不应该依赖弹性。这是因为弹性服务本身是控制平面实现的，有一定的局限性：

• 控制平面过载：当控制器的负载过高时，它可能无法及时响应所有请求，导致部分请求超时或被拒绝。
• 资源不足：即使控制平面能够接收请求，也可能因为可用资源不足而无法满足所有的扩展需求，造成弹性策略失效。
• 依赖外部服务：某些弹性方案可能依赖于第三方服务（如 DNS 解析、存储服务等）。如果这些服务出现问题，那么基于它们的弹性操作也会受到影响。
• 响应时间：弹性服务由于实现了复杂的决策逻辑、较多的跨服务调用延迟、数据一致性要求，响应时间可能会达到分钟级别。

实际运行数据显示，在正常工作状态下弹性服务的失败率大约在 1~5% 之间，资源不足是最大的原因。而数据平面的丢包率低于 0.02%（万分之二），这两者之间有 2 个数量级的巨大差距。因此，关键服务的部署必须有足够的资源预留。比如为云网络用户提供服务的控制器、基础的转发网关，他们日常部署的容量和处理能力是巨大的，远超单个租户的能力。

从这个局限性继续延伸，还有好几个重要的推论：

• 第一个是网络状态的变化优先采用数据面的收敛。针对网元的宕机和夯机我们设计了两套收敛方案：数据面的收敛方案采用高密的健康检查探测，自主决策，实际使用中一般是在 500ms-3s 之间就能生效；而控制面的收敛虽然同样采用高密的健康检查探测，但是由于执行的复杂度，一般需要 10-30s 才能生效。
• 第二个是保持控制平面负载的恒定性。自上而下的配置下发可以采用异步队列、变更合并、增量推送等技术，将“瞬时高压”转化为“平稳输入”。控制面报文的收发，如 HC报文、zoonet 报文、抓包等，必须通过队列、优先级调度、用户级+系统级限速的能力等机制，确保控制平面恒定有序地处理。
• 第三个是当控制平面组件失联失效时，转发组件保持最后已知状态继续工作，即静态稳定性。例如，我们的转发网关是由 Agent、转发进程、日志等多个组件组成的。最开始我们一直把所有进程看成一个整体工作：当 watchdog 进程监控某个组件失效时，它会重启所有的进程。重启转发组件进程会导致分钟级的流量黑洞。我们的改进是，如果失效组件是 Agent、日志等控制平面进程，让转发进程继续保持转发，直到值班工程师介入。

4.4 以破坏性测试为核心的工程实践 - 持续的混沌工程与故障演练，“Fail-Ops”，把经验“编码”进系统

以破坏性测试为核心的工程实践 - 持续的混沌工程与故障演练，“Fail-Ops”，把经验“编码”进系统

演练是稳定性的重要一环。作为复杂的大规模的基础设施，仅靠单元测试 / 功能测试 / 集成测试是不够的。对于故障的态度是，面向失败进行学习，从故障中学到的经验和改进，固化到系统中，并通过重复的故障注入，确定问题已经被彻底修复。

• 线上演练。在云网络稳定性建设中，线上演练已不再是“可选项”，而是验证系统韧性、暴露隐藏缺陷、锤炼应急能力的核心工程实践。线上演练的核心价值在于：在可控条件下，主动制造不可控的破坏。通过模拟光链路抖动、AZ 级断网、控制节点宕机、配置风暴等极端场景，验证系统是否能在无感或秒级恢复中维持服务 SLA。例如，借助 ZooRoute 的主动重路由能力，演练可触发某条物理链路的“亚健康”状态，观察系统是否能在 1s 内完成流量切换，而用户连接无中断。
• 事前评估，事后复盘。事前评估的核心是“影响域分析”与“风险预判”：通过自动化工具评估变更可能波及的租户范围、依赖组件和服务链路，识别是否涉及关键路径、是否有足够的资源预留、是否满足 Cell 化隔离原则。事后复盘是杜绝重复问题的根本手段。复盘不应止步于“谁错了”，而应聚焦于“系统为何未能自动恢复”。复盘要定义明确的行动，责任人，完成时间，并且被跟踪起来。
• 把经验“编码”进系统。在云网络的稳定性体系中，“把经验‘编码’进系统”是一项核心工程理念——它意味着不再依赖人的记忆或文档化的复盘报告，而是将每一次故障、演练或变更的教训，转化为可执行、可复用、自动化的系统能力。这是从“人治”向“自治”跃迁的关键一步。
• 重复故障注入，面向失败的学习。线上演练的 case 如何设计？除了像宕机这样常规的案例外，更多来自于我们踩过的故障。每一次故障的复盘，把一个个故障构造成为下一次线上演练的输入，是这个大循环的开始。

4.5 确定性的变更管理与系统密闭性 - 标准化发布与快速回滚、完全白屏化的变 更管控，杜绝黑屏引入故障

根据我们的统计，变更是引发稳定性问题的头号元凶，高达 80% 的故障是由于设备的替换、配置的变化、版本的更新引起的。洛神管理着 100 多种控制平面微服务近 1w+ 运行实例，1w+ 网关设备，10w+ 网元设备，百万级别的端设备。为了不断地更新演进，我们维护着 2000+ 套变更方案，每天运行的变更操作对象高达 1w+。如果不能有效地管理变更的质量，将会带来灾难性的结果。

云网络开发了齐天作为云网络的运维平台，它包括数据中台、智能运维、网络质量和可视化分析四大组件。数据中台是它的关键基础，它采集了云网络所有的控制器、链路和设备、产品实例、网络探测的多种维度的数据和观察。基于数据中台的能力采用大数据以及机器学习的方法，结合高度的自动化，通过分析海量的网络数据来将整个网络的生命周期进行智能化改造，成为超大规模的智能网络平台，从而让整张网络更稳定，更高效，更低成本。

标准化变更完全白屏化，形成密闭系统

云网络的变更方式，是沿着“手工变更→自动化变更→白屏变更”的思路去升级的：

• 手工变更：所有步骤都通过工程师登录到各个分散的系统敲命令行或者在管理页面上操作完成。
• 自动化变更：操作步骤通过 API 调用脚本化，放在 Access Gateway 上统一执行。
• 白屏变更：工程师在齐天控制台进行变更的创建，执行，分析。

变更方式的升级，首先是降低因为人为的错误引发的故障，同时提升变更的效率。在手工变更和自动化阶段，为了降低人为的操作错误，采用的机制是 double check 的机制。所有的操作由操作工程师 A 准备好，然后由复核工程师 B 进行double check，最后再由操作工程师 A 执行。这能够降低 99%的人为参数错误，但是效率很低。白屏变更并不是简单地将变更脚本的参数放到齐天控制台上一一录入然后执行，而是对所有的变更脚本进行了标准化，强调统一的输入，统一的错误处理，统一的回滚手段。比如原来不同的变更脚本对于“地域”这个参数，命名五花八门，region/regionId/regionNo 等多种都有。通过标准化统一收敛到 region，前端提供标准的树形选择框，减少错误发生的概率。同时由于入口的收敛，所有的变更都必须经过审批，无审批不变更，让一切对系统的更改都清清楚楚地被平台感知。

在白屏变更的中后期，我们开始逐步去除工程师们登录 Access Gateway 的权限。由于阿里云的办公网（开发）和生产网是相互隔离的，对于线上的生产系统就变成了密闭系统，它只能通过被有效管控的入口进行修改。

超大规模无人值守发布，异常自动刹车

随着阿里云业务的持续发展，云网络发布的规模相对于早年有了将近 100 倍的增长。按照阿里云要求的变更灰度原则、低峰期发布的基本要求下，即使采用白屏发布的方式也很难满足快速迭代快速上线的诉求，对于发布对象的观察忽略导致的问题持续上升，对于工程师们的变更压力越来越大。针对超大规模的发布，必须提升到 100% 的无人值守，才能实现业务增长、稳定性、人力投入的协调发展。无人值守是在白屏化的基础上，沿着“变更编排→智能监控→异常自动刹车”的路线再次提升。

变更编排按照发布的地域、客户的等级、封网的要求以及业务的诉求确定变更实际的发布顺序和时间。变更编排的基本要求是可灰度：

1. 从小地域到大地域，从小客户到大客户
2. 支持按客户灰度
3. 发布的设备量从小到大
   
   智能监控是无人值守发布的关键。智能监控对集群粒度和产品实例粒度的测量数据预测。针对 15% 平稳时序的数据，如大集群的整体流量，采用智能基线的方式，预测未来流量的上下限，当流量超出上下限时系统给出原子的告警。对于 85% 非平稳时序，如大部分中长尾产品实例的突发流量，监控其陡升陡跌、流量非超规格丢包等异常点。监控产生海量原子告警，通过多维度的聚合关联告警，通过AI训练的指标关联度进行更精细化异常检测计算，最终产生告警，进行异常自动刹车。

“1-5-10”快速恢复

发生故障，客户肯定不满意。在故障应急响应中，时间就是在不满意下努力追求的最小损失。我们一直追求的目标是 1-5-10：1 分钟响应，5 分钟定位，10 分钟恢复。

1. 1 分钟响应，重点在于组织协调能力。
2. 5 分钟定位，重点在于通过观察去发现哪个产品的哪个组件出问题，而不是定位具体的 root cause。前者可以通过异常指标观察，比如流量变化、限速丢包、异常指标值。而定位 root cause 往往更加复杂，往往需要分析代码、隔离场景、线下复现等一系列的过程，这些不是故障应急响应时的目标。
3. 10 分钟恢复，重点在于定义标准恢复流程 SOP。

定位问题更依赖于经验，需要有资深的同学主导。对于恢复，我们更加强调建设快速恢复三板斧，这些是业务无损的方案。对于三板斧的 SOP，我们要求全员都必须熟练掌握，甚至形成肌肉记忆。

总结

综上所述，虽然计算、存储、网络等 IaaS 服务构成了云计算的基石，并支撑着海量客户的业务运行，但仅依赖应用层的高可用和分布式架构已无法完全满足客户对稳定性的极致追求。随着越来越多客户将核心业务迁移至云端，阿里云深刻意识到，提升 IaaS 层本身的稳定性与可靠性，是保障客户业务连续性的根本所在。未来，唯有不断打磨底层基础设施的高可用能力，结合不同客户的实际需求与技术条件，提供更加全面、智能、无感的稳定性保障方案，才能真正实现“稳如磐石”的云服务承诺，为客户业务的持续增长保驾护航。

与此同时，在中国企业加速走向全球的浪潮下，阿里云也正以战略级投入，打造“全球云计算一张网”，推出国际化的 AI 产品体系，构建海内外一体的最优服务体系，全面支持中企出海。在 AI 时代的大背景下，阿里云将以更加稳定、智能、开放的基础设施和技术能力，助力中国企业在全球市场开创新格局，行稳致远，共赢未来。

（完）