Beobachtbarkeitstechnik

Kapitel 4. Wie sich Observabilität auf DevOps, SRE und Cloud Native bezieht

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bisher haben wir uns auf die Beobachtbarkeit im Kontext moderner Softwaresysteme bezogen. Deshalb ist es wichtig zu erklären, wie sich Beobachtbarkeit in die Landschaft anderer moderner Praktiken wie DevOps, Site Reliability Engineering (SRE) und Cloud Native einfügt. In diesem Kapitel wird untersucht, wie diese Bewegungen den Bedarf an Beobachtbarkeit erhöht und sie in ihre Praktiken integriert haben.

Beobachtbarkeit existiert nicht im luftleeren Raum, sondern ist sowohl eine Folge als auch ein integraler Bestandteil der DevOps-, SRE- und Cloud Native-Bewegungen. Wie die Testbarkeit ist auch die Beobachtbarkeit eine Eigenschaft dieser Systeme, die das Verständnis für sie verbessert. Beobachtbarkeit und Testbarkeit erfordern kontinuierliche Investitionen und sind keine einmalige Anschaffung oder eine Einheitslösung. Je besser sie werden, desto mehr Vorteile ergeben sich für dich als Entwickler und für die Endnutzer deiner Systeme. Wenn du untersuchst, warum diese Bewegungen einen Bedarf für Beobachtbarkeit geschaffen und ihre Nutzung integriert haben, kannst du besser verstehen, warum Beobachtbarkeit zu einem Mainstream-Thema geworden ist und warum immer mehr verschiedene Teams diese Praxis übernehmen.

Cloud Native, DevOps und SRE in einer Kurzfassung

Im Gegensatz zu den monolithischen und Wasserfallentwicklungsansätzen, die Softwareentwicklungsteams in den 1990er bis frühen 2000er Jahren verwendeten, nutzen moderne Softwareentwicklungs- und -betriebsteams zunehmend Cloud Native und Agile Methoden. Diese Methoden ermöglichen es den Teams, eigenständig neue Funktionen zu veröffentlichen, ohne dass diese eng mit anderen Teams verbunden sind. Lose Kopplung bringt mehrere wichtige Geschäftsvorteile mit sich, darunter höhere Produktivität und bessere Rentabilität. Die Möglichkeit, einzelne Servicekomponenten nach Bedarf zu skalieren und Ressourcen über eine große Anzahl von virtuellen und physischen Servern zu bündeln, bedeutet beispielsweise, dass das Unternehmen von einer besseren Kostenkontrolle und Skalierbarkeit profitiert.

Hinweis

Weitere Beispiele für die Vorteile von Agile und cloud-nativen Methoden findest du im DevOps Research and Assessment (DORA) 2019 Accelerate State of DevOps Report von Nicole Forsgren et al.

Cloud Native ist jedoch mit erheblichen Kompromissen hinsichtlich der Komplexität verbunden. Ein oft übersehener Aspekt bei der Einführung dieser Fähigkeiten sind die Verwaltungskosten. Abstrahierte Systeme mit dynamischen Kontrollmechanismen bringen neue Herausforderungen mit sich, wie z. B. die entstehende Komplexität und nicht-hierarchische Kommunikationsmuster. Ältere monolithische Systeme wiesen eine geringere emergente Komplexität auf, und daher genügten einfachere Überwachungsansätze; man konnte leicht herausfinden, was in diesen Systemen geschah und wo unbemerkte Probleme auftraten. Heute erfordert der Betrieb nativer Cloud-Systeme in großem Maßstab fortschrittlichere soziotechnische Praktiken wie kontinuierliche Bereitstellung und Beobachtbarkeit.

Die Cloud Native Computing Foundation (CNCF) definiert Cloud Native als "Aufbau und Betrieb skalierbarer Anwendungen in modernen, dynamischen Umgebungen... [Cloud Native] Techniken ermöglichen lose gekoppelte Systeme, die belastbar, verwaltbar und beobachtbar sind. In Kombination mit robuster Automatisierung ermöglichen sie es Ingenieuren, mit minimalem Aufwand häufig und vorhersehbar Änderungen vorzunehmen." Durch die Minimierung des Arbeitsaufwands (sich wiederholende manuelle Arbeit) und die Betonung der Beobachtbarkeit geben Cloud Native Systeme den Entwicklern die Möglichkeit, kreativ zu sein. Diese Definition konzentriert sich nicht nur auf die Skalierbarkeit, sondern auch auf die Entwicklungsgeschwindigkeit und die Bedienbarkeit als Ziele.

