Interview – Unsere DevOps Profis sprechen über Observability |cosee

Danke, dass ihr euch Zeit für dieses Interview genommen habt. Als Software-Dienstleister erstellt ihr Software für Kunden, begleitet aber auch DevOps-Transformationen. Wann seid ihr das erste Mal mit dem Thema Observability in Berührung gekommen?

Konstantin: Hier möchte ich zwischen dem Thema Observability und dem Schlagwort unterscheiden. Das Schlagwort habe ich zum ersten Mal vor ein paar Jahren auf einer DevOpsCon gehört. Mit dem Thema verhält es sich für uns so ähnlich wie DevOps. Unsere Kunden hatten nie einen Betrieb, an den wir Software hätten übergeben können. Das heißt, dass die Leute, die die Software gebaut haben, diese auch von Anfang an betrieben haben. Und irgendwann haben wir gelernt: Das heißt DevOps.
Ebenso bei Observability, denn beide Themen haben einen gemeinsamen Ursprung, nämlich: „you build it, you run it“. Wenn du „you build it, you run it“ machst, hast du keine Trennung mehr zwischen Dev und Ops. Da nun die Menschen dieselben Menschen sind, die die Software bauen und betreiben, wird es für sie auf einmal interessant, wie sich dieses Stück Software in Produktion verhält. Das hat die Software-Entwickler vorher nie interessiert! Wenn du es also ernst meinst mit „you build it, you run it“, dann wirst du auf jeden Fall so etwas wie „Observability light“ brauchen. Denn du willst ja wissen, was in deiner Anwendung passiert.

Roman: Als Entwickler geht man an das Thema Software-Betrieb ganz anders ran. Durch die Applikationsmetriken kann man auf das Verhalten der Anwendung rückschließen. Auch im Fehlerfall kann man als Anwendungsentwickler wesentlich schneller die wirklich wichtigen Log-Nachrichten erkennen.
Mein erster Berührungspunkt war, als ich vor vielen Jahren in einem Team, das eine verteilte Legacy-Anwendung in die Cloud gehievt, betrieben und weiterentwickelt hat. Anfangs waren wir trotz aller Logs und Metriken öfters mal im Blindflug, wenn die Anwendung als Folge von Incidents einfach vollständig out-of-service ging. Damals kannten wir den Begriff Observability noch nicht, haben aber versucht, aus vorhandenen Metriken abzuleiten, wie „healthy“ die Anwendung ist und ob sich ein Incident anbahnt.

Eigentlich ist es doch ganz schön rücksichtslos von den Entwicklungs-Teams, dass sie sich erst mit dem Betrieb einer Software beschäftigen, wenn sie es selbst tun müssen, oder?

Konstantin: Wir wurden eben in diesen Dev- und Ops-Silos dazu incentiviert. In der Software-Entwicklung ging es immer darum, schnell viele Features zu kloppen. Wenn jemand anderes das dann ausbaden muss, ist es ja nur ein menschliches Verhalten, auf das hin zu optimieren, an dem man gemessen wird: „Features kloppen“. Ganz analog verhält es sich in Organisationen mit einer dedizierten QA- oder Testabteilung. Da werden sich Entwicklungs-Teams weniger intensiv mit dem Thema Testen auseinandersetzen, weil die wissen: Da kommt noch jemand und sorgt später für Qualität im Produkt.In der Vor-DevOps-Ära gab es unterschiedliche Zielsetzungen: Operations hatte das Ziel, für einen möglichst stabilen Betrieb zu sorgen und die Entwicklung sollte möglichst viele Features entwickeln. So kommt es dann zustande, dass Anwendungen entstehen, die „niemand betreiben“ kann und will. DevOps oder Agilität änderte die Philosophie dann dahingehend, ein Problem auch von denjenigen lösen zu lassen, die dies am ehesten können.

Als ganz spitze These formuliert: Hätten wir uns den DevOps-Ausflug sparen können, wenn wir Observability vorher gelöst hätten?

