Intercom präsentiert Engineer Chats

Wir haben Ihnen alles über unsere Produkte und Funktionen und die Markteinführungen erzählt, auf die wir uns freuen. Jetzt führen wir Sie hinter die Kulissen und stellen Ihnen die Arbeit der Menschen vor, die sie möglich machen.

Im Laufe der Jahre haben wir mit unseren Podcasts eine Menge Terrain abgedeckt. Jede Woche geben wir Ihnen mit Inside Intercom einen Einblick in die Welt des Produktmanagements, des Designs, des Supports und des Marketings; Erfahren Sie, wie führende Unternehmen der Branche CX nutzen, um ihr Geschäft mit Scale auszubauen. und zeigen Ihnen die Welt von Intercom-Mitbegründer Des Traynor und Intercom SVP of Product, Paul Adams, während sie ihre neuesten Gedanken darüber teilen, wie man großartige Produkte baut.

Und jetzt etwas ganz anderes. Zum allerersten Mal veröffentlichen wir Engineer Chats , einen internen Podcast hier bei Intercom über alles, was mit Technik zu tun hat. Zuvor war Jamie Osler, seit über sieben Jahren Senior Product Engineer bei Intercom, Gastgeber, jetzt liegt es an Brian Scanlan, Principal Systems Engineer, den Stab in die Hand zu nehmen und die Chats am Laufen zu halten.

Diese Woche hören Sie neben Jamie und Brian auch von:

• Mike Stewart, ehemaliger Senior Principal Engineer bei Intercom
• Patrick O'Doherty, ehemaliger Senior Security Engineer bei Intercom und jetzt Ingenieur bei Oso
• Intercom-Mitbegründer Ciaran Lee
• Meena Polich, Senior Counsel von Intercom, die Forschung und Entwicklung unterstützt

Vom Prozess der Begriffsklärung und dem schlimmsten Ausfall, den wir je hatten, bis hin zu unserer Besessenheit von Geschwindigkeit und wie Rechts- und Ingenieurteams besser zusammenarbeiten können, geben Ihnen Ingenieur-Chats einen Einblick in den Entwicklungsprozess bei Intercom.

Wenn Sie wenig Zeit haben, hier sind ein paar schnelle Takeaways:

• Begriffsklärung oder das Eingrenzen eines breiten Lösungsraums in jedem Problem ist nicht nur gut für mehrdeutige Projekte. Es kann für den gesamten Bauprozess im Engineering und sogar im Produktmanagement eingesetzt werden.
• Der Kern von Algorithmen und Systemen sind Datenmodelle. Wenn Sie ein technisches Design für ein System in Angriff nehmen, sollten Sie immer zuerst die Datenmodelle verstehen.
• Die Automatisierung in der Infrastruktur kann zu ziemlich schwerwiegenden Fehlern führen. Und obwohl diese Probleme niemandem Spaß machen, können Sie sie verwenden, um nach anderen blinden Flecken zu suchen und ein robusteres System aufzubauen.
• Ihre Standardbetriebskadenz sollte Laufen sein – es ist wichtig, dass Startups keine Kompromisse bei der Geschwindigkeit eingehen. Wenn Sie diese Woche statt im nächsten Quartal etwas tun können, springen Sie darauf.
• Die Rechtsabteilung ist nicht da, um die Forschung und Entwicklung zu bremsen. Ihre Priorität ist es, sicherzustellen, dass das Unternehmen wächst und an Komplexität zunimmt, und zwar im Rahmen der gesetzlichen Bestimmungen.

Wenn Ihnen unsere Diskussion gefällt, sehen Sie sich weitere Folgen unseres Podcasts an. Sie können auf iTunes, Spotify folgen oder den RSS-Feed in Ihrem bevorzugten Player abrufen. Was folgt, ist eine leicht bearbeitete Abschrift der Episode.

Liam Geraghty: Hallo und willkommen bei Inside Intercom. Ich bin Liam Geraghty. Wenn Sie regelmäßig zuhören, wissen Sie, dass wir Macher und Macher aus den Bereichen Produktmanagement, Design, Startups und Marketing interviewen. Wir haben auch zwei weitere Podcasts – Intercom on Product, in denen Intercom-Mitbegründer Des Traynor und Intercom SVP of Product, Paul Adams, ihre neuesten Gedanken darüber diskutieren, wie man erfolgreiche Produkte in großem Maßstab entwickelt, und Scale by Intercom – in dem wir untersuchen, wie Unternehmen sind Wachstum durch Kundenbeziehungen vorantreiben.

Ein Podcast, von dem Sie definitiv nicht wussten, dass wir ihn erstellt haben, heißt Engineer Chats , und das liegt daran, dass es sich um einen internen Podcast bei Intercom handelt. Gastgeber war Jamie Osler, ein ehemaliger Senior Product Engineer hier. In jeder Folge setzte sich Jamie hin, um mit einer Vielzahl verschiedener Leute über eine Vielzahl unterschiedlicher Themen im Zusammenhang mit Ingenieurwesen zu sprechen.

