Fivetran用AI构建状态页，替换6.5万美元SaaS

在约4个月内，Fivetran的两名工程师——瓦伦蒂娜·马奇科维奇和耶莱娜·科斯蒂奇——设计、构建并交付了一个替代每年6.5万美元SaaS产品的方案，从需求到生产全程使用AI编码代理。它现在服务于Fivetran的公共状态页面和大约2.6万名通知订阅者。以下是实际成本、实际有效的方法，以及我们犯的错误。

背景：我们正在替换什么

Fivetran的状态页面是一个重度定制化的应用，运行在Atlassian Statuspage上。它完成了设计初衷，但我们的使用方式已经远远超出了Statuspage框架的原生能力。我们的状态页面显示大量单独监控的服务，我们想要每个服务的状态和正常运行时间。这种形态是托管产品从未真正围绕设计的。因此我们在其上增加了定制化：从我们的BigQuery数据仓库计算正常运行时间的Google Cloud Functions，一个同步状态的事件跟踪器，以及将其接入我们事件管理流程的自动化。

结果是，系统在账本两侧都有实际运营成本：

• 金钱：每年约花费6.5万美元，主要因为每个通知订阅者都需计费。我们有大约2.6万个订阅者。
• 时间：我们持续花费大量工时管理、排查和修复状态页面，每年累计至少1万美元的工程师时间。
• 性能：页面加载缓慢，有时首次加载失败。对于一个其全部目的就是在其他一切都不可用时保持可用的页面，这是一个严重的失败模式。
• 静默故障：我们遇到过更新未传播且未检测到缺陷的情况。
• 速率限制：我们自己的自动化遇到了供应商API的速率限制。

公平地说，对Atlassian而言，这些都不是丑闻。这是当你把通用产品远远推离其预期形态时会发生的情况，也是按订阅者定价在2.6万订阅者时的普通算术。在这篇文章中，我们将展示如何使用AI替换一个超出其需求范围的系统。

[CTA_MODULE]

我们决定迁移的原因

状态页面处于一个不寻常的位置。它是一个小应用——少量读取端点、一个管理面板、一个电子邮件队列——但承担着生产规模的后果。当Fivetran日子不好过时，它是成千上万客户查看的工件，大规模通知事件可能意味着5万封以上的电子邮件。低复杂性，高风险。

正是这种组合使其有趣。一年前，DIY状态页面会轻易得到“不”的答案：工程成本远超许可费用。变化在于AI将这条线移到了特定软件类别的位置——定义明确、复杂性适中、租用昂贵。我们很快就会发现这条线是否移动得足够远。

推动构建与购买决策的因素

按权重排序的三件事：

1. 对可靠性的控制。依赖第三方的状态页面只能与第三方一样可靠，我们无法修复缓慢的部分。拥有它意味着我们可以将其与我们自己的核心平台以及外部提供商解耦。
2. 定价模式与产品不一致。我们按订阅者付费，而结构上这是一个邮件列表。成本随客户增长而增加，而提供的价值并未增加。
3. 我们想要组织层面的答案，而不仅仅是软件。两名工程师使用AI代理能否有意识地将某物从PRD带到生产？如果可以，那是一种可重复使用的能力。状态页面是检验的好地方，因为搞错的爆炸半径是可控的。我们可以与旧页面并行运行，直到我们信任它。我们也可以在不投入大量时间、金钱和精力的情况下宣布实验失败。

我们也希望坦诚结论的边界。Fivetran自己的产品是SaaS产品，我们并非主张AI使SaaS过时。状态页面比数据移动平台更容易替换。但同样的逻辑适用于任何供应商的边缘：你的使用越是通用产品的薄而明确的切片，构建侧的等式就越已移动。

我们如何构建

设置AI

团队做出的最重要决定是花费大量时间不编写代码。

在任何功能工作之前，瓦伦蒂娜和耶莱娜构建了相当于AI代理入职培训的内容。他们编写了定义项目规则的CLAUDE.md和16步开发流程。他们定义了6个代理角色，每个都有其初始化文件：

除了角色，他们构建了一个技能库——可重复使用的指令集，涵盖后端约定、前端模式、整洁代码、JUnit、Bazel、Nx、QA和版本控制。代理只彼此通信；当不确定时，做出有记录的尽力决策，而不是等待人类。每个功能都有自己的git分支和工作树，因此多个代理团队可以并发运行而不会冲突。

他们还给了代理大多数AI编码尝试跳过的东西：真正的规格说明. PRD和TDD被写成正式文档，转换为markdown，并作为上下文，连同定义每个端点的OpenAPI模式和一组用于UI的Figma设计资源一起交给代理。我们决定按原样实现UI设计，从而可以利用现有状态页面作为参考，自动化大部分Figma和UX设计。

工作量分配是整个项目的关键发现：

大致花了每建设一小时就要准备两小时。这个比例不是效率的失败，而是机制本身。代理之所以快，正是因为上下文已经消除了所有歧义。