Konstantin: Der DevOps-Ausflug beinhaltet noch wesentlich mehr Aspekte. Observability ist mit Sicherheit ein wichtiges Thema davon, aber nicht alles. DevOps bedeutet Kollaboration und gemeinsame Verantwortung – u. a. für die Infrastruktur.

Roman: Viele Praktiken aus DevOps sind auch nötig und notwending für Observability. Das beginnt bei CI/CD, dass die Infrastruktur als Code vorliegt, und vor allem, dass die Wand zwischen Betrieb und Entwicklung eingerissen wird.

Konstantin: DevOps ist Agilität über die Software-Entwicklung hinaus. Im Endeffekt haben wir nicht eine kleine, selige, agile Insel der Software-Entwicklung zwischen Silos mit Wasserfällen. Observability gehört zu DevOps dazu. Im Kleinen haben wir durch TDD kontinuierliches Feedback, im Großen brauche ich dieses Feedback auch. Und das gibt es mit Observability.
Darüber hinaus gibt es im 2018er State of DevOps Report [1] die DevOps Journey. Darin finden sich Maßnahmen, die mit Observability nichts zu tun haben, sich aber positiv darauf auswirken. Diese Maßnahmen sollen in einer empfohlenen Reihenfolge implementiert werden. Ganz am Anfang steht z. B. die Normalisierung des Technologie-Stacks (wenige Betriebsysteme, Application-Server-Produkte etc.). Wenn man diese Journey direkt mit Infrastructure as Code oder Observability beginnen würde, hätte man schier unendlichen Aufwand. Im Bezug auf Observability würde das bedeuten, Metriken aus den unterschiedlichsten Betriebssystemen und Anwendungen einzusammeln – man würde in den unterschiedlichsten Daten quasi ersaufen, ohne daraus sinnvolle Informationen zu ziehen. Observability in einer bestehenden Systemlandschaft bedeutet also, erst einmal die ersten Schritte aus der DevOps Journey anzugehen.
Wenn man nach der Philosophie „you build it, you run it“ leben möchte, sind die Bausteine der DevOps Journey unerlässlich – zu denen auch Observability gehört.

Wie lässt sich Observability zum Monitoring und Log-Management abgrenzen? Wann „mache ich“ Observability?

Roman: Log-Management und Monitoring sind Praktiken, die für Observability notwendig sind, genau wie CI/CD und IaC Praktiken von DevOps sind. Die DevOps Practices sind definitiv ein Beschleuniger für Observability und ganz ohne diese Praktiken wird es schwierig, Observability zu erreichen. Wann man allerdings „Observability macht“, weiß ich auch nicht. Das hängt sicher auch von der Komplexität der jeweiligen Plattform ab. Wenn ich aber on-call bin und nachts nicht schlafen kann, mache ich vermutlich nicht genug Observability!

Konstantin: Man kann genauso wenig „Observability machen“ wie man „DevOps macht“. DevOps ist keine Rolle, sondern ein Mindset. Ich denke, DevOps und Observability sind beides Ziele, denen man nur asymptotisch näher kommen kann, die man aber niemals erreichen wird. Es gibt keine 100 %-ige Observability.
In der DevOps Journey gibt es einen Schritt 0 (klar: Informatiker), der die „Reisevorbereitungen“ für die DevOps Journey beschreibt. Dort sind es z. B. Continuous Integration und Continuous Improvement. Analog dazu gibt es für Observability auch einen Werkzeugkasten, der u. a. mit Logging, Metriken, Tracing und Alerting gefüllt sein muss. Ohne diese Dinge hat es keinen Sinn, mit der Observability Journey zu beginnen.

Roman: Anders herum kann es dann auch reichen, Observability so lange zu implementieren, bis man seine Incidents beheben kann und nicht mehr das Gefühlt hat, vor einer Blackbox zu sitzen.