Heute bringen wir Ihnen bei Intercom ein klangliches Fenster in alle technischen Dinge. Wir haben die besten Teile der Show mitgenommen, von der Geschichte des schlimmsten Ausfalls, den wir je hatten, bis hin zu der Frage, wie Rechts- und Technikteams besser zusammenarbeiten können. Zunächst einmal Begriffsklärung: die Handlung oder der Prozess der Unterscheidung zwischen ähnlichen Dingen und Bedeutungen, um die Bedeutung oder Interpretation klarer oder sicherer zu machen. Mike Stewart, der ehemalige Senior Principal Engineer bei Intercom, setzte sich im Oktober 2020 zusammen, um mit Jamie über dieses Wort zu sprechen und warum er es bei der Arbeit so häufig verwendet. Hier ist Jamie.

Begriffsklärung ganz nach unten

Jamie Osler: Ich habe gesehen, wie Sie großartige Ergebnisse erzielt haben, wenn Sie sich einem Projekt nähern, das ein wenig verschwommen und nicht sehr gut definiert ist, was Erfolg bedeutet und wie man es am besten angeht, was Sie manchmal als Begriffsklärung bezeichnen. Können Sie uns sagen, was Sie meinen, wenn Sie das sagen?

Mike Stewart: Ja. Begriffsklärung. Das ist ein Wort, das ich nie oft benutzt habe, bevor ich zu Intercom kam, und ich habe es so oft benutzt, seit ich hier bin. Ich hätte es wahrscheinlich schon früher an früheren Stellen verwenden sollen, aber es ist so ein gutes Wort. Es ist nicht einmal nur für wollige Projekte oder mehrdeutige Projekte. Ich denke fast, dass dies ein sehr allgemeines Verb als Teil unseres gesamten Bauprozesses ist, der weit über das Engineering hinausgeht und in viele Dinge einfließt, die PMs tun, um Dinge herauszufinden.

„Sie haben einen großen Lösungsspielraum … es ist der Prozess, das auf der Grundlage von Beweisen, Entscheidungen und Anrufen abzuwickeln.“

Wenn Sie direkt zum Vorprojektstatus zurückkehren, haben wir offensichtlich Teams, sie haben Verantwortungsbereiche und sie entwickeln Roadmaps um sie herum, richtig? Das Team ist verantwortlich für unseren gesamten Marketing-/Engagement-/Outbound-/Flächenbereich, und sie sind dafür verantwortlich, darin erfolgreich zu sein. Das ist ein mehrdeutiges Problem. Der Prozess, herauszufinden, wo wir darin sitzen, und all die Dinge, die wir tun könnten, und die Art und Weise, wie wir sie tun könnten, und uns einzugrenzen – vielleicht nicht hundertprozentig herauszufinden – und diesen Lösungsraum zu schließen, um ein engeres und Genauer betrachtet sind dies unter all den Dingen, die Sie im Engagement-Bereich tun könnten, die, die wir für die wichtigsten halten, die Kunden am meisten suchen, die höchste Kapitalrendite – das ist ein Prozess der Begriffsklärung. Sie haben einen großen Lösungsraum, Unklarheit darüber, wohin Sie innerhalb der vielen verschiedenen Orte gehen sollten, die Sie innerhalb dieses Lösungsraums gehen könnten, und es ist der Prozess, dies auf der Grundlage von Beweisen, Entscheidungen und Anrufen abzuwickeln.

Wenn ich das einem Engineering-Projekt vorspiele, gibt es das Gleiche ein paar Stufen weiter unten in der Pipeline. Sobald wir uns entschieden haben, einen neuen Messenger mit einer öffentlichen Plattform zu entwickeln, auf der Sie Apps erstellen und in einen Messenger einbetten können, gibt es den gesamten Lösungsraum dessen, was das bedeutet, all die verschiedenen Formen, die es annehmen könnte, wie es sich manifestieren könnte, und wie man es bauen könnte. Begriffsklärung ganz nach unten, bis Sie zu dem Punkt kommen, an dem die Mehrdeutigkeit, an die Sie denken, lautet: „Wir wissen, dass wir einen iFrame mit einer bestimmten Schnittstelle einbetten wollen, die Entwickler bewegen sich hin und her, und dann, wie machen wir das? Implementieren Sie das tatsächlich, entwerfen Sie es technisch und schreiben Sie die Codes dafür? Das sind die noch stärker vergrößerten Ebenen. Sie arbeiten sich dort immer noch durch Mehrdeutigkeit. Ich denke also, dass die Begriffsklärung den gesamten Produktentwicklungsprozess betrifft.

„Ich stelle mir das fast als eines dieser Videos des Universums vor, das vom Zoomen bis zur Erde als Punkt in einer Galaxie und den ganzen Weg durch den menschlichen Maßstab und den Mikromaßstab reicht.“

