从5名工程师的初创公司到200名工程师的独角兽公司，我们一直专注于一个目标:让商业数据像电力一样容易获取。
就在几年前，Fivetran还是一家只有五名工程师的数据集成初创公司。现在我们是拥有200名工程师的独角兽
2000多名客户
50000多个连接源
1M +每日同步包括〜25B的数据行
99.9％的正常运行时间管道
要达到这一点需要付出很多努力。构建数据管道只需要三个简单的步骤——提取数据、处理和规范化数据，并将其写入目的地——但我们花了很多年才掌握这些步骤。
我们得到的主要教训是:您不可能构建一次数据复制解决方案就期望它永远可靠地工作，因为源系统太复杂了。api会突然中断或工作，而且有很多边缘情况，只有时间和大量客户才能帮助您找到并解决它们。在此基础上，源系统不断发展，并要求我们调整这些变化，以确保复制快速可靠地工作。
这是我们如何吸取教训的故事，以及其他许多教训。我们认为我们的工程进化有四个不同的发展阶段：爬行、行走、奔跑和飞翔。我们现在正在跑步，准备飞行。
我们认为管道是可靠的:
所有预期的数据都会到达目的地
不存在数据完整性问题
禁止任何未经授权的访问数据
意外的行为和源系统的瞬态问题被容忍
同步性能足够
区域数据要求得到尊重和执行
有一个可靠的数据管道归结起来就是这些基本要素:
监控和可观察性。监控和报警系统必须到位。应该有识别问题的根本原因，因此可以迅速解决的方法。
事件管理。无论何时报告影响客户的事件，都必须有一个处理过程。
来源API故障处理．必须为源端故障和意外行为做好准备。
源API更改跟踪．引起在源端合同变更避免破裂，应该有主动监控。
客户支持。虽然与可靠性没有直接关系，但支持部门必须能够快速地对客户请求进行分类，并决定是否需要简单的响应，或者问题是否应迅速传递给工程团队。
还有其他方面，如安全性、隐私性和数据区域性。我们将省略这些问题，因为它们值得一篇单独的文章。
在第一阶段，我们的目标是让产品工作。在那时，构建可靠的数据管道的组件需要大量的关注和严格。什么也没发生。
我们的第一个监控系统是一个计划好的作业，每天两次向开发团队发送一封包含所有失败连接器的电子邮件。我们称之为耻辱之墙。开发团队将查看此失败连接器列表并解决问题，但只解决与多个连接器有关的问题。在早期，在s的可靠性改进和功能开发非常重要，因为我们需要继续扩大业务。
至于可观察性，查看日志是我们识别问题根源的主要方法。工程师会引入一个修复，然后在本地运行连接器，看看是否成功。如果成功了，这种改变就会进入到生产中。
如果任何重要事件是由员工或客户注意到，消息被张贴在松弛火警通道。开发团队的跃升，直到我们可以肯定的火已经被扑灭。如果需要进行任何后续工作，任务被分配到一个工程师来解决它在即将到来的天（或周）。
我们依靠工程团队的努力，以管理源侧故障。如果工程师认为是边缘的情况，并质疑任何假设，我们再继续努力，即使我们的工程团队只有五工程师（包括首席执行官和VPE），以及投资所要求的水平意味着它并不总是可行的。
与任何软件一样，连接器需要时间来成熟。他们必须面对真实的客户用例和数据量，因为这是找到和解决所有源API问题的唯一方法。通常这些问题都没有被记录下来——通常源代码公司的工程师也不知道它们，这使得几乎不可能发现演示源代码的问题。
尽管我们有自动测试，帮助我们在源端找到合同变更(例如,Facebook（拒绝使用API端点），找到它们通常是运气的问题。如果我们能够发现即将发生的合同变更，连接器就不会断开。如果我们不这样做，连接器就坏了，我们不得不赶紧去修理它。
所有支持团队成员都在美国（以及Fivetran的大多数员工）。鉴于支持存在于一个时区，团队必须24小时工作以确保我们的响应时间满足客户期望。我们以先到先得的方式工作，没有任何指标记录。
我们投资在班加罗尔的第二个工程场地。该流程和工作流发展而来的，我们得到的可靠性一个新的水平。是时候把重点放在进一步提高我们的可靠性。
依靠工程或支持团队来检查羞耻之墙是不够的——我们选择了自动化。我们创建了BugBot来自动提交失效超过48小时的任何连接器的罚单。
除日志外，我们还收集了一些关键指标，如故障连接器数量和同步队列大小。当指标达到需要立即关注的阈值时（例如，如果有太多故障连接器），我们会在火灾报警通道中设置自动报警。
我们引入了随叫随到的“超级英雄”轮换。这是一对来自两个不同时区(PST和IST)的工程师，他们一周24小时全天候待命。这些超级英雄对任何即将发生的事件都能立即做出反应，并且必须足够了解产品以排除所有即将发生的事件。如果他们需要负责受损产品区域的团队提供额外的输入，这有时意味着在地球另一边的团队上线之前会有延迟。
我们创建了各种最佳实践，如程序查询增量，以避免数据完整性问题的数据。我们学会了如何处理在源端特定类型的故障，以及如何实现重试。我们的连接器架构演变到需要更少的努力，以创造新的连接器。新的连接器的质量不断提高。现有的连接器也日趋成熟：随着越来越多的客户使用它们，我们可以在源端解决边缘情况和扭结。
相反，希望没有什么不好的事情发生（并假设源的API将始终保持稳定），我们开始定期检查插件。负责其连接器工程师验证其合同的变更。工程师提交门票，以解决这些变化。
我们主要集中在三个地区，北美，EMEA和APAC。然后将它们传递给下一个支持团队，因为它上线了 - 我们在使我们的团队来实现过程，在高优先级问题的工作每个区域建立了一个支持组织。虽然我们队是涓涓细流，我们能够显著提高我们的响应时间以及来自100每人压低我们的票积压。这种跟踪太阳进程加速时间 - 分辨率为大大改善客户体验。
保持工程重点建设的软件，而不是优先分配的门票也是在角色的专业化主要的第一步。
今天，我们的工程师分布在四个地方，我们的全球支持团队分布在三个不同的时区。此外，我们还建立了一个专门的SRE(现场可靠性工程)团队，专注于Fivetran平台的可靠性。
工程团队投入了大量精力，为我们支持的所有服务准备详细的内部文档、警报和运行簿。一旦问题发生——甚至更早——团队就会得到通知，因此可以在它们影响我们的客户之前解决它们。警报系统自动归档票据并通知负责团队。
除了日志和指标之外，我们还提供了一个功能齐全的应用程序性能监视(APM)解决方案，它不仅可以让我们了解问题的原因，还可以让我们了解如何优化性能和修复瓶颈。
由于我们的增长和产品功能的复杂性，维持一对随叫随到的工程师不再是一个可持续的解决方案。如今，问题由该领域的专家来解决，而且解决得更快。为了减少全天候待命的压力，每个团队都有一对位于不同时区的团队，允许遵循太阳模式。
此外，还有一个随叫随到的经理轮换，以确保在发生重大事件时始终有人支持团队。所有事件都自动归档到我们的任务管理系统中。
我们有一个零事件政策：所有事件都在21天的时间窗口内解决。这一政策意味着团队必须优先考虑事件而不是功能工作。这种权衡是值得的：数据的一致性和可靠性至关重要。
为了改进连接器的质量，我们现在由功能性结构域和提取的共享组件组它们。这改善了质量，也使我们能够做出类似的连接器工作更稳定，使他们能够变得更强大和可预测性。我们还引入了更多的可重复使用的实用程序进行连接器开发不易出错。
无论在框架中，可重用的组件，以及共享的核心投资，建设连接器需要努力和勤奋来获得数据模式的权利。我们的目标是要找到同时保持数据的完整性，并确定和周围源API软木塞要获取信息的最佳方式。
在源端跟踪更改的过程仍然需要定期手动签入。不过，我们正在研究一种解决方案，该解决方案允许我们通过对源文档页面进行爬网来自动跟踪更改。早期的实验已经成功。
Fivetran的核心原则之一是“像电力一样可靠”。我们的客户依靠我们以可靠和完整的方式将他们的所有数据从数据源传送到目的地。这就是为什么我们在客户成功组织．
我们已经聘请了客户成功经理(CSM)和技术成功经理(TSM)的全球团队，并将我们的支持团队发展为全球客户支持团队(GCS)。我们的GCS团队是我们客户成功组织的骨干，我们继续发展我们支持客户的方式。
我们已经优化了后续的太阳过程，让客户的请求和事件，以持续的基础上，直到提供的分辨率加以解决。我们不断地监测我们的决议时间逐步改善。
本着这种精神，我们已经推出：
我们初步的自我服务产品：客户可以寻求解答他们的问题，使我们的社区分享想法和协作。
特性请求门户:虽然我们每个月都在添加新的连接器和服务，但我们为客户提供一种要求特性和连接器的方式是极其重要的。
除了全面监控和可观察系统外，我们正在建设一个管道飞行交通管制系统。这是一个高级监视仪表板，将提供所有正在运行的同步的运行状况和性能的概述。
虽然可靠的事件管理流程非常重要，但处理事件的最佳方法是首先防止事件发生。这就是为什么我们新的和不断增长的QA团队正在努力工作，在新代码交付生产之前尽可能多地实施保护。
数据可靠性是自动化数据管道行业必须具备的条件，这就是Fivetran正在构建现代数据堆栈战略与客户。
继续构建我们的自助服务能力和社区，使我们能够与客户一起构建他们自己的数据策略。客户可以成为真正的数据驱动企业。它们可以打破数据竖井，将许多数据源聚集在一起，以获得组织的整体视图。
数据访问将推动业务向前发展。但要达到目标，我们需要付出所有的努力和精力——我们必须爬、走、跑。我们的故事还没有结束：我们要飞。