Konstantin: Genau! Es gibt bei Observability definitiv ein „good enough“ ganz analog zu TDD. Wenn sich jemand mit 100 %iger Test-Coverage brüstet, kann man gut und gerne entgegnen, dass das Erreichen der letzten 10 % Coverage wahrscheinlich reine Verschwendung war. Denn dort beginnt man, Tests für triviale Dinge wie Getter und Setter zu schreiben. Mit TDD ist dieses „good enough“ die Sicherheit, sagen zu können, dass eine Software-Komponente tut, was sie soll. Analog bedeutet das für Observability, dass ich sicher sagen kann, was in meinem System passiert. Dann habe mich dieser Asymptote der Observability ausreichend genähert. Alles weitere wäre Ressourcenverschwendung.

Neben der Anwendungsentwicklung betreibt ihr auch Cloud-Infrastruktur für Kunden. Wie wirkt sich Observability beim Aufbau und im Betrieb einer Cloud-Infrastruktur aus?

Roman: Observability fließt schon in die Planung einer Cloud-Infrastruktur ein. Es geht nicht nur darum, welche Services benutzt werden, sondern auch darum, zu definieren, wo die Logs landen oder wie das Alerting aufgesetzt wird. Man fragt sich von Anfang an, ob man genug Observability hat, um sinnvoll auf Incidents reagieren zu können. Gerade bei Serverless-Architekturen ist Kostenkontrolle oder Kostenoptimierung ein Treiber für Observability. Man sieht schnell, welche Teile der Anwendung vielleicht überdimensioniert sind. Dazu kommt, dass sich bei vielen Services in den Public Clouds erweiterte Infrastrukturmetriken per Option aktivieren lassen.

Konstantin: Ich glaube, dass Observability in Cloud-Umgebungen einem psychologischen Effekt dient. In seinem eigenen Rechenzentrum betreibt man dedizierte Infrastruktur. Man weiß, wo sie im Keller steht, kann im Notfall hingehen, Tastatur und Monitor anschließen, sich einloggen und debuggen. Das gibt natürlich ein gewisses Gefühl der Sicherheit. In der Cloud verliert man diese physische Verbindung zum Server und damit auch die Möglichkeit der Fehlersuche.

Kann Observability wirklich bei einer Cloud-Migration helfen? In meiner Erfahrung sind die On-Premise-Infrastrukturen eher diejenigen, auf die man ein Auge haben sollte. Beim Cloud-Provider sitzen Menschen, die ihr Handwerk zu 100 % verstehen.

Roman: Dazu kommt, dass eine nicht funktionierende virtuelle Maschine in der Cloud einfach neu daneben gestellt werden kann. Das geht nicht, wenn man bei der IT-Abteilung eine VMWare-Instanz bestellt hat. Dennoch ist Observability im Kontext einer Cloud-Migration wichtig, um festzustellen, wie die Anwendung sich in der Cloud-Umgebung verhält.

Konstantin: Die Standard-Anwendungsarchitektur hat sich in den letzten 10 Jahren weiterentwickelt. Wo früher ein Monolith neben einer Datenbank stand, sieht es im Cloud-Zeitalter grundlegend anders aus. Wenn man Cloud „richtig“ macht, kommt inzwischen ein ganzer Zoo von Managed Services zum Einsatz. Das reicht von der Datenbank über das Login bis hin zum Message Queueing. Und überall dort fehlt die Möglichkeit, per SSH in Logdateien zu schauen.
Cloud-Native wirkt als Beschleuniger für den Entwicklungsprozess. Das kann ich an der Entwicklung von cosee sehen. Vor fast zehn Jahren haben wir klassisch VMs in der Cloud gemietet und irgendwann festgestellt, dass es noch mehr Managed Services als die Datenbank gibt. Mit einer wachsenden Nutzung von Managed Services, kommt man am Thema Observability nicht mehr vorbei. Du hast dann eben „das eine Logfile“ nicht mehr.

