Das 3-Stufen Observability-Prinzip

Einführung

Ob Hightech, industrielle Fertigung, Gesundheitswesen oder Finanzdienstleistungen: Ihre Kunden erwarten eine nunmehr komplett nahtlose Interaktionserfahrung. Zu jedem Zeitpunkt, bei jedem Berührungspunkt. Beim Thema Kundenbindung wird das Eis nur allzu schnell dünn. Und Software ist dabei längst kein strategischer Differenzierungsfaktor mehr, sondern vielmehr unabdingbare Ingredienz. Wenig verwunderlich: Studien haben mit Nachdruck belegt, dass Kunden mit hoher Interaktionsdynamik 90 % häufiger positive Kaufentscheidungen treffen und durchschnittlich 60 % mehr pro Kauf aufwenden. Pro Jahr entsprechen ihre Ausgaben im Mittel sogar dem Dreifachen von vergleichbaren Durchschnittskunden. Unterfüttert werden wollen diese Chancen aber auch – mit einer Infrastruktur, die auch in absoluten Spitzenzeiten ansprechende Benutzererlebnisse konsequent skalieren kann.

Genau hier ist jedoch auch ein Paradoxon verortet: Wie lassen sich diese innovativen, höchst performanten Interaktionsmomente generieren, ohne ungewollt das so wichtige Kundenerlebnis als großes Ganzes in Mitleidenschaft zu ziehen? Schließlich hallen schlechte Kundenerfahrungen weitaus lauter und länger nach als gute. Wer kennt sie nicht, die viel gefürchteten Downtime- Schlagzeilen? Wenige Stunden Systemausfall multiplizieren sich rasch zu Millionenverlusten und Wochen oder Monaten an Kulanzgesten. Die Bremse für alle Hiobsbotschaften: Neue Code Releases und moderne Infrastruktur müssen nicht zum Drahtseilakt werden. Mit einer durchdacht konzipierten Observability-Methodik gelingen erstklassige, softwarebasierte Kundenerlebnisse im komplexen digitalen Kontext moderner Unternehmen. 

New Relic unterteilt dabei in drei Observability-Reifegrade: reaktiv, pro-aktiv und datengesteuert. Der ideale Zustand ist ein automatisiertes, selbstheilendes System. Ihren Entwicklern vermittelt es in Echtzeit, welchen Einfluss ihre Updates auf das digitale Kundenerlebnis Ihrer Benutzer haben. Liegt ein Problem vor? Gut zu wissen. Viel wichtiger: warum? Mit Observability haben Ihre Engineering-Teams diesen Vorteil auf ihrer Seite.

In diesem E-Book betrachten wir alle drei Observability-Reifegrade sowie ihren zugehörigen Handlungsradius und notwendige KPIs. 

Observability-Reifegrad: Reaktive Phase

REAKTIVE HANDLUNGSWEISEN UND EMPFEHLUNGEN

  • Instrumentieren und justieren
  • Baselines und Basis-Alerts definieren

KPIs: Fehler, Durchsatz, Latenz, Traffic, Sättigung, Auslastung, Apdex 

„Was man nicht quantifizieren kann, kann man auch nicht verbessern.“ – Eine Plattitüde zwar, aber ein guter Ansatzpunkt: So beginnt eine mit Weitsicht angelegte Observability-Methodik mit der entsprechenden Instrumentierung, um so viele Telemetriedaten Ihres Systems zu erfassen wie nur möglich. Von hier an kann der Fokus dann zunächst auf die Behebung offensichtlicher Probleme gelegt werden.

Instrumentieren und justieren

An der Auswahl der Datenpunkte zum Monitoring sollten sowohl Vertreter geschäftlich strategischer Unternehmensbereiche als auch digitale Leader beteiligt sein. Diese Symbiose ist wichtig. Ihre Teams sollen nicht mit Alerts überladen, sondern via Monitoring auf geschäftlich relevante Vorfälle aufmerksam gemacht werden. 

Metrics, Events, Logs und Traces (MELT) bilden die Datengrundlage für Observability. Fassen Sie Daten aus unterschiedlichen Quellen wie Logs aggregiert zusammen, erhalten Sie die Möglichkeit, Ihre Systeme zentral über eine Plattform zu analysieren, zu visualisieren und auftretende Fehler zielgerichtet zu beheben. Jeden Datentyp aus jeder beliebigen proprietären oder Open-Source-Quelle instrumentieren zu können – das Fundament für Observability als Motor für dynamische Telemetrie-Erfassung und Problembehebung.

four golden signals