Jamie Osler: Sie haben das auch wirklich eingegrenzt. Vielleicht könntest du das ein wenig entziffern.

Liam Geraghty: Mike hat eine großartige Art, den Prozess der Begriffsklärung zu visualisieren.

Mike Stewart: Ja. Ich stelle mir das fast als eines dieser Videos des Universums in verschiedenen Größenordnungen vor, das vom Zoomen bis zur Erde als Punkt in einer Galaxie und den ganzen Weg durch den menschlichen Maßstab und den Mikromaßstab reicht. Auf jeder dieser Ebenen gibt es eine interessante Struktur, und ebenso denke ich, dass es auf jeder der Zoom-Ebenen interessante Mehrdeutigkeiten gibt, da die Dinge immer klarer werden.

Die Techniken sind anders, wenn Sie beispielsweise Code schreiben und herausfinden: „Hey, was sind meine Konzepte im Code und wie soll ich diesen Code strukturieren?“ im Gegensatz zu der Frage: „Hey, wie soll ich das technisch gestalten?“ und was sind die Datenmodelle und die beweglichen Teile im Vergleich zu was ist die Lösung im Vergleich zur Roadmap? Ich abstrahiere es sehr weit, da es alles eine Begriffsklärung ist. Sehr bewusst zu sein, was man angreift und mit welcher Zoomstufe, ist das wichtigste Prinzip in meinem Kopf. Und hier können Ingenieure ganz natürlich in die tieferen Zoom-Ebenen der Begriffsklärung hineingezogen werden, um herauszufinden, wie man etwas baut, denn das ist oft bequemer oder eine leichter zu knackende Nuss.

Eins sein mit den Datenmodellen

Liam Geraghty: Um all dies mit einem konkreten Beispiel zu verbinden, präsentiert Jamie dieses.

Jamie Osler: Als wir untersuchten, wie das Abrechnungssystem Daten an Zuora sendete und wie es versuchte sicherzustellen, dass der Status zwischen den beiden synchronisiert wurde, mussten wir verstehen, wie das aktuelle System dies tat, damit wir diese Art von Daten erhalten konnten Begriffsklärung des bestehenden Systems, brechen Sie es auf seine Kernideen und -prinzipien herunter und sehen Sie, welche davon für die Zukunft relevant sind. Als Teil davon haben Sie ein Dokument verfasst, in dem untersucht wurde, wie Zuoras Modellierung von Tarifdaten im Laufe der Zeit funktionierte. Und ich denke, das war etwas, mit dem sich viele Leute auf dieser Ebene nicht beschäftigt hätten. Was hat Sie dazu veranlasst zu denken, dass dies eine nützliche Sache wäre? Und wann wissen Sie, wann Sie diese Untersuchung durchführen müssen, wann nicht?

Mike Stewart: Ja, sicher. In Bezug auf die Zoomstufen, über die wir zuvor gesprochen haben, ist dies für mich genau in dieser High-Level-Tech-Design-Zoomstufe. Um es noch einmal zusammenzufassen: Bei der Abrechnung waren wir an dem Punkt angelangt: „Hey, wir sind uns ziemlich sicher, dass wir diese beiden Systeme haben. Wir haben unsere eigene Rails-App und wir haben dieses externe Zuora-System. Wir wissen, dass wir zumindest für einen anständigen Teil der Zukunft diese beiden Systeme haben werden. Wir werden diese Einschränkung nicht ändern. Wir haben viel auf die beiden gebaut, also ist es nicht machbar, loszuziehen. Wir müssen die beiden Systeme synchronisieren, und sie müssen miteinander übereinstimmen, und all diese Probleme, die darauf zurückzuführen sind, dass wir sie nicht miteinander vereinbaren können, müssen wir beseitigen. Wir haben irgendwie verstanden, dass das die Mission war.

„Man kann keinen Algorithmus unabhängig von einem Datenmodell entwickeln. Und ich denke, das Gleiche gilt, wenn man anfängt, über Systeme und Produkteigenschaften zu sprechen.“

Und dann ging es darum, mit welcher technischen Lösung das zu erreichen ist? Was die Techniken betrifft, so gehe ich fast immer zu den Modellen, wenn ich an Tech-Design und diese High-Level-Art von Tech-Design oder Systemdesign-Phase denke. Es gibt eine Menge Oberfläche, die Sie versuchen können zu verstehen. Es gibt viele Dinge, die wichtig sind, wie zum Beispiel, wie ist Ihre Codestruktur, was bewegt sich, welche Arbeiter haben Sie und was versucht, was zu tun? Aber die grundlegenden Konzepte, die Kernkonzepte im System, sind fast immer die gleichen wie die Datenmodelle in der eigentlichen Datenbank; das Schema davon in Ihrer Datenbank oder das öffentliche Schema in Ihrem Drittanbieter oder was auch immer sie sind. Sie sind die Kernkonzepte in den beteiligten Datenmodellen. Und ein berühmter Informatiker – ich weiß nicht welcher – hat definitiv die Meinung geäußert, dass der Kern von Algorithmen Datenmodelle sind. Sie können keinen Algorithmus unabhängig von einem Datenmodell entwickeln. Und ich denke, das Gleiche gilt, wenn man anfängt, über Systeme und Produktfeatures zu sprechen. Die Datenmodelle sind die Grundlage jedes Designs.