使用AI工作

一旦工具就位，MVP很快就完成了。原型仓库的整个提交历史从2026年3月4日到4月15日：6周，46个拉取请求。前3周几乎完全是上下文和技能文件。然后，在3月下旬和4月初的约2周内，功能依次落地：群组CRUD、服务CRUD、数据库设置、事件、维护窗口、公共页面、CI、单元测试、部署工作流。

形成的工作模式：

• 小任务胜过大型任务。团队明确测试了这一点并将其定为政策。大型功能请求产生了庞大、难以审查的拉取请求，这些请求常常不得不被丢弃。
• 架构师角色物有所值。拥有一个加载了内部约定的专门审查代理，可以在人类看到之前捕获结构性问题，包括一次完整的后端重构。
• 人类拥有契约，而不是击键。Valentina和Jelena决定了什么才是正确的——API形状、数据模型、发布顺序——并验证输出是否匹配。AI编写代码。工程师构建系统。

陷阱

假装这一切一帆风顺对谁都没好处。有几个地方比预期复杂：

• 代理重做工作。群组CRUD在4个单独的拉取请求中实现，服务CRUD在5个中实现。在原型仓库的46个拉取请求中，有8个从未合并，包括被放弃的重复和死胡同。如果没有人类跟踪实际完成的内容，并行代理会愉快地重新解决已解决的问题。
• 与AI合作是一种新范式。最初的MVP既是一个学习练习，也是一个项目执行。这是我们的工程师犯错并纠正的一次性代价。吸取教训后，我们现在可以将其应用到其他项目，更自信、更高效地工作。我们在这一阶段花费了总工作量的25%，这使得开发状态页面的成本偏高。
• 内部约定不是免费的。第一个后端不符合Fivetran的构建系统或代码标准，不得不重构。你关心的每个约定都必须写在某个代理会读到的地方。这些知识的集合最终成为技能库。
• 演示不是生产系统。虽然AI加速了初始实现，但将原型转化为生产质量的软件需要大量的工程工作。

使其生产就绪

MVP在4月底完成，并于7月下旬上线。这个差距就是故事所在。

将原型转化为我们可以呈现给客户的东西花费了72个跟踪工作项在主生产史诗中，另有17个用于预发布错误修复。几乎所有这些都不是功能工作，而是：

• 迁移到单仓库：原型位于独立的仓库中。生产代码位于我们的生产GitHub仓库，具有通用的Bazel构建系统和CI。
• 认证和授权：原型可以模拟认证；生产版本需要真正工作。我们为管理面板在暂存和生产环境实现了Okta，具有基于角色的权限和API令牌管理。
• 真实基础设施：使用Cloud SQL Postgres，我们构建了具有持续部署和结构化日志的暂存环境。
• 与所有其他系统的集成：我们重新连接了现有的数据聚合器和公共事件追踪器Cloud Functions，以写入新API，实现了从事件管理系统自动创建事件，构建了Java客户端，使产品仪表板从我们的后端而不是供应商那里读取数据，并全部置于功能标志之后交付。
• 订阅者迁移：26,000名订阅者必须迁移，不能有人丢失通知或收到重复。仅此一项就耗费了40小时的脚本编写和后续的数据修正。
• 可审计性：对事件、服务、群组或订阅者的每次更改都由数据库触发器捕获到审计日志中。
• 规模测试：大规模事件可能产生50,000多个电子邮件事件。我们进行了压力测试，在5分钟内持续发送9,000条通知。
• 一系列正确性错误：特殊字符在事件标题中渲染不正确。超过30天的事件没有影响正常运行时间条。维护窗口发生了双重状态转换，新旧聚合之间的正常运行时间存在差异。这些都不是有趣的，但客户都会注意到。

生产加固占总工作量的56%——比需求、代理工具和整个MVP的总和还要多。如果要从这篇文章中带走一个数字，就是这个。

部署到生产

我们进行了一次刻意平淡的发布。

1. 暂存：我们对公共页面和管理面板进行了完整的QA测试。
2. 生产环境，静默：新系统已部署到生产环境，拥有完整数据和所有自动化，但通知被禁用，没有客户流量。它在单独域名的旧页面旁边运行了数周，保持自身正确。
3. DNS切换： 客户流量迁移到了新页面。通知仍然关闭。
4. 通知开启： 最后一个且最难逆转的步骤，只在其他步骤充分落实后才采取。

系统随后以你从未计划过的方式得到了验证：一次真实P1事故 需要通知全部订阅用户。向所有约26,000名订阅者的扇出操作从新系统发出。那是一个它不再只是实验的时刻。

可靠性

状态页面有一个不寻常的可靠性要求：它必须在其所报告的系统发生故障时幸存下来。因此，它的依赖项是设计约束，而不是实现细节。

我们特意解耦的内容：