Nützlicher Ansatzpunkt zum Baselining Ihrer Anwendungen:
die vier goldenen Signale des Monitoring (Google SRE-Handbuch).

Durch Konsolidierung Ihrer geschäftskritischen Observability-Daten reduzieren Sie ebenso Arbeitsaufwand und Kosten für die Wartung anderer Systeme, mit denen Sie diese Daten speichern, abfragen, anzeigen und Alerts zu ihnen ausgeben. 

Baselines und Basis-Alerts definieren

Metrics und Performance-Statistiken zu Ihren Anwendungen und Ihrer Infrastruktur zeigen Ihnen Engpässe und Fehler auf, die zu Momenten der Instabilität in Ihrer Software und letztlich wenig begeisterten Benutzern führen können. Sorgen Sie für umgehende Restabilisierung, indem Sie Ihre langsamsten Transaktionen und gängigsten Fehler adressieren. Hieraus erarbeiten Sie einen Benchmark für das „Normverhalten“ Ihrer Services und Systeme. Analysieren Sie offensichtliche Fehler und definieren Sie Alert-Baselines mit präzise justierten Toleranzschwellen. Um wenig erstrebenswerte Silos zwischen Ihren Produkt-, Ops-, Engineering- und Serviceteams aufzulösen, müssen Sie die Transaktions-Performance an den Servicegrenzen Ihrer Produkt-Features abbilden können.

Observability-Reifegrad: Pro-aktive Phase

PRO-AKTIVE HANDLUNGSWEISEN UND EMPFEHLUNGEN

  • SLOs definieren

  • Alerting-Strategie optimieren

  • Ausfall-Behebung beschleunigen

  • Schnelle Feedback-Schleifen einrichten 

KPIs: Verfügbarkeit, Fehler, Latenz, Traffic, Sättigung, Auslastung, Deployment- Frequenz, Änderungsdauer, MTTD, MTTR, MTBF, Seitenladezeit

Die enorme Bandbreite an Signalen aus verschiedenen Systemen macht es häufig nicht einfach, die Vorfall-Ursache genauer zu bestimmen, geschweige denn Probleme rasch zu erkennen und zu adressieren. Komplexe Infrastruktur- und Prozess-Gebilde führen dabei zu Prüf- und Interpretationsverrenkungen rund um tausende „unbekannter Unbekannten“. Bei diesem Reifegrad wird mittels SLOs eine einheitliche Service-Level-Basis für verschiedene Teams etabliert. Weiter geht es hier um die Optimierung von Prozessen, um Systemzuverlässigkeit und -geschwindigkeit in Einklang zu bringen und Probleme zu adressieren, bevor sie sich auf Ihr Kundenerlebnis auswirken. 

Gemeinsamer SLO-Nenner

Service Level Objectives (SLOs) quantifizieren Ihre Ziele in einem Format, das teamübergreifend erfasst und umgesetzt werden kann. Gleichwohl grenzen Sie Service- Erwartungen klar ab und machen Ihre Teams agiler und flexibler beim Experimentieren mit neuen Ansätzen. Einen hervorragenden Startpunkt zur Erkennung von Problemen bilden hierbei die vier goldenen Signale des Monitoring (Latenz, Traffic, Fehler, Sättigung), wie sie im Google SRE-Handbuch beschrieben sind. Im Anschluss gilt es, ein bis zwei übergreifende Service Level Indicators (SLIs) zu identifizieren, über die sich der allgemeine Zustand der Services ablesen lässt. Videostreaming-Services etwa setzen auf den Messfaktor Time to First Frame – die Zeitspanne zwischen der Auswahl eines Films durch den Kunden bis zur Einblendung des ersten Frames auf dem Bildschirm. 

Alerting-Strategie optimieren

Mechanismen zur Datenaggregation sind funktional implementiert, Team-Ziele klar definiert. Nun ist ein systematisch einsetzbarer, verlässlicher Prozess vonnöten, der Bereitschaftsteams bei Bedarf ohne Umschweife mobilisiert. Adäquat angelegte Alerts helfen, den Zustand Ihrer Systeme klar zu erfassen und rasch auf Performance-Probleme zu reagieren.

Es muss aber nicht jeder SLO in einen Alert überführt werden. Eine starke Strategie schnürt aus Ihren SLOs vielmehr ein Paket einfacher, zielführend umsetzbarer Alerts. So halten es auch viele Unternehmen mit besonders hohem Reifegrad: Hier schlagen eher wenige, ausgewählte Alerts für Kern- Metriken dediziert Alarm, wenn das Kundenerlebnis wesentlich beeinträchtigt ist. DevOps-Teams nutzen häufig Apdex als Teil ihrer Strategie, um Alerts mit Hinweisen auf eine suboptimale Benutzerzufriedenheit in einen gemeinsamen Kontext zu bringen. 

