2025 年 8 月，我曾写过一篇文章，讲述 AWS在毫无预警的情况下删掉了我用了 10 年的账号。后来，我又写了一篇后续：一个 AWS 内部员工如何帮我把账号救了回来。

那个人叫 Tarus Balog，一位在开源社区摸爬滚打 20 年的老兵。

他帮我把问题升级成 Severity 2 级别工单，引起了 AWS CEO 的关注，还推动 AWS 启动了内部调查流程。那时候我以为：即便是在 AWS 这种庞大到像机器一样的公司里，一个真正愿意负责的人，依然能改变点什么——可现在，AWS 把他裁了。

这笔账，怎么算都不对

5 月 23 日，Tarus 发布了一篇博客：《Amazon Web Services - 四年，出局》。这标题已经说明了一切：他在 AWS 开源战略与市场团队待了四年，然后被裁。

而真正让我破防的是里面一句话：他在 AWS 四年里最骄傲的事情，就是帮我恢复了账号。

不是哪个产品发布，不是哪场主题演讲，也不是什么营收指标，而是帮一个远在摩洛哥的开发者，把数据救了回来——这是他在全球最大科技公司之一工作四年后，最有成就感的一件事。

更扎心的是，基层员工被这件事打动了，很多人告诉他，这件事让他们重新相信 AWS 还是一家“有人味”的公司。但管理层？根本不在乎。

把时间线串起来，你会发现一切都很讽刺：

• 2025 年 8 月：Tarus 帮我升级工单，50 多封内部邮件往来，CEO 知情，VP 级别介入，AWS 甚至启动了 “Correction of Error（错误纠正）” 流程。

• 2025 年 10 月：AWS 第一轮裁员开始。

• 2026 年 1 月：第二轮裁员几乎把他的团队掏空。

• 2026 年 5 月：Tarus 被裁。

那个推动 CEO 级别调查、暴露 AWS 系统性问题的人，10 个月后消失了。我不是说“恢复我的账号”直接导致了他被裁，但现实很明显：公司没有因此奖励他，甚至没有真正认可他。

最后，AWS 只是做了它最擅长的事——把他“优化掉”了。

免费领 100 小时云算力｜CSDN 读者专属福利

适配 DeepSeek、Qwen 等主流大模型

扫码即刻领取，每月还有显卡、AIPC 等实物好礼抽奖

咖啡领取链接：https://s.csdn.cn/4nPsOp

“以客户为中心” vs. 实际得到的奖励

Tarus 在博客里写了一句特别精准的话：“现在公司疯狂推动 AI 生成内容，而这些内容最终又会被 AI 消费，人类反而从流程中消失了。”

他亲眼看着同事吹嘘自己用一条 Prompt 生成了一整场大会 PPT。他亲眼看着公司全力转向生成式 AI，以至于像 S3、EC2、RDS 这种真正的互联网基石服务，在 re:Invent 大会上成了背景板。

还记得 Tarus 当初是怎么帮我的吗？他读了一篇博客，感受到了问题，便拿起电话，超越了自己的职责范围去升级问题——他做了一个“人”会做的事。

这不是一个能被自动化的技能，但显然AWS 也没觉得这个技能值得留住。

被 AWS“压垮”的人

说实话，过去我其实挺喜欢 AWS 的。它混乱、复杂，甚至有点离谱：47 个功能类似的服务，每个都单独收费。但对很多工程师来说，这种复杂度本身就是一种乐趣。

直到 2024 年，大量 AWS 老员工开始被裁。等到 2025 年 7 月我的数据被删时，我开始一个个联系以前认识的 AWS 朋友，希望还有人在内部能帮忙。

结果发现：几乎全走了。有人转行去种地了，有人开了咖啡店，还有一个现在在烤面包。

在我看来，这不是普通的职业转型，而是“被技术体系彻底耗尽”后的逃离。这些人不是没能力再找一份类似的工作，恰恰相反，他们太懂这套系统了，以至于他们开始觉得：相比维护 87 个 Kubernetes 配置文件、加 CloudFormation 模板、加 Terraform 状态、再加 Amazon 那个季度新发明的什么抽象层，装饰一块饼干要有成就感、快乐得多。

当一群曾经搭建全球云平台的人，宁愿揉面团也不想再碰 Terminal 时，那不叫转行，那叫创伤后的应激反应。

Tarus 不是第一个被 AWS“压垮”的人，只是第一个公开写出来的人。而其他人，早已散落在各个小镇里，经营着那些“不需要 IAM策略就能开门”的小生意。

装不出的“开源公信力”

Tarus 当初被 AWS 招进去，本来是为了改善 AWS 在开源社区的名声。招聘时，他老板甚至说他是“不可替代的”。

开源公信力这事吧，你买不来、也装不来，更不可能靠开除那些赢得公信力的人来维持。诚然，AWS 还在赞助各种大会，还在运行它的开源 Credits 项目——当初 Tarus 在帮我恢复账号后，也曾推荐我申请这个计划。

