Charity Majors, CTO & Co-Founder bei Honeycomb – Interview-Serie

Charity ist eine Ops-Engineerin und zufällige Startup-Gründerin bei Honeycomb. Vorher arbeitete sie bei Parse, Facebook (META ) und Linden Lab an Infrastruktur und Entwicklungstools und landete immer wieder bei der Verwaltung von Datenbanken. Sie ist Co-Autorin von O’Reillys Database Reliability Engineering und liebt freie Rede, freie Software und Single-Malt-Whiskey.

Sie waren über 2 Jahre lang Production Engineering Manager bei Facebook (jetzt Meta), was waren einige Ihrer Highlights aus dieser Zeit und was sind einige Ihrer wichtigsten Erkenntnisse aus dieser Erfahrung?

Ich arbeitete an Parse, das eine Backend für mobile Apps war, ähnlich wie Heroku für mobile Apps. Ich war nie daran interessiert, für ein großes Unternehmen zu arbeiten, aber wir wurden von Facebook übernommen. Eine meiner wichtigsten Erkenntnisse war, dass Übernahmen wirklich, wirklich schwer sind, selbst unter den besten Umständen. Der Rat, den ich anderen Gründern jetzt gebe, ist: Wenn Sie übernommen werden sollen, stellen Sie sicher, dass Sie einen Exekutiv-Sponsor haben und gründlich überlegen, ob Sie eine strategische Ausrichtung haben. Facebook übernahm Instagram nicht lange vor der Übernahme von Parse, und die Übernahme von Instagram war nicht gerade ein reibungsloser Prozess, aber letztendlich sehr erfolgreich, weil sie eine strategische Ausrichtung und einen starken Sponsor hatten.

Ich hatte es nicht leicht bei Facebook, aber ich bin sehr dankbar für die Zeit, die ich dort verbracht habe; ich weiß nicht, ob ich ein Unternehmen hätte gründen können, ohne die Lektionen, die ich über Organisationsstruktur, Management, Strategie usw. gelernt habe. Es hat mir auch einen Ruf verschafft, der mich für VCs attraktiv machte, die mir vorher keine Beachtung geschenkt hatten. Ich bin ein bisschen verärgert darüber, aber ich werde es trotzdem tun.

Können Sie die Genesis-Geschichte hinter der Gründung von Honeycomb teilen?

Definitiv. Aus architektonischer Sicht war Parse seiner Zeit voraus – wir verwendeten Microservices, bevor es Microservices gab, wir hatten eine massiv fragmentierte Datenlage und als Plattform, die über eine Million mobile Apps bediente, hatten wir viele komplizierte Multi-Tenant-Probleme. Unsere Kunden waren Entwickler, und sie schrieben und luden ständig willkürliche Code-Snippets und neue Abfragen von, sagen wir, “unterschiedlicher Qualität” – und wir mussten all das einfach aufnehmen und zum Laufen bringen, irgendwie.

Wir waren an der Spitze einer Reihe von Veränderungen, die seitdem zum Mainstream geworden sind. Früher waren die meisten Architekturen ziemlich einfach, und sie versagten wiederholt auf vorhersehbare Weise. Sie hatten eine Web-Schicht, eine Anwendung und eine Datenbank, und die meisten Komplexitäten waren in der Anwendungs-Code gebunden. Also schrieben Sie Überwachungs-Checks, um nach diesen Fehlern zu suchen, und konstruierten statische Dashboards für Ihre Metriken und Überwachungsdaten.

Die Branche hat in den letzten 10 Jahren eine Explosion an architektonischer Komplexität erlebt. Wir haben den Monolithen gesprengt, also haben Sie jetzt zwischen mehreren Diensten und Tausenden von Anwendungs-Microservices. Polyglotte Persistenz ist die Norm; anstelle von “der Datenbank” ist es normal, viele verschiedene Speichertypen sowie horizontale Fragmentierung, Caching-Schichten, db-pro-Microservice, Queueing und mehr zu haben. Dazu kommen Server-seitige gehostete Container, Drittanbieter-Dienste und -Plattformen, serverlose Code, Block-Speicher und mehr.

