Verfügbarkeit: an sich ganz einfach und doch erstaunlich komplex - Teil 1: Kennzahlen und Berichtszeitraum

24.02.2016 – „Verfügbarkeit: an sich ganz einfach und doch erstaunlich komplex“, so lautete der Titel eines Vortrags von amasol-Vorstand Hans Maurer im Rahmen einer Track Session auf dem amasol-Kundentag 2015 in Köln. Auf der Grundlage dieses Vortrags greift die gleichnamige dreiteilige Beitragsserie nochmals die wichtigsten Fragen zum Thema Verfügbarkeit auf und verdeutlicht, weshalb das Thema prinzipiell „ganz einfach“, im Einzelfall aber „erstaunlich komplex“ sein kann.

[ Weiter zu Teil 2: Datenquellen und Ergebnisse ]

Warum ist „Verfügbarkeit“ heute so wichtig?

Der Grund, weshalb die Verfügbarkeit heute eine zentrale Messgröße für die Qualität eines IT-Systems oder IT-Service ist, liegt zum einen natürlich in der Bedeutung, die die Unternehmens-IT heute allgemein für den Betrieb eines Unternehmens hat. Viele Geschäftsprozesse (Produktion, Vertrieb, Logistik, Projektmanagement etc.) sind heute ohne IT überhaupt nicht mehr durchführbar. Häufig ist ein Ausfall eines IT-Systems gleichbedeutend mit einem Stillstand (zumindest von Teilen) des Unternehmens und zieht damit kostspielige Folgen in Form von Produktions- oder Umsatzausfälle nach sich. Ein weiterer Grund für die zentrale Bedeutung des Themas „Verfügbarkeit“ liegt in der geänderten Rolle der IT-Abteilung in vielen Unternehmen. Als interner „IT-Service-Provider“ ist sie heute nicht mehr nur dafür verantwortlich, sicherzustellen, dass alle IT-Systeme „laufen“, sondern sie muss den konkreten Nachweis dafür erbringen, dass vorher in Service Level Agreement (SLAs) festgelegte Verfügbarkeits-Niveaus auch eingehalten wurden, bzw. erklären, weshalb dies nicht der Fall war. Dasselbe gilt natürlich seit Langem für externe IT-Service-Provider, die Ihren Kunden die vertraglich vereinbarte Verfügbarkeit mit konkreten Daten und Fakten auch nachweisen müssen. Und letztendlich ist die Verfügbarkeit auch die Grundlage für die Abrechnung der zur Verfügung gestellten IT-Systeme bzw. der geleisteten Services einschließlich entsprechender Pönalen bei Nichtverfügbarkeit.

Fakt ist: Der Nachweis der Verfügbarkeit ist zentrales Thema in der Zusammenarbeit von (internem/externem) Service-Provider und dessen Kunden.

Verfügbarkeit – was ist das?

Prinzipiell ist der Begriff „Verfügbarkeit“ schnell definiert. Laut Wikipedia ist „die Verfügbarkeit eines technischen Systems […] die Wahrscheinlichkeit oder das Maß, dass das System bestimmte Anforderungen zu bzw. innerhalb eines vereinbarten Zeitrahmens erfüllt. […] Sie ist ein Qualitätskriterium und eine Kennzahl eines Systems.“ Daraus ergibt sich dann die grundsätzliche mathematische Formel: Verfügbarkeit = (Gesamtzeit – Ausfallzeit)/Gesamtzeit bzw. als Prozentsatz dargestellt: Verfügbarkeit = (Gesamtzeit – Ausfallzeit)/Gesamtzeit × 100 %.

Diese klassische Art der Berechnung der Verfügbarkeit ist in der Praxis am weitesten verbreitet und kommt auch bei den von amasol betreuten Kundenprojekten am häufigsten zum Einsatz. In der Regel ergeben sich aus dieser Kalkulation dann Verfügbarkeitswerte von mehr als 99%; Systeme, bei denen eine Verfügbarkeit von 99,99% und mehr vereinbart wurde, werden als „hochverfügbare Systeme“ bezeichnet.

Was diese Kennzahlen in der Realität bedeuten, verdeutlichen die beiden folgenden Beispiele. Bei einem System, das 12 Stunden am Tag an 5 Wochentagen in 52 Wochen im Jahr verfügbar sein soll, bedeutet eine Verfügbarkeit von 99 % eine maximale Ausfallzeit während dieses Zeitraums von 31,2 Stunden. Bei einem System, das allerdings das ganze Jahr (365 Tage) rund um die Uhr (24 Stunden) verfügbar sein soll und eine Verfügbarkeit von 99,999 % („five nines“) erzielen soll, bedeutet dies eine maximale Ausfallzeit von gerade einmal 5,26 Minuten – im gesamten Jahr!