可问题是，真正代表这些项目精神的人，已经被裁掉了。

Tarus 曾质疑：“当最先进的 AI 模型全部锁在厂商 API 后面时，开源还怎么活下去？”他并不是在搞哲学，这是他每天工作中亲眼看到的现实矛盾。

还记得他们说过“不是 AI 的锅”吗？

2025 年 7 月，我账号被删时，AWS 一直坚持：这是账单问题、payer 问题、我这边的人为错误。跟自动化没关系，跟 AI 没关系，就是一次普通的失误。

结果5 个月后，2025 年 12 13 小时宕机。那个 AI 继承了一个工程师的高权限，绕过了双人审批流程，而它看了问题之后得出的最优解是：把整个环境删掉重建。

听起来是不是很耳熟？

AWS 官方回应依然很经典： “这次短暂的事件是用户错误导致的，具体是访问控制配置不当，不是 AI 的问题。” 甚至还补了一句：“AI 工具出现在事故中纯属巧合。”

嗯，巧合，就像我账号被删，也是“恰巧”发生在 AWS 内部一次休眠账户实验期间。

然后又到了 2026 年 3 月：AI 辅助的代码变，又导致 Amazon 一天损失 630 万订单，美国订单量连续 6 小时暴跌 99%。最后 AWS 不得不对 335 个关键系统启动 90 天安全整改，强制要求所有 AI 辅助部署必须双人审批。

我来捋一捋时间线：

• 2025 年 7 月：我账户被删，AWS 说：账单问题，不是 AI。

• 2025 年 12 月：Kiro 删了生产环境，AWS 说：人锅，不是 AI。

• 2026 年 3 月：AI 辅助的代码干掉了 630 万笔订单，AWS 启动 90 天安全整改。

连续三起事件，三次都说不是 AI 的锅，最后却专门针对“绝对没有问题”的AI 推出了全面安全整改。现状已经很明显了：AWS 一边被自动化系统引发的问题烧得焦头烂额，一边却对客户坚称一切正常，所有事故“纯属巧合”。

一个没有纠正任何东西的 CoE 流程

当初，AWS 为我的事故启动了“错误纠正（Correction of Error，CoE）”流程，目标是确保类似事情不再发生。

那现在结果如何？

• AWS 修好了 payer 关联级联删除的问题吗？不知道，没有公开说明。

• AWS 把关键账户通知切换到 .aws 域名了吗？没有，验证邮件依然来自 no-reply@amazon.com，依然躺在 Gmail 的“推广”标签页里，依然和黑五促销广告混在一起。

• 那个真正推动修复问题的人，保住工作了吗？很可惜，也没有。

所谓的 CoE 流程，本来是修复系统问题的。结果呢，最后系统的“修复方式”，是把提出问题的人裁掉。

Tarus 到底为我做了什么？

说到这里，我想引用 Tarus的原话——他在博客里轻描淡写地说：

否则的话，我现在可能还在收到 no-reply@amazon.com 发来的五星好评请求。

在博客中，Tarus提到他在 AWS 期间胖了 30 磅、血压升高、失眠，甚至把被裁称为“一种解脱”——他说的意思，其实我懂。

当初账号被删后，我气得想把自己维护的所有 gem 从 RubyGems 上撤掉，想把一切都删光。最后没这么做，只是因为我知道：受伤的只会是依赖这些项目的开发者，而不是 AWS。

Tarus 背负的也是类似的重量：眼睁睁看着自己曾经相信的公司，慢慢变成另一个样子，看着同事不断被裁，看着“以客户为中心”变成 GenAI 演示稿里的一页模板，而不是任何人真正在践行的东西。

当初，我说“AWS 需要更多像 Tarus 这样的人”的时，我是在认真推荐，没想到他们把它当成了黑名单。

真正的教训

在账号被删事件解决后，我曾写道：“我没有完全恢复对 AWS 的信任，但我重新相信了：即便在巨型公司里，一个人依然可以带来改变。”

我依然相信这一点，但我得再补充一句：这个人带来的改变，往往与公司留下他的时间成反比。

那些挑战坏系统的人、那些不按剧本走的人、那些在模板提示“关闭工单”时坚持升级问题的人——他们对企业惯性来说，是一种威胁。他们太昂贵，太麻烦，会逼管理层回答难堪的问题。

所以最终，他们会被优化掉，就像一个“低活跃度”的 AWS 账户一样。

最后，我有些话想说：

• 致 Tarus：欢迎回来，开源世界没有忘记你，摩洛哥的薄荷茶随时备好，等你来。

• 致 AWS：你们曾经拥有一个“人类断路器”，但现在们亲手把它拆掉了，下次级联故障的时候，祝你好运。

• 致所有开发者：记得做好分布式备份，记得准备平台迁移方案。如果你在云厂商内部遇到一个像 Tarus 那样的人——请在系统把他“优化掉”之前，先好好谢谢他。