Roman: Kelsey Hightower sagt treffend, dass die gleiche Software heutzutage nicht zweimal auf demselben System läuft. Im Container-Zeitalter weißt du nicht mehr, auf welcher Maschine dein Container läuft. Und selbst die Ausführung auf der gleichen Maschine garantiert nicht, dass eine Software identisch funktioniert. Für die Menschen in der Software-Entwicklung ist es einfach viel undurchsichtiger geworden, wo unsere Software läuft und wie sich der Stack aus Plattform, Virtualisierung und Hardware untendrunter verhält.

In den Cloud-Migrationen, an denen ich mitgewirkt habe, setze ich gerne auf Open Source Observability-Infrastruktur. In Summe ist das aber ein ganz schön massiver Kostentreiber, sowohl zeitlich als auch im Hinblick auf die Cloud-Ressourcen.

Roman: Das ist definitiv ein wichtiger Punkt. Gerade in kleineren Projekten möchte der Kunde eine Software, die Cloud native läuft, deren Kosten aber nicht aus dem Ruder laufen. In einem solchen Umfeld sind SaaS-Lösungen für Observablity sehr attraktiv, weil sie ein sinnvolles Feature-Set mitliefern und preislich mit der Größe der Infrastruktur skalieren.

Konstantin: Wir haben jetzt viel über technische Metriken gesprochen. Was aber wesentlich wichtiger für schnelles Feedback ist, sind Business-Metriken. Für Netflix z. B. ist die wichtigste Metrik „(stream) starts per second“. Wenn diese Metrik Anomalien aufzeigt, deutet das auf ein wichtiges Problem hin. Und solche Informationen kommen eben nicht direkt aus Log-Dateien.

Roman: Das stimmt. Hardware-Metriken zeigen dir oftmals nur das Symptom an, nicht aber die Ursache. Wenn die CPU-Load steigt, kann das auf ein Problem hindeuten, muss aber nicht. Auch die Art des Problems ist völlig unklar: Ansteigender CPU-Load kann bedeuten, dass die User viele Retries machen, weil irgendetwas nicht funktioniert. Vielleicht ist es aber auch ein Hardware-Problem oder ein Hintergrund-Job erzeugt einfach zu viel Last, weil er nie gut optimiert wurde.

Oder sie sagen dir einfach, dass dein Server etwas für sein Geld tut. Hardware-Metriken sind halt so unglaublich einfach zu erheben und sehen immer so schön vollständig aus. Deshalb frage ich POs gerne, an welchen Metriken sie erkennen, dass ihre Anwendung jetzt gerade Geld verdient.

Konstantin: Eric Riess nennt solche Metriken in Lean Startup [2] „Vanity Metrics“-Metriken, die sich leicht erheben lassen, dir im Zweifel aber gar nichts sagen.

Gibt es für das Monitoring von (Cloud-)Infrastruktur einen Observability Stack, den ihr empfehlen könnt und/oder auch in der Praxis einsetzt? Wie groß ist der Trade-Off zwischen SaaS-Lösungen und Open-Source-Lösungen?

Roman: Eine klare Empfehlung finde ich schwer, es kommt ganz auf die Anwendung an. Wenn eine Anwendung als Container in einer Managed Platform wie z. B. ECS + Fargate läuft, um Betriebsaufwand zu vermeiden, macht es keinen Sinn, selbst einen Open-Source-Stack für Obervability zu betreiben. SaaS-Lösungen haben außerdem den Vorteil, dass sie immer außerhalb meiner Infrastruktur laufen, was bei Eigenbetrieb nicht immer zu bewerkstelligen ist. Wenn man z. B. Kubernetes-Metriken mit einem Prometheus sammelt, der im selben Cluster läuft, könnten die Metriken genau dann nicht verfügbar sein, wenn man sie am meisten braucht. Aber SaaS-Lösungen können je nach Cloud-Architektur auch sehr teuer werden, teilweise teurer als die eigentliche Infrastruktur, wenn die Container klein und zahlreich genug werden.
In größeren Microservice-Architekturen kann eine Open-Source-Lösung wiederum von Vorteil sein, vor allem da sie wohl weniger kosten wird als eine SaaS-Lösung. Dann lohnt sich meist auch der zusätzliche Aufwand, diese Lösungen selbst zu hosten und warten.

