亚马逊一周 4 次 Sev1 事故：裁 1.6 万人后网站崩 6 小时，AI 写代码背锅？
过去三年，生成式AI在科技行业的渗透速度堪称“十倍速”——从GitHub Copilot的代码补全，到企业内部AI编程工具的批量落地，AI已经从“辅助工具”变成了生产环境的“直接参与者”。但当效率与风险正面碰撞，巨头也难逃“翻车”命运。 2026年3月，亚马逊一连串系统故障震惊行业：一周内爆发4次Sev1级最高级别事故，核心电商平台直接瘫痪近6小时，大量用户无法下单、查价、提现。而就在两个月前，这家科技巨头刚刚完成1.6万人的大规模裁员，叠加内部AI编程工具Kiro的疑似“闯祸”，让这场危机蒙上了“人祸+技术失控”的双重阴影。 更戏剧性的是，亚马逊紧急召开全员复盘会后，官方一口否认裁员与AI是事故主因，却连夜推出“AI代码必须经资深工程师签字”的新规。这场“越否认越可疑”的行业事件，到底藏着哪些未被公开的细节？ 要理解这场危机的严重性，首先得搞懂亚马逊的“事故分级体系”——在其内部，故障被划分为Sev1至Sev5五个等级，其中Sev1是最高紧急级别，定义为“核心业务中断、用户大规模受影响、需全员紧急响应”，相当于技术领域的“特级警报”。 除此之外，另外两起Sev1事故分别涉及“第三方卖家后台崩溃”和“物流追踪系统失效”，每起事故的修复时间均超过3小时，给亚马逊带来的直接经济损失保守估计超千万美元，更导致其美股股价在当日下跌1.2%。 事实上，亚马逊对AI工具的依赖早已不是秘密。为了提升开发效率，其在2025年就全面推广内部AI编程工具Kiro，允许工程师使用AI生成代码、修改配置、优化系统性能，覆盖从电商前端到AWS后端的全业务线。但这场连环事故，让Kiro从“效率神器”变成了“风险源头”。 根据《金融时报》获取的会议准备材料，亚马逊最初的复盘文档中明确将“GenAI工具辅助的代码变更”列为事故核心诱因之一，并指出关键问题：“部分团队过度依赖AI生成代码，且缺乏针对GenAI输出的标准化审核流程，导致未被发现的逻辑漏洞流入生产环境”。文档还提到，“新的生成式AI使用场景（如直接修改系统配置）缺乏成熟的安全防护机制，相当于给核心系统开了‘无锁大门’”。 但蹊跷的是，在3月10日正式召开复盘会议前，这份文档被紧急修改，涉及GenAI的相关表述被全部删除。知情人士透露，这一调整并非基于事实修正，而是“考虑到内部信息敏感性和市场舆论影响”——当时已有媒体开始猜测“AI失控导致事故”，亚马逊担心进一步披露会引发投资者恐慌。 尽管亚马逊发言人在事后反复强调“仅有一起事故与AI相关，且非AI直接编写代码导致”，但内部推出的新规却暴露了真实态度。根据Dave Treadwell在会议上宣布的措施： 这一系列措施相当于给亚马逊的AI开发模式“踩了刹车”。Constellation Research首席分析师Chirag Mehta直言：“如果只是个别事故，没必要修改全公司的开发流程。亚马逊的动作恰恰说明，他们已经意识到AI辅助开发的风险失控，只是不愿公开承认。” 除了AI工具的争议，亚马逊两个月前的1.6万人大裁员也被推上风口。不少现任和前任工程师在社交平台爆料，裁员导致技术团队“人力腰斩”，但维护的系统复杂度和业务量却丝毫未减，这才是事故频发的“隐形诱因”。 根据亚马逊2026年1月的裁员公告，此次裁撤的1.6万个岗位中，有40%来自技术部门，其中又以安全审核、系统运维、质量测试团队为主。一位已离职的AWS安全工程师透露：“我们团队原本有12人，负责核心系统的代码审核和漏洞排查，裁员后只剩3人，工作量直接翻了4倍。以前一份代码会经过‘AI生成→工程师初筛→安全团队复核→压力测试’四个环节，现在为了赶进度，安全复核和压力测试经常被简化，甚至跳过。” 更严重的是，运维团队的减员导致故障响应效率大幅下降。此前，亚马逊承诺Sev1事故的响应时间不超过15分钟，但在3月5日的电商平台瘫痪事故中，由于负责该模块的运维工程师同时处理3起故障，导致故障上报延迟了40分钟，错过了最佳修复窗口期。 多位现任工程师向媒体匿名表示，裁员后他们的工作强度达到了“极限”。一位负责电商前端的工程师说：“以前我只负责结算模块，现在要同时兼顾购物车、订单查询、支付接口三个模块，还要参与AI代码的审核。每天加班到深夜是常态，周末也经常被紧急呼叫，疲劳状态下很容易出现判断失误。” 《金融时报》还披露，亚马逊内部的“Sev2级别事故”（次高级别，需快速响应）处理量在裁员后增长了67%，很多工程师每天要处理5-8起故障，根本没有时间进行系统优化和风险预判。“以前我们每个季度会做一次全系统的漏洞扫描，现在半年都抽不出时间，小问题积累成大事故是必然的。” 面对“裁员导致事故”的质疑，亚马逊官方明确回应“系统稳定性与人员调整无关”，声称“公司通过优化流程、提升自动化水平，弥补了人力减少的影响”。但这一说法遭到工程师反驳：“自动化工具确实能处理常规问题，但面对复杂的系统故障，最终还是要靠人。优化流程不能替代人力，尤其是安全审核这种需要经验判断的工作。” 值得注意的是，亚马逊并未公布裁员后技术团队的工作负荷、故障处理时长等关键数据，也未回应“安全团队减员”的具体影响，这让其否认显得缺乏说服力。 亚马逊的连环事故，不仅给自身带来了经济损失和声誉危机，也给整个科技行业敲响了警钟。当AI辅助开发成为趋势，如何在提升效率的同时守住安全底线，成为所有企业必须面对的课题。 Info-Tech Research Group的研究总监Manish Jain指出：“AI本身不是问题，问题在于企业对AI的使用方式。人类工程师会犯错，但AI的错误会被其高效性放大——一个逻辑漏洞，人类可能需要一天才能扩散，AI却能在一小时内部署到全系统。” 他建议，企业应建立AI辅助开发的“分级管控机制”：普通业务模块可适当放宽AI使用权限，但核心系统（如支付、数据存储、配置管理）必须限制AI的操作范围，且所有AI生成的代码都需经过“人工审核+自动化测试+压力测试”三重校验，杜绝“一键部署”。 科技行业的裁员潮中，很多企业为了降低成本，盲目裁撤安全、运维、测试等“非直接产出”岗位，但这些岗位恰恰是系统稳定性的“护城河”。亚马逊的案例证明，削减核心安全岗位可能会在短期内降低成本，但长期来看，一次重大事故的损失就可能超过裁员节省的开支。 LexisNexis Risk Solutions的CISO Flavio Villanustre的比喻很形象：“AI就像一个非常聪明但没有安全意识的孩子，给他越多权限，就越需要成年人的监管。”当前，很多企业的AI策略过于激进，在治理体系尚未完善的情况下就全面推广AI辅助开发，导致风险失控。 真正合理的模式应该是“技术先行，治理同步”：在引入AI工具的同时，建立对应的安全规范、审核流程、责任划分机制，明确AI生成代码的质量标准和追责方式，让AI在“规则框架内”发挥效率优势。 截至目前，亚马逊的复盘会议并未给出事故的最终定论，关于“裁员”和“AI”的争议仍在继续。但无论真相如何，这场连环事故已经给整个科技行业上了生动的一课：在数字化时代，系统稳定性是企业的生命线，而这条生命线的守护，既需要技术的创新，也需要理性的治理和足够的人力保障。 对于亚马逊而言，新规的推出只是“亡羊补牢”，如何真正平衡效率与安全、规模与质量，才是长期课题。而对于其他企业来说，与其旁观亚马逊的“翻车”，不如借此机会审视自身的AI策略和团队配置——毕竟，在技术迭代的浪潮中，只有守住安全底线，才能走得更远。 那么，你认为亚马逊频发事故的核心原因是什么？是AI工具的失控，还是裁员导致的人力缺口，亦或是两者共同作用的结果？欢迎在评论区留下你的观点。一、引子：科技巨头的“稳定性危机”，敲响行业警钟
二、一周4次Sev1事故：从AWS宕机到电商瘫痪，影响波及全球
而根据亚马逊高级副总裁Dave Treadwell的内部邮件披露，仅3月第一周，公司就连续触发4次Sev1警报，其中两起直接影响面向全球用户的核心服务：三、AI工具“闯祸”细节：从内部文档点名到紧急删改，疑点重重
1. 内部文档先“点名”再“删改”，欲盖弥彰
2. 官方否认但行动诚实：给AI代码加“人工刹车”
四、1.6万人大裁员的“后遗症”：团队减员却工作量翻倍，工程师疲于奔命
1. 裁员集中在“安全与运维团队”，留下致命缺口
2. 工程师被迫“多线作战”，疲劳工作引发失误
3. 官方强硬否认，却拿不出反驳证据
五、行业反思：AI时代的“效率与安全”，该如何平衡？
1. AI不是“甩锅对象”，但需建立“分级管控”
2. 裁员不能“一刀切”，核心安全岗位需保留
3. 治理体系需“跟上”技术发展，不能让AI“野蛮生长”
六、尾声：真相未明，但行业已经“被上课”
参考链接：https://arstechnica.com/ai/2026/03/after-outages-amazon-to-ma...
巧手打字通：只输出有价值的知识。