Wie vorher DevOps, ist „Observability“ der neue Begriff, der verspricht, die IT-Welt auf den Kopf zu stellen. Beide Konzepte sagen ganz deutlich: „You build it, you run it.“ Wir haben mit Konstantin Diener und Roman Neß darüber gesprochen, was das in der Praxis bedeutet.

Torsten Bøgh Köster: Danke, dass ihr euch Zeit für dieses Interview genommen habt. Als Softwaredienstleister 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 Diener: 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 mit 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 dieselben Menschen 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 Softwareentwickler vorher nie interessiert (Abb. 1)! Wenn du es also ernst meinst mit „you build it, you run it“, dann wirst du auf jeden Fall so etwas wie „Observability lite“ brauchen. Denn du willst ja wissen, was in deiner Anwendung passiert.

Roman Neß: Als Entwickler:in geht man an das Thema Softwarebetrieb 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 Lognachrichten erkennen.

Mein erster Berührungspunkt war, als ich vor vielen Jahren in einem Team war, 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.

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

Diener: Wir wurden eben in diesen Dev- und Ops-Silos dazu ermutigt. In der Softwareentwicklung 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 Entwicklungsteams 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 und Agilität änderte die Philosophie dann dahingehend, ein Problem auch von denjenigen lösen zu lassen, die es am ehesten können.

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

Diener: 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.

Neß: Viele Praktiken aus DevOps sind auch nötig und notwendig 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.

Diener: DevOps ist Agilität über die Softwareentwicklung hinaus. Im Endeffekt haben wir nicht eine kleine, selige agile Insel der Softwareentwicklung 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 Technologiestacks (wenige Betriebssysteme, Application-Server-Produkte etc.). Wenn man diese Journey direkt mit Infrastructure as Code oder Observability beginnen würde, hätte man schier unendlichen Aufwand. In 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.

Köster: Wie lässt sich Observability gegnüber Monitoring und Logmanagement abgrenzen? Wann „mache ich“ Observability?

Neß: Logmanagement und Monitoring sind Praktiken, die für Observability notwendig sind, genau wie CI/CD und IaC Praktiken von DevOps sind. Die DevOps-Praktiken sind definitiv ein Beschleuniger für Observability, und ganz ohne sie 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.

Diener: 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äherkommen kann, man aber niemals erreichen wird. Es gibt keine hundertprozentige 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.

Neß: Andersherum kann es dann auch reichen, Observability so lange zu implementieren, bis man seine Incidents beheben kann und nicht mehr das Gefühl hat, vor einer Blackbox zu sitzen.

...