Hinweis

Wenn du wissen willst, was es bedeutet, Mühen zu eliminieren, empfehlen wir dir Kapitel 5 des Buches Site Reliability Engineering, herausgegeben von Betsy Beyer et al. (O'Reilly).

Die Umstellung auf Cloud Native erfordert nicht nur die Einführung einer ganzen Reihe neuer Technologien, sondern auch eine Veränderung der Arbeitsweise der Menschen. Dieser Wandel ist von Natur aus soziotechnisch. Oberflächlich betrachtet erfordert die Nutzung der Microservices-Toolchain selbst keine explizite Einführung neuer sozialer Praktiken. Aber um die versprochenen Vorteile der Technologie zu erreichen, müssen auch die Arbeitsgewohnheiten geändert werden. Obwohl dies aus der erklärten Definition und den Zielen hervorgehen sollte, machen die Teams in der Regel mehrere Schritte, bevor sie merken, dass ihre alten Arbeitsgewohnheiten ihnen nicht dabei helfen, die durch diese neue Technologie verursachten Verwaltungskosten zu bewältigen. Deshalb ist die erfolgreiche Einführung von Cloud Native Design Patterns untrennbar mit der Notwendigkeit von beobachtbaren Systemen und DevOps- und SRE-Praktiken verbunden.

In ähnlicher Weise betonen DevOps und SRE in ihren Definitionen und Praktiken den Wunsch, Rückkopplungsschleifen zu verkürzen und betriebliche Mühen zu reduzieren. DevOps bietet "bessere Werte, schneller, sicherer und glücklicher"¹ durch Kultur und Zusammenarbeit zwischen Entwicklungs- und Betriebsgruppen. SRE verbindet die Fähigkeiten von Systemtechnikern und Softwareentwicklern, um komplexe betriebliche Probleme durch die Entwicklung von Softwaresystemen zu lösen, anstatt sie manuell zu bearbeiten. Wie wir in diesem Kapitel herausfinden werden, ist die Kombination aus Cloud-Native-Technologie, DevOps- und SRE-Methoden und Beobachtbarkeit gemeinsam stärker als jedes einzelne Teil.

Beobachtbarkeit: Fehlersuche damals und heute

Das Ziel der Beobachtbarkeit ist es, eine Ebene der Introspektion zu schaffen, die den Menschen hilft, über den internen Zustand ihrer Systeme und Anwendungen nachzudenken. Dieser Zustand kann auf verschiedene Weise erreicht werden. Du könntest zum Beispiel eine Kombination aus Logs, Metriken und Traces als Debugging-Signale verwenden. Aber das Ziel der Beobachtbarkeit selbst ist unabhängig davon, wie es erreicht wird.

In monolithischen Systemen konntest du die potenziellen Fehlerbereiche vorhersehen und daher deine Systeme selbst debuggen und eine angemessene Beobachtbarkeit erreichen, indem du ausführliche Anwendungsprotokolle oder grobe Metriken auf Systemebene wie die CPU- und Festplattenauslastung in Kombination mit blitzartigen Einsichten verwendet hast. Diese alten Werkzeuge und instinktiven Techniken eignen sich jedoch nicht mehr für die neuen Managementherausforderungen, die durch die Möglichkeiten der Cloud Native Systems entstehen.

Zu den Beispieltechnologien, die in der Cloud-Native-Definition genannt werden, gehören Container, Service-Meshes, Microservices und unveränderliche Infrastrukturen. Im Vergleich zu Legacy-Technologien wie virtuellen Maschinen und monolithischen Architekturen bringen containerisierte Microservices von Natur aus neue Probleme mit sich, z. B. kognitive Komplexität aufgrund von Abhängigkeiten zwischen den Komponenten, flüchtige Zustände, die nach einem Neustart des Containers verworfen werden, und inkompatible Versionierung zwischen separat veröffentlichten Komponenten. Eine unveränderliche Infrastruktur bedeutet, dass es nicht mehr möglich ist, ssh zu Debuggingzwecken in einen Host einzudringen, da dies den Zustand dieses Hosts stören könnte. Service-Meshes fügen eine zusätzliche Routing-Schicht hinzu, die es ermöglicht, Informationen darüber zu sammeln, wie Service-Aufrufe ablaufen, aber diese Daten sind nur von begrenztem Nutzen, wenn du sie später nicht analysieren kannst.

Die Fehlersuche bei anomalen Problemen erfordert neue Fähigkeiten, die den Ingenieuren helfen, Probleme innerhalb ihrer Systeme zu erkennen und zu verstehen. Tools wie verteiltes Tracing können dabei helfen, den Zustand der Systeminterna zu erfassen, wenn bestimmte Ereignisse auftreten. Indem du jedem Ereignis einen Kontext in Form von vielen Schlüssel-Wert-Paaren hinzufügst, erhältst du einen umfassenden Überblick über die Vorgänge in allen Teilen deines Systems, die normalerweise verborgen sind und über die du keine Aussagen treffen kannst.

In einem verteilten, cloudbasierten System kann es zum Beispiel schwierig sein, ein Problem, das auf mehreren Hosts auftritt, anhand von Protokollen oder anderen nicht korrelierten Signalen zu beheben. Wenn du jedoch eine Kombination von Signalen verwendest, kannst du anomales Verhalten systematisch untersuchen, indem du auf der höchsten Ebene deiner Servicemetriken beginnst und so lange iterierst, bis du herausfindest, welche Hosts am wichtigsten sind. Die Aufteilung der Logs nach Hosts bedeutet , dass du keine zentrale Speicherung und Indizierung aller Logs mehr brauchst, wie es bei einem Monolithen der Fall wäre. Um die Beziehungen zwischen den Teilkomponenten und Diensten in einem monolithischen oder verteilten System zu verstehen, musstest du früher die Beziehungen aller Systemkomponenten im Kopf behalten.

Wenn du stattdessen verteiltes Tracing verwenden kannst, um jeden einzelnen Schritt aufzuschlüsseln und zu visualisieren, musst du die Komplexität deiner Abhängigkeiten nur in dem Maße verstehen, wie sie sich auf die Ausführung einer bestimmten Anfrage auswirken. Wenn du verstehst, welche Aufruf- und Empfangscodepfade mit welchen Versionen der einzelnen Dienste verbunden sind, kannst du Probleme mit der Rückwärtskompatibilität und Änderungen, die die Kompatibilität unterbrochen haben, feststellen.

Die Beobachtbarkeit bietet einen gemeinsamen Kontext, der es den Teams ermöglicht, Probleme unabhängig von der Komplexität eines Systems auf kohärente und rationale Weise zu beheben, anstatt dass eine Person den gesamten Zustand des Systems im Kopf behalten muss.

Observabilität unterstützt DevOps- und SRE-Praktiken

Es ist die Aufgabe von DevOps- und SRE-Teams, Produktionssysteme zu verstehen und die Komplexität zu zähmen. Daher ist es selbstverständlich dass sie sich um die Beobachtbarkeit der Systeme kümmern, die sie aufbauen und betreiben. SRE konzentriert sich auf die Verwaltung von Diensten anhand von Service Level Objectives (SLOs) und Fehlerbudgets (siehe Kapitel 12 und 13). DevOps konzentriert sich auf die Verwaltung von Diensten durch funktionsübergreifende Praktiken, wobei die Entwickler die Verantwortung für ihren Code in der Produktion behalten. Anstatt mit einer Fülle von Warnmeldungen zu beginnen, die mögliche Ursachen für Ausfälle aufzählen, messen ausgereifte DevOps- und SRE-Teams alle sichtbaren Symptome von Benutzerbeschwerden und gehen dann mit Hilfe von Beobachtungswerkzeugen dem Ausfall auf den Grund.

Die Abkehr von der ursachenbasierten Überwachung und die Hinwendung zur symptombasierten Überwachung bedeutet, dass du in der Lage sein musst, die Fehler, die du in der Praxis siehst, zu erklären, anstatt wie bisher eine immer länger werdende Liste bekannter Fehlerarten aufzuzählen. Anstatt einen Großteil ihrer Zeit damit zu verbringen, auf eine Vielzahl von Fehlalarmen zu reagieren, die keinen Einfluss auf die für den Endnutzer sichtbare Leistung haben, können sich die Teams darauf konzentrieren, systematisch Hypothesen zu überprüfen und Abhilfemaßnahmen für tatsächliche Systemausfälle zu entwickeln. Darauf gehen wir in Kapitel 12 näher ein.

Über den Einsatz von Observability für Break/Fix-Anwendungsfälle hinaus verwenden vorausschauende DevOps- und SRE-Teams Engineering-Techniken wie Feature Flagging, kontinuierliche Überprüfung und Vorfallsanalyse. Observability verbessert diese Anwendungsfälle, indem sie die Daten bereitstellt, die für ihre effektive Anwendung erforderlich sind. Sehen wir uns an, wie Observability die einzelnen Anwendungsfälle unterstützt:

Chaos Engineering und kontinuierliche Überprüfung

Diese erfordern eine Beobachtungsmöglichkeit, um zu erkennen, wann das System im Normalzustand ist und wie es von diesem Zustand abweicht, während die Methode des Experiments ausgeführt wird.² Du kannst keine sinnvollen Chaos-Experimente durchführen, wenn du nicht in der Lage bist, den Ausgangszustand des Systems zu verstehen, das erwartete Verhalten während des Tests vorherzusagen und Abweichungen vom erwarteten Verhalten zu erklären. "Es hat keinen Sinn, Chaos-Engineering zu betreiben, wenn du nicht weißt, wie sich dein System im aktuellen Zustand verhält, bevor du das Chaos einführst."³

Merkmal kennzeichnen

Dies führt zu neuen Kombinationen von Flag-Zuständen in der Produktion, die du in Vorproduktionsumgebungen nicht erschöpfend testen kannst. Deshalb brauchst du eine Beobachtungsmöglichkeit, um die individuellen und kollektiven Auswirkungen der einzelnen Merkmalsausprägungen für jeden einzelnen Benutzer zu verstehen. Das Konzept, das Verhalten der einzelnen Komponenten zu überwachen, ist nicht mehr gültig, wenn ein Endpunkt auf verschiedene Arten ausgeführt werden kann, je nachdem, welcher Benutzer ihn aufruft und welche Feature Flags aktiviert sind.

Progressive Freigabemuster

Diese Muster, wie z.B. Canarying und Blue/Green Deployment, erfordern eine Beobachtungsmöglichkeit, um effektiv zu wissen, wann die Freigabe gestoppt werden muss und um zu analysieren, ob die Abweichungen des Systems vom Erwarteten eine Folge der Freigabe sind.

Analyse des Vorfalls und tadellose Obduktion

Dazu musst du klare Modelle über deine soziotechnischen Systeme erstellen - nicht nur darüber, was in dem fehlerhaften technischen System passiert ist, sondern auch darüber, was die menschlichen Bediener während des Vorfalls glaubten. Robuste Beobachtungstools erleichtern die Durchführung exzellenter Retrospektiven, indem sie einen ex-post-facto-Papierpfad und Details zur Verfügung stellen, die die Verfasser von Retrospektiven anregen.

Fazit

Mit der Weiterentwicklung der DevOps- und SRE-Praktiken und dem Wachstum des Plattform-Engineerings als übergreifende Disziplin werden unweigerlich weitere innovative Engineering-Praktiken in deinen Toolchains auftauchen. Aber all diese Innovationen werden davon abhängen, dass du deine modernen komplexen Systeme mit Hilfe von Beobachtbarkeit verstehen kannst. Der Wandel hin zu DevOps, SRE und cloudbasierten Praktiken hat einen Bedarf für eine Lösung wie Observability geschaffen. Im Gegenzug hat Observability auch die Fähigkeiten der Teams verbessert, die diese Praxis übernommen haben.

¹ Jonathan Smart, "Willst du eine agile Transformation durchführen? Don't. Konzentriere dich auf Flow, Qualität, Glück, Sicherheit und Wert", 21. Juli 2018.

² Russ Miles, Chaos Engineering Observability (Sebastopol, CA: O'Reilly, 2019).

³ Ana Medina, "Chaos Engineering with Ana Medina of Gremlin", o11ycast podcast, 15. August 2019.