Der harte Teil war früher das Debuggen Ihres Codes; jetzt ist der harte Teil, herauszufinden, wo im System der Code ist, den Sie debuggen müssen. Anstelle von wiederholtem Versagen auf vorhersehbare Weise ist es wahrscheinlicher, dass jedes Mal, wenn Sie einen Pager erhalten, es um etwas geht, das Sie noch nie gesehen haben und vielleicht nie wieder sehen werden.

Das Debuggen dieser Probleme von Grund auf ist unglaublich schwer. Mit Protokollen und Metriken müssen Sie基本 wissen, wonach Sie suchen, bevor Sie es finden können. Aber wir begannen, einige Datensätze in ein FB-Tool namens Scuba zu füttern, das es uns ermöglichte, auf willkürlichen Dimensionen und hochkardinalen Daten in Echtzeit zu schneiden und zu drehen, und die Zeit, die es uns brauchte, um diese Probleme von Grund auf zu identifizieren und zu lösen, sank wie ein Stein, von Stunden auf… Minuten? Sekunden? Es war nicht einmal mehr ein Ingenieurproblem, es war ein Support-Problem. Sie konnten einfach der Spur der Brotkrümel zum Antworten folgen, jedes Mal, wenn Sie klickten.

Es war atemberaubend. Diese massive Quelle der Unsicherheit und der Mühe und unglücklichen Kunden und 2-Uhr-Pager… einfach weg. Es war nicht, bis Christine und ich Facebook verließen, dass uns bewusst wurde, wie sehr es unsere Art und Weise, mit Software umzugehen, verändert hatte. Die Vorstellung, zu den alten schlechten Zeiten der Überwachung und Dashboards zurückzukehren, war einfach unvorstellbar.

Aber zu diesem Zeitpunkt dachten wir ehrlich, dass dies eine Nischenlösung sein würde – dass es ein Problem löste, das andere massive Multi-Tenant-Plattformen haben könnten. Es war nicht, bis wir fast ein Jahr lang aufgebaut hatten, dass wir begannen, zu realisieren, dass, oh Mann, dies tatsächlich zu einem Jeder-Problem wird.

Für Leser, die nicht vertraut sind, was ist genau eine Observability-Plattform und wie unterscheidet sie sich von traditioneller Überwachung und Metriken?

Traditionelle Überwachung hat drei Säulen: Metriken, Protokolle und Spuren. Sie benötigen normalerweise viele Tools, um Ihre Bedürfnisse zu erfüllen: Protokollierung, Spuren, APM, RUM, Dashboarding, Visualisierung usw. Jedes davon ist für einen anderen Anwendungsfall in einem anderen Format optimiert. Als Ingenieur sitzen Sie in der Mitte davon und versuchen, all dies zu verstehen. Sie scannen durch Dashboards, um visuelle Muster zu finden, Sie kopieren und fügen IDs aus Protokollen in Spuren und zurück ein. Es ist sehr reaktiv und stückweise, und normalerweise beziehen Sie sich auf diese Tools, wenn Sie ein Problem haben – sie sind dazu gedacht, Ihnen zu helfen, Ihren Code zu betreiben und Fehler und Fehler zu finden.

Moderne Observability hat eine einzige Wahrheitsquelle; willkürlich breite strukturierte Protokoll-Ereignisse. Aus diesen Ereignissen können Sie Ihre Metriken, Dashboards und Protokolle ableiten. Sie können sie über die Zeit als Spur visualisieren, Sie können schneiden und drehen, Sie können in einzelne Anfragen hineinzoomen und auf die lange Sicht hinauszoomen. Weil alles verbunden ist, müssen Sie nicht von Tool zu Tool springen, raten oder auf Intuition vertrauen. Moderne Observability ist nicht nur darum, wie Sie Ihre Systeme betreiben, sondern auch darum, wie Sie Ihren Code entwickeln. Es ist die Grundlage, die es ermöglicht, leistungsstarke, enge Feedback-Schleifen zu verbinden, die Ihnen helfen, vielen Wert für Benutzer zu liefern, schnell, mit Zuversicht und finden Probleme, bevor Ihre Benutzer sie finden.

