Availability Management – ist nicht bloss Monitoring!

Verfügbarkeit ist das absolute Killerqualitäts-Kriterium für IT Services. Die tollste Anwendung nützt nichts, wenn die Kiste unten ist. Verfügbarkeit ist die Grundvoraussetzung überhaupt, damit der Service genutzt werden kann.  Availability Management müsste demnach eine der zentral zu beherrschenden Fähigkeiten einer IT Service Organisation sein. Müsste, ist es aber erschreckenderweise oft nicht.

ITIL® hat den Prozess Availability Management sehr prominent in der Phase Service Design platziert. Die meisten Organisationen wissen mit diesem Prozess aber wenig anzufangen. Im Rahmen von Standortbestimmungen stelle ich immer wieder fest, dass diese Disziplin mit der Implementation eines Monitoring Tools als erfüllt betrachtet wird. Monitoring mit dem Ziel festzustellen, ob die Service Komponenten aktiv sind oder nicht. End-to-End Monitoring ist dann schon den fortgeschrittenen Organisationen vorbehalten.

Da ist ein weiteres Grundübel in IT Organisationen begraben: die IT ist gut im Reagieren, wenn es knallt. Dann wird in Best-Effort-Manier versucht, den Service wieder in Gang zu bringen – ohne Garantie notabene: man muss ja zuerst den Fehler finden – und der kann bekanntlich sehr komplex sein. Vorausschauend zu planen, dass es gar nicht erst zu Ausfällen kommt – oder eine garantierte Beherrschung der Downtime – das ist nicht so das Ding der IT Organisationen.

Dabei liegt gerade hier der Schlüssel zum Erfolg. Kunden werden dies in Zukunft nicht mehr einfach hinnehmen, dass Ausfälle mit unbestimmtem Ausgang angeboten werden.  Nur noch Service Provider, welche in der Lage sind, ihr Service-Versprechen einzuhalten, werden sich mittel- bis langfristig behaupten können.

Vergügbarkeits-Design
Dass es eine hundertprozentige Verfügbarkeit nicht gibt, akzeptiert heute auch der anspruchsvollste Kunde. Und es ist auch für ihn nachvollziehbar, dass die Kosten mit zunehmenden Verfügbarkeitsanforderungen mitunter exponentiell steigen können. Mit gezielter Redundanz, Vermeidung von SPOFs (Single Point of failure)“ sowie  zuverlässigen und standardisierten IT Komponenten lässt sich  die gewünschte Verfügbarkeit bis zur einer fehlertoleranten Hochverfügbarkeitslösung einrichten.

Aber Achtung: Hoch-Verfügbarkeit muss beherrscht sein. Oftmals  beschaffen sich Manager eine High-Availability-Lösung und meinen damit die Ausfall-Sicherheit gekauft zu haben. Von den IT Ingenieuren aufgebaut werden diese dann mit mangelhafter Einführung in den Betrieb gestellt. Die Systeme laufen lange stabil –vielfach ein System als Master, das andere als wartender Slave. Die Systemwartung erfolgt dann nicht immer synchron – und schon nach geraumer Zeit sind die Zustände nicht mehr kompatibel. Im Fehlerfall zeigt sich dann gerade diese Hochverfügbarkeitsfunktionalität  als Hinderungsgrund, das System überhaupt wieder in den Griff zu bekommen. Man wünscht sich regelrecht eine manuelles, kontrollierbares Hochfahren eines Einzelsystem. Ohne den ganzen Schnickschnack.

Testen des Failovers gehört zur Routine-Tätigkeit des Operation-Personals genauso wie ein konsequentes Change Management unter Berücksichtigung dieser sensitiven Funktionalität.

Der Availability Manager muss die Infrastruktur-Architektur im Griff haben. Wo es keine entsprechende Verantwortlichkeit gibt, gibt es auch keine Kontrolle darüber. Schon klar: es gibt die Netzwerk-Verantwortlichen, die Server-Verantwortlichen, die Datenbank-Verantwortlichen und die vielen Applikationsverantwortlichen.  In all diesen Bereichen wird kräftig aufgerüstet und umgestellt. Wenn Netze voll sind, werden neue geschaltet. Durch die Virtualisierungstechnik ist es ein Leichtes, noch einen Server zu konfigurieren. Und die Daten verschwinden eh in einem SAN, sodass man sich über irgendwelche Verfügbarkeiten von Daten schon gar nicht mehr zu kümmern braucht.

Wie sich diese Entwicklung auf die ursprünglich vielleicht noch berechnete Verfügbarkeit auf den Gesamt-Service auswirkt, dies bleibt oft unerkannt. Es interessiert in der Regel auch nicht wirklich.

Für die Behebung von Ausfällen hat man ja das Incident Management eingerichtet.  Und im Problem-Fall wird dann vertiefter untersucht. So einfach sieht die Welt der Reaktiven aus. Die IT ist gut im Reparieren – aber leider nicht im Planen. Vorausschauendes Availability Management beugt Fehlern viel mehr vor. Und lässt die eh schon knappen IT Ressourcen nicht unbegrenzt nach Fehlern suchen, sondern setzt diese in zukunftsträchtige Projekte ein.