In dieser Situation war das erste, was wir taten, als wir bei der Abrechnung landeten, unsere eigenen Datenmodelle zu verstehen. Denn für dich und mich, Jamie, war die Landung dort wie im Wilden Westen. Wie die meisten von Intercom hatten wir noch nie das Innere davon gesehen, es war eine mutige neue Grenze. Also mussten wir zuerst verstehen: „Hey, was zum Teufel sind all diese Tabellen in unserem eigenen System involviert?“ Mit Hilfe des vorherigen Teams in San Francisco kamen wir relativ schnell zu diesem Verständnis und bauten dieses mentale Modell auf.

„Ich fühle mich nie wohl dabei, mit einem technischen Design voranzukommen, wenn ich die Datenmodelle nicht vollständig verstehe.“

Dann war der nächste große Teil, der fehlte und den wir meiner Meinung nach fast zu spät angegriffen hätten, „Lassen Sie uns das Datenmodell von Zuora wirklich verstehen, das System, in das wir uns einarbeiten.“ Der Aufwand, von dem Sie sprachen, ich glaube, es war nur etwa eine Woche, in der ich im Grunde genommen die Konsole hochgefahren, die Datenmodelle in Zuora manuell angestoßen, etwas geändert, einige Befehle ausgeführt habe, um zu sehen, was passiert ist, und eine Art untersucht im Black-Box-Stil, um das Datenmodell zu verstehen. Und am Ende des Verständnisses könnten wir sagen: „Hey, da ist dieser große Stapel von Modellen. Die wirklich wichtigen sind hier unten, direkt am Blatt. Sie sind wie der Tarifplan, Gebührensegmente oder so etwas, das die Daten speichert.“ Und sobald Sie die Kernkonzepte und Datenmodelle richtig verstanden haben, können Sie mit dem Aufbau beginnen, Sie können mit dem Entwurf eines Systems beginnen. Und das gilt insbesondere, wenn wir über Replikationssysteme wie dieses sprechen, deren grundlegende Aufgabe darin besteht, einen Satz von Datenmodellen zuverlässig zu mischen und in das semantisch Äquivalente in einem anderen Satz von Datenmodellen zu übersetzen.

Ihre ursprüngliche Frage, um sie nicht aus den Augen zu verlieren, lautet: Woher wissen Sie, wann Sie das tun sollten? Für mich ist das eine ganz einfache Sache. Ich fühle mich nie wohl dabei, mit einem technischen Design voranzukommen, wenn ich die Datenmodelle nicht vollständig verstehe. Und ich werde Ihnen sagen, dass ich später, als ich zu Salesforce kam, ein gewisses Verständnis für die Kernkonzepte und Datenmodelle hatte, dass Salesforce eine große, große Welt war, wo ich verbrannt war, weil ich diesem Prinzip nicht tief gefolgt war. Der Zeitdruck war also groß. Und ich ging nicht auf die gleiche Tiefe des Verständnisses der Datenmodelle wie bei Zuora. Und ich denke, das gleiche galt für alle im Team. Wir haben nicht die gleiche Tiefe von Datenmodellen erreicht. Und wir spüren das Ergebnis davon, dass wir etwas Gutes gebaut haben, aber ein Jahr später, nach mehr Kontext mit diesen Datenmodellen, stellten wir fest: „Hey, wir haben sie beim ersten Mal nicht richtig verstanden. Wir haben die Übersetzung zwischen Salesforce und unserem eigenen System nicht richtig abgebildet, und wir müssen noch mehr tun, um diesen Mangel an Wissen zu beheben.“

Jamie Osler: Das ist super nützlich. Das war ein tolles Gespräch darüber, wie Sie Projekte disambiguieren.

Mike Stewart: Ich hoffe, es war ein tolles Gespräch, Jamie, und ich hoffe, wir haben hier einige nützliche Inhalte bekommen.

Jamie Osler: Hashtag-Inhalte.

Die helle Seite eines glorreich schlimmen Ausfalls

Liam Geraghty: Wenn Sie ein Nutzer von Facebook, WhatsApp oder Instagram Anfang dieses Jahres sind, werden Sie sich zweifellos an diesen Ausfall im Oktober erinnern. Es war der längste weltweite Ausfall in der Geschichte von Facebook. Es lief alles auf eine fehlerhafte Konfigurationsänderung auf ihrer Seite hinaus. Ausfälle machen also niemandem Spaß. Jemand, der sie besonders nicht mag, ist Brian Scanlan, Principal Systems Engineer von Intercom.

