因公众号更改推送规则请点“在看”并加“星标”第一时间获取精彩技术分享点击关注#互联网架构师公众号领取架构师全套资料 都在这里0、2T架构师学习资料干货分上一篇2T架构师学习资料干货分享大家好我是互联网架构师过去几年里科技公司几乎都在同一件事上加速让 AI 参与写代码。从自动补全、自动生成函数到直接修改系统配置生成式 AI 已经逐渐走进真实生产环境。但最近发生在亚马逊的一连串事故却给整个行业泼了一盆冷水——当 AI 开始真正参与生产环境开发时事情可能远比想象复杂。最近多家媒体披露本周二亚马逊内部紧急召开了一场工程“深度复盘deep dive”会议专门讨论最近频繁出现的系统故障——其中一个被反复提及的关键词是AI 辅助代码。一周 4 次严重事故亚马逊内部紧急复盘事情的起点是最近一段时间亚马逊系统稳定性明显下降。负责亚马逊网站技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中坦言“各位正如大家可能已经知道的最近网站及相关基础设施的可用性确实不太理想。”为此公司决定把原本每周例行举行的技术会议 “This Week in Stores Tech”简称 TWiST 临时改成一次“深度复盘会议”。通常来说TWiST 会议对员工是自愿参加的但这一次Treadwell 要求工程师尽量全部参加。这场会议在周二中午 12:30 召开主要目标只有一个弄清楚最近这一连串系统故障到底是怎么发生的——Treadwell 在内部邮件中透露仅仅在一周时间内公司就发生了 4 起 Sev1 级别事故。这里解释一下在亚马逊的事故分级体系中Sev1 即最高级别事故通常意味着核心系统宕机或关键功能严重受影响。也就是说这已经不是普通的小 Bug而是直接影响业务运行的大问题。一次 6 小时宕机让购物功能几乎瘫痪其中最明显的一次事故就发生在上周。当天亚马逊网站和购物 App 突然出现大规模故障持续时间接近 6 小时。在这段时间里大量用户无法完成商品结算、查看账户信息、查询商品价格……简单来说整个电商核心流程几乎停摆。事后亚马逊对此给出的解释是这次事故源于一次错误的软件代码部署。不过并没有进一步披露细节比如是否涉及 AI 生成代码等。不仅如此去年 12 月亚马逊云计算部门 AWS 也曾发生一次持续 13 小时的服务中断。根据多家媒体报道那次事故发生的原因是工程师允许内部 AI 编程工具 Kiro 修改系统环境而 AI 在执行任务时选择了一个极端操作——删除并重新创建了整个运行环境。不过亚马逊后来回应称那次问题本质上是人为操作失误并非 AI 本身造成的。内部文档曾点名GenAI 代码变更是事故因素之一但事实上据《金融时报》报道在此次会议的准备材料中亚马逊的一份内部文档曾提到过去几个季度公司出现了一种“事故趋势”其中一个因素就是“GenAI 工具辅助的代码变更”。这份文档还指出了一个关键问题一些新的生成式 AI 使用方式目前还没有成熟的工程规范和安全防护机制。不过根据 CNBC 获得的更新版本文件显示在亚马逊内部会议开始前涉及 GenAI 的那一条内容被删除了——知情人士表示该调整可能与内部信息敏感性有关。在媒体报道发布后亚马逊发言人进一步回应称近期的事故中只有一起与 AI 相关没有任何事件是 AI 直接编写代码导致的。发言人还强调这次会议本身只是“常规运营”的一部分“TWiST 是零售技术负责人每周举行的例会我们会在会上评估网站和应用的运行情况并持续改进系统可用性。”AI 辅助开发被“加上刹车”虽然亚马逊试图淡化 AI 的直接责任但内部仍然决定采取新的工程措施而最核心的一条规则就是今后任何 AI 辅助生成的代码修改都需要更高级别工程师审批。换句话说初级工程师可以用 AI 改代码但不能直接上线必须由资深工程师签字确认——某种意义上这相当于给 AI 生成代码增加了一层“人工安全阀”。但对于这项新规定一些分析师也提出了担忧。例如Constellation Research 首席分析师 Chirag Mehta 就表示“如果每次 AI 改代码都需要高级工程师去逐行审核那么企业很可能把 AI 带来的效率优势又还回去了。”而真正的风险也并不是 AI 会犯错毕竟人类工程师同样会犯错——真正的问题在于AI 会把错误放大。正如 Info-Tech Research Group 的研究总监 Manish Jain 所说AI 最大的危险是它压缩了人类干预和纠正问题的时间。LexisNexis Risk Solutions 的 CISO Flavio Villanustre 给出了一个很形象的比喻“AI 就像一个非常聪明但没有安全意识的孩子。”在 AI Agent 技术出现之后软件开发速度已经大幅提升企业的治理体系却没有同步升级AI 策略还过于激进。如果企业直接让这样的系统操作关键基础设施结果就是小 Bug 可能瞬间影响大规模系统、修复时间窗口变得更短、事故影响范围更大——因此虽然“人类审核”会降低效率但目前看来这仍是必要的安全措施。工程师猜测故障变多可能和大裁员有关除了AI工具一些亚马逊工程师还把最近频发的系统故障指向另一个原因——大裁员。此前有多名员工表示由于团队规模大幅缩减工程团队每天需要处理更多“Sev2”级别事故。亚马逊内部“Sev2”指的是需要快速响应否则可能导致产品服务中断的严重事件。众所周知亚马逊在过去几年中确实进行了多轮大规模裁员。最近一次是在今年 1 月裁掉了约 1.6 万个岗位。不过亚马逊官方否认裁员与其系统故障有关并表示系统稳定性评估只是公司的“常规运营流程”。那么在你看来最近亚马逊频发的系统故障是什么原因导致的呢参考链接https://arstechnica.com/ai/2026/03/after-outages-amazon-to-make-senior-engineers-sign-off-on-ai-assisted-changes/出品 | CSDN 整理 | 郑丽媛说到底程序从职场角度看公司这样做很可能是想“信息差”捞点回本。建议保存所有当年的交接记录、邮件、IM聊天截图必要时走仲裁流程不然这种事开了先例下一个就可能是别人员写代码要留注释职场上做事也要留痕迹。只有手里握着证据才能不被随便背锅。1、2T架构师学习资料干货分享2、10000TB资源阿里云盘牛逼3、基本涵盖了Spring所有核心知识点总结· END ·最后关注公众号互联网架构师在后台回复2T可以获取我整理的 Java 系列面试题和答案非常齐全。如果这篇文章对您有所帮助或者有所启发的话帮忙扫描上方二维码关注一下您的支持是我坚持写作最大的动力。求一键三连点赞、转发、在看
猛裁1.6万人后，网站再崩6小时、一周4次重大事故！官方“紧急复盘”：跟裁员无关，也不是AI写代码的锅
发布时间：2026/6/23 5:02:47
因公众号更改推送规则请点“在看”并加“星标”第一时间获取精彩技术分享点击关注#互联网架构师公众号领取架构师全套资料 都在这里0、2T架构师学习资料干货分上一篇2T架构师学习资料干货分享大家好我是互联网架构师过去几年里科技公司几乎都在同一件事上加速让 AI 参与写代码。从自动补全、自动生成函数到直接修改系统配置生成式 AI 已经逐渐走进真实生产环境。但最近发生在亚马逊的一连串事故却给整个行业泼了一盆冷水——当 AI 开始真正参与生产环境开发时事情可能远比想象复杂。最近多家媒体披露本周二亚马逊内部紧急召开了一场工程“深度复盘deep dive”会议专门讨论最近频繁出现的系统故障——其中一个被反复提及的关键词是AI 辅助代码。一周 4 次严重事故亚马逊内部紧急复盘事情的起点是最近一段时间亚马逊系统稳定性明显下降。负责亚马逊网站技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中坦言“各位正如大家可能已经知道的最近网站及相关基础设施的可用性确实不太理想。”为此公司决定把原本每周例行举行的技术会议 “This Week in Stores Tech”简称 TWiST 临时改成一次“深度复盘会议”。通常来说TWiST 会议对员工是自愿参加的但这一次Treadwell 要求工程师尽量全部参加。这场会议在周二中午 12:30 召开主要目标只有一个弄清楚最近这一连串系统故障到底是怎么发生的——Treadwell 在内部邮件中透露仅仅在一周时间内公司就发生了 4 起 Sev1 级别事故。这里解释一下在亚马逊的事故分级体系中Sev1 即最高级别事故通常意味着核心系统宕机或关键功能严重受影响。也就是说这已经不是普通的小 Bug而是直接影响业务运行的大问题。一次 6 小时宕机让购物功能几乎瘫痪其中最明显的一次事故就发生在上周。当天亚马逊网站和购物 App 突然出现大规模故障持续时间接近 6 小时。在这段时间里大量用户无法完成商品结算、查看账户信息、查询商品价格……简单来说整个电商核心流程几乎停摆。事后亚马逊对此给出的解释是这次事故源于一次错误的软件代码部署。不过并没有进一步披露细节比如是否涉及 AI 生成代码等。不仅如此去年 12 月亚马逊云计算部门 AWS 也曾发生一次持续 13 小时的服务中断。根据多家媒体报道那次事故发生的原因是工程师允许内部 AI 编程工具 Kiro 修改系统环境而 AI 在执行任务时选择了一个极端操作——删除并重新创建了整个运行环境。不过亚马逊后来回应称那次问题本质上是人为操作失误并非 AI 本身造成的。内部文档曾点名GenAI 代码变更是事故因素之一但事实上据《金融时报》报道在此次会议的准备材料中亚马逊的一份内部文档曾提到过去几个季度公司出现了一种“事故趋势”其中一个因素就是“GenAI 工具辅助的代码变更”。这份文档还指出了一个关键问题一些新的生成式 AI 使用方式目前还没有成熟的工程规范和安全防护机制。不过根据 CNBC 获得的更新版本文件显示在亚马逊内部会议开始前涉及 GenAI 的那一条内容被删除了——知情人士表示该调整可能与内部信息敏感性有关。在媒体报道发布后亚马逊发言人进一步回应称近期的事故中只有一起与 AI 相关没有任何事件是 AI 直接编写代码导致的。发言人还强调这次会议本身只是“常规运营”的一部分“TWiST 是零售技术负责人每周举行的例会我们会在会上评估网站和应用的运行情况并持续改进系统可用性。”AI 辅助开发被“加上刹车”虽然亚马逊试图淡化 AI 的直接责任但内部仍然决定采取新的工程措施而最核心的一条规则就是今后任何 AI 辅助生成的代码修改都需要更高级别工程师审批。换句话说初级工程师可以用 AI 改代码但不能直接上线必须由资深工程师签字确认——某种意义上这相当于给 AI 生成代码增加了一层“人工安全阀”。但对于这项新规定一些分析师也提出了担忧。例如Constellation Research 首席分析师 Chirag Mehta 就表示“如果每次 AI 改代码都需要高级工程师去逐行审核那么企业很可能把 AI 带来的效率优势又还回去了。”而真正的风险也并不是 AI 会犯错毕竟人类工程师同样会犯错——真正的问题在于AI 会把错误放大。正如 Info-Tech Research Group 的研究总监 Manish Jain 所说AI 最大的危险是它压缩了人类干预和纠正问题的时间。LexisNexis Risk Solutions 的 CISO Flavio Villanustre 给出了一个很形象的比喻“AI 就像一个非常聪明但没有安全意识的孩子。”在 AI Agent 技术出现之后软件开发速度已经大幅提升企业的治理体系却没有同步升级AI 策略还过于激进。如果企业直接让这样的系统操作关键基础设施结果就是小 Bug 可能瞬间影响大规模系统、修复时间窗口变得更短、事故影响范围更大——因此虽然“人类审核”会降低效率但目前看来这仍是必要的安全措施。工程师猜测故障变多可能和大裁员有关除了AI工具一些亚马逊工程师还把最近频发的系统故障指向另一个原因——大裁员。此前有多名员工表示由于团队规模大幅缩减工程团队每天需要处理更多“Sev2”级别事故。亚马逊内部“Sev2”指的是需要快速响应否则可能导致产品服务中断的严重事件。众所周知亚马逊在过去几年中确实进行了多轮大规模裁员。最近一次是在今年 1 月裁掉了约 1.6 万个岗位。不过亚马逊官方否认裁员与其系统故障有关并表示系统稳定性评估只是公司的“常规运营流程”。那么在你看来最近亚马逊频发的系统故障是什么原因导致的呢参考链接https://arstechnica.com/ai/2026/03/after-outages-amazon-to-make-senior-engineers-sign-off-on-ai-assisted-changes/出品 | CSDN 整理 | 郑丽媛说到底程序从职场角度看公司这样做很可能是想“信息差”捞点回本。建议保存所有当年的交接记录、邮件、IM聊天截图必要时走仲裁流程不然这种事开了先例下一个就可能是别人员写代码要留注释职场上做事也要留痕迹。只有手里握着证据才能不被随便背锅。1、2T架构师学习资料干货分享2、10000TB资源阿里云盘牛逼3、基本涵盖了Spring所有核心知识点总结· END ·最后关注公众号互联网架构师在后台回复2T可以获取我整理的 Java 系列面试题和答案非常齐全。如果这篇文章对您有所帮助或者有所启发的话帮忙扫描上方二维码关注一下您的支持是我坚持写作最大的动力。求一键三连点赞、转发、在看
