对讲机呈现工程师聊天

我们已经向您介绍了我们的产品和功能以及我们兴奋的发布。 现在，我们带您走进幕后，向您介绍实现这一目标的人的工作。

多年来，我们在播客中涵盖了很多内容。 每周，我们都会通过 Inside Intercom 让您深入了解产品管理、设计、支持和营销领域； 探索行业领导者如何使用 CX 通过 Scale 发展业务； 并向您展示 Intercom 联合创始人 Des Traynor 和 Intercom 产品高级副总裁 Paul Adams 的世界，他们分享了他们关于如何打造出色产品的最新想法。

而现在完全不同的东西。 这是我们第一次发布工程师聊天，这是 Intercom 的内部播客，内容涉及所有工程。 以前由对讲机的高级产品工程师 Jamie Osler 主持了七年多，现在由首席系统工程师 Brian Scanlan 接棒并继续聊天。

本周，除了 Jamie 和 Brian，您还会收到以下消息：

• Mike Stewart，Intercom 前高级首席工程师
• Patrick O'Doherty，Intercom 前高级安全工程师，现为 Oso 工程师
• 对讲机联合创始人 Ciaran Lee
• Meena Polich，Intercom 支持研发的高级顾问

从消除歧义的过程和我们曾经遇到的最严重的中断到我们对速度的痴迷以及法律和工程团队如何更好地合作，工程师聊天将让您一窥对讲机的工程流程。

如果你的时间不够，这里有一些快速的要点：

• 消歧，或在每个问题中缩小广泛的解决方案空间的过程，不仅适用于模棱两可的项目。 它可用于工程甚至产品管理的整个构建过程。
• 算法和系统的核心是数据模型。 在处理系统的技术设计时，请确保您始终首先了解数据模型。
• 基础设施中的自动化可能会导致非常严重的错误。 虽然这些问题对任何人来说都不好玩，但您可以使用它们来寻找其他盲点并构建更强大的系统。
• 您的默认操作节奏应该是运行——重要的是初创公司不要在速度上妥协。 如果你可以在本周而不是下个季度做点什么，那就去做吧。
• 法律团队不会放慢研发速度。 他们的首要任务是确保随着公司的发展和复杂性的增加，它会继续在法律范围内这样做。

如果您喜欢我们的讨论，请查看我们播客的更多剧集。 您可以关注 iTunes、Spotify 或在您选择的播放器中获取 RSS 提要。 以下是该剧集的轻微编辑记录。

Liam Geraghty：您好，欢迎来到 Inside Intercom。 我是利亚姆·杰拉蒂。 如果您经常倾听，您就会知道我们采访了来自产品管理、设计、初创公司和营销领域的制造商和实干家。 我们还有另外两个播客——Intercom on Product，Intercom 联合创始人 Des Traynor 和 Intercom 产品高级副总裁 Paul Adams 讨论了他们关于如何大规模构建成功产品的最新想法和 Scale by Intercom——我们在其中探讨了企业的发展方式通过客户关系推动增长。

您绝对不知道我们制作的一个播客是名为Engineer Chats的播客，那是因为它是 Intercom 的内部播客。 它由这里的前高级产品工程师 Jamie Osler 主持。 在每一集中，杰米都会坐下来与各种不同的人就与工程相关的各种不同主题进行交谈。

今天，我们为您带来了一个了解 Intercom 工程所有事物的声音窗口。 我们从节目中汲取了最好的部分，从我们经历过的最严重中断的故事到法律和工程团队如何更好地合作。 首先，消除歧义：区分相似事物和含义以使含义或解释更加清晰或确定的行为或过程。 2020 年 10 月，Intercom 的前高级首席工程师迈克·斯图尔特 (Mike Stewart) 坐下来与杰米讨论了这个词，以及他为什么在工作中如此使用它。 这是杰米。

一路消歧

Jamie Osler：我看到你在处理一个有点模糊的项目时取得了很好的成果，并且在成功意味着什么以及如何最好地处理它方面没有得到很好的定义，这就是你有时所说的消除歧义。 你能告诉我们你这么说是什么意思吗？

