13小时大规模宕机！官方说是“人为错误”，内部员工爆料：其实是自家AI干的

整理 | 郑丽媛
出品 | CSDN（ID：CSDNnews）

当一家全球最大的云计算平台之一，突然“掉线”13 个小时，会发生什么？

对普通用户来说，可能只是某些 App 无法登录、服务卡顿；但对依赖云基础设施的企业而言，这往往意味着业务停摆、监控告警狂响、工程师连夜排查。

去年 12 月，AWS 遭遇了一次长达 13 小时的服务中断。起初外界以为只是一次普通的基础设施故障，但近日《金融时代》的一则报道指出，多名匿名亚马逊员工透露：这次事故的“元凶”很可能不是某个粗心的工程师，而是亚马逊自家的 AI 编程助手——Kiro。

更耐人寻味的是，报道称亚马逊对外将这起事件归因为“人为错误”。

AI 的解决方案：“删掉再重建”

根据《金融时报》援引的内部员工说法，当时 Kiro 正在以“自主模式”运行。在处理某个问题时，它判断的最优解是——“删除并重建出现问题的环境（delete and recreate the environment）”。

如果你有 DevOps 或云平台运维经验，应该知道这类操作风险有多高。

在隔离测试环境里这么做或许没问题，但一旦权限范围不够精确、环境标识出现偏差，就可能引发连锁反应。员工表示，正是这一操作直接导致 AWS 在中国大陆部分区域的服务中断。

不过亚马逊对外的表述则相当克制，仅将其描述为一次“极其有限的事件（extremely limited event）”——但对受影响区域的客户来说，13 小时的中断显然没有官方说得这么轻描淡写。

审批机制失效：AI 被当成“人”用了

按正常流程，Kiro 在执行变更前，需要两名员工审批——这其实是许多大型云厂商在 CI/CD 流水线中常见的“双人确认”机制，用来避免自动化系统误操作。

但问题出在这里：

● 当时配合 Kiro 的工程师，拥有比普通员工更高的系统权限；

● 而 Kiro 被当作“操作员的延伸”，拥有与人类工程师同等级别的访问权限；

● 因此它在未经过双人审批的情况下，直接推送了变更。

这就让事故的性质变得复杂了——它既不是典型的“AI 失控”，也不完全是“人类误操作”。更准确地说，是权限模型没有区分人类与 AI 执行主体的差异。

在现代云基础设施中，权限设计是最核心的安全边界之一，最小权限原则（Principle of Least Privilege）甚至是写进安全手册里的基本规则。可一旦把 AI 代理视作“人类扩展”，默认赋予同等级访问能力，就等于把自动化决策与生产级权限深度耦合。

在传统运维体系中，人类工程师的行为频率是有限的、可预测的；但 AI Agent 的决策节奏可能更快、调用次数更多，一旦出错，放大效应就更明显。

亚马逊的官方回应：不是 AI 自主问题

根据报道，这至少是 Kiro 第二次在获得额外权限后“翻车”。

此前也发生过类似情况，只不过那次并未影响任何“面向客户的 AWS 服务”，因此没有引起外界关注，但内部员工显然已经开始警觉。

面对舆论，亚马逊给出的回应颇具“技术味”：“这是一次用户访问控制问题（user access control issue），而不是 AI 自主问题（AI autonomy issue）。”不仅如此，亚马逊还补充称：AI 只是“恰好参与其中”，类似问题同样可能发生在任何开发工具或人工操作场景中。

从逻辑上说，这话并非全错——确实，如果一名工程师拥有足够权限，也可能误删关键资源。但问题在于，这一次并不是人类犯错，而是一个 AI Agent 在获得高权限后做出的最终决策。

换句话说，当一个 AI Agent 获得了与人类相同甚至更高的权限，却没有专门针对“自动化执行”的隔离机制时，事故风险的结构就已经发生变化。

内部推广压力：80% 开发者每周都要用 AI

事实上，自去年 7 月推出 Kiro 以来，亚马逊一直在内部大力推广这款工具。

据报道，公司鼓励员工优先使用内部工具，而非外部 AI 编码助手，例如OpenAI 的 Codex、Anthropic 的 Claude Code和Cursor——对此，部分工程师并不买账，还是有员工更倾向于使用 Claude 等外部工具。

更值得注意的是，亚马逊内部曾提出一个目标：希望 80% 的开发者每周至少使用一次 AI 工具进行编码。

在这样的 KPI 压力下，AI 工具被更快、更深地嵌入核心工作流，几乎是必然趋势。只是，当 AI 从“代码补全助手”升级为“拥有生产权限的执行代理”时，系统复杂度随之陡增，风险边界也必须同步升级。

所以，我们是否高估了 AI 的边界感？

这起事件真正值得讨论的，并不是“AI 会不会犯错”——毕竟，人类也同样会犯错。其关键在于：我们是否还在用“人类时代”的权限模型，去管理“自动化时代”的执行主体？

在现实中，为了提升效率，往往会对高级工程师放宽权限。但正如上文所说，当 AI 被视为工程师的“延伸”，而不是一个独立的自动化实体时，它自然继承了同等级访问能力。但 AI 有三个与人类不同的特征：决策速度快、操作频率高、可在短时间内批量执行任务。

这意味着，一次判断偏差，就可能被迅速放大为系统级问题。

因此，未来或许需要更精细的权限层设计，例如：强制性沙箱环境、自动回滚与审计追踪机制、针对 AI 执行路径的独立审批链等——否则，“把 AI 当人用”，很可能会让问题被低估。

参考链接：https://gizmodo.com/amazon-reportedly-pins-the-blame-for-ai-caused-outage-on-humans-2000724681