Brian Scanlan: Ich hasse Ausfälle, deshalb habe ich meine Karriere dem Kampf gegen sie gewidmet.

Liam Geraghty: Brian hat sich im November 2020 mit Jamie über sie unterhalten.

Brian Scanlan: Einer der Gründe, warum ich Ausfälle mag, warum ich mich zu ihnen hingezogen fühle oder meine Zeit damit verbringe, ist, dass es meiner Karriere bisher ziemlich gut getan hat. Und das liegt daran, dass ich mich dafür entschieden habe, mich dafür zu interessieren, mich an deren Leitung zu beteiligen, über sie nachzudenken, ein Teil von ihnen zu sein und sie weiterzuverfolgen.

Liam Geraghty: Brian erinnerte sich an einige bemerkenswerte Ausfälle bei Intercom.

„Ich erinnere mich, dass ich am liebsten in einem Mülleimer liegen wollte, als ich feststellte, dass Elasticsearch leer war. Ich dachte: ‚Oh, das ist so schlimm‘.“

Brian Scanlan: Einer der traumatischsten Ausfälle, an denen ich beteiligt war, war der große Elasticsearch-Ausfall im Januar 2019, obwohl ich während des Ausfalls nicht wirklich dabei war.

Liam Geraghty: Jemand, der dort war, war Patrick O'Doherty, damals ein leitender Sicherheitsingenieur hier.

Patrick O'Doherty: Ich erinnere mich, dass ich am liebsten in einem Mülleimer liegen wollte, als ich merkte, dass Elasticsearch leer war. Ich dachte: „Oh, das ist so schlimm.“

Brian Scanlan: Das war besonders spektakulär. Ich war nicht da, weil ich an meinem 40. Geburtstag mit ein paar Freunden getrunken habe. Es war wie an einem Freitagabend. Und weil wir keine Angst davor haben, an einem Freitag Code an die Produktion zu senden, genehmigte ich an diesem Freitagabend einen Pull-Request, der unserer VPC AWS ein Subnetz hinzufügte.

Jamie Osler: Zwischendurch etwas trinken?

Brian Scanlan: Nein, es war tatsächlich unterwegs. Ich war damals nüchtern. Als versucht wurde, dieses Subnetz zu unserem Netzwerk innerhalb von Amazon hinzuzufügen, die Automatisierung, die wir geschrieben haben … Wir verwenden ein Tool namens Terraform, um unsere Low-Level-Infrastruktur innerhalb von AWS zu verwalten, und wir hatten eine Reihe von Teammodulen – stellen Sie sich vor Es handelt sich um wiederverwendbaren Code, den wir geschrieben haben, um zu versuchen, eine Reihe von Infrastrukturen innerhalb von AWS mit allen Einstellungen und Dingen, die wir anwenden möchten, zu vereinfachen.

„Zu diesem Zeitpunkt, als die Konfiguration angewendet wurde, hatte sie unser Netzwerk vollständig zerstört oder offline geschaltet.“

Und so hat diese Automatisierung sehr gewissenhaft die Beschreibung des Subnetzes übernommen, das wir hinzufügen wollten. Aber zum Zeitpunkt der Anwendung lehnten die APIs von AWS es ab, weil es ein überlappendes IP-Subnetz gab, oder besser gesagt, das Subnetz, das konfiguriert wurde, überlappte mit einem bereits bestehenden. Und so gab der Terraform-Bewerbungsprozess an diesem Punkt einfach auf. Es hielt an. Was in einer Reihe von Fällen eine völlig vernünftige Sache ist. Aber leider bedeutete die Art und Weise, wie wir unser Terraform-Modul implementiert hatten, dass es alle Informationen über die in einem Subnetz vorhandenen Routing-Tabellen entfernte und sie wieder hinzufügte, während es alle diese Subnetze konfigurierte. Es wurden also praktisch alle Routen entfernt, über die ein Netzwerk weiß, wie es zum Internet und zu anderen Netzwerken gelangt, was ziemlich wichtig ist. Zu diesem Zeitpunkt, als die Konfiguration angewendet wurde, hatte sie unser Netzwerk vollständig zerstört oder offline geschaltet. Das ist nur der Anfang.

Jamie Osler: Ich meine, das ist schlecht, oder? Das ist nicht gut.

Brian Scanlan: Ja. Das hat Intercom also komplett offline geschaltet. Und dann dauerte es eine Weile, bis wir den Punkt erreichten, an dem wir zurückrollen konnten. Mit wir meine ich, nicht ich. Ich genoss meine Getränke zu diesem Zeitpunkt. Und so fand das Team einen Weg, in unsere Terraform-Bereitstellungsinfrastruktur einzusteigen und zur Konfigurationsänderung zurückzukehren.