迈克·斯图尔特：是的。 消除歧义。 这是我在来对讲之前从来没有用过的一个词，自从我来到这里以来，我已经用过很多次了。 我可能以前应该在以前的地方使用过它，但它是一个很好的词。 它甚至不仅适用于模糊项目或模棱两可的项目。 我几乎认为这是一个非常笼统的动词，作为我们整个构建过程的一部分，它超越了工程，进入了 PM 用来解决问题的许多事情。

“你有一个广泛的解决方案空间......这是根据证据、决定和呼吁来结束它的过程”

如果您直接回到项目前的状态，显然我们有团队，他们有所有权领域，并且他们会制定围绕他们的路线图，对吗？ 该团队负责我们的整个营销/参与/出境/表面区域，他们自己在这方面取得了成功。 这是一个模棱两可的问题。 弄清楚我们在其中的位置以及我们可以做的所有事情以及我们可以做这些事情的方式并缩小范围的过程——也许不是百分之一百的弄清楚——并关闭那个解决方案空间以获得更紧密和更紧密的解决方案空间。更严格的观点，在你可以在参与空间内做的所有事情中，这些是我们认为最重要的，客户最期待的，最高的投资回报——这是一个消除歧义的过程。 您有一个广泛的解决方案空间，在该解决方案空间中您可以去的许多不同的地方，您应该去哪里不明确，这是根据证据、决定和电话来结束它的过程。

当我在一个工程项目中播放它时，同样的事情会在几个阶段进行。 一旦我们决定使用公共平台构建一个新的 Messenger，您可以在其中构建应用程序并将它们嵌入到一个 Messenger 中，这意味着整个解决方案空间，所有可能采用的不同形状，它如何体现，以及如何构建它。 一直消除歧义，直到您想到歧义的程度，“我们知道我们想要嵌入一个具有特定界面的 iFrame，开发人员来回移动，然后，我们如何真正实现它，技术设计它，并编写代码来做到这一点？” 这些是更放大的水平。 你仍然在那里解决模棱两可的问题。 所以，我认为消歧存在于整个产品开发过程中。

“我几乎认为这是宇宙的视频之一，从放大到地球，就像银河系中的一个点，一直到人类尺度和微观尺度”

Jamie Osler：你也确实缩小了范围。 也许你可以稍微消除歧义。

Liam Geraghty： Mike 有一种很好的方式来可视化消除歧义的过程。

迈克·斯图尔特：是的。 我几乎认为这是宇宙不同数量级的视频之一，从放大到地球作为星系中的一个点，一直到人类尺度和微观尺度。 每个级别都有一个有趣的结构，同样，我认为随着事情变得越来越明确，每个缩放级别都有有趣的歧义。

例如，当您编写代码并弄清楚“嘿，我在代码中的概念是什么，我应该如何构建这段代码？”时，这些技术是不同的。 而当你在想，“嘿，我应该如何设计这个？” 什么是数据模型和活动部件，解决方案和路线图是什么？ 我将它抽象得很远，因为它是消除歧义的。 非常慎重地考虑你要攻击的是什么以及缩放级别是我脑海中最重要的原则。 工程师可以很自然地被吸引到更深层次的消歧，弄清楚如何构建一些东西，因为这通常是更舒适或更容易破解的东西。

与数据模型合一

Liam Geraghty：为了将所有这些与一个具体的例子联系起来，Jamie 提出了这个例子。

Jamie Osler：当我们研究计费系统如何将数据发送到 Zuora 以及它如何尝试确保两者之间的状态同步时，我们必须了解当前系统是如何做到的，这样我们才能获得那种消除现有系统的歧义，并将其分解为其核心思想和原则，并查看其中哪些与未来相关。 作为其中的一部分，您编写了一份文档，探讨了 Zuora 的费率计划数据建模如何随着时间的推移而发挥作用。 而且我认为这是很多人在那个级别上不会挖掘的东西。 是什么让你认为这将是一件有用的事情？ 你什么时候知道什么时候做调查，什么时候不做？

