Azure CTO揭秘云端弹性：从宕机事故到AI运维的进化

微软Azure首席技术官Mark Russinovich在一次深度访谈中，罕见地公开了Azure在运行千万级服务器规模时如何应对故障、硬件失效以及AI带来的全新不确定性。这场对话不仅回顾了那次"拖垮整个Azure"的经典事故，也揭示了云厂商在AI时代重构可靠性思维的路径。

那次改变一切的宕机事故

当被问及"Azure是否真的曾整体宕机"时，Russinovich坦承确有其事，且不止一次。其中影响最深远的一次发生在Azure Storage的表格服务上。

一位开发者为满足Xbox的性能优化需求，改写了table接口的代码。测试环境下一切正常，于是他开始快速地将变更推向全球多个区域的存储戳（storage stamp）。问题却出在他没测试的blob接口上：某些应用会以"零字节长度"调用blob API——这本身是不合理的请求，但很多循环代码并未正确处理这种情况。当零长度请求命中新代码后，存储前端陷入无限循环而挂起。

更致命的是弹性机制本身放大了灾难。客户端遇到服务器故障后会重试，负载均衡器将故障服务器移出轮换、把客户端导向另一台，而这台又被零长度请求击垮——故障像多米诺骨牌一样连锁扩散至全球。

Russinovich指出一个关键数据：行业规模下约70%的云宕机都与变更相关。这次事故的"漂移"根源正是那次变更本身。

安全部署与混沌工程：把风险关进笼子

这次事故直接催生了Azure的"安全部署实践策略"（Safe Deployment Policy）。核心是分阶段灰度发布：

• 金丝雀区域：类似生产环境，但只对主动加入的客户开放
• 试点区域：小规模区域验证
• 烘焙期（bake time）：持续监控健康信号
• 随后才逐步推向全球

除了从真实事故中学习，Azure还主动"制造麻烦"。存储等最关键的服务大量投入混沌工程（chaos engineering）——向系统注入各种故障，验证"某台VM失效时系统应保持可用"这类假设。

Russinovich提到Netflix著名的"Chaos Monkey"，但强调Azure不会破坏生产服务，而是构建了名为Chaos Studio的公开服务。许多Azure服务已接入，用于故障注入、运行假设验证、举办"game day"，测试VM故障、网络中断、DNS失败等各种失效模式——这些都是Azure真实经历过的场景。

他坦言，无论测试多充分，都不可能彻底消除故障："这永远是概率游戏，渐进逼近完美却永远无法抵达。"

混沌工程（Chaos Engineering）的概念由Netflix于2010年代初正式提出并系统化。其核心思想是"在系统中主动注入受控故障，以发现未知的脆弱性"，而不是等待真实故障自然暴露。Netflix的Chaos Monkey会随机终止生产环境中的虚拟机实例，迫使工程师将容错能力内建于服务设计之中，而非事后补救。这一实践后来演化为更完整的"混沌工程原则"（Principles of Chaos Engineering），强调在稳定状态下建立假设、引入真实世界变量、在生产环境中运行实验，并持续自动化。Azure Chaos Studio与Netflix方案的关键区别在于平台定位：Chaos Studio作为公开云服务提供，允许客户对自己的工作负载进行受控故障注入，而不局限于内部团队使用，且故障实验的范围与爆炸半径受到明确边界约束，以保护生产稳定性。

用行为定义健康：SLI与Brain系统

大约五年前，Azure发现各团队对"服务是否健康"缺乏统一标准——有人ping一下有响应就算健康，粒度粗糙且各行其是。于是Azure确立了一条原则：服务只有在客户认为它健康时才算健康。

为此他们定义了标准化的**服务级别指标（SLI）**架构，涵盖每秒成功请求数、吞吐量、失败率等维度，并让所有服务按统一schema向Azure Monitor上报。这带来了跨个体客户、扩展单元、区域、可用区等各粒度的一致性度量。

