Nichts ist beständiger als der Wandel
Wie viele SREs braucht es, um „Observability“ zu definieren?
Alle. Denn einig werden sie sich eh nicht.
Ganz gleich, für wessen Definition man sich nun aber entscheidet, ohne eine der wichtigsten Konstanten moderner verteilter Software-Umgebungen darf man die Rechnung keinesfalls machen: Veränderung.
Veränderungen bei Telemetrie-Datentypen und Quellen. Veränderungen in punkto Anwendungsarchitekturen und Deployment-Methoden. Veränderungen im Hinblick auf Best Practices und favorisierte Tools. Veränderungen bei der Anzahl und der Art von verteilten Systemen, Containern und Abstraktionsebenen zwischen Anwendungen und Infrastruktur. Veränderungen hinsichtlich der Nutzung Ihres Produkts.
Veränderungen in geschäftlicher Hinsicht, die technologische Umwälzungen einfordern.
New Relic fasst seine Definition von Observability ganz einfach und prägnant: Für uns geht es darum, wie genau Sie Ihre Systeme in ihrer Komplexität verstehen.
Wir sind der Auffassung, dass die eigentliche Definition von Observability weitaus weniger wichtig ist als die eigentlichen Prinzipien, aus denen sich ihr Erfolg letztlich speist.
Statt also nur wieder eine weitere Definitionsdiskussion vom Zaun zu brechen, haben wir uns lieber eingehend mit Entwicklern und Engineers zum Thema unterhalten. Die Ergebnisse dieser Gespräche haben wir schließlich in 10 Observability-Prinzipien zusammengefasst.
Die 10 Prinzipien der Observability
1. Observability vermittelt eine teamübergreifend konsequent anwendbare Datenarchitektur.
DevOps verfolgt ein klares Ziel: Alle Silos zwischen Engineers und Teams, die ihren Programm-Code in der Produktion umsetzen, sollen eliminiert werden. Observability fügt sich hier nahtlos ein, verhilft diesen Teams zu einem Framework gemeinsam genutzter Daten, auf das sich beide Bereiche beziehen können.
„Monitoring-Spezialisten, Observability-Experten und Budgetverantwortliche – sie gilt es, zu einen, ihre Prioritäten auf einen Nenner zu bringen. Mit Observability als gemeinsamer, zentraler Informationsquelle gelingt genau das.“
Josh Biggley, TechOps Strategy Consultant, New Relic
2. Observability sollte eine Instrumentierung Ihrer Systeme ermöglichen und so Ihre Daten jederzeit über dieselbe Plattform verfügbar machen – in Echtzeit.
Mehr denn je müssen Sie nun Ihren gesamten Stack überblicken und Tracing im großen Maßstab durchführen können. Genau deshalb sehen 94 % aller Software-Leader Observability als unerlässlich in der Software-Entwicklung. Eine Priorität also, die sich auszahlt.
Was genau bedeutet das? Nun, es geht darum, stets Zugriff auf alle Metrics, Events, Logs und Traces zu haben. Dies komplett zentral. Und ob sie vom Agent eines externen Anbieters stammen, von Ihrer intern entwickelten Anwendung oder von einer Open-Source-Lösung, muss dabei unerheblich sein.
„Daten sind heutzutage fest verknüpft mit allem Tun eines Unternehmens. Diese Daten in ihrer Essenz zu verstehen, darin liegt nunmehr auch der wichtigste Schlüssel zum Erfolg.“
Zack Mutchler, TechOps Strategy Consultant, New Relic
3. Observability bedarf Daten mit hoher Kardinalität.
Warum überhaupt Daten erfassen, wenn man sie nicht auch direkt analysieren kann? Hohe Kardinalität gibt Ihnen die Flexibilität, Ihre Daten von jedem Blickwinkel abzuklopfen, bis dato noch unbekannte Unbekannte auszumachen und generell wichtige Einblicke zu gewinnen.
Ihre Engineering-Teams müssen ihre Systeme in der Produktion testen und prüfen können, um so Problemen nachzugehen, die sie zuvor nicht hatten voraussehen können.
„New Relic hat unsere Entscheidungen fundierter gemacht, da wir nun die nötigen Einblicke haben, um Problemursachen zu isolieren und sie pro-aktiv anzugehen. Wir lösen inzwischen Probleme, von denen wir noch gar nicht wussten, dass wir sie hatten.“
Daniela Constanza Muñoz, Entwicklerin, Banco de Crédito e Inversiones (BCI)
4. Observability gibt Ihren Teams Sicherheit.
Je schneller die Abläufe komplexer Systeme im Detail nachvollziehbar werden, desto zielgenauer lassen sich Systemänderungen umsetzen.
Schließlich können Sie darauf vertrauen, dass allen die Daten zur Verfügung stehen, die sie für informierte Entscheidungen benötigen. Ebenso können Sie auf Nachfragespitzen mit den entsprechenden Skalierungsmöglichkeiten reagieren. Neuen Code können Sie live schalten, sich ansehen, wie er sich auswirkt, und etwaige Probleme direkt adressieren, ohne dass auch nur ein Endbenutzer sie überhaupt bemerkt hat.
„Observability bedeutet im Grunde, Änderungen durchführen und ihren Effekt direkt nachvollziehen zu können. Ohne diese Sicherheit steht man in Sachen Innovation nur massiv auf der Bremse, denn man ist ja stets im Unklaren, was man möglicherweise mit einer Änderung anrichtet, und zögert somit andauernd.“
Leo Guinan, DevOps Engineer, Fuse by Cardinal Health
5. Observability steht nicht nur für Problemlösung, sondern vor allem auch für Prävention.
Es geht darum, Signale miteinander in Verbindung bringen, sie korrelieren zu können. Denn nur dies verschafft Ihnen den so wichtigen Kontext, den Sie benötigen, um ein Problem zu beheben, bevor es sich auf Ihr Kundenerlebnis auswirken kann. Es gilt, erfassen und interpretieren zu können, warum kritische Incidents vorgefallen sind, und einer Wiederholung pro-aktiv vorzubeugen. Das Ergebnis: Sie verringern nicht nur automatisch Ihre Downtime, sondern verbessern die MTTR und geben Ihrem Team mehr Zeit und Raum für Innovationen.
„Wir können die Anwendungs-Performance genauestens analysieren, erkennen, warum etwa eine Fehlerrate sprunghaft ansteigt, wann es zu Latenzspitzen kommt und an welchem Node Probleme auftreten. Gerade nach einem Build Release ist diese Transparenz wirklich von immensem Wert, denn punktuelle Instabilitäten sind dadurch sofort ausgemacht.“
Chris Callaghan, Site Reliability Engineering Manager, Royal Society of Chemistry des Vereinigten Königreichs
Observability-Ergebnisse in Zahlen: Software-Leader vs. Nachzügler
- 83 % aller Software-Leader verzeichnen weniger als 5 Ausfälle/Monat, bei den Nachzüglern sind dies lediglich 3 %.
- Bei 75 % der Software-Leader beläuft sich die MTTR auf unter 30 Minuten. Im Falle der Nachzügler kann dies nur 1 % von sich behaupten.
- 78 % der Software-Leader identifizieren Service-Unterbrechungen mithilfe von Observability-Lösungen. Im Lager der Nachzügler trifft dies nur auf 12 % zu.
- Zu 89 % nutzen die Software-Leader automatische Wiederherstellung, die Nachzügler gerade einmal zu 5 %.
- Die Nachzügler erfahren über nahezu jede zweite Unterbrechung (48 %) von ihren Kunden – ganze 15 % mehr als bei den Leadern mit 33 %.
- Software-Leader wenden 77 % ihrer Zeit für Innovationen auf und nur 23 % für die Behebung von Problemen. Nachzügler hingegen sind mit dieser ganze 46 % ihrer Zeit beschäftigt.
Quelle: Deeper Than Digital - New Relic
6. Observability ist ein soziotechnisches System.
Observability beschränkt sich nicht auf bestimmte Systeme und Software oder spezifische Unternehmensbereiche, Teams oder Rollen. Es ist für jeden Einzelnen relevant.
Wie hängen Ihre Anwendungen und deren zugrunde liegende Services und Systeme zusammen? Erlangen Sie bei dieser allumfassenden Frage Klarheit, werden auch Abhängigkeiten über Abteilungsgrenzen hinweg deutlich, lassen sich Probleme rascher erkennen und beheben.
Im Kern steht hier nicht nur Technologie, sondern vor allem Mitarbeiter, Kunden und Prozesse.
„Observability als Konzept umspannt das gesamte soziotechnische System – Sensoren und menschliche Seite gleichermaßen. Eine Trennlinie zwischen den beiden gibt es hier nicht. Eine solche einzufordern, wäre schlichtweg zum Scheitern verurteilt. Und würde dabei zudem auch noch den Versuch untergraben, all diese Abläufe zu verstehen und zu optimieren, was ja eben Sinn und Zweck von Observability ist.“
Beth Long, Sr. Software Engineer, New Relic
7. Observability bringt Sie schneller voran.
Mit wertvollem Kontext für komplexe Zusammenhänge und agilen Reaktionsmöglichkeiten im Falle von Incidents.
„Unsere Microservices-Umgebung wächst ungebrochen. Ohne Observability und End-to-End-Transparenz wäre für uns überhaupt nicht ausreichend ersichtlich, was in unserer Infrastruktur, unseren Anwendungen und Microservices überhaupt vor sich geht. Mit Observability allerdings erreichen wir nicht nur unsere Vorgaben und Ziele in punkto Service-Levels. Kommt es doch einmal zu Incidents, haben wir sie viel rascher behoben. So können wir direkter reagieren, müssen uns aber nicht sorgen, dass wir dabei etwa überhastet vorgehen.“
Matthew Tapper, Lead Site Reliability Engineer, Culture Amp
8. Observability ist eine Endlosschleife.
Der Weg ist das Ziel. Auch hier, schließlich geht es um inkrementelle, konstante Verbesserungen, nicht um Veränderung mit dem Dampfhammer. Wer glaubt, für alle Ewigkeit „perfekte“ Observability erlangt zu haben, liegt einem Irrglauben auf. Ohne kontinuierliche Anpassung an und Optimierung bei Neuerungen für geschäftliche Anforderungen und Best Practices wird auch aus einer heute umfassenden Methodik mit der Zeit ein unzureichendes Modell.
Auf der Haben-Seite allerdings wirkt sich ein gut ausgestaltetes Observability-Programm positiv auf alle Stränge im Unternehmen aus. Nur an eine Endgültigkeit ohne weitere Arbeit sollte man eben auch im Erfolgsfall nicht glauben.
„Wie wir unsere heutigen Probleme adressieren, wird auch einige neue zu Tage fördern. All dies weiterhin zu kontrollieren, wird über Jahre hinweg eine Herausforderung bleiben.“
Beth Long, Sr. Software Engineer, New Relic
9. Arbeit oder Freizeit? Observability kennt den Unterschied.
Alert-Schwemmen und schierer physischer Erschöpfung ob all der Prompts und Pop-ups zu ihnen macht Observability ein Ende. Ihre Alerts werden so gesteuert, dass sie zum richtigen Zeitpunkt nur für kritische Incidents ausgelöst werden. So können Sie die Fehlerresistenz Ihres Systems stets bestens nachvollziehen, ohne auf Events mit niedriger Priorität reagieren zu müssen.
„Für ein System verantwortlich zu sein, das so einige blinde Flecken, für das man nicht alle Informationen hat – da sind schlaflose Nächte vorprogrammiert. Man fühlt sich einfach machtlos, in vielerlei Hinsicht im Unklaren.“
Beth Long, Sr. Software Engineer, New Relic
10. Observability ist eine Superkraft.
Als solche hilft sie Ihnen, Ihr Vorgehen im Kontext zu reflektieren. Speziell im Hinblick darauf, wie Änderungen an Zusammenhängen zwischen Ihren Tools, Anwendungen und Infrastruktur Einfluss auf Endbenutzer nehmen. Bessere Kundenerlebnisse – aber nicht zum Risiko Ihrer Systeme und Stabilität.
„Dank Observability kann ich aus verschiedenen Datenpunkten Einblicke ablesen. Benötige ich intern Unterstützung, um eine Problemstellung zu adressieren, kann ich dank ihr präzise die Notwendigkeit dokumentieren.“
Josh Biggley, TechOps Strategy Consultant, New Relic
6 Fragen, die jetzt wichtig sind
Observability ist wie Demokratie: Es geht immer besser.
Finden Sie den für Ihr Unternehmen geeigneten Ansatzpunkt und verfahren Sie dann mit einem Tempo, das zu ihm passt.
Um von Monitoring – einem passiven Prinzip, das Sie auf Probleme hinweist – zu Observability zu gelangen und somit zu einer Methodik, die aufzeigt, warum dies der Fall ist, sollten Sie die folgenden Fragen stellen. Und zwar sich, Ihren Vorgesetzen und Ihren SREs.
Frage 1 - Erfassen Sie Metrics, Events, Logs und Traces aus absolut jeder Quelle, ob open source, homegrown oder proprietär?
Frage 2 - Verschafft Ihnen Ihre Plattform die Flexibilität, Daten mit hoher Kardinalität zu erfassen. Daten, mit denen Sie die spezifischsten wie auch Ad-hoc-Fragen gleichermaßen stellen und beantworten können?
Frage 3 - Sind Sie in der Lage, Ihre erfassten Daten eingehend zu hinterfragen? Insbesondere im Kontext von Fragestellungen, an die Sie bei Ihrer anfänglichen Instrumentierung noch gar nicht gedacht hatten?
Frage 4 - Ist es für Sie umsetzbar, Datenpunkte zu korrelieren und aus ihnen für Business Metrics relevante Einblicke zu generieren?
Frage 5 - Können Sie dynamische Verbindungen automatisch generieren und so Muster anhand von Analytics und Visualisierungen identifizieren?
Frage 6 - Sind Sie auf allen Hierarchie-Ebenen hinweg bereit, in eine Plattform zu investieren, die Ihnen die für alle Gegebenheiten nötige Transparenz verschafft?
Anders gefragt: Sind in Ihrem Unternehmen Daten gefragt, die bestätigen, was Sie denken? Oder Daten, die Zusammenhänge korrekt und präzise beleuchten, auch wenn diese Ihren aktuellen Paradigmen widersprechen?
Änderungen verändern
Signale von Alert-Rauschen zu unterscheiden wird angesichts zunehmender Komplexität immer schwerer. Und so passen sich klassische Unternehmensstrukturen neuen Anforderungen und Herausforderungen nur schwerlich an.
Wie dabei einzelne Mitarbeiter, Teams und Systeme gewinnbringend interagieren und zusammenwirken sollen, ist dabei nicht ohne Weiteres vorstellbar.
Je besser Ihre Observability-Methodik ausgestaltet ist, je mehr sie sich im Gleichschritt mit Ihren Systemen entwickelt, desto besser sind Sie in der Lage, dieser Komplexität Herr zu werden.
100 % Observability. 0 % Komplexität.
Registrieren Sie sich noch heute für ein kostenloses New Relic Konto.