迈克·斯图尔特：是的，当然。 就我们之前讨论的缩放级别而言，对我来说，这就是高级技术设计缩放级别。 回顾一下，在计费方面，我们处于这样的地步，“嘿，我们非常清楚我们拥有这两个系统。 我们有自己的 Rails 应用程序，还有这个外部的 Zuora 系统。 我们知道，至少在未来的相当大一部分时间里，我们将拥有这两个系统。 我们不会改变这个限制。 我们在他们两个基础上建立了很多东西，所以离开是不可行的。 我们需要让两个系统同步，我们需要让它们彼此一致，而所有这些源于我们无法让它们彼此一致的问题，我们需要这些问题消失。 我们有点理解这是使命。

“你无法设计出独立于数据模型的算法。 我认为当你开始谈论系统和产品功能时也是如此”

然后，这是一个案例，什么技术解决方案是实现这一目标的方法？ 在技​​术方面，当我在考虑技术设计和这种高级技术设计或系统设计阶段时，我几乎总是去模型。 您可以尝试了解很多表面积。 有很多重要的事情，例如，您的代码结构如何，正在发生什么变化，您有哪些工作人员，以及正在尝试做什么？ 但基本概念，系统中的核心概念，几乎总是与实际数据库中的数据模型相同； 它们在您的数据库中的架构或第三方中的公共架构，或者它们是什么。 它们是所涉及的数据模型中的核心概念。 一些著名的计算机科学家——我不知道是哪一个——明确表达了算法的核心是数据模型的观点。 您无法设计独立于数据模型的算法。 我认为当您开始谈论系统和产品功能时也是如此。 数据模型是任何设计的基础。

所以，在这种情况下，当我们开始计费时，我们做的第一件事就是了解我们自己的数据模型。 因为对你和我来说，杰米，登陆那里就像狂野的西部。 像大多数对讲机一样，我们从未见过它的内部，这是一个勇敢的新领域。 所以，首先，我们必须明白，“嘿，我们自己的系统中涉及的所有这些表到底是什么？” 在旧金山之前的团队的帮助下，我们相对较快地理解了这一点，并建立了这种心智模型。

“除非我完全理解数据模型，否则我从不习惯于推进技术设计”

然后，我认为我们几乎来不及攻击的下一个主要部分是“让我们真正了解 Zuora 的数据模型，我们正在研究的系统。” 你所说的努力，我想大概只有一周左右的时间，我基本上是在启动控制台，在 Zuora 中手动戳数据模型，改变一些东西，运行一些命令来看看发生了什么，并探索一种黑盒风格来理解数据模型。 在了解了这一点之后，我们可以说，“嘿，有这么一大堆模型。 真正重要的都在这里，就在树叶上。 它们就像存储数据内容的费率计划、收费段或其他东西。” 一旦你正确理解了核心概念和数据模型，你就可以开始构建，你可以开始设计一个系统。 当我们谈论像这样的复制系统时尤其如此，其基本工作是可靠地改组一组数据模型并将其转换为另一组数据模型中的语义等价物。

你最初的问题，不要忽视它，你怎么知道什么时候应该这样做？ 对我来说，这是一个非常简单的。 除非我完全理解数据模型，否则我永远不会舒服地推进技术设计。 我会告诉你一个地方，我因为没有深入遵循该原则而被烧伤，后来来到 Salesforce，我对 Salesforce 是一个很大的世界的核心概念和数据模型有了一些了解。 所以，时间压力很大。 而且我对数据模型的理解深度不如对 Zuora 的理解。 我认为团队中的每个人都是如此。 我们没有达到相同水平的数据模型深度。 我们觉得这样做的结果是我们构建了一些不错的东西，但一年后，在了解了这些数据模型的更多背景后，我们意识到，“嘿，我们第一次没有正确理解它们。 我们没有正确映射 Salesforce 和我们自己的系统之间的翻译，我们需要做更多的工作来弥补知识的不足。”

杰米奥斯勒：这非常有用。 那是关于您消除项目歧义的方式的一次很棒的聊天。

Mike Stewart：我希望这是一次很棒的聊天，Jamie，我希望我们能在这里得到一些有用的内容。

Jamie Osler：标签内容。

光荣的严重停电的光明面

Liam Geraghty：今年早些时候，如果你是 Facebook、WhatsApp 或 Instagram 的用户，你无疑会记得 10 月份的那次中断。 这是 Facebook 历史上最长的全球中断。 这一切都归结为他们最终的错误配置更改。 因此，中断对任何人来说都不好玩。 特别不喜欢它们的是对讲系统首席系统工程师 Brian Scanlan。

