Auch in Zeiten des IT-Fachkräftemangels steht die Forderung im Raum, sämtliche IT-Systeme wann möglich immer verfügbar zu haben und Ausfallzeiten immer weiter zu reduzieren. Das Stichwort heißt: Minimieren der MTTR (Mean Time to Repair) - unabhängig davon, ob es sich um PCs, Server, Netzwerk oder andere Komponenten handelt. Doch die meisten Ansätze, um Ausfallraten zu senken, konzentrieren sich nur auf einen Teil des Problems. Der ganzheitliche Blick fehlt - und Automatisierung findet, wenn überhaupt, nur rudimentär statt. Besonderes Augenmerk gilt dem Netzwerk: Immer komplexere Netzwerklandschaften stellen eine besondere Herausforderung für die skalierbare Automatisierung des Netzwerkbetriebs dar.
MTTR ist durch drei Betriebsphasen definiert: Erkennen, Identifizieren und Beheben. Jede Phase hat ihre eigenen Herausforderungen. Um zu verstehen, wie sich Automatisierung für die Reaktion auf Vorfälle anwenden lässt, ist eine gründliche Analyse der MTTR sowie des Workflows für die Vorfallreaktion erforderlich. Die Fehlererkennung erfolgt über bestehende Monitoring- und Event-Management-Lösungen, die in Unternehmensumgebungen verbreitet sind. Während die erhöhte Gerätetelemetrie früher deutlich mehr Störungen und Fehlalarme verursachte, sind die heutigen Event-Korrelationslösungen und SIEM-Produkte (Security-Information- und Event-Management) genau dazu entwickelt, um dies zu reduzieren.
Lange MTTR-Zeiten liegen daher in der Regel nicht in dieser Phase selbst, sondern treten beim Übergang vom Erkennen zum Identifizieren auf. In der Identifizierungsphase gibt es große potenzielle Verzögerungen und unzuverlässige Variabilität. Denn oft sind keine Anhaltspunkte vorhanden, wo der Fehler konkret liegt. Folglich muss das IT-Team die Analyse in unterschiedliche Richtungen beginnen, bevor es die relevanten Daten findet. Entsprechend ist die Dauer dieser Phase unvorhersehbar und hat den größten Einfluss auf die Kosten eines Ausfalls. Die Behebungsphase schließlich kann zwar sehr kurz sein, aber dennoch sind Bemühungen notwendig, um das jeder Änderung (Change) innewohnende Risiko zu reduzieren und diese Phase in einen vollständigen Vorfallreaktions-Workflow zu integrieren.
Die drei genannten Phasen sind notwendig und finden in der Regel ausreichende Beachtung. Doch sollten Unternehmen eine vierte MTTR-Phase in Betracht ziehen: die proaktive Phase. Der Vorfall ist behoben, aber was ist, wenn später wieder ein ähnliches Ereignis auftritt? Lassen sich die gewonnenen Erkenntnisse aufzeichnen und daraus eine Handlungsempfehlung für das nächste Mal ableiten? Doch viele Unternehmen sind noch nicht so weit. Heute manifestiert sich der Mangel an Automatisierung im unvorhersehbaren, riskanten und manuellen Netzwerkbetrieb. Traditionelle Ansätze konzentrieren sich auf die Verbesserung von Überwachung, Datenkorrelation, Dokumentation, Change-Management und auf Prozesse, um Vorfälle im Netzwerk abzuarbeiten. Allerdings trägt keiner dieser Ansätze viel dazu bei, die größten Zeitlücken im MTTR-Prozess zu schließen.
Die ganzheitliche MTTR-Reduktion erfordert einen systematischen Ansatz, um einzelne Verbesserungsbereiche in jedem Schritt des MTTR-Prozessablaufs anzugehen. Die Lösung muss die einzelnen Teile der MTTR so miteinander verknüpfen, dass sie das Tempo erhöht, das Risiko minimiert und gewonnene Erkenntnisse für ähnliche Ereignisse in der Zukunft kodifizierbar macht.
Eine Analyse der MTTR aus dieser Sicht zeigt, in welchen operativen Bereichen eine Verbesserung erforderlich ist.
Traditionell erfolgen die Wechsel zwischen den MTTR-Stadien manuell - ebenso wie die Diagnose. Die Reduktion der durchschnittlichen Ausfallzeit hängt daher stark vom Menschen ab. Somit ist eine Verkürzung der MTTR ohne Automation entweder nur mit mehr Mitarbeitern oder durch ein besseres Netzwerk möglich. Beides ist aufgrund von Budgebeschränkungen und des Fachkräftemangels schwierig zu erreichen. Ein skalierbarer Ansatz besteht in einer besseren Automatisierung bei jedem Schritt des MTTR-Workflows. Einfach ausgedrückt kann eine IT-Organisation eine Verkürzung der MTTR mit zwei Methoden erzielen: Erstens könnte sie die Automatisierung in jeder Phase des MTTR-Prozesses steigern. Zweitens könnte sie eine proaktive Automation entwickeln, die in der Post-Mortem-Phase auf jeden Vorfall folgt. Dabei lässt sich die NetOps-Automatisierung (Network Operations, Netzwerkbetrieb) in drei Kategorien einteilen: Triggered Automation, interaktive Automatisierung und proaktive Automatisierung.
Triggered Automation bedeutet hier, dass ein Vorfall im Netzwerk automatisch die Suche nach dem Fehler, dessen Identifizierung und Analyse und somit den gesamten automatisierten Prozess auslöst. Der Kerngedanke der NetOps-Automatisierung ist, dass keine Person mit einem Trouble Ticket in Kontakt kommen sollte, bevor diese Automation ihre Arbeit getan hat. Ohne Automatisierung bleibt das Ticket vorerst unbearbeitet und potenzielle Diagnosedaten können schon bei Beginn einer Untersuchung nicht mehr vorhanden sein.
Deshalb muss Software diesen Prozess ergänzen und die Diagnose des Ereignisses einleiten. Damit die Triggered Automation erfolgreich sein kann, ist eine vollständige Workflow-Integration erforderlich. Das Monitoring- oder ITSM-Tool (IT-Service-Management) muss mit dem NetOps-Automationssystem kommunizieren, um eine Diagnose zu automatisieren.
Eine Automatisierung kann die Erkennungsphase auf drei Arten ergänzen:
Automatisierung soll Menschen unterstützen. Statt CLI-Ausgaben (Command Line Interface) von Netzwerkgeräten sequenziell zu analysieren, nutzt der Techniker vorgefertigte Runbooks und ruft kontextbezogene Diagnosedaten auf Knopfdruck ab. Dies trägt dazu bei, wiederholbare, vorhersagbare Ergebnisse zu liefern. Zugleich stellt es sicher, dass die Software genau die relevanten Daten abruft. Dies verkürzt die Zeit für den Diagnoseprozess erheblich.
Sobald der erste Techniker auf den Vorfall reagiert und mit der ersten Einordnung und Untersuchung beginnt, besteht die Priorität darin, schnell die richtigen Daten zu erhalten und eine genaue und effiziente Analyse durchzuführen. Die Methode beinhaltet typischerweise manuelles Durchsuchen per CLI. Es gilt, diese Diagnose durch Automatisierung zu beschleunigen. Zugleich sollte die Automatisierung auch Folgendes ermöglichen:
Einige Störungen kann bereits der First-Level-Support beheben, viele andere erfordern eine Eskalation. Die Zusammenarbeit scheitert oft bei der Bearbeitung von Vorfällen, da Daten den Second-Level-Techniker nicht ordnungsgemäß erreichen. Der Second-Level-Techniker wiederholt üblicherweise die Arbeit des First-Level-Kollegen, bevor er zu einer weiterführenden Diagnose übergeht. Eine Netzwerk-Automatisierungslösung sollte deshalb die gesammelten Diagnose- und Fehlerbehebungshinweise aufzeichnen und es jedem ermöglichen, mit den gleichen Daten am gleichen Vorfall zu arbeiten. Die Fehlerbehebung zielt darauf ab, Changes sicher umzusetzen und zu bestätigen, dass die Störung tatsächlich behoben ist. Dazu ist ein gut durchdachtes System für die Change-Automatisierung erforderlich. Dabei muss sichergestellt sein, dass die Software den gesamten Ablauf der Störungsbehebung automatisiert.
Um eine kontinuierliche Verbesserung zu erreichen, gilt es, immer mehr Vorfälle möglichst sofort zu diagnostizieren und deren Ursache zu identifizieren. Die Automatisierungsstrategie sollte sich also darauf konzentrieren, immer mehr Störungen auf eine MTTR nahe Null zu bringen. Indem immer mehr Vorfälle mittels ordnungsgemäßer Post-Mortem-Überprüfungen dokumentiert sind, kann das NetOps-Team diese Vorfallstypen in die Kategorie "bekanntes Problem" einordnen und sie zur Bibliothek bekannter Probleme für die Ticket-initiierte Automatisierung (also "Triggered Automation") hinzufügen.
Erweitert das IT-Team das System um immer mehr operative Runbooks, kann es immer mehr bekannte Probleme vollautomatisch diagnostizieren. Ein solcher Prozess verkürzt die MTTR dann nach und nach immer weiter.
Bei der Entwicklung der Strategien zum Wissens-Management und zur Netzwerkautomatisierung geht es auch darum, Nachwuchstechnikern die Möglichkeit zu geben, das unternehmensspezifische Fachwissen der erfahreneren Mitarbeiter zu nutzen. Aus Sicht einer Eskalationskette (mit Zeitachse von links nach rechts) ist es das Ziel, das Wissen von Spezialisten, die sich logischerweise auf der rechten Seite des Betriebsprozesses befinden, zu den "Ersthelfern" auf der linken Seite des Prozesses zu verlagern. Dadurch wird wichtiges Wissen sozusagen "nach links" weitergegeben, ein Verfahren, das man deshalb auch "Shift-Left-Ansatz" nennt. Dieser "nach links" verlagerte Wissensfluss ermöglicht es, Diagnosearbeiten, die bisher ein First-Level-Support-Techniker erledigt hat, vom System durchführen zu lassen. Komplexere Arbeiten, die bisher ein Second-Level-Techniker durchgeführt hat, kann nun das First-Level-Support-Team übernehmen.
Ein wichtiger Punkt ist dabei das Erstellen von NetOps-Runbooks nach jedem Vorfall per Aufbau einer Bibliothek bekannter Probleme inklusive zugehöriger Lösungen. Mit dem Wachstum dieser Bibliothek wächst auch die Fähigkeit, die Ursache für bekannte Probleme schnell zu isolieren oder alternativ eine Reihe möglicher Ursachen auszuschließen. Findet man neue Probleme, muss es das NetOps-Framework erlauben, die Bibliothek bekannter Probleme ohne großen Aufwand um neue Runbooks zu ergänzen.
Triggered Automation, interaktive Automatisierung und proaktive Automatisierung sind Bestandteile einer umfassenden NetOps-Automation. Nur wenn diese möglichst vollständig umgesetzt ist, lässt sich die MTTR deutlich und nachhaltig reduzieren.