IT-Administrator: Was ist unter Observability zu verstehen?

Oliver Oehlenberg: Observability ist eine Weiterentwicklung des Monitoring. Ich vergleiche das immer recht gerne mit Astronomie. Dort haben die frühen Wissenschaftler angefangen mit dem Fernrohr und dem sichtbaren Licht die Planeten zu beobachten, dann haben sie kosmische Nebel gesehen oder auch unseren Mond betrachtet. Das hat sich dann weiterentwickelt, sodass nicht nur das sichtbare Licht, sondern alles Mögliche zum Beispiel mit Radioteleskopen beobachtet wurde. Und da kommen wir jetzt in die Observability rein. Dass ITVerantwortliche nicht mehr nur sehen, welche Dienste "OK" sind, welche Daten von A nach B fließen, sondern dass jetzt verschiedene Aspekte wirklich zusammenkommen – zum Beispiel Daten aus einer Netzwerkperspektive mit solchen aus dem Desktop.

Wir haben zuletzt mit einem großen Unternehmen aus der Versicherungsbranche ein Projekt durchgeführt, in dem der komplette Erstattungsfall digitalisiert werden sollte. Der Versicherungsnehmer sollte auf einer Webseite den Fall melden, alle Informationen hochladen und ein Workflow das Ganze automatisch analysieren. Und aus rechtlichen Gründen war es wichtig zu prüfen, ob zum Schluss wirklich ein Brief an den Versicherungsnehmer rausging. Ein Monitoring würde nun checken, ob der Prozess oder Bestandteile davon reibungslos funktionieren. Observability bringt die einzelnen Aspekte zusammen, und das nicht nur aus der technischen Sicht, sondern auch aus der Workflow-Sicht: Welche Erfahrungen hat der Kunde gemacht? Nutzt er die Anwendung wie gedacht? Es ist also im Detail erkennbar, wie dieser Prozess durchläuft. Somit ist Observability mehr als der technische Blick auf die Daten, sondern einer auf die eigenen geschäftlichen Abläufe.

Also ich würde sagen, der normale Administrator kann über Observability einiges rausholen, weil ein Teil davon eben ist, Daten automatisch zu bewerten. Gerade bei einem Exchange-Server kommen lauter Fehlermeldungen hoch und der Admin muss hingehen und prüfen, was da eigentlich passiert. Das erfordert also teilweise Handarbeit. Doch in der Workflow-Betrachtung über Observability stecken sehr viele Logikelemente der einzelnen Exchange-Services, die eine automatische Vorabanalyse erlauben und so vermeiden, jeder einzelnen Fehlermeldung hinterherzurennen. Der Administrator erkennt schneller, ob ein wichtiges Problem vorliegt, von dem auch die Anwender betroffen sind.

Es ist streng genommen die Datenqualität. Monitoring prüft meistens nur eine bestimmte technische Metrik, nehmen wir zum Beispiel einfach mal die CPU-Last eines Exchange-Servers. Observability zeigt die Auswirkungen dessen, beim User, im Serversystem – eben über den kompletten Service. Es ist übrigens auch eine der grundlegenden Methoden von Observability, dass eben nicht nur auf den Status gewartet wird, sondern die angelieferten Daten verifiziert sind. Sprich, die Daten, die jetzt über die Leitungen gehen, sind auch die Daten, die ich erwartet habe. Und das ist eigentlich der Kern dieser Technologie, die nicht nur Statusinformationen sammelt, sondern weitere Daten zur Analyse anfordert. Sozusagen der sprichwörtliche Blick über den Tellerrand.

Ja, es ist ein Problem, dass die Hersteller immer nur ihre eigene Blickweise auf ihre Anwendung haben. Dementsprechend stellen sie auch nur APIs oder Event-Logs aus ihrem eigenen Szenario zur Verfügung. Wir als Observability-Anbieter umgehen dies zum Beispiel, indem wir den Netzwerkverkehr in unsere Analysen integrieren. Und mein persönlicher Favorit ist immer das, was beim Anwender passiert. Das heißt, wenn ich am Endgerät oder in der Webanwendung Elemente von Observability installiere, die nachverfolgen, wie lange zum Beispiel ein User warten muss, dann kann ich diese Informationen wieder zurück in das eigene System liefern und korrelieren. Nur aus den technischen Daten kann der Admin – um auf das Beispiel Exchange zurückzukommen – nicht ablesen, dass sich beim Endanwender der Kalender sehr langsam öffnet. Die zahlreichen Elemente zwischen dem Exchange-Server und dem Endgerät verhindern, dass der IT-Verantwortliche das herausfindet. Observability zeigt die Quelle einer solchen Störung. Aber, um auf die Frage zurückzukommen, Observability funktioniert immer dann, wenn mehrere Datenquellen zur Verfügung stehen.

