Charity Majors, CTO & Co-Founder at Honeycomb – Interview Series

Charity ist eine Ops-Engineerin und zufällige Startup-Gründerin bei Honeycomb. Vorher arbeitete sie bei Parse, Facebook und Linden Lab an Infrastruktur und Entwickler-Tools und landete immer wieder bei der Verwaltung von Datenbanken. Sie ist Co-Autorin von O’Reilly’s Database Reliability Engineering und liebt freie Meinungsäußerung, 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 habe an Parse gearbeitet, das eine Backend für mobile Apps war, ähnlich wie Heroku für mobile Apps. Ich war nie daran interessiert, in einem großen 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 immer gebe, ist: Wenn Sie übernommen werden, stellen Sie sicher, dass Sie einen Exekutiv-Sponsor haben und überlegen Sie sich gut, ob Sie eine strategische Ausrichtung haben. Facebook hat Instagram nicht lange vor der Übernahme von Parse übernommen, und die Übernahme von Instagram war nicht gerade ein Spaziergang, aber letztendlich war sie sehr erfolgreich, weil sie eine strategische Ausrichtung und einen starken Sponsor hatten.

Ich hatte keine leichte Zeit 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 zu lernen, die ich über organisatorische Struktur, 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 Entstehungsgeschichte hinter der Gründung von Honeycomb teilen?

Auf jeden Fall. Aus architektonischer Sicht war Parse seiner Zeit voraus – wir haben Microservices verwendet, bevor es Microservices gab, wir hatten eine massiv shardierte Datenlage und als Plattform, die über eine Million mobile Apps bediente, hatten wir viele wirklich komplizierte Multi-Tenancy-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” hoch – und wir mussten einfach alles aufnehmen und es irgendwie zum Laufen bringen.

Wir waren an der Spitze einer Reihe von Veränderungen, die seitdem zum Mainstream geworden sind. Es gab früher eine Explosion an architektonischer Komplexität. Wir haben den Monolithen gesprengt, so dass Sie jetzt zwischen mehreren Diensten und Tausenden von Anwendungs-Microservices haben. Polyglot Persistence ist die Norm; anstelle von “der Datenbank” ist es normal, viele verschiedene Speichertypen sowie horizontale Sharding, Caching-Schichten, db-per-Microservice, Queueing und mehr zu haben. Dazu kommen serverseitige Container, Drittanbieter-Dienste und -Plattformen, serverlose Code, Block-Speicher und mehr.

Das Schwierige war früher, Ihren Code zu debuggen; jetzt ist das Schwierige, herauszufinden, wo im System der Code ist, den Sie debuggen müssen. Anstelle von wiederholten, vorhersehbaren Fehlern ist es wahrscheinlicher, dass jedes Mal, wenn Sie einen Anruf 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 Logs und Metriken müssen Sie基本 wissen, wonach Sie suchen, bevor Sie es finden können. Aber wir haben einige Datenmengen in ein FB-Tool namens Scuba eingespeist, das es uns ermöglichte, auf beliebige Dimensionen und hochkardinale 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 kein Ingenieurproblem mehr, es war ein Support-Problem. Sie konnten einfach der Spur der Brotkrümel zum Antworten folgen, jedes Mal, wenn Sie klickten.

Können Sie unseren Lesern, die nicht vertraut sind, erklären, was genau eine Observability-Plattform ist und wie sie sich von traditionellem Monitoring und Metriken unterscheidet?

Traditionelles Monitoring hat berühmterweise drei Säulen: Metriken, Logs und Spuren. Sie benötigen normalerweise viele Tools, um Ihre Bedürfnisse zu erfüllen: Logging, Tracing, 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 Dashboards, um visuelle Muster zu finden, Sie kopieren und fügen IDs von Logs zu 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 dafür ausgelegt, Ihnen zu helfen, Ihren Code zu betreiben und Fehler zu finden.

Moderne Observability hat eine einzige Quelle der Wahrheit; beliebig breite strukturierte Log-Ereignisse. Aus diesen Ereignissen können Sie Ihre Metriken, Dashboards und Logs ableiten. Sie können sie über die Zeit als Spur visualisieren, Sie können sie schneiden und drehen, Sie können in einzelne Anfragen hineinzoomen und aus der langen Sicht herauszoomen. Weil alles miteinander verbunden ist, müssen Sie nicht zwischen Tools hin- und herspringen, raten oder auf Intuition vertrauen. Moderne Observability ist nicht nur dafür da, wie Sie Ihre Systeme betreiben, sondern auch, wie Sie Ihren Code entwickeln. Es ist das Substrat, das es Ihnen ermöglicht, leistungsstarke, enge Feedback-Schleifen zu verbinden, die Ihnen helfen, viele Werte für Benutzer schnell, mit Zuversicht und vor Ihren Benutzern zu liefern.

Sie sind bekannt dafür, dass Observability eine einzige Quelle der Wahrheit in Ingenieuren-Umgebungen bietet. Wie integriert sich AI in diese Vision ein, und was sind die Vorteile und Herausforderungen in diesem Kontext?