Bei all diesen vielen „Neunen“ sei allerdings darauf hingewiesen, dass es in der Praxis sehr wohl auch Systeme gibt, z. B. in den Bereichen Test und Entwicklung, bei denen eine Verfügbarkeit von unter 99 Prozent (z. B. 98,5 %) ausreichend und auch in den entsprechenden SLAs festgelegt ist.

Neben dieser „klassischen“ Verfügbarkeitsformel gibt es eine Reihe alternativer Verfügbarkeitskennzahlen, die allerdings in der Praxis – dies zeigt sich auch in der amasol-Projektpraxis – deutlich seltener vorkommen, wie z. B.

  • die Anzahl einzelner Ausfälle,
  • die maximale Dauer der einzelnen Ausfällen,
  • die kumulierte Ausfallzeit.

Diese Kennzahlen spielen unter Umständen dann eine Rolle, wenn es sich bei dem betreffenden System oder Service um einen sogenannten „Single Point of Failure“ handelt, also eine Komponente eines übergeordneten Systems oder Service, dessen Ausfall den Ausfall des gesamten Systems oder Service nach sich zieht. Dabei können dann eben insbesondere die Anzahl und die Dauer von Ausfällen dieses SPoFs eine zentrale Rolle für die Bewertung der Verfügbarkeit spielen. So kann häufig ein einzelner Ausfall von einer Stunde ganz andere Auswirkungen – beispielsweise auf die Produktivität des Gesamtsystems – haben als 60 Ausfälle von jeweils 1 Minute.

Doch wie bereits erwähnt wird die Verfügbarkeit klassischerweise mit der oben angegebenen Formel definiert und berechnet.

Der Berichtszeitraum: zweite wichtige Bemessungsgrundlage

Eine zweite wichtige Kennzahl neben der reinen Verfügbarkeitsberechnung ist der Berichtszeitraum, für den die Verfügbarkeit gemessen wird. In der Regel – und dies gilt auch für die amasol-Projekte in diesem Bereich – wird die Verfügbarkeit je Monat angegeben. Dies macht allein schon aus dem Grund Sinn, dass die Nutzung der zur Verfügung gestellten IT-Systeme oder IT-Services ebenfalls auf Monatsbasis abgerechnet wird. Dies gilt für die Abrechnung durch externe IT-Dienstleister und Service-Provider an ihre Kunden genauso wie für die interne Abrechnung zwischen IT-Abteilung als internem Service-Provider und den Fachabteilungen als internen Kunden.

Kürzere (je Tag) oder längere (je Quartal, je Jahr) Berichtszeiträume kommen in der Praxis zumindest mit zugesicherten Zielwerten eher selten vor. Ein kürzerer Berichtsraum kann allerdings dann vereinbart sein, wenn es sich bei dem System oder Service um einen bereits oben beschriebenen Single Point of Failure handelt, dessen Verfügbarkeit besonders wichtig ist. Eine gängige Vorgehensweise in der Praxis ist es, bei einem VerfügbarkeitsBericht die Monatswerte mit Zielvorgabe durch eine grafische Darstellung der Tageswerte (ohne Zielvorgaben) zu ergänzen. Damit erhält der Anwender einen besseren Überblick über die Verteilung der Nichtverfügbarkeiten während des Berichtsmonats als beispielsweise bei einer reinen Ausfallliste.

Ein längerer Berichtszeitraum ist dann sinnvoll, wenn die Bedeutung des Systems oder Dienstes eher niedrig ist bzw. das System oder der Dienst nur selten genutzt wird. Längere Berichtszeiträume werden darüber hinaus als ergänzende Information für den Kunden ausgewiesen – in der Regel ohne Zielzusage. Ein aus der amasol-Praxis bekannter Wert ist „Year to Date“, die Berechnung der Verfügbarkeit im laufenden Berichtsjahr bis zum aktuellen Datum.

Gesamtzeit vs. Betriebszeit/Servicezeit – der „Nenner“ in der Verfügbarkeitsformel