Sie sind bekannt dafür, dass Observability eine einzige Wahrheitsquelle in ingenieurtechnischen Umgebungen bietet. Wie integriert sich AI in diese Vision ein, und was sind die Vorteile und Herausforderungen in diesem Zusammenhang?

Observability ist wie das Anziehen von Brillen, bevor Sie auf die Autobahn fahren. Testgetriebene Entwicklung (TDD) revolutionierte die Software in den frühen 2000er Jahren, aber TDD verliert an Wirksamkeit, je mehr Komplexität in unseren Systemen anstelle von nur unserer Software liegt. Immer mehr müssen Sie, wenn Sie die Vorteile von TDD nutzen wollen, tatsächlich Ihren Code instrumentieren und etwas Ähnliches wie Observability-getriebene Entwicklung (ODD) durchführen, wo Sie instrumentieren, während Sie gehen, schnell bereitstellen, dann Ihren Code in der Produktion durch die Linse der Instrumentierung, die Sie gerade geschrieben haben, betrachten und sich fragen: “Macht es das, was ich erwartet habe, und sieht alles andere… seltsam aus?”

Tests allein sind nicht genug, um zu bestätigen, dass Ihr Code das tut, was er tun soll. Sie wissen es nicht, bis Sie es in der Produktion beobachtet haben, mit echten Benutzern auf echter Infrastruktur.

Diese Art der Entwicklung – die die Produktion in schnelle Feedback-Schleifen einschließt – ist (zumindest ein bisschen kontraintuitiv) viel schneller, einfacher und einfacher als das Verlassen auf Tests und langsamere Bereitstellungszyklen. Sobald Entwickler auf diese Weise gearbeitet haben, sind sie berühmt dafür, nicht zu diesem alten, langsamen Weg zurückkehren zu wollen.

Was mich an AI begeistert, ist, dass, wenn Sie mit LLMs entwickeln, Sie in der Produktion entwickeln müssen. Die einzige Möglichkeit, eine Reihe von Tests abzuleiten, ist, Ihren Code zuerst in der Produktion zu validieren und rückwärts zu arbeiten. Ich denke, dass das Schreiben von Software, die von LLMs unterstützt wird, so gemeinsam sein wird wie das Schreiben von Software, die von MySQL oder Postgres unterstützt wird, in ein paar Jahren, und meine Hoffnung ist, dass dies Ingenieure in eine bessere Lebensweise zwingt.

Sie haben Bedenken hinsichtlich der zunehmenden technischen Schulden aufgrund der AI-Revolution geäußert. Können Sie die Arten von technischen Schulden erläutern, die AI einführen kann, und wie Honeycomb dabei hilft, diese Schulden zu verwalten oder zu mindern?

Ich bin besorgt über technische Schulden und vielleicht noch mehr über organisatorische Schulden. Eine der schlimmsten Arten von technischen Schulden ist, wenn Sie Software haben, die von niemandem gut verstanden wird. Was bedeutet, dass jeder, der sie erweitern oder ändern muss, oder debuggen oder reparieren muss, die harte Arbeit leisten muss, sie zu lernen.

Und wenn Sie Code in die Produktion bringen, den niemand versteht, gibt es eine gute Chance, dass er nicht so geschrieben wurde, dass er verständlich ist. Guter Code ist geschrieben, um leicht lesbar und verständlich zu sein und zu erweitern. Er verwendet Konventionen und Muster, er verwendet konsistente Benennung und Modularisierung, er findet ein Gleichgewicht zwischen DRY und anderen Überlegungen. Die Qualität des Codes ist untrennbar von der Frage, wie leicht es für Menschen ist, mit ihm zu interagieren. Wenn wir einfach Code in die Produktion bringen, weil er compiliert oder Tests besteht, erstellen wir ein riesiges Eisberg von zukünftigen technischen Problemen für uns selbst.

Wenn Sie sich entschieden haben, Code zu versenden, den niemand versteht, kann Honeycomb nicht helfen. Aber wenn Sie sich um saubere, iterierbare Software kümmern, sind Instrumentierung und Observability absolut entscheidend für diesen Versuch. Instrumentierung ist wie Dokumentation plus Echtzeit-Zustandsberichterstattung. Instrumentierung ist die einzige Möglichkeit, wirklich zu bestätigen, dass Ihre Software das tut, was Sie erwarten, und sich so verhält, wie Ihre Benutzer es erwarten.

