过去几年，科技公司似乎达成了一种默契：让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的首席信息安全官Flavio Villanustre给出了一个形象的比喻：“AI就像一个非常聪明但没有安全意识的孩子。”在AI Agent技术出现之后，软件开发速度已经大幅提升，但许多企业的治理体系却未能同步升级，AI策略有时过于激进。
如果让这样的系统直接操作关键基础设施，结果就是：一个小Bug可能瞬间影响大规模系统、修复时间窗口被急剧压缩、事故的影响范围成倍扩大。因此，虽然“人类审核”可能会降低一些效率，但在现阶段，这似乎仍是必要的安全措施，这对于保障系统稳定性至关重要。
工程师猜测：故障变多可能和大裁员有关？
除了AI工具，一些亚马逊工程师将最近频发的系统故障指向了另一个可能的原因——大规模裁员。
此前有员工表示，由于团队规模大幅缩减，工程团队每天需要处理的“Sev2”级别事故（指需要快速响应，否则可能导致服务中断的严重事件）变多了。众所周知，亚马逊在过去几年进行了多轮裁员，最近一次是在今年1月，裁掉了约1.6万个岗位。
不过，亚马逊官方否认了裁员与系统故障之间的关联，再次强调系统稳定性评估只是公司的“常规运营流程”。
写在最后
亚马逊的这一系列事件，为整个行业敲响了警钟。它不仅仅是某个公司的内部问题，更是运维与研发领域在AI时代共同面临的挑战：如何在享受AI带来的开发效率红利的同时，构建与之匹配的可靠性与治理体系？
单纯地给AI“踩刹车”或“甩锅”给裁员并非长久之计。核心在于，企业需要建立一套适应AI参与的新开发流程、更严格的代码审查与测试机制，以及对工程师进行相应的技能培训。每一次事故都是对现有DevOps流程和工程师经验的压力测试。技术的进化不会停步，但确保系统稳定运行的敬畏之心，以及对工程卓越的持续追求，在任何时候都不可或缺。关于技术治理与工程实践，也欢迎在云栈社区进行更多探讨。
发表于 2 小时前
|
查看: 3|
回复: 0