Konstantin: Die Metapher von dem Bobby-Car, das auf einem Sattelschlepper transportiert wird, ist auch für die Auswahl der Observability-Lösung sehr passend. Ich würde auch immer mit einer SaaS-Lösung beginnen, wir nutzen hier gerne New Relic. Es gibt aber einen Punkt, an dem das Preis-Leistungsverhältnis nicht mehr stimmt, an dem man sich entscheiden muss, wie es weiter geht. Vielleicht ist die Anwendung so gewachsen und ich habe so spezielle Anforderungen, dass ich bereit bin, mir etwas eigenes zu bauen. Wenn man aber von Anfang an etwas eigenes baut, investiert man im Zweifel Geld in eine überdimensionierte Lösung, die man so gar nicht benötigt.
Was aber auch klar ist: Mit dem Einsatz von SaaS-Lösungen entsteht i.d.R. ein Vendor-Lock-In.

Wie groß ist denn dieser Vendor-Lock-In? Ich habe auch schon Migrationen weg von New Relic gemacht. Deren Artefakte im Code waren überschaubar.

Roman: Inzwischen nutzen viele Anbieter standardisierte Annotations von OpenTelemetry [3]. Und dieses Customizing braucht man eben, wenn man z. B. Tracing in speziellen asynchronen Jobs aktivieren möchte.

Konstantin: Viele Features der proprietären Lösung sind im Opensource-Pendant oft so erstmal nicht vorhanden. Es ist ein immenser Aufwand, die Features nachzubauen, die z. B. New Relic dir bietet. Obwohl es Open Source Tools gibt, kostet dich das eine ganze Stange Aufwand – und damit auch Geld.

Allerdings sieht man durch den Start mit einem SaaS-Anbieter schnell, welche Features der Observability man wirklich täglich nutzt. Auf diese Features konzentriert man sich dann beim Umstieg auf eine Open-Source-Lösung.

Konstantin: In einer rationalen Welt mag das so ein, in der Realität gewinnt man all diese Features lieb und möchte sie auch nicht mehr weggeben – man will sich halt nicht verschlechtern. (lacht)

Für das Überwachen von (Cloud-)Infrastruktur gibt es sicherlich Anleitungen und Best-Practises. Wie schaut es mit dem Überwachen von selbst entwickelten Anwendungen aus?

Roman: Ich glaube, ich würde die Überwachung von Infrastruktur und Anwendungen gar nicht so klar trennen. Nutzt die Anwendung z. B. eine Datenbank, ist eine Observability-Überwachung der Datenbank unerlässlich. Wir müssen identifizieren, wie effizient die Anwendung auf die Datenbank zugreift. Tut sie das nämlich nicht und die Datenbank fällt aus, ist das kein Problem der Datenbank, sondern primär der Anwendung. Man muss eben bei Observability nicht nur dafür sorgen, dass die eigentliche Anwendung samt entsprechender Infrastruktur healthy ist. Genau so wichtig ist es, Observability für die Services zu haben, von denen die Anwendung abhängt.

Konstantin: Ein ganz konkretes Beispiel aus der Praxis war, dass in einem Projekt Web Requests auf einmal langsam wurden. Wir haben mittels Tracing schnell gesehen, dass die Datenbank langsam ist, das aber nicht mit der Menge und Art der Requests zu korrelieren war. Irgendwann ist durch Zufall aufgefallen, das parallel ein Report auf der Datenbank lief, der das System zu glühen brachte. An dem Beispiel sieht man, dass Observability über die Anwendungsgrenzen hinaus funktionieren muss. Sonst sucht man sich im Zweifel die Finger wund.