Wie nutzt Honeycomb AI, um die Effizienz und Effektivität von Ingenieur-Teams zu verbessern?

Unsere Ingenieure nutzen AI intern sehr, insbesondere CoPilot. Unsere jüngeren Ingenieure berichten, dass sie ChatGPT jeden Tag verwenden, um Fragen zu beantworten und ihnen zu helfen, die Software zu verstehen, die sie bauen. Unsere erfahrenen Ingenieure sagen, es sei großartig, um Software zu generieren, die sehr mühsam oder ärgerlich zu schreiben wäre, wie wenn Sie eine riesige YAML-Datei ausfüllen müssen. Es ist auch nützlich, um Code-Snippets in Sprachen zu generieren, die Sie normalerweise nicht verwenden, oder aus API-Dokumentationen. Zum Beispiel können Sie sehr gute, verwendbare Beispiele von Dingen generieren, die mit den AWS-SDKs und -APIs verwendet werden, da es auf Repos trainiert wurde, die eine reale Verwendung dieses Codes haben.

Jedes Mal, wenn Sie jedoch AI verwenden, um Ihren Code zu generieren, müssen Sie ihn zeilenweise durchgehen, um sicherzustellen, dass er das Richtige tut, denn er wird absolut regelmäßig Unsinn halluzinieren.

Können Sie Beispiele dafür geben, wie AI-gesteuerte Funktionen wie Ihr Abfrage-Assistent oder die Slack-Integration die Teamzusammenarbeit verbessern?

Ja, definitiv. Unser Abfrage-Assistent ist ein großartiges Beispiel. Die Verwendung von Abfrage-Generatoren ist kompliziert und schwierig, sogar für Power-User. Wenn Sie Hunderte oder Tausende von Dimensionen in Ihrer Telemetrie haben, können Sie sich nicht immer merken, was die wertvollsten sind. Und selbst Power-User vergessen die Details davon, wie man bestimmte Arten von Grafiken generiert.

Unser Abfrage-Assistent ermöglicht es Ihnen, Fragen in natürlicher Sprache zu stellen. Zum Beispiel “Was sind die langsamsten Endpunkte?” oder “Was passierte nach meinem letzten Deploy?” und er generiert eine Abfrage und legt Sie hinein. Die meisten Leute finden es schwierig, eine neue Abfrage von Grund auf zu komponieren und leicht, eine bestehende zu bearbeiten, also gibt es Ihnen einen Vorteil.

Honeycomb verspricht eine schnellere Lösung von Vorfällen. Können Sie beschreiben, wie die Integration von Protokollen, Metriken und Spuren in einen einheitlichen Datentyp die schnelle Fehlersuche und Problemlösung unterstützt?

Alles ist verbunden. Sie müssen nicht raten. Anstelle von dem, dass Sie das Dashboard betrachten und denken, dass es die gleiche Form wie das andere Dashboard hat, oder raten, dass dieser Spike in Ihren Metriken der gleiche ist wie dieser Spike in Ihren Protokollen aufgrund von Zeitstempeln… stattdessen ist die Daten verbunden. Sie müssen nicht raten, Sie können einfach fragen.

Daten werden durch Kontext wertvoll. Die letzte Generation von Tools arbeitete, indem sie alle Kontexte zur Schreibzeit entfernte; sobald Sie den Kontext entfernt haben, können Sie ihn nie wieder zurückbekommen.

Außerdem: Mit Protokollen und Metriken müssen Sie wissen, wonach Sie suchen, bevor Sie es finden können. Das ist nicht wahr für moderne Observability. Sie müssen nichts wissen, oder suchen.

