📰 AI 资讯

Datadog 借助 Claude 和 Cursor 完成测试驱动式生产环境迁移

2026-07-15 13:00

Datadog 工程师 Arnold Wakim 近期发表了一篇文章，分享了他们使用 AI 迭代一个核心生产系统的经历，包括他们踩过的坑以及总结出的经验教训。该系统借助 AI 突破了存储后端的硬性性能瓶颈，显著提升了性能。Stream Router 是一个用于管理指标管道路由的 API，初始版本基于键值模型构建，采用最终一致性架构。然而，随着路由表不断扩展，KV 数据库开始触及事务容量上限，高负载操作性能大幅衰减，因数千次串行往返请求，单次耗时最长可达 45 分钟。在 KV 模型中，程序需要自行重建数据关联关系。程序会将数万个条目拉取到 Pod 进程中，并在进程内部模拟实现关系型数据库的能力——处理本应由关系系统中外键强制执行的逻辑。为了解决这个问题，Datadog 的工程师们重新设计了模型，用外键取代之前需要在应用代码中重建的逻辑。新的模型设计完成后，他们重构了整个代码库，完成从旧模型到新模型的迁移，为此他们借助了 AI：我们借助 Claude 与 Cursor 工具加快了整个基于测试驱动的系统化重构过程。这两款工具并不能自主生成完整可用的代码：针对每一个方法，我们都会提供原有实现、新的数据结构以及一条失败测试用例。大模型会先输出一版初稿代码，再由测试用例校验代码逻辑是否正确。Wakim 表示，此次迁移能够顺利完成离不开三个关键要素：高度模块化的代码架构使得新的 Stream Router 可以在 PostgreSQL 上实现相同的 API，而无需修改其他部分；完备的测试用例为每次 AI 生成的变更提供了明确的通过/失败标准；并行部署基础设施可让两个独立的 Stream Router 实例并排运行，处理相同的请求，同时通过功能开关控制客户端流量在两者之间切换：每个集群内部都部署了独立的校验服务，该服务会定期对比两个系统之间的路由响应，一旦出现不一致，会立即向团队发送告警。迁移分为三个阶段：首先，使用 Claude 描述每个关键函数的意图；其次，通过提供预期行为以及上一步的上下文，编写有针对性的提示词来修复失败的测试；最后，使用蓝绿部署方案上线到生产环境，新的 PostgreSQL 后端和现有的 FoundationDB 后端 Stream Router 并行运行，并持续进行比较。Wakim 也指出了这套方案的一些不足之处，包括高层级提示词的效果有限，以及 Claude 倾向于生成逻辑正确但性能欠佳的查询：像批处理、UNNEST 技巧、公用表表达式（CTE）等小众优化需要人工输入。AI 生成的查询返回了正确的结果，但产生了大量不必要的网络往返请求。我们自己编写了优化版本，一旦大模型见过这种模式后就能在后续方法中复现。但大模型无法独立发现这些模式，尽管这些模式在文献中已经存在。另一个问题是词元消耗量过高，造成该问题的原因有两点：一是向大模型输入完整的测试输出日志，而非精简后的片段；二是整个流程需要反复传入测试输出、代码上下文与表结构信息，造成多次迭代循环。迁移完成后，操作时间从 45 分钟降至约 1 秒，延迟从数百毫秒降至仅几毫秒。数据存储占用空间最高缩减至原先的 1/40，而 PostgreSQL 和 DuckDB 简化了关系处理并提高了查询效率。CPU 和内存使用率下降，数据库成本降低了 90%。Wakim 总结道，Datadog 使用 Claude 进行迁移的关键成功因素是完备的测试套件，这最终决定了他们能在多大程度上信任 AI 生成的代码。查看英文原文：<a href="https://www.infoq.com/news/2026/07/datadog-ai-production-migration/" title data-type="link">https://www.infoq.com/news/2026/07/datadog-ai-production-migration/</a>

🔗 查看原文 ↗

← 返回资讯列表