Roman: Wenn man ein Verständnis davon hat, wo in der Anwendung mögliche Bottlenecks liegen bzw. wo Incidents zu erwarten sind, kann man sich zunächst auf diese Bereiche fokussieren. Wenn ich eine „gemeine“ REST-Anwendung ohne asynchrone Tasks und Background Jobs baue, liegen die meisten Bottlenecks vermutlich in der Datenbankkommunikation. Dann brauche ich Traces inklusive ausgeführter DB-Queries und eine Möglichkeit, langsame Calls zu erkennen. Wenn in der Testumgebung schon Observability vorhanden ist, dann kann ich schon vor der Produktion erkennen, wo Indizes in der DB fehlen oder nicht korrekt genutzt werden. Dafür ist immens wichtig, nicht nur Funktionsaufrufe innerhalb meiner Anwendung, sondern auch Datenbank-Queries im Trace identifizieren zu können.

Konstantin: Auch unheimlich wertvoll sind Dark Releases, weil die es ermöglichen, ein Feature auf Produktionsdaten in der Produktionsumgebung auszurollen, es aber eben noch nicht zu veröffentlichen. So sieht das Entwicklungs-Team schon früh, wie sich das Feature von der Performance her verhält.

Wie fließt die Denkweise von Observability in die Anwendungsentwicklung ein? Gibt es Auswirkungen auf die Scrum-Planung oder die Definition of Done? Was sind hier die Komplexitätstreiber? Gibt es Low Hanging Fruits, die sich mitnehmen lassen?

Konstantin: Wenn wir das Thema Observability zu Ende denken, dann sind die User Stories Hypothesen, die ich messe. Die kann ich nur messen, wenn ich entsprechende Messpunkte in meiner Anwendung habe.

Roman: Man kann natürlich Observability auch als nicht funktionale Anforderung (NFA) begreifen, aber ich glaube, dass das nicht passt. Wenn in der Definition of Done steht, dass man etwas loggen, Metriken exportieren und Traces aufzeichnen soll, sagt das nichts über die Qualität der Daten aus. Observability muss aber auch verhältnismäßig zum Aufwand sein. Wenn meine Anwendung ein Lambda ohne externe Abhängigkeiten ist, sollte ich wesentlich weniger Aufwand betreiben, als wenn ich Abhängigkeiten zu anderen Services habe.
Low Hanging Fruits sind sicherlich gute Metadaten, mit denen ich Logs, Metriken und Traces annotiere (z. B. UserAgent, tenantId, userId, appVersion etc). Damit mache ich mir das Leben im Fehlerfall sehr viel einfacher. Generell ist der erste nächtliche Incident ein Weckruf – spätestens dann ist man für das Thema sensibilisiert. Von da an hat Observability immer Einfluss auf die Architektur und die Resilienz meiner Anwendung.

Konstantin: Wir entwickeln ja Änderungen an Software-Produkten, weil wir beim Kunden einen gewissen Effekt erzeugen wollen. DevOps enthält das Vorgehen des schnellen Feedbacks. Das bezieht sich aber nicht nur auf die CPU-Last, sondern vor allem auf Produkthypothesen. Im Endeffekt habe ich den vollen Feedback-Zyklus nur, wenn ich in meinen Kennzahlen auch die gewünschte Veränderung sehe.

Im Gegensatz dazu fehlen dir bei der Hypothesenvalidierung durch Experimente die kontinuierlichen Metriken. Du validierst die Hypothese einmalig, schließt die Story ab, misst aber nicht, ob sich das Feature vielleicht nach der Validierung im Laufe der Zeit verwässert. Habt ihr eine Rule of Thumb, wie und wann sich Anforderungen an Observability während der Entwicklung am besten umsetzen lassen? Sollte man von Anfang mit „Observability Driven Development“ vorgehen?

Konstantin: Die Frage lässt sich für Tests und Infrastruktur as Code ähnlich stellen: Wenn man feststellt, dass es jetzt sinnvoll wäre, Tests zu schreiben, Terraform zu nutzen oder Observability zu haben, ist es deutlich zu spät.

