AI代理致GitHub宕机，微软急寻AWS支援
在AI编码代理的爆发式增长面前，微软旗下的开发者平台GitHub正经历前所未有的可靠性危机。为了履行对企业客户的服务等级协议（SLA），微软被迫做出了一个令人瞩目的决定：将部分GitHub流量路由至其主要云竞争对手亚马逊云服务（AWS）的基础设施上。此举不仅暴露了Azure云在应对AI驱动工作负载时的容量瓶颈，也揭示了GitHub自2008年构建的Ruby on Rails单体架构，在面对机器速度的连续式流量冲击时的结构性缺陷。
AI代理流量激增325%，275周均千万级Commit压垮容量模型
导致此次危机的直接原因，是AI编码代理活动量的指数级增长。2026年3月，由AI代理发起的Pull Request数量较半年前激增325%，达到1700万个，而2025年9月这一数字仅为400万。这些代理（如Cursor、Claude Code、GitHub Copilot、Devin等）的运行模式与人类开发者截然不同：它们通过API和命令行全天候连续运作，无视周末和节假日，彻底打破了GitHub原有的容量规划模型。GitHub COO Kyle Daigle在4月证实，该平台每周处理Commit数量已达2.75亿个，按此速度，2026年全年Commit总数将达140亿，是2025年全年10亿个的14倍。GitHub Actions的计算分钟数也印证了这一趋势：从2023年周均5亿分钟，飙升至2025年的10亿分钟，并在2026年初达到每周21亿分钟的历史峰值。
Azure容量不足，微软被迫向AWS“借力”以换取重组时间
面对这份远超预期的需求，微软的应对措施是启动多云策略。微软发言人确认，由于“去年底开始的代理化开发的惊人激增，已经考验了我们基础设施的极限”，正在“加速迁移至Azure”的同时，“继续探索多云战略”。具体的权宜之计，是将部分GitHub流量通过AWS路由。截至2026年5月，GitHub单体应用40%的流量已由Azure承载（2月份这一比例仅为8%），而Git流量则有30%由AWS服务。此举直接引发了与亚马逊的竞争敏感问题，但微软显然认为，确保旗舰开发者平台的可靠性优先级更高。更深层次的原因在于，GitHub CTO Vlad Fedorov指出，其架构问题是单纯增加计算能力无法解决的：该平台需要一个根本性的再架构，包括将性能敏感代码从Ruby迁移至Go、减少单点故障，并降低负载，而AWS的容量为其完成这些结构性改造争取了宝贵的时间。期间，平台暴露的可用性问题已引发一起针对微软CEO Satya Nadella和CFO Amy Hood的证券集体诉讼，指控其在Azure容量和Copilot采用率上误导投资者。
合约可靠性标准失守，企业工程团队应建立降级预案
对于依赖GitHub Actions进行生产CI/CD流水线的百万级开发者与企业而言，目前情况依然严峻。尽管AWS的容量支援提供了一定缓冲，但平台的可靠性尚未恢复。CTO Fedorov承认，GitHub在2月和3月均未能达到对企事业客户承诺的“三个九”（99.9%可用性）标准。仅2026年5月，平台就记录了9起服务降级事件；截至6月中旬的故障追踪数据显示，6月份的可用率远低于99%，这意味着若折算全月，将出现数天的停机时间。为应对风险，企业工程团队必须评估自身风险敞口：建立面向GitLab CI、CircleCI或自托管运行器的CI/CD降级路径，以防GitHub中断导致全线部署管线停滞；主动监控GitHub状态页面并订阅事件通知；与GitHub企业客户团队沟通，明确低于合约水平的可用性所对应的补偿承诺；并对内部AI代理工作流实施速率限制，避免其对平台造成全局性过载。GitHub COO Daigle预计，到2026年9月，平台可用性问题将显著减少，这一判断很大程度上取决于其架构重设计能否在14周内产生实效。