Brian Scanlan：我讨厌停机，这就是为什么我将我的职业生涯奉献给与它们作斗争的原因。

Liam Geraghty： 2020 年 11 月，Brian 坐下来与 Jamie 聊了聊他们。

Brian Scanlan：我喜欢停电，为什么我被他们吸引，或者我把时间花在他们身上的部分原因是因为到目前为止它对我的职业生涯非常好。 那是因为我决定对它感兴趣，参与管理它们，思考它们，成为它们的一部分，并跟进它们。

Liam Geraghty： Brian 回忆了对讲机的一些显着中断。

“我记得当我意识到 Elasticsearch 是空的时，我想在垃圾箱里生病。 我当时想，‘哦，这太糟糕了’”

Brian Scanlan： 2019 年 1 月的 Elasticsearch 大中断是我参与的最痛苦的中断之一，尽管我在中断期间实际上并不在场。

Liam Geraghty：当时在场的一位高级安全工程师 Patrick O'Doherty。

Patrick O'Doherty：我记得当我意识到 Elasticsearch 是空的时，我想在垃圾箱里生病。 我当时想，“哦，这太糟糕了。”

Brian Scanlan：这是一个特别壮观的。 我不在是因为我在 40 岁生日时和一些朋友一起喝酒。 这就像一个星期五的晚上。 而且因为我们不害怕在周五将代码运送到生产环境，所以我在周五晚上批准了一个拉取请求，将子网添加到我们的 VPC AWS。

杰米奥斯勒：在喝酒之间？

布赖恩斯坎兰：不，实际上是在路上。 我当时很清醒。 当试图将该子网添加到我们在亚马逊内部的网络中时，我们编写的自动化......我们使用一个名为 Terraform 的工具来管理我们在 AWS 内部的低级基础设施，并且我们有一堆团队模块——想想它是我们编写的可重用代码，用于尝试使用我们想要应用的所有设置和内容来简化 AWS 内部的一堆基础设施。

“那时，当应用配置时，它已经完全破坏或使我们的网络离线”

因此，这种自动化非常努力地采用了我们想要添加的子网的描述。 但是在申请的那一刻，AWS 的 API 拒绝了它，因为有一个重叠的 IP 子网，或者更确切地说，正在配置的子网与已经存在的子网重叠。 所以，在那个时候，Terraform 应用程序就放弃了。 停了。 在很多情况下，这是一件完全合理的事情。 但不幸的是，我们实现 Terraform 模块的方式意味着它正在删除有关子网上存在的路由表的所有信息，并在配置所有这些子网时将它们重新添加。 因此，实际上，它已经删除了所有路由，这是网络知道如何访问互联网和其他网络的方式，这非常重要。 因此，那时，当应用配置时，它已经完全破坏或使我们的网络脱机。 这只是开始。

杰米奥斯勒：我的意思是，这很糟糕，对吧？ 这不好。

布赖恩斯坎兰：是的。 因此，这使对讲机完全脱机。 然后，我们花了一段时间才到达可以回滚的地步。 我的意思是我们，不是我。 此时我正在享受我的饮料。 因此，团队想出了一种进入我们的 Terraform 供应基础设施并回滚到配置更改的方法。

“弄清楚到底发生了什么以及这些数据去了哪里也需要很长时间。 我们在这里谈论的是八小时的停电”

但不幸的是，与此同时，其他自动化开始了。这一次，AWS拥有一些自动化。 我们使用这种称为 OpsWorks 的技术（它是 Chef 的托管版本）来管理我们的 Elasticsearch 主机。 它内置了这个称为自动修复的功能，我们在主机级配置中默认启用了这个功能。 如果 OpsWorks 后端无法联系到主机，OpsWorks 的工作流系统将尝试自动修复有问题的主机，因为它认为那里出了问题。 操作系统已关闭，可能内存不足 - 发生了一些不好的事情，所以让我们尝试修复它。 因此，这个 OpsWorks 控制平面决定通过更换主机来修复我们的整个基础架构。