• 独立数据库： 状态页面运行在独立的Postgres实例上，不与核心平台系统共享。
• 独立的域名和部署流水线： 状态页面的发布不与产品发布耦合，糟糕的产品部署不会导致页面不可用。
• 独立的GCP项目： 它运行在独立的GCP项目和可用区中，与Fivetran控制平面或数据移动功能的运行环境隔离。
• 管理路径独立性： 我们的支持团队即使在产品不健康时也能发布事件更新，因为管理面板不依赖产品。

为什么只使用一个区域？

目前，状态页面运行在单个GCP区域。这是一个刻意且临时的权衡。我们实际要防范的故障是Fivetran平台事故 — 对此，单区域隔离是完全有效的。额外防范区域云中断则是一个不同且罕见得多的故障，它几乎会使该系统的基础设施和运营成本翻倍，而该系统的全部经济论点就是它运行成本低。

我们选择交付能解决常见情况的版本，并在生产环境中验证。我们的要求是状态页面能挺过CSP区域中断。由于状态页面在Fivetran区域之外提供，这满足了初始故障要求。我们打算让系统达到所需的可靠性，这可能意味着在另一个CSP中有一个缓存副本，但很可能仅此而已。

成本

以下工作量数据来自已记录工作项上的估算，而非日志中的时间表。它们涵盖了在我们的跟踪器中记录的工程工作，不包括未单独跟踪的管理、QA和设计时间。美元数字使用假设的全负担率$100/工程小时，而非实际薪酬。请将其视为善意的数量级，而非经审计的数字。

我们过去支付的费用

我们为Atlassian Statuspage支付每年约$65,000，主要由于约26,000个订阅者的计费通知订阅者，再加上用于维护定制、Cloud Functions和自动化层的内部工程时间。更不用说应对其速率限制和静默失败。内部成本是真实的，但从未单独预算，这本身也是现状真实成本不可见的一部分原因。

构建成本

这大约是131人日，或6.6人月。这相当于2名工程师约4个月的日历时间，这与实际发生的情况相符。

按假设的$100/小时全负担计算，一次性构建成本约为$105,000。团队消耗的AI token成本最多约为$4,500，因此总构建成本约为$109,500。

运行成本

维护预测基于发布后积压工作的实际情况：29个未结事项，涵盖韧性工作、订阅管理、界面打磨和前端重构。值得注意的是，使供应商变得昂贵的通知量，对我们自己服务来说几乎不花什么钱——那只是一个队列和一个使用我们已有的客户通知系统的电子邮件发送器。

诚实的算术

我们每年节省约$40,000 – $53,000，而一次性构建成本约为$109,500。投资回收期约为2.5年，之后节省持续累积。

这是值得深思的部分。这个故事的标题版本是"2名工程师取代了价值$65K的产品。"真实版本是，构建成本高于年度许可费，节省是真实的但不是立竿见影的，而做这件事的最有力理由并非纯粹财务上的：

• 页面更快、更可靠，这是客户实际体验到的。
• 成本不再随订阅者数量增加而增加，因此随着Fivetran的增长，节省也随之增长。
• 我们现在能够以边际成本构建供应商未提供的功能。
• 我们现在拥有一个可复用的AI开发框架。其中包括AI开发的角色、技能和流程。这是一次性的300小时成本，适用于下一个项目，此外还有2名拥有使用AI构建产品的实际生产经验的工程师。

任何为自己的状态页面做此类计算的人都应预期类似的形状。如果你的账单是每年$10,000而非$65,000，答案可能仍然是"继续购买。"这是一个真实的结论，我们宁愿发布它也不愿发布更讨喜的版本。

我们学到的东西

规格说明是瓶颈，而不是代码生成。 我们每花1小时构建，就花2小时准备，这是正确的比例。能从AI代理中获得最大收益的团队，是那些已经善于写下他们想要什么的团队。

最后一英里仍然是一英里。生产加固占了56%的工作量——比需求、工具和整个MVP加起来还要大。AI压缩的是软件开发中本已最快的部分。集成、迁移、认证、可观测性以及冗长的正确性bug尾巴并没有被压缩那么多。任何从“我们两周内做出了工作演示”外推的估算都会错误至少两倍以上。

代理需要管理者，而管理者不能是另一个代理。重复的工作、幻觉UI以及偶尔出现的掷骰子应用并不是边缘案例；它们是正常的失败模式。工程师增加的价值在于判断何为正确，并验证输出是否符合要求。

经济性确实已对特定类别的软件产生了变化。“定义良好、复杂度适中、定价维度对你不利”描述的是大多数公司SaaS支出中真实且增长的项目。它并不描述大多数软件。

小团队现在已经能做出令人惊讶的事情。两名工程师花了4个月时间，将一个服务于26,000订阅者的系统从空仓库带到了生产环境，并在真实的P1事件下进行了验证。这是最希望其他团队认真对待的结果。

新的状态页面已在status.fivetran.com上线。它由Valentina Mačković和Jelena Kostic设计、构建和交付。

[CTA_MODULE]