index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文深入探讨了阿里云在基础设施稳定性方面的多年实践与理念。文章阐述了稳定性是云计算核心命门，并强调了云与客户共担责任的重要性。阿里云从减少故障发生次数、缩小故障影响范围、降低故障恢复时间三个维度，遵循深度自主可控、面向全局设计、可控变更管理、Fail-Ops运营等原则，构建了计算、存储、网络全栈的稳定性保障体系。通过智能调度、故障预测、数据校验、主动重路由等技术，阿里云致力于为客户提供稳如磐石的产品和服务。
🛡️ **稳定性是核心命门，双轮驱动追求极致**：阿里云将稳定性视为云计算的核心命门，这不仅源于百万客户的信赖，更受到阿里巴巴集团核心IT系统（如双十一）的极限考验。在内外双重驱动下，阿里云致力于提供“稳如磐石”的IaaS服务，将复杂留给自己，将简单留给客户。
🤝 **云与客户共担责任，构建稳定性共同体**：云上应用的稳定性是云基础设施与应用系统自身稳定性的综合体现。阿里云负责提供高可靠的基础设施并指导客户构建高可用应用，而客户则需选择合适的云产品、进行可用性配置，并参考设计原则构建高可用系统，共同保障应用系统的稳定运行。
🎯 **多维度衡量与目标设定，驱动稳定性体系演进**：阿里云将稳定性建设围绕“减少故障发生次数”、“缩小故障影响范围”、“降低故障恢复时间”三个核心维度进行衡量和目标设定。通过全生命周期（设计研发、发布上线、故障应急）的约束和建设，并引入中断频率、中断时间、影响范围等量化指标，驱动稳定性能力的持续迭代和提升。
💡 **全栈自研与精细化工程，构筑坚实技术底座**：阿里云通过自研飞天操作系统、AliServer服务器、神龙计算平台、盘古存储、洛神云网络等核心组件，实现了对云计算平台的深度自主可控。在此基础上，通过智能异常调度、精细化灰度探测、智能故障预测、主动式重路由ZooRoute、NetExpress公网质量调优等先进技术和工程实践，构筑了计算、存储、网络全栈的高容错、高可用、高韧性的稳定性保障体系。
🔧 **Fail-Ops运营与智能运维，实现“治未病”**：阿里云积极践行“Fail-Ops”理念，通过破坏性测试和故障演练主动暴露系统弱点，将经验“编码”进系统。同时，大力发展智能运维（AI-Ops），利用机器学习和大数据分析进行故障预测、根因分析和自动化修复，将稳定性保障从“救火式”转向“预防式”，实现“一次故障，永久免疫”的目标。
原创 阿里云基础设施 2025-08-18 08:30 浙江
这是2025年的第91篇文章
（ 本文阅读时间：15分钟 ）
本文作者：
李刚—阿里云弹性计算稳定性高级技术专家
闫卫斌—阿里云对象存储资深技术专家
温曙光—阿里云云网络产品运营高级技术专家
前言 - 基础设施稳定性理念十五年磨一剑，稳定性为何是今天的“命门”？深度自主可控能力使阿里云能够针对特定场景进行深度优化，例如通过自研调度算法平衡资源利用率与故障隔离需求，或定制化硬件，开发智能网卡提升系统整体性能。
深度自主可控还体现在对技术栈的端到端理解上，当故障发生时，拥有完整技术栈控制权的团队能够快速跨越传统组织边界，从应用层直达硬件层进行问题诊断。与之相对，过度依赖黑盒组件的架构可能导致"故障盲区"，当问题超出供应商支持范围时，恢复时间将显著延长。
阿里云通过自研飞天操作系统，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稳定性工程的核心支撑
存储篇 - 多重技术护航：构建高可用的存储稳定性体系数据可靠性：OSS 首先是一个存储产品，面临着所有存储产品都要解决的数据可靠性的问题。从最基本的磁盘/服务器的硬件故障，到发生概率极低但是对一个大规模存储系统来说却是必然发生的磁盘/CPU的静默错误，以及现实环境中开发工程师的代码 bug，到运维同学的错误操作等等，都可能导致数据安全问题。
多租户隔离：OSS 是一个共享型产品，所有租户共享一个巨大的资源池；这带来了极致的弹性和成本优势；付出的代价就是任何用户的异常流量、冲击访问都可能会对其他大量客户造成影响。OSS 通过建设多维度的 QoS 能力来解决多租户隔离的问题。并且在近期开始将多年来打造的 QoS 能力输出给面临同样问题的大型客户。
互联网安全：OSS 提供互联网访问能力，为客户带来了便捷的使用体验。这也使得 OSS 暴露在互联网的 DDoS、CC攻击中，事实上 OSS 每年都要面临数万次的 DDoS 攻击。OSS 持续建设的防攻击模块 OSSDefender 有效地抵御了相关的攻击风险，使得个别客户引发的攻击不会影响到其他的租户。同时，OSS 也联合安全推出了和 OSS 紧密集成的“高防”能力，帮助面临类似困扰的客户应对攻击风险。
以上只是一些稳定性风险的例子，类似这样的稳定性风险还有很多。其中每一种风险都需要长期的持续投入来建设相应的稳定性机制。限于篇幅，后文我们将重点介绍 OSS 如何应对“数据可靠性”风险，过程中也会提及一些关联的“可用性”保障机制。数据可靠性的风险来自很多方面，大致可以划分为硬件、软件、人。首先，所有的硬件都是可能发生故障的，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/3*6) / (2/3) = 4 倍。这是一个非常夸张的数字，如果按这个比例预留资源，客户要付出的成本就变得难以接受了。而 OSS 采用了盘古创新的 AZC 编码算法，如上图所示，通过数据块和校验块划分为 AZ 内、AZ 间两个不同的维度，可以在 AZ 故障时，将故障 AZ 数据修复的读放大降低到 2 倍，从而将故障时的单机带宽放大降低到 (2/3 + 1/3*2) / (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-Ops4.1 全栈自研的稳定性红利 - 从内生可靠到破除任何“黑盒”依赖，最短的“经验-修复”闭环，差异化的稳定性能力
全自研的SDN管控系统，通过分层、Trident cache、高性能的changeset运算，支撑百万级VPC实例运转，单VPC支持百万级网络节点。
高性能网关系统，阿里云是首个可编程交换芯片大规模落地应用的云厂商，当前我们演进到可编程交换芯片+自研网卡芯片+CPU的混合方案。支撑了单实例100T+专线接入。
弹性网元平台Cstar，基于ECS构建的弹性开放的虚拟化网元平台，基于ECS构建意味着资源“无限”，弹性“无限”，解决了依赖传统X86物理服务器部署扩容周期长、弹性扩展困难等问题。支撑NLB分钟级0~1Tbps弹性带宽，TR连接带宽分钟级50~100Gbps弹性带宽。
云网络全栈自研的技术底座，不仅仅是把云网络的规模、性能、弹性不断推向新的高度，更是稳定性的最根本基础。没有一个优秀的系统设计，就没有好的稳定性结果，稳定性不可能依靠打补丁达到。破除任何“黑盒”依赖全栈自研带来的第一个直接效果，让稳定性不再寄托于外部承诺，而是根植于自身可演进、可验证、可迭代的系统基因之中。上图是DPDK 2020年修复的关于ipv4头校验和计算的bug，由于DPDK是众多网络服务，如Virtual Switch，负载均衡，NAT，VPN，因此虽然它发生的概率低至十万分之二，但还是会给大量用户带来困扰。唯有全栈自研，才能实现故障的精准定位，并找到更好的解决方法。源码面前无秘密。最高效的“经验-修复-沉淀”闭环面对不可避免的硬件故障、软件缺陷、配置错误和外部攻击，系统的稳定性不再仅仅取决于“不出问题”，而更关键地体现在从问题发生到彻底修复的响应速度与闭环效率上。“经验-修复”闭环，指的是从故障发生 → 问题发现 → 根因定位 → 修复方案制定 → 代码/配置变更 → 验证上线 → 经验沉淀的完整过程。闭环越短，意味着系统从“受伤”到“痊愈”并“获得免疫力”的周期越快。传统模式：依赖外部组件或黑盒系统 → 故障定位难 → 需厂商支持 → 修复周期以“季度”甚至“年”计 → 经验难以沉淀。
理想状态：全栈自研、深度可观测 → 秒级告警、分钟级定位、10分钟级逃逸、小时级修复 → 经验自动编码进系统 → 实现“一次故障，永久免疫”。
差异化的稳定性能力真正决定云服务商能否支撑关键业务、赢得企业客户长期信任的，是那些超越通用方案、基于深度自研和场景洞察所构建的“差异化稳定性能力”。这些能力不是简单堆叠冗余或引入开源组件所能实现的，而是根植于全栈自研、架构创新、工程文化与大规模实践之上的系统性优势，是云厂商“内生可靠”体系的高阶体现。尽管我们在物理网络层采用了大量传统技术进行优化，但仍面临一个棘手挑战——临界光衰。网络链路的质量并非简单的“通”或“断”，而是一个连续变化的过程。当光纤受到外力挤压、弯折、施工割接、器件老化或外部环境干扰时，可能进入一种“时好时坏”的亚健康状态。
这种抖动具有突发性强、持续时间不一（从几百毫秒到十几分钟）的特点，难以预测且无法通过常规手段主动规避。传统的网络自愈机制（如BGP收敛）对此类间歇性故障响应迟缓，通常需数十秒才能完成路径切换，难以有效保障业务连续性。为此，洛神推出主动式重路由技术ZooRoute，实现对这类隐性故障的快速识别与精准应对。ZooRoute具备高精度异常检测、多因子路径决策和秒级路由收敛能力，可将全网路由调整时间控制在1秒以内，相较传统BGP大幅提升。通过主动绕行劣化链路，ZooRoute有效避免物理层抖动对客户业务的影响，提供确定性的网络体验。针对复杂以及不可控的Internet质量，除了加强公网互联资源建设，同时还需要进行技术创新，过去的公网质量调优更多是针对网段粒度的。但网段粒度很难满足不同客户千人千面的质量优化需求（除非这个网段的所有IP都是属于某个用户的），NetExpress的目标是进行单EIP粒度的流量调度。NetExpress的关键技术有三点：1）在公网网关入方向封装SRv6格式携带相应路径标签进入阿里巴巴骨干网络，实现就近转发；2）广域网链路借助NetO技术具备可编程能力，可以根据客户对SLA的需求选择相应的路径；3）在公网网关出方向借助自研的ePF（external peering fabric），选择最佳的运营商出口。借助NetExpress的能力，阿里云的公网平均抖动降低30%，TOP运营商平均时延降低7~20%。7*24主动式遥测ZooNet。传统的物理网络用于诊断网络问题的方法，如ping、traceroute用于解决客户网络的问题效率比较低，这来源于这些方法无法完全覆盖虚拟网络协议栈、缺乏虚拟网络和物理网络的精确映射、旁路中间件、无法覆盖用户粒度的跨VPC或者internet边界。为此，洛神推出主动式遥测ZooNet，实现在所有租户7*24的主动式覆盖，实现主动发现问题，发生问题后的快速排查。ZooNet系统架构图
ZooNet在一个月内一共检测了307次异常case
4.2 主动式故障域隔离与爆炸半径控制 - 单元化部署，水平拆分，Shuffle Sharding
可用区级别故障隔离，当某可用区内网络节点出现故障时，影响范围被限制在该可用区内，其他可用区单元仍能正常提供服务。支持流量调度和故障逃逸；可用区级别流量调度，基于可用区的单元化架构支持快速的故障切换。当检测到某个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）以下，这两者之间有2个数量级的巨大差距。因此，关键服务的部署必须有足够的资源预留。比如为云网络用户提供服务的控制器、基础的转发网关，他们日常部署的容量和处理能力是巨大的，远超单个租户的能力。从这个局限性继续延伸，还有好几个重要的推论：第一个是网络状态的变化优先采用数据面的收敛。针对网元的宕机和夯机我们设计了两套收敛方案：数据面的收敛方案采用高密的健康检查探测，自主决策，实际使用中一般是在500ms~3s之间就能生效；而控制面的收敛虽然同样采用高密的健康检查探测，但是由于执行的复杂度，一般需要10~30s才能生效。
第二个是保持控制平面负载的恒定性。自上而下的配置下发可以采用异步队列、变更合并、增量推送等技术，将“瞬时高压”转化为“平稳输入”。控制面报文的收发，如HC报文、zoonet报文、抓包等，必须通过队列、优先级调度、用户级+系统级限速的能力等机制，确保控制平面恒定有序地处理。
第三个是当控制平面组件失联失效时，转发组件保持最后已知状态继续工作，即静态稳定性。例如，我们的转发网关是由Agent、转发进程、日志等多个组件组成的。最开始我们一直把所有进程看成一个整体工作：当watchdog进程监控某个组件失效时，它会重启所有的进程。重启转发组件进程会导致分钟级的流量黑洞。我们的改进是，如果失效组件是Agent、日志等控制平面进程，让转发进程继续保持转发，直到值班工程师介入。
4.4 以破坏性测试为核心的工程实践 - 持续的混沌工程与故障演练，"Fail-Ops"，把经验“编码”进系统
线上演练。在云网络稳定性建设中，线上演练已不再是“可选项”，而是验证系统韧性、暴露隐藏缺陷、锤炼应急能力的核心工程实践。线上演练的核心价值在于：在可控条件下，主动制造不可控的破坏。通过模拟光链路抖动、AZ级断网、控制节点宕机、配置风暴等极端场景，验证系统是否能在无感或秒级恢复中维持服务SLA。例如，借助ZooRoute的主动重路由能力，演练可触发某条物理链路的“亚健康”状态，观察系统是否能在1s内完成流量切换，而用户连接无中断。
事前评估，事后复盘。事前评估的核心是“影响域分析”与“风险预判”：通过自动化工具评估变更可能波及的租户范围、依赖组件和服务链路，识别是否涉及关键路径、是否有足够的资源预留、是否满足Cell化隔离原则。事后复盘是杜绝重复问题的根本手段。复盘不应止步于“谁错了”，而应聚焦于“系统为何未能自动恢复”。复盘要定义明确的行动，责任人，完成时间，并且被跟踪起来。
把经验“编码”进系统。在云网络的稳定性体系中，“把经验‘编码’进系统”是一项核心工程理念——它意味着不再依赖人的记忆或文档化的复盘报告，而是将每一次故障、演练或变更的教训，转化为可执行、可复用、自动化的系统能力。这是从“人治”向“自治”跃迁的关键一步。
重复故障注入，面向失败的学习。线上演练的case如何设计？除了像宕机这样常规的案例外，更多来自于我们踩过的故障。每一次故障的复盘，把一个个故障构造成为下一次线上演练的输入，是这个大循环的开始。
4.5 确定性的变更管理与系统密闭性 - 标准化发布与快速回滚、完全白屏化的变更管控，杜绝黑屏引入故障
手工变更：所有步骤都通过工程师登录到各个分散的系统敲命令行或者在管理页面上操作完成。自动化变更：操作步骤通过API调用脚本化，放在Access Gateway上统一执行。白屏变更：工程师在齐天控制台进行变更的创建，执行，分析。
变更方式的升级，首先是降低因为人为的错误引发的故障，同时提升变更的效率。在手工变更和自动化阶段，为了降低人为的操作错误，采用的机制是double check的机制。所有的操作由A准备好，然后由B进行double check，最后再由A执行。这能够降低99%的人为参数错误，但是效率很低。白屏变更并不是简单地将变更脚本的参数放到齐天控制台上一一录入然后执行，而是对所有的变更脚本进行了标准化，强调统一的输入，统一的错误处理，统一的回滚手段。比如原来不同的变更脚本对于“地域”这个参数，命名五花八门，region/regionId/regionNo等多种都有。通过标准化统一收敛到region，前端提供标准的树形选择框，减少错误发生的概率。同时由于入口的收敛，所有的变更都必须经过审批，无审批不变更，让一切对系统的更改都清清楚楚地被平台感知。在白屏变更的中后期，我们开始逐步去除工程师们登录Access Gateway的权限。由于阿里云的办公网（开发）和生产网是相互隔离的，对于线上的生产系统就变成了密闭系统，它只能通过被有效管控的入口进行修改。超大规模无人值守发布，异常自动刹车随着阿里云业务的持续发展，云网络发布的规模相对于早年有了将近100倍的增长。按照阿里云要求的变更灰度原则、低峰期发布的基本要求下，即使采用白屏发布的方式也很难满足快速迭代快速上线的诉求，对于发布对象的观察忽略导致的问题持续上升，对于工程师们的变更压力越来越大。针对超大规模的发布，必须提升到100%的无人值守，才能实现业务增长、稳定性、人力投入的协调发展。无人值守是在白屏化的基础上，沿着“变更编排→智能监控→异常自动刹车”的路线再次提升。变更编排按照发布的地域、客户的等级、封网的要求以及业务的诉求确定变更实际的发布顺序和时间。变更编排的基本要求是可灰度：从小地域到大地域，从小客户到大客户；支持按客户灰度；发布的设备量从小到大。
智能监控是无人值守发布的关键。智能监控对集群粒度和产品实例粒度的测量数据预测。针对15%平稳时序的数据，如大集群的整体流量，采用智能基线的方式，预测未来流量的上下限，当流量超出上下限时系统给出原子的告警。对于85%非平稳时序，如大部分中长尾产品实例的突发流量，监控其陡升陡跌、流量非超规格丢包等异常点。监控产生海量原子告警，通过多维度的聚合关联告警，通过AI训练的指标关联度进行更精细化异常检测计算，最终产生告警，进行异常自动刹车。“1-5-10”快速恢复发生故障，客户肯定不满意。在故障应急响应中，时间就是在不满意下努力追求的最小损失。我们一直追求的目标是1-5-10：1分钟响应，5分钟定位，10分钟恢复。1分钟响应，重点在于组织协调能力；5分钟定位，重点在于通过观察去发现哪个产品的哪个组件出问题，而不是定位具体的root cause。前者可以通过异常指标观察，比如流量变化、限速丢包、异常指标值。而定位root cause往往更加复杂，往往需要分析代码、隔离场景、线下复现等一系列的过程，这些不是故障应急响应时的目标；10分钟恢复，重点在于定义标准的快速恢复的SOP。
定位问题更依赖于经验，需要有资深的同学主导。对于恢复，我们更加强调建设快速恢复三板斧，这些是业务无损的方案。对于三板斧的SOP，我们要求全员都必须熟练掌握，甚至形成肌肉记忆。综上所述，虽然计算、存储、网络等IaaS服务构成了云计算的基石，并支撑着海量客户的业务运行，但仅依赖应用层的高可用和分布式架构已无法完全满足客户对稳定性的极致追求。随着越来越多客户将核心业务迁移至云端，阿里云深刻意识到，提升IaaS层本身的稳定性与可靠性，是保障客户业务连续性的根本所在。未来，唯有不断打磨底层基础设施的高可用能力，结合不同客户的实际需求与技术条件，提供更加全面、智能、无感的稳定性保障方案，才能真正实现“稳如磐石”的云服务承诺，为客户业务的持续增长保驾护航。与此同时，在中国企业加速走向全球的浪潮下，阿里云也正以战略级投入，打造“全球云计算一张网”，推出国际化的AI产品体系，构建海内外一体的最优服务体系，全面支持中企出海。在AI时代的大背景下，阿里云将以更加稳定、智能、开放的基础设施和技术能力，助力中国企业在全球市场开创新格局，行稳致远，共赢未来。阅读原文
跳转微信打开