Ein proaktiver Availability Manager ist ein Infrastruktur-Architekt und RZ-Gralshüter. Es kann nicht mehr sein, dass unabgestimmt neue Server und Anwendungen auf bestehende Umgebungen implementiert oder Netze mit immer neuen Systemen verbunden werden, ohne dass die Auswirkung der Verfügbarkeit bestehender Services geklärt ist. Wie die Implementation letztlich umgesetzt werden soll, obliegt dem Availability Manager. Die Infrastruktur wächst kontrolliert.

Recovery-Design
Auch beim besten Design kann es vorkommen, dass die Verfügbarkeit einmal versagt. Grundsätzlich wurde ja mit dem Kunden vereinbart, dass eine bestimmte Nicht-Verfügbarkeit toleriert wird. Dazu gehört in der Regel eine maximale Ausfalldauer, welche in den meisten Fällen eingehalten werden muss. Auch hier lassen sich Ausnahmen verhandeln, weil es durchaus auch grössere Ereignisse gibt, die dann mehr Zeit in Anspruch nehmen (zum Beispiel in 95% der Fälle sind die Störungen innerhalb von 30 Minuten gelöst – die restlichen in 2 Stunden). Zudem wird auch die akzeptierte Häufigkeit von Ausfällen vereinbart, um die Zuverlässigkeit des Services bestimmen zu können.

Nur mit der Ausfalldauer und der Ausfallhäufigkeit lässt sich für den Kunden die zu erwartende Verfügbarkeit abschätzen und nachvollziehen. Die damit vereinbarte Verfügbarkeit lässt sich dann auch in Prozenten zur vereinbarten Servicezeit berechnen. Aber Achtung – vereinbarte und in Anspruch genommene Wartungsfenster gehören nicht zu diesen Ausfällen. Oft setzen IT Verantwortliche nur die Prozentzahl der Verfügbarkeit in das SLA – ohne die Auswirkungen auf den gesamten Service wirklich zu kennen. Der Kunde kann mit dieser Zahl alleine in aller Regel nichts anfangen und weiss gar nicht, was er sich damit einhandelt.

Die Kunst ist nun, diese maximale Ausfallzeit zu beherrschen. Das kann man nur, wenn man genau weiss, wie bei einem Ausfall von Komponenten genau vorgehen muss, um den Service wieder bereitzustellen. Ein blosses Restarten eines Systems reicht oft nicht mehr. Vielmehr müssen bestimmte Restart-Szenarien durchgeführt werden, um den Service funktionsfähig bereitzustellen.

Das gehört ebenfalls zur Planung: die Beschreibung des Vorgehens bei Ausfällen der einzelnen Komponenten oder kritischen Systemzuständen. Dieses Vorgehen muss auch mit dem Support-Personal trainiert und die Beschreibungen als Incident-Modelle in der Knowledge-Datenbank bereitgestellt werden. Nur so können im Störungsfall die Support Mitarbieter den Service so schnell wie möglich wieder zur Verfügung zu stellen.

Das Monitoring ist auch eine wichtige Funktion im Supportfall. Damit kann die fehlerhafte Komponente identifiziert und gemeldet werden. Aber auch hier muss klar unterschieden werden zwischen Komponenten-Überwachung und End-to-End Überwachung. Es ist wichtig zu wissen, welcher Service betroffen ist. Aber dem Kunden ist es letztlich egal, ob der Ausfall wegen des Netzes oder der Datebank war – für die Support-Organisation ist es jedoch essentiell. Es braucht also beides.

Ohne diese vordefinierten Incident-Modelle fehlt das entsprechende Knowhow. Das ist typisch für Organisationen, welche Schwierigkeiten haben,  zwischen Problem Management und Incident Management zu unterscheiden.  Jeder Incident endet schnell zur Situation, dass man nicht weiss, wie damit umzugehen ist und es muss zuerst die Ursache gesucht werden. Wie mit der Stange im Nebel muss unter Zeitdruck die fehlerhafte Stelle versucht werden, zu treffen. Dass hier niemand eine garantierte Wiederherstellungszeit unterschreiben will, ist nachvollziehbar.

Fazit
Gutes Availability Management macht die Downtime beherrschbar und für die meisten Ausfälle auch maximal garantiert. Diese Standard-Ausfälle können dann mit bekannten Verfahren auch rasch wieder behoben werden. Nur wenn diese Verfahren nicht mehr greifen, muss mit ein zu reparierender Defekt einer Komponente angenommen werden. Dann ist das Eröffnen eines Problem Tickets und damit der Anstoss des Problem Managements gerechtfertigt. Mit der gesamten Historie des Vorfalls lässt sich die Ursache auch gezielter einkreisen und letztlich identifizieren.

Zu einem guten Aailability Management gehört auch die proaktive Wartung der Systeme, das Nachziehen von System-Patches und das gezielte Auswechseln von Komponenten bei Erkennung von Störungshäufigkeiten. Die Auswahl eines fachlichen externen Partners zur Unterstützung im Fehlerfall (Servicefähigkeit), welcher ebenfalls garantierte Lösungen anbietet, kann die Sicherheit zusätzlich erhöhen.