Vorwort
In den letzten Jahren ist der Begriff "Beobachtbarkeit" aus dem Nischendasein der Systemtechnik in den allgemeinen Sprachgebrauch der Softwareentwicklung übergegangen. In dem Maße, in dem dieser Begriff an Bedeutung gewann, erlitt er auch das (leider unvermeidliche) Schicksal, austauschbar mit einem anderen Begriff verwendet zu werden, mit dem er eine gewisse Verwandtschaft hat: "Monitoring".
Was dann folgte, war ebenso unvermeidlich wie unglücklich: Überwachungs-Tools und -Anbieter begannen, dieselbe Sprache und dasselbe Vokabular zu übernehmen und zu verwenden wie diejenigen, die versuchten, die philosophischen, technischen und soziotechnischen Grundlagen der Beobachtbarkeit von denen der Überwachung zu unterscheiden. Diese Vermischung der Begriffe war, gelinde gesagt, nicht besonders hilfreich. Es bestand die Gefahr, dass "Beobachtbarkeit" und "Überwachung" zu einem homogenen Konstrukt verschmolzen wurden, was es noch schwieriger machte, sinnvolle, differenzierte Gespräche über die Unterschiede zu führen.
Den Unterschied zwischen Überwachung und Beobachtbarkeit als rein semantisch zu betrachten, ist ein Irrglaube. Beobachtbarkeit ist kein rein technisches Konzept, das durch den Kauf eines "Beobachtungstools" (egal, was irgendein Anbieter behauptet) oder durch die Übernahme des aktuellen offenen Standards erreicht werden kann. Im Gegenteil, Beobachtbarkeit ist eher ein soziotechnisches Konzept. Die erfolgreiche Umsetzung von Beobachtbarkeit hängt genauso sehr, wenn nicht sogar noch mehr, von einem geeigneten kulturellen Gerüst ab, das die Art und Weise unterstützt, wie Software entwickelt, eingesetzt, debuggt und gewartet wird, als davon, dass man das richtige Werkzeug zur Verfügung hat.
In den meisten (vielleicht sogar allen) Szenarien müssen Teams sowohl die Überwachung als auch die Beobachtbarkeit nutzen, um ihre Dienste erfolgreich aufzubauen und zu betreiben. Für eine erfolgreiche Umsetzung müssen die Praktiker/innen jedoch zunächst die philosophischen Unterschiede zwischen beiden verstehen.
Was die Überwachung von der Beobachtbarkeit unterscheidet, ist der Zustandsraum des Systemverhaltens und darüber hinaus die Art und Weise, wie man den Zustandsraum erforschen möchte und mit welchem Detailgrad. Mit "Zustandsraum" meine ich alle möglichen Verhaltensweisen, die ein System in den verschiedenen Phasen zeigen kann: vom Entwurf des Systems über die Entwicklung und den Test bis hin zum Einsatz des Systems, dem Kontakt mit den Nutzern und der Fehlersuche im Laufe seiner Lebensdauer. Je komplexer das System ist, desto größer und vielfältiger wird der Zustandsraum.
Die Beobachtbarkeit ermöglicht es, diesen Zustandsraum akribisch abzubilden und mit einem feinzahnigen Kamm bis ins kleinste Detail zu untersuchen. Eine solch sorgfältige Erkundung ist oft erforderlich, um unvorhersehbare, langschwänzige oder multimodale Verteilungen im Systemverhalten besser zu verstehen. Im Gegensatz dazu liefert die Überwachung eine grobe Annäherung an den Gesamtzustand des Systems in groben Zügen.
Daraus folgt, dass alles, von den Daten, die zu diesem Zweck gesammelt werden, über die Art und Weise, wie diese Daten gespeichert werden, bis hin zu der Art und Weise, wie diese Daten untersucht werden können, um das Systemverhalten besser zu verstehen, von den Zielen der Überwachung und Beobachtbarkeit abhängt.
In den letzten Jahrzehnten hat das Ethos der Überwachung die Entwicklung unzähliger Tools, Systeme, Prozesse und Praktiken beeinflusst, von denen viele zum De-facto-Industriestandard geworden sind. Da diese Tools, Systeme, Prozesse und Praktiken speziell für die Überwachung entwickelt wurden, leisten sie in dieser Hinsicht hervorragende Arbeit. Sie können - und sollten - jedoch nicht als "Überwachungsinstrumente" oder -verfahren umbenannt oder an ahnungslose Kunden vermarktet werden. Das würde nur wenig bis gar keinen erkennbaren Nutzen bringen und für den Kunden eine enorme Zeit-, Arbeits- und Geldverschwendung bedeuten.
Außerdem sind Werkzeuge nur ein Teil des Problems. Der Aufbau oder die Übernahme von Beobachtungsinstrumenten und -praktiken, die sich in anderen Unternehmen als erfolgreich erwiesen haben, löst nicht unbedingt alle Probleme, mit denen das eigene Unternehmen konfrontiert ist, denn ein fertiges Produkt verrät nichts darüber, wie sich die Instrumente und die dazugehörigen Prozesse entwickelt haben, welche übergeordneten Probleme damit gelöst werden sollten, welche impliziten Annahmen in das Produkt eingeflossen sind und vieles mehr.
Die Entwicklung oder der Kauf des richtigen Beobachtungstools wird kein Allheilmittel sein, wenn nicht zuvor ein förderlicher kultureller Rahmen im Unternehmen geschaffen wird, der die Teams zum Erfolg führt. Eine Denkweise und Kultur, die in den Schibboleths des Monitorings verwurzelt ist - Übersichten, Alarme, statische Schwellenwerte - ist nicht hilfreich, um das volle Potenzial der Beobachtbarkeit zu erschließen. Ein Observability-Tool kann zwar auf eine sehr große Menge sehr detaillierter Daten zugreifen, aber um diese Datenberge erfolgreich zu nutzen - und das ist der ultimative Gradmesser für die Gesamttauglichkeit und den Nutzen des Tools und wohl auch der Observability selbst - ist eine hypothesengesteuerte, iterative Debugging-Mentalität erforderlich.
Der bloße Zugang zu modernsten Werkzeugen führt nicht automatisch dazu, dass die Praktiker/innen diese Einstellung entwickeln. Genauso wenig hilft es, über nebulöse philosophische Unterscheidungen zwischen Monitoring und Beobachtbarkeit zu schwärmen, ohne diese Ideen in übergreifende praktische Lösungen zu destillieren. In einigen Kapiteln dieses Buches wird zum Beispiel kritisiert, dass Logs, Metriken und Traces als die "drei Säulen der Beobachtbarkeit" gelten. Die Kritik ist zwar nicht unbegründet, aber die Wahrheit ist, dass Logs, Metriken und Traces lange Zeit die einzigen konkreten Beispiele für Telemetrie waren, die Menschen, die reale Systeme in der realen Welt betreiben, zur Verfügung standen, um ihre Systeme zu debuggen, und es war daher unvermeidlich, dass sich das Narrativ der "drei Säulen" um sie herum entwickelte.
Was bei Praktikern, die Systeme in der realen Welt aufbauen, am besten ankommt, sind keine abstrakten, luftigen Ideen, sondern ein umsetzbares Konzept, das Lösungen für dringende technische und kulturelle Probleme bietet, mit denen sie konfrontiert sind. Dieses Buch überbrückt die Kluft, die zwischen den philosophischen Lehren der Beobachtbarkeit und der Praxis gähnt, indem es einen konkreten (wenn auch eigenwilligen) Plan liefert, wie die Umsetzung dieser Ideen in die Praxis aussehen könnte.
Anstatt sich auf Protokolle oder Standards oder sogar Low-Level-Darstellungen verschiedener Telemetriesignale zu konzentrieren, sieht das Buch die drei Säulen der Beobachtbarkeit als Dreiklang aus strukturierten Ereignissen (oder Spuren ohne Kontextfeld, wie ich sie gerne nenne), iterativer Überprüfung der Hypothese (oder hypothesengesteuertem Debugging, wie ich es gerne nenne) und der "Kernanalyse-Schleife". Diese ganzheitliche Betrachtung der Bausteine der Beobachtbarkeit von Anfang an macht deutlich, dass Telemetriesignale allein (oder Werkzeuge, die diese Signale nutzen) das Systemverhalten nicht maximal beobachtbar machen. Das Buch scheut sich nicht, die Herausforderungen zu beleuchten, die sich beim Aufbau einer Beobachtungskultur in einem Unternehmen ergeben können, und gibt wertvolle Hinweise, wie man dabei nachhaltig vorgehen kann, damit Beobachtungspraktiker/innen langfristig erfolgreich sind.
Get Beobachtbarkeitstechnik now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