下一步是如何利用这些数据。Azure没有让开发者主观定义"多少QPS才算健康"，而是反其道而行——用ML算法观察服务的实际行为来定义健康。这套名为Brain的AI系统持续监控SLI，自动训练ML模型，理解特定区域、特定服务在特定规模下"什么是健康"，并将显著偏离视为异常。

"你是在用现实定义现实，而不是靠某个人的断言。"Russinovich如此评价。因为系统过于复杂，开发者本身也无法精确预知系统应如何表现。

服务级别指标（SLI，Service Level Indicator）是Google SRE体系中定义可靠性的基础概念，与SLO（服务级别目标）和SLA（服务级别协议）共同构成可观测性框架。SLI是对服务行为的量化测量，例如"过去5分钟内成功请求占总请求的比例"；SLO是对SLI设定的目标阈值，例如"99.9%的请求应在200ms内成功返回"；SLA则是与客户签订的具有法律约束力的承诺，违反后会触发赔偿条款。三者之间存在层级关系：SLI是数据来源，SLO是内部工程目标，SLA是对外承诺，通常会在SLO基础上留出一定余量。Azure将SLI标准化并统一上报至Azure Monitor的做法，本质上是将Google SRE方法论在超大规模多租户环境中系统落地，同时通过机器学习替代人工设定SLO阈值，解决了"谁来定义正常"这一在复杂分布式系统中极难回答的问题。

硬件必然失效：千万服务器的数字游戏

在千万级服务器规模下，一个概率法则变得触目惊心：若某故障日发生概率为百万分之一，那意味着它今天已经发生了10次。

Russinovich展示了几个真实的失效部件：

• 电源分配单元（PDU）：负责为整机架服务器供电，一旦失效整个机架断电
• Azure Boost卡：搭载ARM处理器、FPGA的片上系统，服务器所有网络和存储流量都经过它，失效即失去主接口连接
• 基板管理控制器（BMC）：作为冗余，当主CPU无响应时可接管电源控制和离线访问
• Intel Gen 11处理器：任一针脚出问题都会导致整个CPU插槽失效

当硬件真正损坏时，就需要数据中心技术人员进行"break-fix"——拉出服务器托架就地维修，或送去"off for repair"。Russinovich表示，任何数据中心每天都有几十台服务器在做break-fix，因为哪怕失效率再低，庞大的基数也会产生大量故障。

有意思的是，Brain自动识别的故障比例长期稳定在70%-75%。这个数字从零起步后保持平稳，并非能力停滞，而是因为服务越来越硬化后，总有更加"深奥"的新故障类型不断浮现——如同剥洋葱，永远有下一层。

AI进入系统：加速响应的Triangle

环境不再是静态的VM，而是承载着AI应用的动态系统。Russinovich明确指出：Azure并未让AI直接管理基础设施，AI主要出现在应用层，以及事故响应侧。

事故排查最耗时的环节往往是定责。在AI时代之前，确定性分类器有时难以判断故障归属哪个服务，只能叫醒工程师翻日志、互相争论"是不是你的锅"。这会让缓解时间（time to mitigate）从几分钟飙升到数小时。

Azure的Triangle系统改变了这一点：不再叫醒工程师，而是由一个代表该服务、理解其历史与失效模式的LLM来回答"这是不是你的问题"。通过完全绕开人工介入，故障定位时间被大幅压缩。不过Russinovich强调，Triangle目前仍属"实验模式"，部分服务已接入，前景可期但仍在成熟中。

AI的不确定性：新的弹性挑战

AI著名的非确定性成为可靠性的新难题：同一个问题问两次，可能得到略有不同甚至截然不同的答案。这引出一系列全新风险：如何度量AI的正确性？如何确保它不泄露数据？如何防止它在未授权时执行破坏性操作？

Russinovich提出一个深刻的对比：人类以人类的速度行动，且需要为行为负责，因此有天然的谨慎与约束；而AI"只是想把活干完"，它可能不知道该遵守什么护栏，也不知道自己何时正在造成损害。

他的核心建议是尽可能保持确定性：只在必须用AI的地方用AI；即便使用，也要给AI套上确定性护栏。他举了一个典型例子——让AI升级代码库的依赖版本号：

