Der Weg der Digitalisierung, so erstrebenswert das Ziel auch sein mag, erweist sich bei vielen Unternehmen doch als ein steiniger Weg. Sicher ist aber, dass Transparenz bei der Anwendungsleistung nicht nur entscheidend für eine effektive Technologiestrategie ist, sondern auch für den geschäftlichen Erfolg.
Die folgende Fallstudie schildert eine Reihe von Umständen und Ereignissen, wie sie viele Unternehmen schon erlebt haben und gibt euch außerdem einige Tipps dazu, wie ihr dafür sorgen könnt, dass ihr genau wisst, wie die digitalen Services aussehen, die eure Kundschaft bekommt. Und wie ihr schnell reagieren könnt, wenn es zu Ausfällen oder Spannungsschwankungen kommt – sodass ihr im Endeffekt die negativen Auswirkungen auf Umsätze und Markenwert minimieren könnt.
Europäischer Versicherer zwischen Tradition und Moderne
Schauplatz ist ein europäisches Versicherungsunternehmen. Die geschäftlichen User beklagten sich über plattformübergreifend nachlassende Performance: Die Verarbeitung von Tastatureingaben wurde als „langsam“ empfunden, und auf Beschwerden, sowohl vonseiten der internen User als auch der Kundschaft, wurde erst spät reagiert. Das Problem war zum Teil auf überholte Altprozesse und -verfahren zurückzuführen, die weder auf das Tempo des Geschäftsbetriebs in der Praxis noch auf die Ansprüche ausgelegt waren, die eine moderne digitale Wirtschaft kennzeichnen. An Sonntagen wurden geschäftskritische Anwendungen zum Beispiel regelmäßig abgeschaltet, damit geplante Änderungen durchgeführt werden konnten – und an den Wochentagen kam es wegen ungeplanter Änderungen allzu oft zu Unterbrechungen.
Interessant ist allerdings, dass dieser konservative Ansatz bei Prozessen und Verfahren keine ebenso konservative Entsprechung in der zugrunde liegenden Technologie hatte. Die Cloud-Migration hatte bereits begonnen, neuere Anwendungen wurden immer öfter modular, mit flüchtigen Komponenten konzipiert und bereiteten bereits auf die späteren Cloud-Möglichkeiten von Flexibilität und kontinuierlichen Änderungen vor. Diese Diskrepanz macht aus geschäftlicher Sicht natürlich alles nur noch problematischer und wirkte sich sogar auf die Release-Zyklen der technologischen Ebene aus.
Kurzum: Damit, wie die Dinge liefen, war niemand zufrieden.
Problem: Fehler finden in einem Wirrwarr von Microservices
Eines der Hauptprobleme der Entwicklungsteams lag darin, dass es kaum möglich war, den Root-Cause von Incidents und Performance-Problemen schnell und genau zu ermitteln. Die Fehler-Ursachen-Analyse war zwar auch früher eine Herausforderung, aber nicht unmöglich.
Das hatte vor allem zwei Gründe:
- Erstens waren die Anwendungstopologien relativ einfach, stabil und sauber von der zugrunde liegenden Infrastruktur getrennt. Von daher war die Fehler-Ursache leicht zu bestimmen, wenn das Problem in der Anwendung lag – oft musste dazu nur das Topologiediagramm in Augenschein genommen werden. Falls das Problem in Komponenten der Infrastruktur steckte, wurde die Sache schon interessanter. Doch auch da ging es letztlich nur darum, ziemlich offensichtliche Anomalien in einer ziemlich überschaubaren Kollektion von Metriken aufzuspüren.
- Zweitens gingen die Entscheider auf der Business-Seite des Unternehmens in der Regel davon aus, dass es eben dauert, bis Performance- und Verfügbarkeitsprobleme gelöst sind. Der Druck auf die ITOps- und Entwicklungsteams war also relativ gering. Wenn es dann so weit war, fand man eine entsprechende Lösung und berichtete gut genug, was schief gelaufen war.
Doch das Ganze kippte durch das eifrige Refactoring von Legacy-Code und die Erstellung von neuem Code in Gestalt von Microservices. Die neuen Anwendungen hatten keine nennenswerte permanente Topologie, und die einzelnen Microservices konnten in Sekundenbruchteilen entstehen und wieder vergehen. Schließlich verschwamm auch die Grenze zwischen Anwendungen und Infrastruktur, weil sich unmöglich sagen ließ, wann sich ein Microservice „wie eine Anwendung“ und wann „wie ein Server“ verhielt. Obendrein gewöhnten sich die geschäftlichen Entscheidungsträger – wie alle andere Teile der Gesellschaft auch – an Abläufe in „Google-Zeit“. Die bedächtigen Reaktionen der Unternehmens-IT gerieten dadurch zunehmend in die Kritik. Schließlich wurde beschlossen, dass man das vordringliche Problem der Diagnose von Performance-Problemen bei Microservices systematisch angehen wollte.
Eine Landschaft, 300 verschiedene Ansichten
Natürlich war dieses Problem speziell den Entwicklungsteams nicht verborgen geblieben. Tatsächlich hatte jedes Team versucht, die Performance-Probleme auf eigene Faust zu lösen. Leider gab es aber rund 300 separate Teams und damit 300 unterschiedliche, fragmentierte Ansichten dessen, was in den digitalen Umgebungen vor sich ging; die einzige gemeinsame Grundlage war eine Open-Source-Lösung aus Grafana und Prometheus. Es versteht sich von selbst, dass diese Fragmentierung wenig hilfreich war, wenn es um das Troubleshooting bei geschäftlichen End-to-End-Transaktionen ging, die in raschem Tempo durch eine Vielzahl von Verantwortungsbereichen unterschiedlicher Entwickler huschten.
Lösung: Mehr als der Kunde erwartet
Das Versicherungsunternehmen sah sich also auf dem Markt um und prüfte neben reinen Open-Source-Lösungen auch eine Reihe weiterer Anbieter – darunter das von Gartner® im Magic Quadrant™ für Application Performance Monitoring und Observability als „Leader“ eingestufte Splunk. Der Evaluierungsprozess war zunächst schwierig, was an den Prämissen des Versicherers lag, der die „harten“ Fehler-Ursachen grundsätzlich aufseiten der Infrastruktur verortete. Von den Anbietern wurde also verlangt, dass sie ihre Fähigkeiten im Infrastrukturmonitoring beweisen sollten. Und weil die Infrastrukturanalyse von jeher anhand von Metriken geschah, richtete sich das Augenmerk vor allem auf die Komponenten zur Erfassung, Analyse und Darstellung von Metriken. Die Mitbewerber von Splunk folgten den Vorgaben des Versicherers; bei ihren Machbarkeitsnachweisen ging es im Wesentlichen nur darum, wie ihre Lösungen anhand von Metriken die Ursachen von Infrastrukturproblemen aufzeigen könnten. Splunk hingegen entschied sich für einen etwas anderen Weg.
Das Team von Splunk nämlich erkannte, dass bei dem Unternehmen eine Fehldiagnose der Probleme vorlag und die Anforderungen daher bestenfalls unvollständig formuliert waren. Der Splunk-Vertrieb vor Ort tat sich also mit Fachleuten aus Sales, Beratung und Strategie zusammen und konnte den Einkauf – sowohl auf Businness- als auch auf Technologieseite – davon überzeugen, dass die Probleme erstens den gesamten Stack betrafen (und nicht nur die Infrastrukturschicht) und dass zweitens die ITOps- und Entwicklungsteams in einer solchen Full-Stack-Situation neben Metriken, auch Logs und vor allem Traces brauchten, wenn sie die MTTD (Mean Time to Detect) spürbar verkürzen und der Root-Cause schneller auf den Grund kommen wollten. Mit anderen Worten: Während die Mitbewerber nicht über den Horizont des Evaluierungsprozess hinausblickten, tauchte Splunk tiefer in die Herausforderungen des Versicherers ein. Nach einer Vorauswahl, bei der nur Splunk und ein weiterer Anbieter übrigblieben, wurde die Observability-Plattform von Splunk als Lösung für das Unternehmen ausgewählt.
Die neue regionale Splunk Observability Cloud
Die Erstimplementierung verlief erfolgreich, aber die Versicherungsgesellschaft hat nun erkannt, dass die Auswahl der richtigen Technologie nur der erste Schritt ist. Jetzt gilt es, die Prozesse und Verfahren weiterzuentwickeln, damit das Unternehmen mit der technologischen Entwicklung Schritt halten kann, die zusehends – noch während diese Zeilen entstehen – Fahrt aufnimmt. Es gilt nun als ausgemacht, dass die Zukunft des Unternehmens technologisch in der Cloud liegt und dass auf den eigenen Servern on premises kaum etwas übrig bleiben wird. Microservices sind jetzt Standard, und das Ausmaß von Modularisierung und flüchtiger Bereitstellung wird eher noch zunehmen, wenn sich die Plattformen stärker Richtung Serverless ausrichten. Anders gesagt: Es wird sich noch eine ganze Menge ändern. Wenn es aber darum geht, Probleme zu diagnostizieren, die damit zu tun haben, dass sich Microservices sonderbar verhalten, dann wird die Technologie von Splunk auf absehbare Zeit eine Konstante sein.
Dass ein europäisches Unternehmen eine solch doch eher revolutionäre Einstellung bezüglich seiner digitalen Transformation an den Tag legt, ist keineswegs das Resultat besonderer Umstände. Jedes Unternehmen, das die Digitalisierung als vordringliche Aufgabe begreift und einen datenstrategischen Ansatz verfolgt, kann mit dem Technologieportfolio von Splunk so weit kommen.
Neuer Bereich (Realm) in Deutschland
Bislang konnten sich die Observability-Funktionen von Splunk auf dem deutschen Markt leider nur in gewissen Grenzen durchsetzen. Der Grund: Es gab bisher noch keinen eigenen Bereich (Realm), keine dedizierte regionale Instanz der Splunk Observability Cloud, die den regulatorischen Anforderungen der Region genügte. Daher konnte Splunk die vielen deutschen Unternehmen nicht in vollem Umfang unterstützen, die einen immer schnelleren digitalen Wandel zu bewältigen haben – selbst dann, wenn Splunk bereits on premises die strategische Wahl für das Log-Management im IT-Betrieb und für SIEM (Security Information and Event Management) ist. Jetzt aber, mit dem neuen Realm, ist unsere Kundschaft in Deutschland optimal aufgestellt und kann mit einem einheitlichen, KI-gestützten Datenansatz für Entwicklung, IT-Betrieb und Security für durchgängige Observability sorgen und digitale Resilienz aufbauen.
Mit dem neuen Realm sind unsere deutschen Kunden nun jedoch in der Lage, einen einheitlichen, KI-gestützten Ansatz für das Management von Entwicklungs-, Betriebs- und Sicherheitsdaten zu entwickeln.
👉 Hier erhaltet ihr mehr Informationen zu Splunk Realms und unserem Lösungsportfolio 👈
