AWS 模拟器与智能体写代码时工程师的角色

2004年，我刚入职Amazon不到一个月，就得到了一个挑选实习生加入团队的机会。我比同事们多一个优势：我早就听说过一位在阿姆斯特丹自由大学攻读博士学位的聪明年轻人（我恰好也是在那里拿到博士学位的 :-)）。我立刻选中了Swaminathan Sivasubramanian，也就是大家现在熟知的Swami。这大概是我担任Amazon CTO 22年来做过的最好的决定之一。

2004年圣诞节那场灾难之后——当时商用关系型数据库无法满足Amazon的扩展需求——我请Swami深入研究关系型数据库在Amazon的实际使用情况。结果发现，70%的数据库操作根本不是关系型的，而是键值操作。这个洞察催生了Dynamo，Swami参与了它的架构设计。实习结束后，我立刻全职聘用了他，甚至在他博士毕业之前。

引入又一位有主见的学者，引发了与Amazon务实工程师们许多精彩的讨论——这些工程师通过真正大规模构建系统，已经成为扩展性方面的专家。最终一致性与强一致性、CAP与Paxos，诸如此类。随着时间推移，Swami成为AWS数据战略的主要架构师之一。而正如近年来所见，他也是Amazon AI创新背后的思想驱动者之一。

我很荣幸他愿意写一篇客座文章，讲述许多AWS服务背后基础的分布式系统工作，以及当agent编写代码时工程师的工作会发生怎样的变化。今天发布的AWS Emulator，正是为agent提供了这类工作所依赖的测试环境。Swami的故事是隐形工程的又一个绝佳范例。

今天我们发布AWS Emulator，它为编码agent提供了一份本地AWS副本用于测试，这也与我职业生涯早期的一个项目相连接。在很多方面，这次emulator的发布让我想起我们为提高所构建分布式系统的质量而在可靠软件工程上投入的努力。为此，我们想分享一个故事：

大约二十年前，Werner让我与Amazon最早的工程师之一Al Vermeulen合作，开发一个我们称为“Alf”的分布式锁服务。Alf构建在Paxos之上——这是一种基于Leslie Lamport工作的协议，让一组服务器就某个值达成一致——其中的复制引擎使数据副本在服务器之间保持一致。时至今日，Alf仍是支撑我们许多复杂分布式系统（如S3、DynamoDB等）的服务（尽管它在之上经历了相当多的演进和变化——这些留待另一篇博客再讲！）。

Paxos是分布式系统共识协议中的黄金标准，在学术界已有充分理解。然而，要在Amazon和AWS不断增长的规模上构建它并不容易。我们不仅要处理跨服务器和数据中心的复制，还要应对数万个客户端同时请求锁、在网络分区期间续租，同时核心要求始终是：永远保持正确！当时，测试分布式系统的最佳思路是大规模系统测试和基于混沌的测试。两者都有效，但成本高昂，而且无法按需复现许多类型的条件。这对Alf尤其重要——它被定位为真相存储，为每个客户端提供强一致的真相视图，并且必须在服务器故障和丢包的情况下持续工作。多篇行业论文曾指出，基于Paxos的锁服务很难做对，而测试它们的难度是部分原因。

我们通过尽可能高保真地模拟Alf的环境来解决这个问题。我们在JVM内运行服务器，并模拟网络及其依赖的其他基础设施，使整个系统存在于一个我们可控的程序中。我们可以随时丢包并注入其他故障，还构建了工具来探查模拟中的bug和扩展性问题。并发bug只在事件以特定顺序发生时才会出现，而在模拟中，我们可以有意设置许多这样的顺序，并检查Alf如何处理每一种。我们还通过TLA+等理论技术进行形式化推理，也发现了许多问题。通过这种测试方式，我们在Alf运行于真实服务器之前就消除了它的大部分并发bug。之后在真实环境中测试又发现了不同的问题，因为现实世界会暴露模拟无法覆盖的情况。

模拟和形式化推理都提升了我们应用它们的分布式系统的软件质量。模拟之所以有效，是因为一个小团队可以手工构建单个系统环境的副本，而当时AWS只有少数几个服务。但如今AWS有200多个服务，一个调用AWS的应用需要为其使用的每个服务准备测试环境。全部手工构建需要数年的工程投入，而agent现在编写代码的速度远超任何团队能在生产环境中检查的速度。因此，我们想知道agent能否自己构建和测试这些环境。

这个想法来自Matt Goldberg，AWS Developer Tools团队的高级首席工程师。他的假设是：给定一个服务应如何行为的书面描述，以及用于对照检查的真实服务，agent可以自行构建该服务的一个可用版本。对AWS而言，书面描述就是以Smithy（AWS用于描述服务操作及其输入、输出和错误的格式）编写的一组公开API模型。用于对照检查的真实服务就是AWS云本身——客户使用的同一个系统。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）