Alert-Grundlagen

Bei der Konzipierung Ihrer Alert-Strategie sollte stets diese Frage Pate stehen: „Wenn meine Kunden nicht beeinträchtigt sind, sollte dann bei jemandem nachts der Wecker klingeln?“

Frage Metriken und KPIs
Können wir unsere Produkte/Services verkaufen?  Richten Sie automatisierte Pings und Alerts zur Verfügbarkeit ein. 
Wie ist es um unsere zugrunde liegende Infrastruktur bestellt?  Verwalten Sie Ihre Hosts und Container und beheben Sie etwaige Fehler. 
Wie ist der Zustand unserer Anwendung?  Analysieren Sie Ihr Backend anhand echter Endbenutzer-Metriken. Nutzen Sie Metrik- und Trace-Daten aus Open-Source-Lösungen und bilden Sie diese Informationen zusammen mit allen anderen von Ihnen verwalteten System- und Servicedaten ab. 
Wie behebe ich einen Systemfehler?  Prüfen Sie Ihre Anwendungs- und Infrastruktur-Logs auf die Fehlerursache. 
Wie ist es um die Gesamtqualität unserer Anwendung bestellt?  Evaluieren Sie die Qualität Ihrer Anwendung rasch per Apdex-Wert. 
Wie ist Ihr Kundenerlebnis?  Etablieren Sie eine Monitoring-Strategie für Ihr Frontend- und mobiles Endbenutzererlebnis. 
Wie ist es um Ihr Gesamtgeschäft bestellt?  Konzentrieren Sie sich auf die Kerntransaktionen innerhalb einer Anwendung und bauen Sie einen Bezug zu geplanten Geschäftszielen auf, um Anwendungs- und Business-Performance zu korrelieren.

Ausfall-Behebung beschleunigen

Jede Minute, die Sie in der Problemdiagnose damit verbringen, Ihre Telemetriedaten manuell zu interpretieren, beeinträchtigt Ihre Reputation und Ihren Geschäftserfolg. Ihre IT Ops-Teams benötigen daher umso mehr Intelligence- und Automatisierungs-Features, die Incidents pro- aktiv erkennen und beheben.

throughput requests per minute

Deployment-Marker vermitteln klar, wie Code-Änderungen die Zuverlässigkeit beeinflussen.

Die Verantwortung für Anwendungs- und System- Zustand kann einem einzelnen Mitarbeiter oder einem gesamten Team obliegen. Diese IT-Erstversorger nehmen sich eines Vorfalls zuerst an. Stellen Sie dabei auch sicher, dass alle Kommunikationsabläufe für kritische Vorfälle über einfach zugängliche und zentrale Kanäle erfolgen. Sind Ihre Teams es etwa gewohnt, mit Tools wie Slack zu interagieren, müssen Vorfall-Alerts auch über diese Kanäle ausgegeben werden können. 

Schnelle Feedback-Schleifen einrichten 

Schnelle Feedback-Schleifen einrichten

Mit schnellen Feedback-Schleifen reduzieren Sie die mittlere Lösungszeit (MTTR) und ebenso Risiken in punkto Zuverlässigkeit im Zusammenhang mit häufigen Anwendungs-Updates. Deployments und der Einfluss von Code- und Infrastrukturänderungen auf das Kundenerlebnis müssen im Detail nachvollziehbar bleiben.

Gerade über Deployment-Daten kann ganz hervorragend erfasst werden, was für kurz- und langfristige oder auch schleichende Verschlechterungen der Anwendungs-Performance ursächlich ist. Schnelle Feedback-Schleifen sind auch elementar für moderne Release-Methoden wie Canary oder Blue-Green Deployments . 

Observability-Reifegrad: Datengesteuerte Phase

DATENGESTÜTZTE HANDLUNGSWEISEN UND EMPFEHLUNGEN

  • SLO-Trendanalyse
  • Visualisierung der Zusammenhänge zwischen Dev, Ops und Kundenerlebnis
  • Instrumentierung automatisieren

KPIs: Anzahl und MTTR von Ausfällen im Zusammenhang mit Änderungen, Entwickler-Zufriedenheit, Kundenzufriedenheit, SLO- und SLA- Einhaltung, Auslastung, Fehlerrate, aktive Alerts, Anzahl der Support-Tickets 

