MTBF und MTTR – Hä?

Nachdem ich diese Diskussion in der letzten Zeit mehrfach geführt habe, gehe ich im Rahmen eines Block-Posts auf diese strukturelle Änderung vom Rechenzentrums-IT-Betrieb auf Cloud-IT-Betrieb ein. Ich mache es an Rechenzentrum und Cloud fest, obwohl es eigentlich ein Paradigmenwechsel ist, der durch die erhöhte Automatisierung im Betrieb von Anwendungen und Systemen bedingt ist.

Aber zuerst einmal: was ist MTBF und MTTR?

Unter MTBF versteht man die Mean Time Between Failure – also die durchschnittliche Zeit zwischen zwei Ausfällen eines Systems.

Die MTTR oder Mean Time To Repair ist die durchschnittliche Zeit, die benötigt wird, um ein System bei einem Ausfall wieder zu reparieren (also verfügbar zu machen).

Nur damit wir komplett sind gibt es auch nocht die MTTF, die Mean Time to Failure. Also die Durchnittszeit bis zum Versagen. Als Formel ließe ich das Verhältnis der drei Betriffe als MTBF = MTTF + MTTR beschreiben. Aber ich werde die MTTF hier nicht weiter betrachten.

IT-Bertrieb in der Vergangenheit

Früher wurde der IT-Betrieb rein kostenbasiert betrachtet. Er sollte eine definierte Leistung bei minimalen Kosten liefern. Und die definierte Leistung war der störungsfreie Betrieb der Systeme. Damit war die Optimierung der IT klar: die Vergrößerung der MTBF, Denn jede einzelne Störung hat Kosten verursacht. Die Idee ist ja auch nicht schlecht, aber jeder erinnert sich noch an das Rennen zu den 5×9 (also 99,999% Verfügbarkeit). Jede 9 nach dem Komma vervielfacht die Kosten.

Trotzdem war es das Ziel, die MTBF zu optimieren. Hierzu dienten die allzeit bekannten Lessons learned und Root Cause Analyse bei jedem einzelnen Vorfall.

Was hat sich geändert?

Die IT ist schneller geworden. Sie ist inzwischen ein zentraler Bestandteil vieler Unternehmen, seien es Serviceunternehmen, die ihre Dienste in Software abbilden (wie z.B. Versicherungen oder Banken bei Vertragsabschlüssen oder Schadensabwicklungen, die oft genug ohne menschliche Intervention seitens des Unternehmens erfolgen) oder um die Firmware von Geräten oder Backendservices der Handy-Apps.

Software ändert sich nicht mehr im Quartals- oder Monatsrhythmus. Oft wird wöchentlich, täglich oder gar mehrfach am Tag eine neue Softwareversion eingespielt (ok, Firmware ist hier noch nicht ganz so weit, aber IoT ebnet dem schnellen Wechsel auch hier den Weg).

Und wo kommt hier die MTTR ins Spiel?

Um dem schnellen Wandel zu managen, gehen viele IT-Betreiber „in die Cloud“ oder bauen eine eigene „private Cloud“ auf. Aber in der Cloud ändert sich etwas: wurden vorher noch die Rechenzentren (angefangen von den Netzwerkkomponenten, den Servern, Betriebssystem bis hin zur Laufzeitumgebung) an die Anwendungen angepasst, so diktieren nun die Clouds die komplette Laufzeitumgebung und die Anwendungen werden entsprechend umgebaut oder neu entwickelt. Containerisierung ist hier das Zauberwort und Mittel der Stunde. Aber darüber soll es hier nicht gehen.

Kontrollverlust

Es ist etwas anderes passiert, dass viele übersehen haben: Einflussverlust. Die Anwendungen haben die Kontrolle über die Infrastruktur verloren. Bei einer „Public Cloud“, also das vollständig virtuelle Rechenzentrum bei einem Cloud-Anbieter wie AWS, Azure oder Google, hat der Kunde nur noch extrem wenig Einfluss, was im Netzwerk, der RZ-Technik oder den Servern passiert. Während im eigenen Rechenzentrum meist schon vor dem Ausfall einer wichtigen Infrastrukturkomponente die Warnsignale angehen, bekommt man davon „in der Cloud“ nichts mit. Aber „die Cloud“ heißt nur „Computer eines anderen Unternehmens“, sie ist keine abstrakte Konstruktion im Nirvana. Auch dort gibt es Ausfälle. Für den Nutzer kommen sie nur unvorhergesehen. Natürlich sind die Cloudbetreiber sehr gut im Betrieb der Komponenten, auch sie mögen keine Ausfälle. Aber zählt mal die beteiligten Komponenten bei einer cloudbasierten Anwendung und bei einer altertümlichen RZ-basierten Anwendungen. Man wird sehen, dass die Cloud als verteiltes System in fast allen Fällen komplexer ist als die alten „on premise“-Systeme.

Der Winter…..Fehler kommt!

Es wird also zu vorher nicht absehbaren Fehlern kommen. Fehler, deren Auftreten man nicht beeinflussen kann. Man hat die Kontrolle über die MTBF verloren. Was bleibt? Man muss die MTTR optimieren. Wenn man weiß, dass Fehler passieren und man keine Chance hat, sie wegzuoptimieren oder zumindest zu reduzieren, dann muss man lernen, diese Fehler möglichst schnell in den Griff zu bekommen.

Lessons Learned und die Root Cause Analyse sind übrigens nicht mitgestorben. Aber sie werden nicht jedes Mal gemacht. Erst wenn die gleiche Störung mehrfach auftaucht, oder der Eindruck entsteht, dass verschiedene Störungen einen gemeinsamen Grund haben, kommen sie zum Einsatz.

Die Königin MTBF ist tot, hoch lebe die neue Königin MTTR.