Ein weiteres wichtiges Kriterium, das in die Verfügbarkeitsberechnung einfließt, ist die Betriebszeit/Servicezeit. In der eingangs vorgestellten Verfügbarkeitsformel stellt die Gesamtzeit den Nenner da. Doch was genau ist die Gesamtzeit? Sie ist die Zeit, in der das IT-System zum Betrieb bzw. der IT-Service zur Nutzung bereitgestellt werden muss. Allerdings müssen bei der Kalkulation dieser Betriebs-/Servicezeit einige Bausteine berücksichtigt werden. Dazu gehören zuerst einmal die Geschäftszeiten. Wird ein System oder Service, z. B. ein Webshop, an 7 Tagen die Woche rund um die Uhr benötigt oder handelt es sich dabei um eine Unternehmensanwendung, die lediglich während der Geschäftszeiten, z. B. werktags von 9.00 bis 17.00 Uhr benötigt wird? Ein weiterer Baustein sind die Wartungsintervalle, bei denen, zumindest wenn sie geplant sind, vorher geklärt werden muss, ob sie in die Betriebszeit einfließen und ob diese dann entsprechend reduziert wird. Dies wirkt sich dann auch auf Ausfälle aus, die während dieser Wartungsintervalle passieren.

Darüber hinaus müssen natürlich nationale wie internationale Feiertage berücksichtigt werden, denn an diesen Tagen wird eine Verfügbarkeit regional nicht erforderlich sein. Dasselbe gilt international auch für die unterschiedlichen Zeitzonen, denn „9.00 bis 17.00 Uhr in Deutschland“ ist nicht gleichbedeutend mit „9.00 bis 17.00 Uhr in den USA“ oder „in Japan“. Spezialzeiten wie Sommer- und Winterzeit und selbst die Frage des genauen Monatsbeginns bei Unternehmen, die global tätig sind und deshalb über die Datumsgrenze hinaus arbeiten, müssen ebenfalls vorab auf ihre Auswirkungen auf die Definition der Betriebszeit und des Berichtszeitraums und damit ihre Relevanz für die SLA-Vereinbarungen überprüft werden.

Abschließend spielt bei der Festlegung der Betriebs-/Servicezeit natürlich auch die Zuordnung zu bestimmten Ressourcen, Services, Verträgen oder Mitarbeitern eine Rolle. Beispiel Mitarbeiter: Wechseln Mitarbeiter innerhalb des Berichtszeitraums zwischen unterschiedlichen Niederlassungen und greifen dort auf unterschiedliche IT-Systeme und IT-Services des Unternehmens zu, kann dies unterschiedlichste Auswirkungen auf die ihnen zugesicherte Verfügbarkeit haben.

Darüber hinaus kann es möglich sein, dass Services innerhalb des Berichtszeitraums (z. B. während des als Berichtzeitraum definierten Monats) in Betrieb genommen oder wieder abgeschaltet werden. Dies gilt insbesondere für in vielen Unternehmen immer häufiger genutzte Services aus der Cloud. Diese werden häufig nur für einen kurzen Zeitraum oder zu Spitzenlastzeiten eingesetzt und müssen deshalb bei der Berechnung der Gesamtverfügbarkeit entsprechend berücksichtigt werden. Dabei stellt sich dann insbesondere die Frage, wie die „Gesamtzeit“ definiert wird. Möglich Optionen sind die tatsächliche Laufzeit, die reservierte Zeit (in der die Ressourcen für die Zuschaltung garantiert zur Verfügung stehen) oder der gesamte Monat. Abhängig von der gewählten Option kann dann derselbe Ausfall zu erheblich unterschiedlichen Verfügbarkeitswerten führen. Es wird damit unter Umständen schwierig, eine „faire“ Regelung zu finden.

Fazit: Prinzipiell ist Verfügbarkeit ein einfach zu definierender Wert, doch in der Praxis zeigt sich schnell, dass sich daraus ein komplexes Rechenwerk ergeben kann. Wichtig ist dabei insbesondere, dass sich die Vertragspartner – IT-Dienstleister/IT-Service-Provider und Kunde/Anwender – vorab an einen Tisch setzen und die wichtigsten Kennzahlen – Gesamtzeit, Betriebs-/Servicezeit, Ausfallzeit, Verfügbarkeitszielwert und Berichtszeitraum – definieren. Nur so entstehen im Rahmen des Reportings auch wirklich valide und aussagekräftige Daten, die letztendlich dazu beitragen, das Erfüllen der in den SLAs festgelegten Zielwerte auch beurteilen zu können.

Der zweite Teil der Beitragsserie wird sich mit der Frage beschäftigen, aus welchen Quellen die Daten stammen, aus denen dann die Gesamtverfügbarkeit berechnet wird.

Weitere Informationen

In unseren Anwenderberichten sind konkrete Projekte mit VMware vRealize Business bei Deutsche Telekom, ITERGO, BASF und IT-DLZ beschrieben.

[ Weiter zu Teil 2: Datenquellen und Ergebnisse ]

zurück

Weitere News