Wenn Sie diese reichen kontextuellen Daten speichern, können Sie Dinge damit tun, die wie Magie wirken. Wir haben ein Tool namens BubbleUp, mit dem Sie einen Bubble um alles ziehen können, das Sie seltsam oder interessant finden, und wir berechnen alle Dimensionen innerhalb des Bubbles gegenüber dem Außenbereich, der Basis, und sortieren und differenzieren sie. Also sind Sie wie “dieser Bubble ist seltsam” und wir sagen Ihnen sofort, “es ist anders in xyz-Wegen”. So viel von Fehlersuche lässt sich auf “hier ist etwas, worüber ich mir Sorgen mache, aber warum mache ich mir Sorgen darüber?” reduzieren. Wenn Sie sofort erkennen können, dass es anders ist, weil diese Anfragen von Android-Geräten kommen, mit dieser bestimmten Build-ID, mit dieser Sprachpakete, in dieser Region, mit dieser App-ID, mit einer großen Nutzlast… bis jetzt wissen Sie wahrscheinlich genau, was falsch ist und warum.

Es geht nicht nur um die einheitlichen Daten, sondern auch darum, wie mühelos wir hochkardinalen Daten wie eindeutigen IDs, Warenkorb-IDs, App-IDs, Vornamen und Nachnamen usw. handhaben. Die letzte Generation von Tools kann nicht mit reichen Daten wie diesen umgehen, was unglaublich ist, wenn man darüber nachdenkt, dass reiche, hochkardiale Daten die wertvollsten und identifizierbaren Daten überhaupt sind.

Wie übersetzt sich die Verbesserung der Observability in bessere Geschäftsergebnisse?

Dies ist einer der anderen großen Wechsel von der letzten Generation zu der neuen Generation von Observability-Tools. In der Vergangenheit waren System-, Anwendungs- und Geschäftdaten alle in separate Tools unterteilt. Dies ist absurd – jede interessante Frage, die Sie über moderne Systeme stellen möchten, hat Elemente von allen drei.

Observability ist nicht nur darum, Fehler oder Ausfälle zu vermeiden. Es geht darum, sicherzustellen, dass wir an den richtigen Dingen arbeiten, dass unsere Benutzer eine großartige Erfahrung haben, dass wir die Geschäftsergebnisse erreichen, die wir anstreben. Es geht darum, Wert zu schaffen, nicht nur zu betreiben. Wenn Sie nicht sehen, wohin Sie gehen, können Sie nicht schnell und sicher navigieren und können nicht schnell korrigieren. Je mehr Sichtbarkeit Sie in das haben, was Ihre Benutzer mit Ihrem Code tun, desto besser und stärker können Sie als Ingenieur sein.

Wohin sehen Sie die Zukunft der Observability gehen, insbesondere im Hinblick auf AI-Entwicklungen?

Observability ist zunehmend darum, Teams zu ermöglichen, enge, schnelle Feedback-Schleifen zu verbinden, damit sie schnell, mit Zuversicht und in der Produktion entwickeln können und weniger Zeit und Energie verschwenden.

Es geht darum, die Verbindung zwischen Geschäftsergebnissen und technischen Methoden herzustellen.

Und es geht darum, sicherzustellen, dass wir die Software, die wir in die Welt setzen, verstehen. Je komplexer Software und Systeme werden, und insbesondere, wenn AI immer mehr im Spiel ist, desto wichtiger ist es, dass wir uns an einem menschlichen Standard für Verständnis und Handhabbarkeit messen lassen.

Von einem Observability-Standpunkt aus werden wir zunehmend komplexere Daten-Pipelines sehen – mit maschinellem Lernen und raffinierten Sampling-Techniken, um Wert gegen Kosten auszugleichen, um so viel Detail wie möglich über Ausreißer-Ereignisse und wichtige Ereignisse zu speichern und Zusammenfassungen des Restes so billig wie möglich zu speichern.

AI-Anbieter machen viele überhitzte Behauptungen darüber, wie sie Ihre Software besser verstehen können als Sie selbst oder wie sie die Daten verarbeiten und Ihren Menschen sagen können, welche Aktionen sie ausführen sollen. Von allem, was ich gesehen habe, ist dies ein teurer Traum. Falsch-Positives sind unglaublich teuer. Es gibt keinen Ersatz für das Verständnis Ihrer Systeme und Ihrer Daten. AI kann Ihren Ingenieuren dabei helfen! Aber es kann Ihre Ingenieure nicht ersetzen.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Honeycomb besuchen.