Roman: Die Aussage „Observability brauchen wir erst zum Go-Live“ ist im Prinzip die Gleiche wie „Tests brauchen wir erst, wenn die Anwendung feature-complete ist“. Der Vergleich mit TDD ist hier auch ganz treffend. Wenn man Software mit TDD entwickelt, schreibt man Code automatisch so, dass er besser testbar ist. Wenn man von Anfang an Observability aufsetzt und im Hinterkopf behält, hat das ebenso Einfluss auf Software und auch Architektur.

Konstantin: Im Endeffekt gilt: Wir werden den perfekten Zeitpunkt nie erwischen, deshalb sollte wir immer direkt damit anfangen. Observability aber auch Tests sind für mich wie eine Krankenversicherung. Die schließe ich auch nicht ab, wenn ich krank bin, sondern vorher.

Davon unbenommen bleibt aber die DevOps Journey, die besagt, dass es durchaus Dinge gibt, die ich vor Observability machen sollte?

Konstantin: Wenn ich an einem bestehendem großen aber ungetesteten Software-Monolithen Änderungen vornehme, ist es unrealistisch, vorher sechs Monate Feature Freeze auszurufen und erstmal alle Tests zu schreiben. In diesem Fall gilt für Observability – wie bei Tests – die Boyscout-Rule. Für alle Stellen, die ich anfasse, schreibe ich Tests und sorge für Observability.

Roman: Wenn in einem unserer Systeme ein neuartiger Incident auftritt, bauen wir gerne eine entsprechende Metrik, die den Fehler sichtbar macht. So können wir das Problem beim nächsten Mal frühzeitig erkennen.

Observability setzt darauf, Metriken, Logdaten und Traces einzusammeln und zu korrelieren. Aber gerade die Korrelation von Events ist schwierig, wenn die Daten in getrennten Silos gesammelt werden. Wie geht ihr hier vor? Und wie wichtig ist die Korrelation für die Tool-Auswahl?

Roman: Das ist ein wichtiges Argument für SaaS-Anbieter. Die bieten eine gute Korrelation und darüber hinaus oft noch AI-gestützte Korrelation, was auch hilfreich sein kann. Wenn das Tool direkt mitteilt, dass 98 % der Fehlertransaktionen von Android-Geräten kommen, ist das großartig. Bei Open Source Tools sehe ich in der Korrelation zwischen verschiedenen Silos den größten Raum für Verbesserung in der Zukunft.

Konstantin: „Damals“ zu SOA-Zeiten war die Correlation ID in aller Munde, mit deren Hilfe zusammengehörige Requests und Transaktionen identifiziert werden konnten.

Roman: Und heute nehmen wir in Microservice-Architekturen dafür die Request ID, welche vom eingehenden Request über den Mapped Diagnostic Context (MDC) des Log-Frameworks wieder an den ausgehenden Request geschrieben wird. Auch wird die Request ID mit jedem Trace an das Observability Tool geschrieben.

Das heißt aber, dass ich bei SaaS-Lösungen diese Detailarbeit selbst übernehmen muss. Alle Filterdimensionen und Metadaten, die die SaaS-Lösung nicht automatisch erkennt, müssen manuell den Analysedaten hinzugefügt werden.

Roman: Bisher haben wir das immer so gemacht. Es kann sein, dass sich das mit der zunehmenden Verbreitung des Open-Telemetry-Standards zumindest ohne Vendor-spezifische Annotationen machen lässt.

Observability schafft Transparenz im Anwendungsbetrieb. Wie wirkt sich das auf die Anwendungsentwickler aus? Erzeugen transparente Kennzahlen wie Downtimes, Antwortzeiten, Fehlerraten mehr Druck?

Roman: Operations ist ja nur dann ein mieser Job, wenn man eine Blackbox betreibt. Eventuell lässt sich eine Anwendung sogar nicht sinnvoll betreiben, weil sie eben nicht beherrschbar ist. Das ist ja genau der Zustand, den wir mit Observability umgehen wollen.