„Herauszufinden, was um alles in der Welt passiert ist und wohin diese Daten gegangen sind, hat auch sehr, sehr lange gedauert. Wir reden hier von einem achtstündigen Ausfall.“

Aber leider kam in der Zwischenzeit eine andere Automatisierung zum Einsatz. Diesmal eine Automatisierung, die AWS gehörte. Wir verwenden diese Technologie namens OpsWorks, eine verwaltete Version von Chef, um unsere Elasticsearch-Hosts zu verwalten. Es hatte diese Funktionalität namens Auto-Healing eingebaut, die wir standardmäßig in unserer Konfiguration auf Host-Ebene aktiviert hatten. Und wenn die Hosts für das OpsWorks-Backend nicht erreichbar waren, versuchte das Workflow-System von OpsWorks, den betreffenden Host automatisch zu reparieren, weil es vermutete, dass dort etwas schief gelaufen war. Das Betriebssystem ist ausgefallen, vielleicht ist der Speicher ausgegangen – etwas Schlimmes ist passiert, also versuchen wir es zu beheben. Also entschied sich diese OpsWorks-Steuerungsebene, unsere gesamte Infrastruktur zu reparieren, indem sie die Hosts ersetzte.

Leider haben wir Elasticsearch ausgeführt und tun dies immer noch mit dem, was als flüchtiger Speicher bekannt ist. Das ist Host-basierter Speicher – wir verwenden kein magisches Cloud-basiertes System, das Ihre Daten in einem Drittanbietersystem oder von einem System außerhalb des Hosts speichert. Es ist nur auf einem physischen Host. Und wenn der physische Host zerstört wird, sind die Daten weg. Das ist also mit jedem einzelnen Elasticsearch-Host passiert. Jeder einzelne Elasticsearch-Cluster hat jedes einzelne Datenelement verloren, was ziemlich schlimm ist, da riesige Mengen von Intercom auf Elasticsearch aufbauen. Es ist nicht der primäre Datenspeicher. Wir neigen dazu, Daten für unsere Benutzer in einen Datenspeicher zu schreiben, wie beispielsweise DynamoDB, und kopieren diese Daten dann zur Suche nach Elasticsearch. Und wir können es wiederherstellen, aber der Prozess, all diese Daten über Backups zurückzubekommen und alle Änderungen seit unseren vorherigen Backups erneut durchführen zu müssen, hat sehr, sehr lange gedauert. Außerdem hat es sehr lange gedauert, herauszufinden, was in aller Welt passiert ist und wohin diese Daten gegangen sind. Wir sprechen hier von einem achtstündigen Ausfall.

„Wir haben nicht einfach gesagt: ‚Nun, jetzt wissen wir von diesen beiden Problemen, lasst uns diese lösen.' Wir gingen los und suchten nach anderen Arten von Automatisierungsbereichen, die uns in bizarren Situationen beißen könnten.“

Das war eine große Sache, weil es am späten Freitag passierte, es brauchte eine ganze Menge Leute, um die Dinge wieder stabil zu machen. Wir wussten irgendwie von diesen Problemen, dass wir unsere Elasticsearch-Cluster neu ansteuern oder neu füllen und kratzen mussten. Wir wussten nichts über einige der Gefahren, die in unserer eigenen Automatisierung und einigen der Automatisierung bei AWS schlummern.

Das war interessant, weil wir im Anschluss daran nicht einfach dachten: „Nun, jetzt wissen wir von diesen beiden Problemen, lasst uns diese beheben.“ Wir gingen los und suchten nach anderen Arten von Automatisierungsbereichen, die uns in bizarren Situationen beißen könnten. Letztendlich haben wir also eine Menge Dinge getan, um wirklich gut darin zu sein, Elasticsearch-Cluster aus verschiedenen Zuständen wiederherzustellen und Daten zu unterschiedlichen Zeiten in unsere Elasticsearch-Cluster zu übertragen, falls wir jemals in Verzug geraten oder ähnliche Katastrophensituationen haben sollten. Und wissen Sie, insgesamt haben wir viel aus diesem herrlich schlimmen Ausfall gelernt, und der Prozess war danach eigentlich ziemlich gut, was wir gelernt haben und wie wir diese Informationen verbreitet haben.

Patrick O'Doherty: Ich kann mich nicht erinnern, wer es war, aber ungefähr eine Stunde später dankte mir jemand dafür, dass ich diesen Vorfall verursacht hatte, weil er sagte: „Wow, du hast hier wirklich eine Menge Zeug aus dem Baum geschüttelt. Das wird eine wirklich unterhaltsame Reaktion auf Vorfälle.“ Das war im Grunde das Wesentliche. Es war wie: „Oh, wow. Wir graben hier Sachen aus.“ Und es war. Unsere Verwendung von Terraform und unsere allgemeine Reife in Bezug darauf, wie wir Tools verwenden, während wir uns bewusst sind, dass Tools uns auch verletzen können. Respektieren Sie Elektrowerkzeuge. Wie die Infrastruktur sind Elektrowerkzeuge gefährlich. Sie können sich schnell bewegen und Sie überraschen, und ich denke, wir haben an diesem Tag unsere Lektion gelernt.