Also grundsätzlich ist es meistens so, dass die Daten teilweise schon in diesen ITFachabteilungen liegen. Diese können also erstmal weiter wie gewohnt arbeiten. Für Observability wandern diese Daten in einen Daten-Lake oder sagen wir einfacher in ein dediziertes System. Dort können die verschiedenen IT-Profis reinschauen und sehen, welcher Abteilung das aktuelle Problem zuzuordnen ist. Der Rest hängt allerdings sehr stark an der Organisation des jeweiligen Unternehmens. Ich bin überhaupt kein Freund davon, dass sich eine Organisation rund um ein Observability-Tool definiert, sondern dass IT lernt, die vorhandenen Daten richtig zu verwenden. Die IT muss also datengetriebene Analysen verstehen. Deshalb verkaufen wir unseren Partnern nicht nur Observability-Software, sondern helfen, das Konzept als Ganzes zu adaptieren. Denn es gilt auf jeden Fall, dass eine Firma ihre Prozesse anpassen und so das mögliche Silodenken aufbrechen muss. Wobei das früher ein größeres Problem war, denn heute führt der Fachkräftemangel dazu, dass IT-Chefs sagen "OK, ich muss dieses Silodenken rausbekommen und wir müssen alle miteinander arbeiten."

Im Prinzip ja, mehr Systeme sind besser. Die Erfahrung zeigt aber, dass der Großteil der IT-Verantwortlichen klein anfängt, weil sich so leicht Know-how ansammeln lässt und Quick Wins entstehen. Beispielsweise hat ein Automobilzulieferer auf diesem Weg festgestellt, ob alle Anwendungen wirklich erforderlich waren, dies mit den Endbenutzern abgestimmt und so am Ende deutlich seine Lizenzkosten reduziert. Das gelang allein mit Daten von den Endgeräten und war der Einstiegspunkt in ein Observability-Konzept. Ich rate den Kunden auch immer, im Kleinen anzufangen.

In Sachen Personal würde ich sagen: es verschiebt sich. Denn meist hat jedes IT-Team irgendwo eine Person, die als Problemlöser agiert. Da liegt es nahe, dass dieser IT-Profi die Observability unter seine Fittiche nimmt. Denn diese Person hat das Wissen, um von den automatischen Analysen zu profitieren, kann aber gleichzeitig auch den Kontext liefern, kennt also die komplette IT einer Firma. In Sachen neues Know-how muss sich der Administrator eigentlich nur darüber klar werden, dass er seine Situation jetzt auch aus anderen Perspektiven sehen kann. Dass er eben nicht nur rein aus der technischen Sicht auf ein Problem schaut, sondern jetzt auch die User-Seite betrachten kann. Oder liefert ihm das Netzwerk ein größeres Bild? Da ist grundsätzlich kein zusätzliches Know-how erforderlich. Tatsächlich habe ich es schon in der Praxis erlebt, dass Admins an dieser neuer Blickweise so viel Spaß hatten, dass sie am Ende des Tages "Head of Observability" wurden.

Ein Punkt ist die automatische Reaktion auf die via Observability gewonnenen Daten. Zum Beispiel beim Thema Sustainability, wenn die IT feststellt, dass ein User seinen Rechner über Nacht laufen lässt. Die IT sieht dann ja, dass die Maschine idle ist, und kann den Anwender darüber automatisiert informieren. Und sie kann auch fragen, ob das beabsichtigt ist. Ist es das nicht, lässt die IT den Rechner abends automatisch herunterfahren, falls er noch an ist und spart so Strom. Für mich ist das auch das Fazit von Observability: Nicht nur die Daten sammeln, sondern damit aktiv zu handeln und wirklich in IT-Workflows einzubauen.