Letztendlich ist es erklärtes Ziel einer jeden Observability-Strategie, Teams mit gemeinsamen Daten zu konzertiertem Vorgehen zu verhelfen. Es geht um eine Verkettung von Humankompetenz, Prozessen und Technologie im Gesamtunternehmen mit Ausrichtung auf spezifische Geschäftsziele. Damit Ihre Observability-Daten im Fluß bleiben, müssen Instrumentierungsvorgänge für neue Apps und Services automatisiert werden. Wer diese Schritte meistert, den erwarten agile, zielgerichtete und datengesteuerte Geschäftsprozesse und -strukturen. 

SLO-Trendanalyse

Mit messbaren SLOs brechen Sie Software- Strukturen in einzelne Schlüsselindikatoren herunter. Diese lassen sich dann nutzen, um Service-Abläufe mit dem Soll abzugleichen und zu erfassen, wie Vorfälle die Service- Verfügbarkeit beeinflussen. Die in die SLO- Definition investierte Zeit im Rahmen der pro-aktiven Phase macht sich nun bezahlt, um Problemschwerpunkte auszumachen. Team- Dashboards bilden einen ausgezeichneten Referenzpunkt, um SLO-Einhaltung mittel- bis langfristig abzubilden. 

application usage

Erfahren Sie, wie Anwendungs- und Infrastruktur-Performance Ihre Geschäftsergebnisse beeinflussen.

Visualisierung der Zusammenhänge zwischen Dev, Ops und Kundenerlebnis

Ein gut konzipiertes Dashboard für Ihre geschäftliche Performance vermittelt Ihren Teams einen klaren Überblick über das Kundenerlebnis Ihrer App. Wenn Sie wissen, wie und wann Ihre Kunden Ihre Anwendung nutzen oder verlassen, lassen sich zukünftig benötigte Bemühungen viel logischer ausrichten. Eine starke Observability-Kultur macht Ihre Daten über klassische Backend-Benutzer hinaus intern viel breiter verfügbar: Kundenservice, Support, Produktmanagement, Sales, Marketing bis hin zum Exec-Level profitieren nun ebenso von ihnen. Haben Ihre Teams ganz demokratisch Zugriff auf diese Informationen, liefert dies ein ganz wunderbares Motivationsmomentum.

Instrumentierung automatisieren

Automatisierung sorgt für neue Agilität und verhindert einfach vermeidbare manuelle Fehler. Viel wichtiger noch: Sie stützt und erweitert Observability. Sie verbringen weniger Zeit mit der Instrumentierung von Systemen und der Verwaltung Ihres unweigerlich weiter wachsenden Infrastruktur- Stacks. Um diese Zielsetzung zu unterstreichen, kann es probat sein, für die operativen Arbeitsschritte aller SREs wie Ticket-Abwicklung, Bereitschaftsdienst und andere manuelle Aufgaben in ihrer Gesamtheit eine Obergrenze von 40 % zu definieren. Die verbleibende Zeit ist dann für die Anwendungsentwicklung aufzuwenden. Mit der Zeit sollte Ihr SRE-Team dann nur noch sehr geringe operative Aufgaben wahrnehmen müssen und sich nahezu komplett auf die Entwicklung konzentrieren können. Service-Wartung und -Korrekturen laufen größtenteils automatisiert ab. Nutzen Sie hierbei Observability-Strategien, die Ihren Teams das Leben leichter machen und Automatisierung begünstigen. 

10 Observability Best Practices

1. DATEN ERFASSEN: Ob proprietär oder Open Source – konsolidieren Sie so viele Telemetriedaten aus Ihren Systemen wie möglich: Metrics, Events, Logs und Traces.

Ziel: Erfassen und analysieren Sie alle Telemetriedaten über eine zentrale Plattform.

2. BASELINING DURCHFÜHREN: AErstellen Sie Alert-Baselines anhand offensichtlicher Fehler und justieren Sie die Toleranzschwellen.

Ziel: Adressieren Sie klar ersichtliche Probleme und legen Sie das Fundament für strategische Prioritäten.

3. SLOs DEFINIEREN: Legen Sie SLOs fest. Eine gute Grundlage bilden die vier goldenen Signale des Monitoring (Latenz, Traffic, Fehler und Sättigung) zusammen mit einigen weiteren Metriken, die das Endbenutzer- Erlebnis quantifizieren.

Ziel: Erfassen Sie teamübergreifende Ziele auf messbare Weise.

4. ALERTS EINRICHTEN: Erarbeiten Sie eine klar verständliche Alert-Strategie, die sich auf einige für das Kundenerlebnis zentrale Kern-Metriken konzentriert.