Konstantin: Der Druck auf eine gewisse Personengruppe wird sich durchaus erhöhen. Wenn ich es in der Entwicklung gewöhnt war, „geile Features“ zu schreiben und meine Software über die Mauer in Richtung Betrieb zu werfen, dann habe ich nun ein Problem. Denn in Zukunft werde ich nachts aufstehen und meine Software richten müssen.
Was auch nicht mehr funktioniert, ist, dass „Rockstar Developer“ den „coolen fancy Teil“ einer Software entwickeln und andere arme Menschen im Team dann den Gruntwork machen. Diese Rockstars müssen sich in Zukunft auch die Hände schmutzig machen. Denn Observability deckt auf, dass deren total elaborierter Code zwar toll aussieht, aber nicht in Produktion funktioniert.

Roman: Man muss als Entwickler das Mindset annehmen, dass es nicht mehr um möglichst viele Features geht, sondern vor allem um einen stabilen Betrieb. Ein konkretes Beispiel ist die Messe SPIEL.digital 2020. Zum Start der Messe hatten wir einen Incident, aber gegen Mittag konnten wir sehen, dass die Antwortzeiten wieder im single-digit millisecond Bereich und die Fehlerrate verschwindend gering waren. So konnte ich trotz on-call ruhig durchschlafen.

Dank umfassender Transparenz kann ich bei Ausfällen von Infrastruktur oder einer Anwendung zielgerichtet alarmieren. Wer fängt diese Alarme in euren Projekten auf? Gibt es eine Grenze zwischen Infrastrukturalarmen und Anwendungsalarmen und wie zieht ihr diese? Wie nehmen Entwickler diese plötzliche Verantwortung an und: Hat dies Einfluss auf die Anwendungsentwicklung? („you build it, you run it“)

Konstantin: Wir bauen Software schon immer so, als würden wir sie selbst betreiben, auch wenn das vielleicht ein Kunde selbst übernimmt.

Roman: Bei uns automatisiert das gleiche Team, das die Anwendung baut, auch die Infrastruktur mit Terraform.
Wir können unser Wissen aus der Entwicklung der Anwendung nutzen, um Alerts sinnvoll und feingranular zu konfigurieren. Gleichzeitig machen wir uns schon während der Entwicklung Gedanken, ob das, was wir heute bauen, sich morgen auch sinnvoll betreiben lässt. Bei Alerts unterscheiden wir lediglich nach User-Impact oder nicht. Das ist für uns das Kriterium dafür, ob jemand nachts aufstehen muss oder nicht. Alle Alerts laufen in PagerDuty zusammen und alarmieren dann je nach Tageszeit entweder den Entwickler, der on-call ist oder den Slack-Channel des Teams.
Anfangs hatten gerade unerfahrene Team-Mitglieder großen Respekt vor der On-Call-Verantwortung. Da aber alle Alerts auch im Slack Channel landen und spätestens im nächsten Daily thematisiert werden, können auch neue Team-Mitglieder schnell abschätzen, worauf sie sich da einlassen.

Wenn ich heute mit Observability in meiner Infrastruktur und in meiner Anwendung beginnen wollte: Was empfehlt ihr mir? Wo und wie beginne ich?

Roman: Es kommt natürlich darauf an, an welchem Punkt man in der DevOps Journey steht. Um mit wenig Investitionen einen Blick in seine Anwendung zu werfen, kann man mittels eines Trials oder Free Tiers ein SaaS Tool schnell testen. Sind schon Metriken in der Cloud oder in Prometheus vorhanden, sollte man sich die erst einmal anschauen. Vielleicht sind die ja eine Basis, um sinnvolle Alerts einzurichten. Auf jeden Fall muss sich das gesamte Entwicklungs-Team mit dem Thema Observability auseinandersetzen.

[1] https://services.google.com/fh/files/misc/state-of-devops-2018.pdf
[2] Eric Ries: „Lean Startup“ (2011)
[3] https://opentelemetry.io/docs/instrumentation/java/

Observability? DevOps? Wenn nicht nur das „Dev“ wichtig ist, sondern auch das „Ops“