Brian Scanlan: Ich habe auch so etwas wie ein Inside Intercom-Gespräch dabei. Außerdem war ich nicht bei dem Vorfall, weil ich an meinem Geburtstag in der Kneipe war. Es war toll. Es war der perfekte Zwischenfall.

Mit Lichtgeschwindigkeit

Liam Geraghty: Im Dezember 2020, einem Weihnachten, das wir sicher nie vergessen werden, kam Ciaran Lee, Mitbegründer von Intercom, zu Jamie, um über Geschwindigkeit zu sprechen und warum Ciaran Wert darauf legt, schnell zu sein.

Ciaran Lee: Ich bin ein extrem ungeduldiger Mensch. Das ist eine Sache. Wenn ich etwas schnell oder langsam machen kann, würde ich es persönlich lieber schnell machen. Intercom mag wie ein altes Unternehmen erscheinen, das auf 10 Jahre zugeht, aber ich glaube ehrlich gesagt, dass wir gerade erst anfangen. Wir haben so viel zu tun. Wir sind so ehrgeizig. Wir können uns ein Bild davon machen, was wir gerne sein würden, dieses All-in-One-Tool, das jeder mit einem Internetgeschäft nutzen kann, um mit seinen Kunden zu sprechen. Und da kratzen wir erst an der Oberfläche.

Eine Sache, die ich von Stripe, einem coolen Unternehmen, zu dem ich aufschaue, wirklich mag, war ein großartiger Blog-Beitrag von Patrick McKenzie, in dem er beschrieb, dass sie ihre Standard-Betriebskadenz auf „Run“ eingestellt haben. Sie handeln unbequem schnell und fragen immer, ob wir die Sache diese Woche schneller erledigen können als in sechs Monaten. Und das gefällt mir persönlich einfach sehr gut. Diese Einstellung hat uns sehr gut getan. Und ich denke, es ist eine lustige Sache, immer darüber nachzudenken. Kannst du schneller gehen?

„Es ist cool, wenn wir in einem Quartal eine hundertprozentige Verfügbarkeit erreichen, aber vielleicht sollten wir uns fragen: ‚Hey, sind wir nicht riskant genug?'“

Jamie Osler: Wenn Sie es für Ihr Unternehmen entscheidend machen, schnell zu gehen, und es etwas ist, was Sie die ganze Zeit tun, neigen Sie dazu, weniger zu brechen.

Ciaran Lee: Ja. Bewegen Sie sich schnell und brechen Sie Dinge innerhalb akzeptabler Parameter. Es ist in Ordnung, Ausfälle zu haben. Es ist in Ordnung, Fehler zu haben – natürlich möchten Sie bestimmte Kategorien von Fehlern weniger haben als andere, aber wir haben Verfügbarkeitsbudgets. Es ist cool, wenn wir in einem Quartal eine hundertprozentige Verfügbarkeit erreichen, aber vielleicht sollten wir uns fragen: „Hey, sind wir nicht riskant genug? Könnten wir etwas mehr Risiko eingehen, um schneller voranzukommen?“ Sie sollten sich an einem bewussten Punkt im Spektrum befinden. Und natürlich haben wir eine große Verantwortung. Wir haben viele Kunden, Hunderttausende von Menschen, die sich einloggen und deren Aufgabe es ist, unseren Posteingang zu nutzen, um jeden Tag mit ihren Kunden zu sprechen. Wir können nicht ihre Sachen kaputt machen, indem wir uns zu schnell bewegen oder sie so schnell ändern, dass sie nicht einmal mehr wissen, wie man sie benutzt. Das wäre falsch. Wir haben Einschränkungen, aber innerhalb dieser Einschränkungen sollten wir unbedingt so schnell wie möglich handeln.

Wo Recht kommt

Liam Geraghty: Und wir bewegen uns so schnell wie möglich durch diese Episode. Als nächstes, Intercom, Senior Counsel, Meena Polich. Meena ist Mitglied unseres Rechtsteams mit Schwerpunkt auf Produkt und Technik. Im Januar 2021 diskutierten Meena und Jamie darüber, wie Rechts- und Ingenieurteams zusammenarbeiten können.

„Wir sind hier, um mit dem Unternehmen und all unseren Kunden im Gleichschritt zu marschieren, um verantwortungsbewusst dorthin zu gelangen, wo wir hin müssen, ohne jemanden zu bremsen.“