如果直接说"升级所有版本号"，可能出现两个问题：一是AI误解某处的版本号而改错东西破坏应用；二是它可能被劫持去执行版本升级之外的操作。正确做法是限定AI"只改版本号"，再用第二个确定性系统检查"是否真的只有版本号被改动"。

如果无法实现确定性监控，则应加上"serial review"——第二个agent专门去找问题。监督与控制的强度应与系统的风险等级匹配：问错一个问题的风险有限，但数据中心级别的风险则完全不同。

AI系统的非确定性（non-determinism）源于大语言模型的生成机制：模型通过对下一个token的概率分布进行采样来生成输出，采样过程受"温度"（temperature）参数控制。温度越高，输出越随机多样；温度为零时输出趋于确定，但仍可能因浮点运算差异而产生细微变化。这种特性使LLM天然不适合作为需要幂等性（idempotency）或精确一致性的基础设施控制平面组件。提示注入（prompt injection）是AI应用在基础设施场景下另一类核心风险：攻击者可在外部数据（如代码注释、文档、网页内容）中嵌入恶意指令，诱使agent执行超出授权范围的操作，例如将依赖升级任务劫持为数据外泄操作。Russinovich所倡导的"确定性护栏"——用规则引擎或程序化验证层检查AI输出——正是针对这两类风险的防御纵深设计，与安全领域的"纵深防御"（defense in depth）原则一脉相承。

问责的不对称与共享责任

对话触及了AI治理的根本矛盾：AI无法被问责。"你要拿它怎么办？开除AI？扣AI的工资？"最终必须有人类为AI的行为负责——就像人类写代码要负责、其管理者要负责一样，部署agent的人也必须为该agent的正确行为负责，否则系统将失控。

Russinovich把"信任"视为AI价值的根本问题：如果能信任AI写的代码正确、符合规范、安全可靠，就能获得巨大价值；如果不能信任，人类就得花大量时间去验证甚至重做，从而侵蚀（虽不完全消除）AI带来的价值。

面向Agent重写的运维未来

Azure将大量故障经验通过Well-Architected Framework（WAF）、Cloud Adoption Framework（CAF）和Azure Essentials开放给客户，还有一个由Russinovich担任赞助人的可靠性博客系列，公开分享包括Triangle在内的实践与教训。

关于灾难恢复，他强调这本质是一道成本方程：比如黑五当天能带来1亿美元业务的应用，就值得投入多区域active-active架构；平日则可缩减为单区域加active-passive故障转移。可用区的取舍同样是弹性与容量成本之间的权衡。

对话最具前瞻性的洞见在于——运维文档正在从"写给人看"转向"写给agent看"。过去人类在VS Code里借助IntelliSense编写bicep清单，Russinovich认为这样的日子正在快速终结：未来是agent在阅读、审查、提供指导。用户只需说出想要的结果，agent就会依据"技能"去实现区域弹性、权衡取舍，甚至反问用户优先级。

因此，对想真正理解弹性的人来说，重点已不是学习具体操作，而是学会提出正确的问题——而这些博客恰恰提供了这些问题。

Well-Architected Framework（WAF）是微软面向Azure的架构最佳实践体系，涵盖可靠性、安全性、成本优化、卓越运营和性能效率五大支柱，与AWS的同名框架和Google Cloud架构框架在结构上相互借鉴。WAF的核心价值在于将大量生产事故中提炼的工程经验转化为可操作的评估问题和设计模式，供架构师在设计阶段使用。Cloud Adoption Framework（CAF）则定位更早期，覆盖组织从"决定上云"到"规模化运营"的完整迁移旅程，包含策略、规划、就绪、迁移、治理和管理六个阶段，更侧重组织变革与云治理。随着运维文档从"写给人读"转向"写给agent读"，WAF和CAF面临内容结构性重构的压力：结构化、机器可解析的指导内容将比叙述性文档更具价值，这也是Russinovich提到"学会提出正确问题"背后更深层的技术迁移逻辑。