Observability ist wie das Aufsetzen Ihrer Brille, bevor Sie auf die Autobahn fahren. Testgetriebene Entwicklung (TDD) revolutionierte die Software in den frühen 2000er Jahren, aber TDD hat an Effektivität verloren, je mehr Komplexität in unseren Systemen anstelle von nur unserer Software liegt. Immer öfter müssen Sie, wenn Sie die Vorteile von TDD nutzen wollen, tatsächlich Ihren Code instrumentieren und etwas Ähnliches wie observability-getriebene Entwicklung oder ODD durchführen, bei der Sie instrumentieren, während Sie gehen, schnell bereitstellen und dann Ihren Code im Produktionsumfeld durch die Linse der Instrumentierung, die Sie gerade geschrieben haben, betrachten und sich fragen: “Macht es das, was ich erwarte, und sieht etwas anderes… seltsam aus?”

Haben Sie Bedenken hinsichtlich der anwachsenden technischen Schulden aufgrund der AI-Revolution. Könnten 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 mache mir Sorgen ü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 wirklich 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.

Wenn Sie Code in die Produktion bringen, den niemand versteht, gibt es eine sehr gute Chance, dass er nicht so geschrieben wurde, dass er verständlich ist. Guter Code ist so geschrieben, dass er leicht zu lesen und zu verstehen ist und erweitert werden kann. Er verwendet Konventionen und Muster, er verwendet konsistente Benennung und Modularisierung, er findet einen Ausgleich zwischen DRY und anderen Überlegungen. Die Qualität des Codes ist untrennbar von der Leichtigkeit, mit der Menschen mit ihm interagieren können. Wenn wir einfach Code in die Produktion bringen, weil er compiliert oder Tests besteht, erstellen wir eine massive Eisberg zukünftiger technischer Probleme für uns selbst.

Wenn Sie sich entschieden haben, Code zu versenden, den niemand versteht, kann Honeycomb Ihnen nicht dabei helfen. Aber wenn Sie sich um saubere, iterierbare Software kümmern, sind Instrumentierung und Observability absolut unerlässlich für diese Bemühungen. Instrumentierung ist wie Dokumentation plus Echtzeit-Zustandsberichterstattung. Instrumentierung ist die einzige Möglichkeit, um 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 stark, 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 große 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 mit AWS-SDKs und -APIs einige wirklich großartige, verwendbare Beispiele generieren, da es auf Repos trainiert wurde, die reale Verwendung dieses Codes haben.

Jedes Mal, wenn Sie jedoch AI generieren lassen, müssen Sie es zeilenweise durchgehen, um sicherzustellen, dass es das Richtige tut, denn es wird absolut Unsinn erfinden.

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

Ja, auf jeden Fall. 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, wie die wertvollsten davon heißen. Und sogar Power-User vergessen die Details darüber, wie man bestimmte Arten von Graphen generiert.

Unser Abfrage-Assistent ermöglicht es Ihnen, Fragen in natürlicher Sprache zu stellen. Zum Beispiel: “Was sind die langsamsten Endpunkte?” oder “Was ist passiert, nachdem ich meine letzte Bereitstellung durchgeführt habe?” und er generiert eine Abfrage und legt Sie direkt 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 Logs, Metriken und Spuren in einen einheitlichen Datentyp die schnelle Fehlersuche und Problemlösung unterstützt?

Alles ist miteinander verbunden. Sie müssen nicht raten. Anstelle von visuellen Mustern auf Dashboards oder dem Versuch, Spike in Metriken und Logs basierend auf Zeitstempeln zu erraten… stattdessen ist die Datenmenge miteinander verbunden. Sie müssen nicht raten, Sie können einfach fragen.

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

Außerdem: Mit Logs und Metriken müssen Sie wissen, wonach Sie suchen, bevor Sie es finden können. Das ist nicht der Fall bei moderner 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 zeichnen können, was Sie seltsam oder interessant finden, und wir berechnen alle Dimensionen innerhalb des Bubbles im Vergleich zum Rest, zur 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 Fehlersuche lässt sich auf “Hier ist etwas, worüber ich mir Sorgen mache, aber warum mache ich mir Sorgen?” reduzieren. Wenn Sie sofort erkennen können, dass es anders ist, weil diese Anfragen von Android-Geräten kommen, mit diesem 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, obwohl das ein großer Teil davon ist. Es geht auch darum, wie mühelos wir hochkardinale Daten wie eindeutige IDs, Einkaufswagen-IDs, App-IDs, Vor- und Nachnamen usw. handhaben. Die letzte Generation von Tooling kann solche reichen Daten nicht handhaben, was unglaublich ist, wenn man darüber nachdenkt, weil reiche, hochkardinale Daten die wertvollsten und identifizierbaren Daten von allen sind.

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

Dies ist einer der anderen großen Wechsel von der Vergangenheit zur neuen Generation von Observability-Tooling. In der Vergangenheit waren System-, Anwendungs- und Geschäftsdaten 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 für Bugs, Ausfälle oder Ausfallzeiten da. 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 sehr schnell vorankommen 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 daran, 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 Punkte zwischen Geschäftsergebnissen und technologischen Methoden zu verbinden.

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

Aus der Perspektive der Observability werden wir zunehmend komplexere Datenpipelines sehen – mit maschinellem Lernen und sophisticateden Sampling-Techniken, um Wert vs. Kosten auszugleichen, um so viel Detail wie möglich über Outlier-Ereignisse und wichtige Ereignisse zu speichern und Zusammenfassungen des Restes so günstig 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. Aus 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.