2023 年 5 月一个看似普通的周一早晨，我以 senior member 身份加入了 Azure Core 团队的 Overlake R&D 项目组。这是我第二次进入微软，第一次是 2013 年加入 Windows 团队，后来参与 SharePoint Online 向 Azure 的迁移，再后来成为 Core OS 团队的内核工程师，参与了容器平台的技术发明与交付 —— 那项技术支撑了 Docker、Azure Kubernetes、Azure Container Instances、Azure App Services 和 Windows Sandbox。某种程度上，我对 Azure 的理解可能比绝大多数人都更深刻，因为我既是它的建设者，也是它最早期的用户之一。
然而，当我走进那个会议室的第一分钟，我就意识到这个组织正在经历某种深层的、工程意义上的危机。
第一个小时看到的工程现实
会议室里坐满了人，屏幕上是密密麻麻的架构图。我看到了 COM、WMI、perf counters、VHDX、NTFS、ETW 等一系列熟悉的缩写，还有新出现的 Azure 相关术语它们被箭头交织成一张复杂的网。一位 Principal Group Engineering Manager 正在讲解他们将现有技术栈迁移到 Overlake 加速卡的计划 —— 那是一张只有指甲盖大小的、运行 Linux 的 ARM SoC 芯片。
我举手提问：你们打算把 Windows 的这些组件移植到那个芯片上？得到的回答是肯定的，至少他们 “在考虑”。更让我震惊的是，这位经理建议 “可以让几个 junior dev 看看”。整个房间陷入了沉默。
我曾在之前的任期中见过 Overlake 卡的硬件规格：RAM 容量、功耗预算 —— 那只是一个普通服务器 CPU TDP 的极小部分。硬件团队的同事告诉我，他们只能为我的 doorbell 共享内存通信协议预留 4KB 的双端口内存。整个系统追求的是轻量化和低功耗，但眼前这个拥有 122 人的团队却在认真地考虑将半个 Windows 移植到那个 tiny chip 上。
这让我想起了 Elon 谈论火星殖民 —— 先炸掉两极再制造大气层，说起来容易做起来难。
173 个代理：过度工程化的标志性符号
在我加入后的几天里，我花了大量时间阅读项目文档、研究现有系统，并与老同事交流。其中一次与 Linux System Group 负责人的超过 90 分钟的面对面交流让我获得了关键信息：他们已经识别出 173 个需要移植到 Overlake 的代理程序。
当我进一步调查时，我发现了一个更加令人不安的事实：在微软，没有一个人能说清楚这 173 个代理分别是什么功能、它们之间如何交互、为什么需要这么多代理，或者说这些代理最初为什么要存在。
Azure 的核心业务是销售虚拟机、网络和存储。加上可观测性和运维服务，就已经足够了。SQL、K8s、AI 工作负载这些上层服务都建立在虚拟机、计算资源、网络和存储之上，使这些魔法成为现实的是 Core OS 团队和 hypervisor。
没有人能解释这 173 个代理是怎么来的。这种程度的技术误解本身就是灾难的温床。
请想一想，这个充满不受控制的 “东西” 的系统正在管理着 Anthropic 的 Claude、剩余的 OpenAI APIs、SharePoint Online、政府云和其他关键任务基础设施。你就会明白这个脆弱的积木堆中的一粒沙子如何导致全球性的崩溃 —— 带来严重的国家安全影响，以及可能终结微软业务的潜在后果。
信任 erosion 的工程化根因
这场危机的本质不是某一次 outage 或安全事件，而是系统性的工程决策失误累积而成的信任 erosion。让我从几个关键维度分析这个问题。
首先，架构复杂度的失控。173 个代理并非一蹴而就，而是在多年迭代中逐步堆积的结果。每一个新功能、每一次问题修复都可能在节点上新增一个代理，每个代理都有自己的生命周期、依赖关系和资源消耗。当复杂度超过人类认知和自动化管理能力的边界时，整个系统就进入了某种布朗运动状态 —— 看似在运行，实则无人能预判其行为。
其次，技术愿景与工程现实的脱节。Overlake 项目的初衷是通过专用硬件卸载卡来提升 Azure 的网络性能，这本身是合理的技术方向。但执行层面将 “卸载” 理解为 “完整移植整个软件栈”，就完全偏离了目标。团队没有对硬件能力进行实事求是的评估，也没有对迁移工作量进行可行性分析，就贸然进入了 “死亡行军” 模式。
第三，内部门沟通和决策机制的失效。一个需要 173 个代理的系统，任何单个工程师或团队都无力完整理解它。当决策权分散且缺乏统一的技术愿景时，组织就会陷入 “每个人都在做看似合理的事，但整体却在向错误方向移动” 的困境。
这些工程层面的问题直接传导到了业务层面。市场价值蒸发万亿级别、OpenAI 作为最大客户几近流失、国防部长公开表达对微软的信任破裂 —— 这些都不是偶然事件，而是长期工程决策累积的必然结果。
云服务选型的工程化建议
作为依赖云服务构建生产系统的工程师，我们应该如何从 Azure 的案例中吸取教训？
第一，审视云服务商的架构复杂度。在评估任何云服务时，不仅要关注其功能是否满足当前需求，还要考察其底层架构的可理解性和可预测性。如果一个服务需要大量隐藏的代理、协调器或中间层才能正常工作，那么其故障域也很难被准确界定。可以要求云服务商提供节点级架构文档，或者通过长期观察其行为模式来积累判断。
第二，关注向后兼容性与弃用策略的透明度。Azure 官方有生命周期政策和弃用流程，但实践中弃用通知期内的服务质量往往明显下降。对于关键生产系统，应该建立多云或多区域架构，避免对单一云服务的过度依赖。同时，定期审计正在使用的云服务是否处于弃用状态，提前规划迁移路径。
第三，将 SLA 承诺与技术实现分开看待。SLA 是一个法律承诺，但它的实现依赖于底层工程系统的健康程度。一个 SLA 达标率 99.9% 的云服务，如果其底层架构存在系统性风险，那么在长周期内遭遇重大故障的概率并不低。在做架构决策时，应该将云服务商的工程文化、技术债务状况和长期路线图纳入考量，而不仅仅是看 SLA 数字。
对于已经在使用 Azure 的团队，建议定期进行架构审查，识别那些隐藏在 “managed service” 后面的复杂性来源，并评估是否有简化的可能。
资料来源：本文核心事实与工程细节主要基于前 Azure Core 工程师在 iSolveProblems Substack 上发布的第一手经历记录，该文详细描述了 2023 年加入 Azure 团队后的观察与思考。