Die Geschichte der Availability ist eine Geschichte voller Mißverständnisse

Es gibt leider mehr IT Abteilungen als man denkt die wesentliche Leistungsmerkmale ihrer Dienste gar nicht beschreiben oder steuern. In ITIL®-Sprache fehlt das managen von OLAs (Operational Level Agreements) im Service Level Management. Die Einführung interner SLAs oder eben OLAs funktioniert bei der richtigen Vorgehensweise bis zu einem gewissen Punkt ganz gut. Werteinschätzung oder auch technische Aspekte wie „ein Service der Klasse 1 muss ein tägliches Backup haben“ sind schnell vermittelt. Erstaunlicherweise kommt es bei dem Thema Verfügbarkeit (Availabilty) immer zu wundersamen Missverständnissen. Woran das liegt? Meist Mangel an Erfahrung und Wissen über die Eigenschaften der eigenen Systeme.

Konnten die internen Service Erbringer einen Vorschlag für Verfügbarkeit abgeben, finden sich lustige Formulierungen, etwa: Betriebszeit 7×24 mit einer Verfügbarkeit von 99% nur zu Zeiten in denen das Betriebsteam anwesend ist oder Betriebszeit an Arbeitstagen 07:00 bis 19:00 Uhr mit einer Verfügbarkeit von 98%, 98,5% Verfügbarkeit kostet 10.000 € Aufpreis.

Das letzte Angebot lautet übersetzt, das System darf in über 60 Stunden pro Jahr still stehen. Dafür das es 15 Stunden länger verfügbar ist, möchte man 10.000 € (oder anderen sinnfrei hohen Betrag). Da das System auch noch Abends und am Wochenende still steht und diese Zeit für Wartung genutzt werden darf, ist 98% vermutlich gar nicht Verfügbarkeit sondern die Absicherung des größten anzunehmenden Unfalls.

Eine Verfügbarkeit von 98% schafft vermutlich der Azubi auf einer 10 Jahre alten Hardware spielend. Auch dürfte ein System, das eine solche lange Ausfallzeit hat, nicht für den geschäftlichen Einsatz taugen.

Nun warum dann diese Antwort? Es dürfte daran liegen, dass IT Systeme Deterministisch sind und somit Ausfälle nicht vorhersagbar sind. Die in Büchern angegebenen Berechnungsmethoden sind auch eher theoretisch und funktionieren eigentlich nur, wenn Verfügbarkeit bereits sehr detailliert gemessen wird. Auch ist mir aufgefallen, dass bei einigen ITIL Beratern Availability so eine Art Variable ohne weiteren Zusammenhang ist.

Ein Weg den Gordischen Knoten zu zerschneiden ist, den IT Verantwortlichen zu fragen was denn eine 100%-Verfügbarkeit bei ihm kosten würde. Damit ist die Diskussion weg von der technischen Plattform und kann in die Risikorechnung eintreten. Da die meisten internen Verrechnungssysteme meist keine Pönale vorsehen, kommt man über den Geschäftswert eines Service ganz gut zu der benötigten Verfügbarkeit und einer realistischen Investition in die IT Systeme.

Was ist denn eigentlich der Geschäftswert eines Service? Um dies so grob einzuschätzen können Szenarios herhalten, was passiert wenn das System einen Tag oder eine Woche nicht verfügbar ist? Nun kommt immer das Argument, dazu müsste die Geschäftsleitung mit an den Tisch, die wüssten aber selbst nicht was sie wollen, etc.

Wenn Dinge gemessen werden sollen, bitte zuerst über das nachdenken was man weiß. Vermutlich liegt pro Geschäftsbereich eine Bilanz vor und gerade bei den wichtigsten Services kann die IT selbst einschätzen was bei Ausfall passiert. So kann ein erster Wert bestimmt werden und dieser nun über das erste Jahr beobachtet werden.

Nachdem ein elementares Service Level Management aufgestellt ist, sich ein Service Katalog herausgebildet hat und ein gewisser Reifegrad erreicht wurde kann dies mit dem Geschäft besprochenen werden. Eine gute Gelegenheit ist die Einführung eines neuen Service.

Noch ein letzter Ausflug zum messen von Verfügbarkeit.

  • Ratschlag Nummer eins: Unwichtige Systeme sind unwichtig. Demnach gehört in das Feld Availability dieses OLAs ein „Unzutreffend“.
  • Ratschlag Nummer zwei: Statt Availability kann gegebenenfalls auch die Zahl der Incidents und deren Lösungszeit (Turn-Around-Time) betrachtet werden. Dies ist etwas anderes als Availability, erfüllt in manchen Fällen jedoch den selben Zweck.
  • Ratschlag Nummer drei: Messen kostet und kann kompliziert werden. In den meisten Fällen benötigt es gar keine End-to-End-Aufzeichnung sondern per Stichproben auf den Transaktionen messen und somit stochastisch eine Verfügbarkeit berechnen. Die Messungenauigkeit hier ist auf jeden Fall besser in den Griff zu bekommen, als ein Messen von Teilbestandteilen. Gemeint ist das typische, wenig Erkenntnis bringende „Bis zur Rechenzentrumswand“-messen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.