不幸的是，我们一直在运行 Elasticsearch，并且仍然使用所谓的临时存储。 那是基于主机的存储——我们没有使用神奇的基于云的系统将您的数据存储在某些第三方系统或来自主机之外的系统中。 它只是在物理主机上。 如果物理主机被破坏，数据就会消失。 因此，这就是发生在每个 Elasticsearch 主机上的情况。 每个 Elasticsearch 集群都会丢失每一条数据，这非常糟糕，因为大量的 Intercom 是建立在 Elasticsearch 之上的。 它不是主数据存储。 我们倾向于将数据写入一个数据存储，例如为我们的用户使用 DynamoDB，然后将该数据复制到 Elasticsearch 进行搜索。 我们可以恢复它，但是通过备份取回所有数据并重新驱动所有更改的过程，因为我们之前的备份需要很长时间。 此外，弄清楚到底发生了什么以及这些数据去了哪里也需要很长时间。 我们在这里谈论的是八小时的停电。

“我们不只是说，‘好吧，现在我们知道了这两个问题，让我们解决这些问题。’ 我们开始寻找其他类型的自动化领域，这些领域可能会在奇怪的情况下困扰我们”

这是一件大事，因为它发生在周五晚些时候，需要大量的人才能让事情恢复稳定。 我们有点了解这些问题，不得不重新驱动或重新填充我们的 Elasticsearch 集群并从头开始。 我们不知道我们自己的自动化和 AWS 的一些自动化中潜在的一些危险。

这很有趣，因为在此之后，我们不只是说，“好吧，现在我们知道了这两个问题，让我们解决这些问题。” 我们开始寻找其他类型的自动化领域，这些领域可能会在奇怪的情况下咬我们。 因此，我们最终做了很多事情，以非常擅长从不同状态恢复 Elasticsearch 集群，能够在我们落后或遇到类似灾难类型的情况时在不同时间将数据重新驱动到我们的 Elasticsearch 集群。 而且，你知道，总的来说，我们从这次光荣的严重中断中学到了很多东西，之后的过程实际上非常好，我们学到了什么以及我们如何传播这些信息。

Patrick O'Doherty：我不记得是谁了，但大约一个小时后，有人感谢我造成了这件事，因为他们就像，“哇，你真的把很多东西从树上摇下来了。 这将是一个非常有趣的事件响应。” 这基本上就是它的要点。 就像，“哦，哇。 我们正在这里挖东西。” 确实如此。 我们对 Terraform 的使用以及我们对如何使用工具的总体成熟度，同时保持意识到工具也会伤害我们。 尊重电动工具。 与基础设施一样，电动工具也很危险。 他们可以迅速行动，让你措手不及，我想我们那天吸取了教训。

布赖恩斯坎兰：我也从中得到了一个内部对讲机的谈话。 另外，我没有参加这起事件，因为我在酒吧过生日。 太好了。 这是一个完美的事件。

以光速

Liam Geraghty： 2020 年 12 月，一个我相信我们永远不会忘记的圣诞节，Intercom 联合创始人 Ciaran Lee 与 Jamie 一起谈论速度以及为什么 Ciaran 关心快速移动。

Ciaran Lee：我是一个非常没有耐心的人。 那是一回事。 如果我可以快速做某事或慢慢做，我个人宁愿快速做。 对讲机可能看起来像是一家成立 10 年的老公司，但老实说，我相信我们才刚刚起步。 我们有很多事情要做。 我们雄心勃勃。 我们可以看到我们想要成为什么样的人，这是每个拥有互联网业务的人都可以用来与他们的客户交谈的一体化工具。 我们只是在那儿摸索表面。

我非常喜欢 Stripe 的一件事，这是一家我敬仰的很酷的公司，Patrick McKenzie 的一篇很棒的博客文章描述了他们将默认的操作节奏设置为运行。 他们默认的快速行动令人不安，总是问我们是否可以在本周而不是六个月后更快地完成这件事。 我个人真的很喜欢。 这种态度对我们很有帮助。 而且我认为这是一件很有趣的事情。 你能走得更快吗？

“如果我们在一个季度达到 100% 的可用性，这很酷，但也许我们应该问自己，‘嘿，我们的风险还不够吗？’”

Jamie Osler：如果你让快速发展对你的公司至关重要，而且这是你一直都在做的事情，那么你往往会更少崩溃。

