對講機呈現工程師聊天

我們已經向您介紹了我們的產品和功能以及我們興奮的發布。 現在，我們帶您走進幕後，向您介紹實現這一目標的人的工作。

多年來，我們在播客中涵蓋了很多內容。 每週，我們都會通過 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 回來。