Monitoring als strategische Entscheidung

Dass es in einer Unternehmens-IT nicht nur „das eine“ Monitoring-Tool gibt, ist selbst einem Neuling bereits nach wenigen Tagen im Unternehmen bewusst. Da gibt es Alarmkonsolen, Infrastrukturüberwachung, OpenSource- und Herstellertools, Applikationsmonitoring, Log-Analysen u. v. a. m. Die meisten IT-Verantwortlichen haben längst den Überblick verloren, welche Tools in welchem Team vorhanden sind, wie und wie oft sie genutzt werden oder ob es irgendwo noch Lücken gibt. 

Bewusst wahrgenommen werden Defizite im Monitoring erst, wenn es zu Ausfällen oder Beeinträchtigungen kommt und große Task-Force-Gruppen gebildet werden, die die Experten zusammenbringen sollen, um das Problem möglichst zeitnah aus der Welt zu schaffen. Dann sitzen Tool-Spezialisten und Generalisten an einem (teilweise virtuellen) Tisch und rätseln über die Ursache des aktuellen Ausfalls: Ist die Fehlermeldung in Tool A wichtig oder nicht? Woher kommt die Antwortzeitverlängerung, die in Tool B dargestellt wird, wirklich? Was passiert eigentlich im Backend, wenn der Nutzer Funktion X, die gerade Probleme macht, ausführt? Jede Stunde, die eine solche Task-Force-Gruppe für die Analyse eines Problems benötigt, kostet mehrere Tausend Euro: Nicht nur die Arbeitszeit der Spezialisten, die eigentliche andere Aufgaben hätten, sondern auch jede Stunde, in der eine Anwendung oder Funktion nicht genutzt werden konnte, kostet Geld.

In einer Studie von 2015 bezifferte AppDynamics (https://devops.com/real-cost-downtime/) die Kosten für einen kritischen Ausfall einer Anwendung bei einem Fortune-1000-Unternehmen mit 500.000 bis 1.000.000 US-Dollar pro Stunde. Selbst wenn ein Unternehmen nicht zu diesem Unternehmenskreis gehört, sind die Kosten und Verluste durch einen Ausfall der wichtigsten Anwendungen nicht zu vernachlässigen. Und jetzt stellen Sie sich einmal vor, die Task Force stellt bei einem solchen Ausfall fest, dass die Ursache in den aktuellen Tools nicht herauszufinden ist? Das gar eine Lücke in der Monitoringlandschaft vorhanden ist?

Um dieses Risiko zu minimieren, ist es wichtig, regelmäßig die Monitoringstrategie der eigenen IT zu überprüfen und gegebenenfalls auf neue Herausforderungen oder geänderte Anforderungen anzupassen. Die Entwicklung einer Monitoringstrategie gliedert sich dabei in verschiedene Phasen, die im Folgenden kurz beleuchtet werden.

Status quo

Am Anfang steht immer die Ermittlung des Status quo: Welche Tools werden aktuell wofür eingesetzt? Viele Unternehmen bauen für sich eine sogenannte Tool-Landkarte. Diese kann ganz unterschiedlich aufgebaut sein. Wichtig ist, sich bei der Erstellung Zeit zu nehmen, eine gemeinsame Kategorisierung zu entwickeln und alle relevanten Stakeholder zu befragen. 
 

Eine solche Tool-Landkarte ist kein statisches Instrument, sondern sollte im Idealfall kontinuierlich angepasst werden.

Blick in die Zukunft

Wenn die aktuelle Situation erfasst wurde, lohnt sich ein Blick in die Zukunft: Gibt es strategische Veränderungen, die auch Auswirkungen auf das Monitoring haben? Sollen beispielsweise Teile der IT-Landschaft in die Cloud verlagert oder outgesourct werden? Stehen Modernisierungsmaßnahmen an, bei der Applikationen oder Infrastruktur umgebaut werden sollen?

Solche Maßnahmen führen auch immer zu einer Änderung im Monitoringbedarf. Wenn Anwendungen in der Cloud betrieben werden, dann sind andere Ansätze für Netzwerk-, Infrastruktur- und Applikationsmonitoring notwendig, als dies in einer klassischen Architektur der Fall ist, in der Netzwerk, Server und Anwendungen vom gleichen Unternehmen betreut werden. Die Änderungen, die sich möglicherweise im Laufe der nächsten Jahre im Monitoringbedarf ergeben werden, sollten für die Bewertung der Monitoringlandschaft herangezogen werden. 

Entwicklung einer Strategie

Wenn man nun den Status quo kennt und auch die künftigen Herausforderungen für das Monitoring definiert hat, dann kann man ermitteln, welche Lücken im Monitoring vorhanden sind oder sich durch künftige Änderungen ergeben werden. Mit dieser Gap-Analyse lässt sich eine priorisierte Strategie erarbeiten, welche Änderungen in welcher Reihenfolge am aktuellen Monitoring vorgenommen werden müssen.

Mithilfe eines Konzepts aus Workshops, Fragebögen, Interviews und Branchenwissen unterstützen wir von amasol diesen Prozess. Wenn Sie Fragen zu unserem Vorgehensmodell haben oder Unterstützung bei der Entwicklung Ihrer eigenen Monitoringstrategie benötigen, kontaktieren Sie mich gerne.

Olga Wall ist seit 2019 als Consultant im Application Performance Management (APM) Team von amasol tätig. In dieser Funktion berät sie Kunden zu unterschiedlichen Themen rund um netzwerkbasiertes Application Performance Management (ExtraHop, Dynatrace, IXIA, NPBs) sowie synthetisches Monitoring (Dynatrace). Darüber hinaus begleitet Olga APM-Einführungsprojekte als technische Projektleitung.

Olga studierte zuerst Materialwissenschaften und dann Informatik. Über ein Praktikum zum Abschluss ihres Informatiksstudium stieß sie zum amasol APM-Team. Dort verfasste sie auch ihre Bachelorarbeit mit dem Titel Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring."

In ihrer Freizeit beschäftigt sich Olga mit Brettspielen und Flamenco sowie Kammermusik, denn sie spielt selbst auch Geige.

Autorin:
Olga Wall