李夏兰：是的。 在可接受的参数范围内快速移动并打破事物。 停电也没关系。 有错误是可以的——显然，某些类别的错误比其他错误要少，但我们有可用性预算。 如果我们在一个季度达到 100% 的可用性，这很酷，但也许我们应该问自己，“嘿，我们的风险还不够吗？ 我们可以冒更多的风险来加快行动吗？” 您应该处于频谱中的一个深思熟虑的位置。 当然，我们有很大的责任。 我们有很多客户，数十万人登录，他们的工作就是使用我们的收件箱，每天与他们的客户交谈。 我们不能因为移动太快或改变太快以至于他们甚至不知道如何使用它而破坏他们的东西。 那是错误的。 我们有限制，但在这些限制内，我们绝对应该尽可能快地行动。

合法的地方

Liam Geraghty：我们正在尽可能快地完成这一集。 接下来，对讲机，高级顾问，Meena Polich。 Meena 是我们法律团队的一员，专注于产品和工程。 2021 年 1 月，Meena 和 Jamie 讨论了法律和工程团队如何协同工作。

“我们在这里与公司和我们所有的客户步调一致，以负责任的方式到达我们需要去的地方，而不会拖慢任何人的脚步”

Meena Polich：了解产品对我们来说非常重要。 如果我们实际上不了解我们所销售的产品，我们怎么可能就哪些法规将对我们产生影响或我们必须遵守哪些法律向公司提供咨询？ 在一个非常基本的层面上，从战略的角度来看，我们不仅需要了解我们现在销售什么，还需要了解我们想要销售什么，以及我们希望如何定位和发展。 通过这种方式，我们可以开始对我们需要从法律角度关注的事情进行预测。 只是确保我们在这里与公司和我们所有的客户步调一致，以负责任的方式到达我们需要去的地方，而不会拖慢任何人的脚步。 从更具战术性的方法来看，了解公司价值观和产品对于与客户甚至供应商进行谈判非常有帮助。 当我了解我们正在努力做的事情时，它让我处于一个更好的杠杆位置。 然后，我可以向我们的供应商解释，“因为我们正在努力做到这一点，我们需要你能够做到这一点。”

相反，当我与客户谈判时，很多时候，桌子另一边的人是其他律师或采购代理人，他们的技术水平不亚于我。 因此，能够以律师的身份解释产品的作用，“看，从法律风险管理的角度来看，我知道您的担忧是什么，但这就是该平台的实际运作方式。 以下是该产品在实践中的实际工作方式。 这就是为什么它不会提示您担心的这种风险。 它不会引发你担心的风险。”

“我的首要任务是帮助研发部门了解我来这里不是为了破坏我们正在取得的惊人进展”

杰米·奥斯勒：我想这是双向的，对吧？ 如果 R&D 对可能关注的领域的高级法律概述有更好的理解，它可以帮助他们避免无意中做有风险或违反这些法律的事情或制造产品。

Meena Polich：是的，绝对是。 在与研发建立法律关系时，这是最重要的事情。 我的首要任务是帮助研发部门明白，我来这里不是为了破坏我们正在取得的惊人进展，我的团队也不是来阻止我们继续以优秀的产品进入市场。 我们的团队在这里确保，随着我们的成长，并且越来越难以密切关注公司中每个人所做的一切，我们将继续以合乎道德的方式这样做，并且我们将继续在法律范围内这样做。 当我们可以时，我们会尝试管理这种风险。

这就是设计合规性如此重要的原因之一。 如果我们牢记合规要求或合规期望，并且我们针对这些进行设计，那么很多时候，我们所做的设计更改将真正有利于我们的底线。 在资源分配方面可能存在初始成本，但从长远来看，甚至不是超长期——在很多情况下，在推出该功能的六个月到一年内——我们将看到令人难以置信的好处在收入增长和我们产生的潜在客户类型和吸引客户方面，因为他们会信任我们。

Liam Geraghty：感谢创建Engineer Chats的 Jamie Osler、新主持人 Brian Scanlan，以及今天所有让我们将内部聊天放到外部的客人。 如果您喜欢今天的节目，为什么不给我们留下评论或在社交媒体上大喊大叫。 我们喜欢看到和听到您的想法。 这就是今天的全部内容。 我们将在下周带着另一集 Inside Intercom 回来。