对讲机的数据基础架构团队如何以可靠的原则满足不断增长的需求

扩大公司规模从来都不是一个线性过程。 随着您的初创公司规模扩大，团队将遇到需要他们快速适应新需求的障碍。

这就是我们在 2020 年底找到我们的数据基础设施团队的地方——我们为 Intercom 的团队提供数据和工具，以获取洞察力并运行关键流程，并且比以往任何时候都更受欢迎。 在过去的几年里，对讲机经历了重大的发展，我们雇佣了很多非常有才华的人来帮助我们的旅程。 因此，我们公司的发展轨迹发生了迅速变化——到去年年底，我们团队的需求比以往任何时候都高。 我们意识到，我们一直在使用的基础设施、实践和流程正在努力以新的规模高效运行。

数据基础架构团队已达到临界点

该团队大部分时间都在处理我们系统中出现的小问题，不断地被动地工作，而不是查看潜在问题并主动加强基础设施——我们根本没有时间。 作为经理，这意味着我经常不得不介入并帮助完成日常任务，而不是专注于团队的方向、战略和专业发展。 我们已经到了一个临界点，很明显有些事情必须改变。

“我们建立了一套原则，以使团队与我们的目标保持一致并专注于我们的工作”

当我们的集团工程经理 Cormac McGuire 加入团队时，我们退后一步，研究需要做些什么才能让我们重回正轨。 我们注意到过去曾遇到过阻塞团队的几个问题，例如知识孤岛、不断的上下文切换以及重要系统健康问题的优先级降低。 为了解决这些问题，我们制定了一套原则，使团队与我们的目标保持一致并专注于我们的工作。

为什么原则是我们在 Intercom 工作方式中不可或缺的一部分？

多年来，我们了解到，当我们表现最好、最快乐的团队对工作方式进行深思熟虑和深思熟虑时，他们会更好地处理需求。 我们发现原则是扩大团队规模并使他们保持一致的最佳方式，同时相信他们会做适合他们的事情。 我们的原则源于我们所了解的关于哪些行之有效——哪些行不通的知识。

以下是我们需要解决的最紧迫的问题，以及我们应用于每个问题的原则。

问题 1：速度优先于解决问题

我们通过快速交付项目来取悦我们的客户，也就是我们在 Intercom 的同事，但我们没有让自己有足够的时间来了解要解决的核心问题。 当先前的假设被证明不正确或我们意识到某个场景被忽略时，我们经常不得不重新审视已完成的项目。

原则 1：做得更少，做得更好

处理更少的任务意味着更少的上下文切换，并允许更深入地专注于完全理解问题。 团队有更多空间来迭代解决方案，直到它满足我们设定的目标。

采用“做得更少，做得更好”的原则意味着做出艰难的权衡以使团队长期受益。 首先，我们建立了一个状态服务，以便其他团队可以检查他们的数据进度，而不是与我们签到。 这让我们腾出时间来回答查询，这样我们就可以用它来处理我们的系统，并最终加快数据传输速度。

“我们需要专注于一件事，直到它得到解决，我们确信我们不必重新审视它。 只有这样，我们才能继续下一件事”

其次，我们选择只关注日常 ELT（提取、加载、转换）的可靠性，即每晚提取最新数据并刷新所有现有数据的过程。 我们需要专注于一件事，直到它被解决，我们确信我们不必重新审视它。 只有这样，我们才能继续下一件事。

问题 2：知识孤岛

我们的数据基础架构团队很小，因此工程师通常会单独处理项目。 如果没有必要的上下文，团队中的其他工程师很难审查代码，并且如果现有服务出现问题，只有在系统上工作过的工程师才能快速解决问题。

“我们让聪明的人同时做聪明的事情”

当那个工程师休假时，所有的工作都会停止。 我们的队友很快就对成为一个地区的唯一负责人感到沮丧。 简而言之，我们让聪明的人同时做聪明的事情——我们需要创建能够更好地支持我们的工程师的有凝聚力的流程。

原则 2：解决问题

每个解决方案都至少有两名工程师在研究它。 分配一名工程师而不是两名工程师并不一定会使结果的效率或质量翻倍，它只会增加故障点的风险。 当过程中包含多个观点时，项目总是会产生更好的结果。

知道总有人回答问题或解决特定领域内的问题，减少了个别工程师的压力，使他们更容易休假或转移到新项目。

问题 3：系统运行状况的优先级不足

系统健康问题是运营任何服务的重要组成部分。 然而，如果没有一个有效的系统来对新问题进行分类和优先排序，待命工程师会主观地决定首先要解决哪些问题。

当这些系统健康问题确实出现时，我们不愿意将它们标记为最高优先级 (P1)，因为我们的分析数据并非严格面向客户，因此我们认为它不那么重要。 但是，这些问题可能会影响整个系统的健康状况，并对我们团队的工作产生负面影响。 我们意识到我们对它们的优先级不够高，而且随着时间的推移，它们正在复合导致更大的问题。

原则 3：系统健康总是 P1

任何影响我们主要 SLA（服务学习协议）的系统问题都将是首要任务 (P1)。 我们需要重新考虑将问题标记为 P1 的方法； 停止将 P1 视为紧急的、阻碍客户的紧急情况，而是将其视为重要流程的煽动者。

自实施这一原则以来，我们处理问题的效率大大提高。 系统健康问题被标记为 P1，如果值班工程师缺乏足够的上下文来独立解决新的 P1 问题，团队将暂停主动工作并重新调整工作方向，直到问题完全得到解决。 该事件会自动记录在我们的工程团队 Slack 频道中，这意味着整个组织中对问题有额外背景或见解的任何人都可以输入以尽快解决问题。

对您的团队可以处理的事情保持现实

小团队很容易承担太多责任，将注意力分散得太细，错过重要的细节，从长远来看会创造更多的工作。

做得更少、更好，并将系统健康作为我们的首要任务，这意味着我们可以建立更强大的结构来改进我们流程的其他关键要素，并主动而不是被动地工作。 为每个项目分配两名工程师已经改变了我们的工作方式。 Intercom 的价值观之一是“我们一起走得更远”，自从我们采用这种方法以来，这已一次又一次地证明是正确的。

您对我们工作和解决问题的方式感兴趣吗？ 我们很乐意与您交谈——查看我们的空缺职位。