Ziel: Etablieren Sie eine klare Ausrichtung auf die wichtigsten SLOs.

5. VORFALL-BEHEBUNG BESCHLEUNIGEN: Verschaffen Sie Ihren IT Ops-Teams Intelligence- und Automatisierungs-Features, die Vorfälle pro-aktiv erkennen und beheben. 

Ziel: Optimieren Sie die Feedback-Schleife zwischen Fehlererkennung und -behebung. 

6. DEPLOYMENTS ERFASSEN: Etablieren Sie Monitoring-Standards für Ihre Anwendungs- Deployments, um die Auswirkungen von Code-Änderungen auf Ihre Performance zu quantifizieren.

Ziel: Bestimmen Sie die Ursache kurz- wie langfristiger und schleichender Performance-Verschlechterungen Ihrer Anwendung. 

7. AUTOMATISIEREN: Halten Sie Ihre Observability-Daten im Fluß, indem Sie Instrumentierungsvorgänge für neue Apps und Services automatisieren. 

Ziel: Mit gemeinsamen Telemetriedaten agieren Ihre Teams schnell und zielgerichtet.

8. ANALYSIEREN: Erstellen Sie Team-Dashboards, um SLO-Einhaltung mittel- bis langfristig abzubilden. 

Ziel: Validieren Sie Erwartungen an die Service-Verfügbarkeit und identifizieren Sie dringliche Problemstellungen. 

9. KUNDENFOKUS SETZEN: Vermitteln Sie Ihren Teams, wie Ihre Kunden Ihre Anwendungen nutzen oder verlassen.

Ziel: Optimieren Sie die strategische Planung zukünftiger Arbeit. 

10. AUFWAND REDUZIEREN: Etablieren Sie eine Automatisierungsmentalität mithilfe einer Beschränkung operativer SRE-Arbeit auf 40 %.

Ziel: Ihre SRE-Teams minimieren ihre operative Arbeitslast und involvieren sich in Dev-Aufgaben, da sich Services größtenteils selbst warten und korrigieren. 

Observability mit New Relic

Nachdem wir die drei Observability-Reifegrade nun eingehend betrachtet haben, ist es Zeit für einige Praxishinweise für erste Schritte mit New Relic.

Reaktive Phase

Pro-aktive Phase

  • Richten Sie New Relic Synthetics ein zur Interaktion mit dem Gesamtsystem. Tun Sie dies durch die Augen eines externen Benutzers. Ihr Team erhält so allgemeine Prüfmöglichkeiten für Performance, Verfügbarkeit und Kundenerlebnis.

  • Implementieren Sie New Relic AI, um die Behebung Ihrer Vorfälle in der Produktionsumge- bung zu beschleunigen.

  • Setzen Sie New Relic APM Deployment- Marker zur Erfassung von Deployments für jede Anwendung ein. Deployment-Marker in Team-Dashboards machen eine Vorher- Nachher-Analyse möglich und zeigen, welchen Performance-Einfluss Releases haben.

Datengesteuerte Phase

  • Nutzen Sie die SLO/R-Anwendung in New Relic One, um SLIs und SLO-Ziele zu definieren. Die SLO- Einhaltung könnte sich zu erfassen und als Leistungskennzahl zu kommunizieren lohnen. Ihre Teams sollten Ihr SLO-Tracking als Indikator dafür nutzen, wann es den Fokus auf Systemstabilität und wann auf neue Features zu legen gilt. SLO-Trends dienen weiter zur Optimierung der geschäftlichen Entscheidungsfindung.

  • Lesen Sie dieses Tutorial, um zu erfahren, wie verschiedene Kundensegmente Ihre Anwendungen einsetzen. So erkennen Sie etwa Unterschiede in punkto Geographie oder Endgerätetyp. Anhand dieser Segmentierung richten Sie die Optimierung Ihrer Kundenerlebnisse genau an Ihrer geschäftlichen Gesamtstrategie aus.

  • Generieren Sie mit New Relic One Dashboards flexible, interaktive Visualisierungen aller beliebigen Daten in der New Relic One Plattform.

  • Erstellen und verwalten Sie mit der Synthetics REST API New Relic Synthetics Monitore..

  • Konfigurieren Sie Alert-Einstellungen und richten Sie Alert-Bedingungen ein.

  • Schreiben Sie ein Build-Script oder -Plugin, das Abhängigkeiten und Aufgaben erfasst, um die Agent-Installation abzuschließen und passende Standard-Konfigurationen zu definieren.

Bereit für Ihre eigene Observability-Strategie?