Herausforderung MTTR-Reduktion

Schneller zurück zum Soll-Zustand

17. Februar 2020, 07:00 Uhr   |  Christian Lorentz

Schneller zurück zum Soll-Zustand

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.

  1. Störungserkennung: Hat ein Monitoring-Tool eine Störung erkannt, kann es zu einer automatisierten Ereigniskorrelation kommen. Anschließend kann das Überwachungssystem ebenso automatisch ein Trouble Ticket generieren.
  2. Wartezeit. Dies ist die Zeitspanne, nachdem ein Ereignis stattgefunden hat, aber bevor eine manuelle Untersuchung des Vorfalls begonnen hat.
  3. Erste Reaktion. Dies ist oft die zeitaufwendigste Phase und damit die Stelle, an der sich die MTTR am stärksten verkürzen lässt. Entscheidend sind hier die richtigen Daten und das richtige Fachwissen.
  4. Eskalation. Wenn der erste bearbeitende Techniker die Störung nicht beheben kann, ist eine Eskalation erforderlich. Die häufigste Schwachstelle bei diesem Schritt ist der doppelte Aufwand: Ohne Automatisierung wird der Second-Level-Techniker unweigerlich die Arbeit des First-Level-Technikers wiederholen.
  5. Störungsbehebung. Das Problem ist identifiziert. Ziel ist es nun, sichere Changes zu gewährleisten. Diese darf keinen zusätzlichen Schaden anrichten. Zudem ist zu prüfen, ob die Behebung erfolgreich war.
  6. Post-Mortem. Dabei handelt es sich um eine oft vernachlässigte oder schlecht umgesetzte Phase der Reaktion auf einen Vorfall im Netzwerk. Die Umsetzung der gewonnenen Erkenntnisse ist entscheidend, damit man es beim nächsten Mal besser machen kann. Allerdings entpuppt sich dieser Teil als äußerst schwierig. Er erfordert ein gut durchdachtes Wissens-Management-System.
    Daher gilt: MTTR = ? (1 + 2 + 3 + 4 + 5). Phase 6 wiederum ist entscheidend, um die Lösungszeiten zukünftig auftretender Vorfälle verkürzen zu können.

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.

408 LANline 2020-02 LL02F08c
©

Es gibt drei Arten von NetOps-Automatisierung: die vom Trouble Ticket ausgelöste Automatisierung (Triggered Automation), die interaktive und die proaktive Automatisierung. Ihre konsequente Umsetzung ermöglicht eine kontinuierliche Optimierung des Netzwerkbetriebs. Bild: NetBrain Technologies

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:

  • automatisches Sammeln zusätzlicher Telemetriedaten, um die Klassifizierung und Diagnose von Störungen zu unterstützen;
  • Verringerung der Übergangsverzögerungen zwischen den Phasen Erkennen und Identifizieren; sowie
  • Diagnose bekannter Probleme.

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.

Skalierbare Diagnose

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:

  • eine Datenanalyse, damit historische Datenvergleiche Aufschluss darüber geben können, was sich geändert hat;
  • eine Baseline-Analyse, um zu verstehen, ob das normal ist. Neben den traditionellen Baselines für die Gerätekonfiguration umfasst dies auch Telemetrie-Baselines sowie Baselines für Netzwerk- und Betriebszustände;
  • eine kontextbezogene Wissensbibliothek (Know-how); sowie
  • anwendbares Expertenwissen (mittels Runbooks).

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.

Shift-Left-Ansatz für Wissenstransfer

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.

Fazit: Mehr Automation nötig

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.

Christian Lorentz ist Director Product Marketing bei NetBrain Technologies, www.netbraintech.com.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

Teamübergreifende Automatisierung für den IT-Betrieb
Einfacheres Monitoring von KMU-Netzwerken
Zyxel überarbeitet seine Cloud-Netzwerk-Management-Plattform

Verwandte Artikel

Monitoring

Netzwerk-Management