Meena Polich: Uns ist es sehr wichtig, das Produkt zu verstehen. Wie können wir das Unternehmen möglicherweise darüber beraten, welche Vorschriften uns betreffen oder welche Gesetze wir befolgen müssen, wenn wir nicht wirklich verstehen, was wir verkaufen? Auf einer sehr grundlegenden Ebene, aus strategischer Sicht, müssen wir nicht nur verstehen, was wir jetzt verkaufen, sondern auch, was wir verkaufen wollen und wie wir uns positionieren und wachsen wollen. Auf diese Weise können wir mit der Erstellung von Projektionen der Dinge beginnen, die wir aus rechtlicher Sicht im Auge behalten müssen. Und wir müssen nur sicherstellen, dass wir hier gewissermaßen im Gleichschritt mit dem Unternehmen und all unseren Kunden marschieren, um verantwortungsbewusst dorthin zu gelangen, wo wir hin müssen, ohne jemanden zu bremsen. Bei einem eher taktischen Ansatz ist das Verständnis der Unternehmenswerte und des Produkts äußerst hilfreich für Verhandlungen mit Kunden und sogar Lieferanten. Es bringt mich in eine viel bessere Position, wenn ich verstehe, was wir zu tun versuchen. Und dann kann ich unseren Lieferanten erklären: „Weil wir das versuchen, brauchen wir Sie, um dies tun zu können.“

Umgekehrt, wenn ich mit Kunden verhandle, sind die Leute auf der anderen Seite des Tisches oft andere Anwälte oder Einkäufer, die genauso technisch, wenn nicht weniger, sind als ich. In der Lage zu sein, die Funktionsweise des Produkts als Anwalt zu erklären, der sagt: „Schauen Sie, ich weiß, was Ihre Bedenken aus Sicht des rechtlichen Risikomanagements sind, aber so funktioniert die Plattform tatsächlich. So funktioniert das Produkt tatsächlich in der Praxis. Und deshalb wird es nicht auf dieses Risiko hinweisen, über das Sie sich Sorgen machen. Es wird nicht das Risiko auslösen, über das Sie sich Sorgen machen.“

„Meine erste Priorität ist es, der Forschung und Entwicklung zu helfen, zu verstehen, dass ich nicht hier bin, um die erstaunlichen Fortschritte, die wir machen, zunichte zu machen.“

Jamie Osler: Ich denke, das funktioniert in beide Richtungen, richtig? Wenn F&E ein besseres Verständnis der Art von rechtlicher Übersicht auf hoher Ebene darüber hat, wo die Problembereiche liegen könnten, hilft es ihnen, zu vermeiden, dass sie unbeabsichtigt Dinge tun oder Produkte herstellen, die riskant sind oder gegen diese Gesetze verstoßen.

Meena Polich: Ja, absolut. Und das ist das Wichtigste, was Sie mitnehmen oder sich darauf konzentrieren sollten, während Sie die rechtliche Beziehung zu F&E aufbauen. Meine erste Priorität ist es, der Forschung und Entwicklung zu helfen, zu verstehen, dass ich nicht hier bin, um die erstaunlichen Fortschritte, die wir machen, zunichte zu machen, und mein Team nicht hier ist, um uns daran zu hindern, weiterhin mit hervorragenden Produkten auf den Markt zu gehen. Unser Team ist hier, um sicherzustellen, dass wir, während wir wachsen und es schwieriger wird, alles, was jeder Einzelne im Unternehmen tut, im Auge zu behalten, dies weiterhin ethisch und innerhalb der Grenzen des Gesetzes tun. Und wenn wir können, versuchen wir, dieses Risiko zu managen.

Das ist einer der Gründe, warum Compliance by Design so wichtig ist. Wenn wir die Compliance-Anforderungen oder Compliance-Erwartungen im Auge behalten und darauf abzielen, werden die Designänderungen, die wir vornehmen, oft Dinge sein, die unserem Endergebnis tatsächlich zugute kommen würden. Es mag anfängliche Kosten in Bezug auf die Ressourcenzuweisung geben, aber auf lange Sicht, und nicht einmal auf sehr lange Sicht – in vielen Fällen innerhalb von sechs Monaten bis zu einem Jahr nach der Veröffentlichung dieser Funktion – werden wir einen unglaublichen Nutzen sehen in Bezug auf das Umsatzwachstum und die Arten von Leads, die wir generiert haben, und die Gewinnung von Kunden, weil sie uns vertrauen werden.

Liam Geraghty: Mein Dank geht an Jamie Osler, der Engineer Chats erstellt hat, an seinen neuen Host Brian Scanlan und an alle heutigen Gäste, die uns freundlicherweise erlaubt haben, ihre internen Chats extern zu platzieren. Wenn Ihnen die heutige Show gefallen hat, hinterlassen Sie uns doch eine Bewertung oder loben Sie uns in den sozialen Medien. Wir lieben es zu sehen und zu hören, was Sie denken. Das ist alles für heute. Wir werden nächste Woche mit einer weiteren Episode von Inside Intercom zurück sein.