Verfügbarkeit und Zuverlässigkeit: Neunen, MTBF, MTTR und Fehlertoleranz

Vier Begriffe, die oft verwechselt werden

Benutzer erleben ein System entweder als funktionierend oder nicht. Architekten brauchen genauere Begriffe, denn jeder Begriff verweist auf eine andere Antwort im Design. Verfügbarkeit ist der Anteil der Zeit (oder der Anfragen), in dem das System bereit ist, seinen Dienst auf Anforderung zu erbringen. Zuverlässigkeit ist die Wahrscheinlichkeit, dass das System über einen festgelegten Zeitraum unter festgelegten Bedingungen korrekt und ohne Ausfall arbeitet. Fehlertoleranz ist die Fähigkeit, den Dienst weiter zu erbringen, obwohl ein Teil ausgefallen ist. Resilienz ist die umfassendere Fähigkeit, Störungen aufzufangen, den wesentlichen Dienst (vielleicht eingeschränkt) aufrechtzuerhalten und sich danach wieder auf den Normalzustand zu erholen.

ISO/IEC 25010:2023 ordnet Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit zusammen mit Fehlerfreiheit (die den Begriff Reife von 2011 ersetzt hat) als Teilmerkmale der Zuverlässigkeit ein. Bass, Clements und Kazman behandeln Verfügbarkeit in Software Architecture in Practice als eigenes Qualitätsmerkmal, weil sie so viele Architekturentscheidungen bestimmt. Keine der beiden Sichtweisen ist falsch; nutzen Sie die, die dem Gespräch hilft, aber sagen Sie ausdrücklich, welchen Begriff Sie meinen.

Der Unterschied zwischen Verfügbarkeit und Zuverlässigkeit ist in der Praxis wichtig. Stellen Sie sich einen Dienst vor, der einmal pro Stunde abstürzt und in einer Sekunde neu startet. Seine Verfügbarkeit beträgt 3599 / 3600 = 99,97 %, was hervorragend aussieht. Seine Zuverlässigkeit über einen zweistündigen Batch-Job ist schlecht: Treten Ausfälle zufällig mit einer Rate von einem pro Stunde auf, liegt die Wahrscheinlichkeit, zwei Stunden ohne Ausfall zu laufen, bei e^-2, etwa 13,5 %. Für ein Zahlungsterminal zählt die Verfügbarkeit; für eine lange wissenschaftliche Berechnung, einen Operationsroboter oder ein Flugzeug zählt die Zuverlässigkeit über die gesamte Mission.

Fehlerursache, Fehler und Ausfall

Die Dependability-Forschung (Avižienis, Laprie, Randell und Landwehr, 2004) trennt drei Begriffe, die die Alltagssprache vermischt. Eine Fehlerursache (Fault) ist die Ursache: ein Bug, eine defekte Festplatte, eine Fehlkonfiguration, ein abgelaufenes Zertifikat. Eine Fehlerursache kann jahrelang schlummern. Wird sie aktiviert, erzeugt sie einen Fehler (Error): einen Teil des internen Systemzustands, der falsch ist, etwa einen beschädigten Datensatz oder einen falschen Wert im Speicher. Erreicht der Fehler die Grenze des Dienstes, ist das Ergebnis ein Ausfall (Failure): Der Dienst, den die Benutzer erhalten, weicht davon ab, wie er sein sollte.

Bass, Clements und Kazman verwenden dieselbe Idee einfacher: Ein Ausfall ist eine Abweichung von der Spezifikation, die die Benutzer des Systems beobachten können, und die Ursache eines Ausfalls ist eine Fehlerursache. Für Architekten zählt, dass jedes Glied der Kette ein Ansatzpunkt ist. Sie können verhindern, dass Fehlerursachen entstehen (Code-Reviews, eine Komponente außer Betrieb nehmen, bevor sie verschleißt), Fehler erkennen, bevor sie sich ausbreiten (Validierung, Health Checks), und Fehler eindämmen oder maskieren, sodass sie nie zu Ausfällen werden (Redundanz, Wiederholungen, Transaktionen).

Die Neunen zählen

Verfügbarkeitsziele werden meist als Prozentsatz mit einer Anzahl von Neunen angegeben: 99,9 % sind drei Neunen. Es hilft, jedes Ziel in zulässige Ausfallzeit umzurechnen, denn ein Prozentsatz verschleiert, wie wenig Zeit Sie wirklich haben. Die Rechnung ist einfach: Ausfallzeit = (1 - Verfügbarkeit) x Zeitraum. Ein Jahr mit 365 Tagen hat 525.600 Minuten, also erlauben 99,9 % 0,001 x 525.600 = 525,6 Minuten, etwa 8,76 Stunden. Für einen Monat mit 30 Tagen (43.200 Minuten) sind es 43,2 Minuten.

Jede weitere Neun teilt das Kontingent durch zehn, während die Entwicklungskosten meist viel schneller steigen. Bei 99,99 % haben Sie etwa 4,3 Minuten pro Monat: weniger als die Zeit, die vergeht, bis jemand alarmiert ist, aufwacht, sich anmeldet und versteht, was nicht stimmt. Oberhalb von drei oder vier Neunen muss die Wiederherstellung daher automatisch erfolgen; Menschen sind zu langsam, um Teil der Schleife zu sein.

MTBF, MTTF und MTTR

Drei Mittelwerte verbinden Ausfälle und Reparaturen. Mean Time to Failure (MTTF) ist die durchschnittliche Zeit, die eine Komponente läuft, bevor sie ausfällt. Mean Time to Repair (MTTR) ist die durchschnittliche Zeit vom Ausfall bis zum wiederhergestellten Dienst (manche Organisationen lesen das R als „Recover“ oder „Restore“; die Idee ist dieselbe, aber sagen Sie, welche Uhr Sie verwenden: ab dem Ausfall, ab der Erkennung oder ab dem ersten Alarm). Mean Time Between Failures (MTBF) ist die durchschnittliche Zeit von einem Ausfall bis zum nächsten.

Die klassische Formel für den stationären Zustand lautet A = MTBF / (MTBF + MTTR). Genau genommen gilt für ein reparierbares System MTBF = MTTF + MTTR, und der exakte Ausdruck ist MTTF / (MTTF + MTTR): Betriebszeit geteilt durch Betriebszeit plus Ausfallzeit. Lehrbücher schreiben oft MTBF, wo sie die mittlere Betriebszeit meinen; wenn Reparaturen im Vergleich zur Zeit zwischen Ausfällen kurz sind, wie es meist der Fall ist, ist der Unterschied vernachlässigbar. Die Formel setzt einen langfristigen Mittelwert voraus und sagt nichts darüber, wie Ausfälle verteilt sind; deshalb passt sie gut zu einem Zuverlässigkeitsmaß und zu Perzentilen der Reparaturzeit.

Komponenten in Reihe und parallel

Reale Systeme sind Ketten von Teilen. Braucht eine Anfrage die Webschicht, den Anwendungsserver und die Datenbank, müssen alle drei funktionieren: Die Komponenten sind in Reihe geschaltet, und ihre Verfügbarkeiten multiplizieren sich. Da jeder Faktor unter eins liegt, ist das Produkt immer niedriger als das schwächste Glied. Zehn Komponenten mit je 99,9 % ergeben 0,999¹⁰ = 0,990, nur 99,0 %.

Genügt dagegen eine beliebige von mehreren identischen Kopien, sind die Kopien parallel geschaltet (Redundanz). Das Paar fällt nur aus, wenn alle Kopien gleichzeitig ausfallen; daher multipliziert man die Nichtverfügbarkeiten: A_parallel = 1 - (1 - A)ⁿ für n identische Kopien. Zwei Server mit je 99 % ergeben 1 - 0,01 x 0,01 = 99,99 %.

Verfügbarkeitstaktiken: erkennen, erholen, vorbeugen

Bass, Clements und Kazman gliedern Verfügbarkeitstaktiken in drei Familien. Sie sind Designoptionen, keine Checkliste, die vollständig abzuarbeiten ist; jede hat ihren Preis.

Die Wahl zwischen Active-Passive und Active-Active

Active-Passive ist leichter zu durchschauen, besonders bei zustandsbehafteten Komponenten wie einer relationalen Datenbank mit einem einzigen beschreibbaren Primärknoten. Die Kosten sind der ungenutzte Standby, eine Failover-Lücke (Erkennung plus Hochstufung, oft einige zehn Sekunden) und das Risiko, dass der Standby unbemerkt aus dem Takt geraten ist. Eine klassische Falle ist Split Brain: Das Netzwerk zwischen beiden bricht ab, jeder hält den anderen für tot, und beide nehmen Schreibvorgänge an. Dagegen hilft ein Quorum oder ein externer Schiedsrichter.

Active-Active nutzt die gesamte Kapazität und hat keinen Hochstufungsschritt, aber jeder Knoten muss so dimensioniert sein, dass er die volle Last tragen kann, wenn sein Partner ausfällt. Zwei Knoten mit je 70 % Auslastung werden bei Ausfall des einen mit 140 % belastet, und der Überlebende bricht zusammen: ein redundantes Design, das trotzdem ausfällt. Active-Active zwingt Sie außerdem, die Datenkonsistenz über Kopien hinweg zu lösen, was ein großes Thema für sich ist (siehe Konsistenzmodelle, CAP und PACELC).

Disaster Recovery: RTO und RPO

Redundanz innerhalb eines Rechenzentrums schützt Sie nicht davor, das ganze Rechenzentrum, eine Region, ein Cloud-Konto oder Ihre Daten durch Ransomware zu verlieren. Die Disaster-Recovery-Planung arbeitet mit zwei Zahlen, die vom Fachbereich kommen sollten, nicht von den Engineers. Das Recovery Time Objective (RTO) ist die längste akzeptable Zeit, um den Dienst nach einer Katastrophe wiederherzustellen. Das Recovery Point Objective (RPO) ist der größte akzeptable Datenverlust, gemessen in Zeit: Ein RPO von 15 Minuten bedeutet, dass Sie höchstens die Änderungen der letzten 15 Minuten verlieren dürfen.

Die beiden Zahlen führen zu sehr unterschiedlichen Designs und Kosten. Nächtliche Backups, die in eine andere Region kopiert werden, ergeben ein RPO von bis zu 24 Stunden und ein RTO von vielen Stunden (Terabytes wiederherzustellen dauert). Kontinuierliche asynchrone Replikation zu einem Warm Standby in einer anderen Region kann ein RPO von Sekunden und ein RTO von Minuten ergeben, bei vielleicht doppelten Infrastrukturkosten. Synchrone Replikation kann das RPO nahe null bringen, fügt aber jedem Schreibvorgang die Round-Trip-Zeit zwischen den Standorten hinzu. Cloud-Anbieter beschreiben eine Stufenleiter von Strategien: Backup and Restore, Pilot Light, Warm Standby und Multi-Site Active-Active, jede schneller und teurer als die vorige. Die Einzelheiten gehören zu Multi-Region und Disaster Recovery.

Unabhängig von der Strategie gilt: Ein Backup, das Sie nie wiederhergestellt haben, ist kein Backup. Testen Sie Wiederherstellungen regelmäßig und messen Sie die Zeit; die gemessene Wiederherstellungszeit ist Ihr echtes RTO.

Von Zielen zu SLIs, SLOs und SLAs

Der moderne Betrieb drückt Verfügbarkeit mit drei verwandten Begriffen aus, die in SLIs, SLOs und Error Budgets ausführlich behandelt werden. Ein Service Level Indicator (SLI) ist die Messung, zum Beispiel der Anteil der Checkout-Anfragen, die in weniger als 800 ms erfolgreich sind. Ein Service Level Objective (SLO) ist das interne Ziel für diese Messung über ein Zeitfenster, zum Beispiel 99,9 % über 30 Tage. Ein Service Level Agreement (SLA) ist ein Vertrag mit Kunden, der Folgen benennt, etwa Gutschriften, wenn ein Niveau verfehlt wird; es wird normalerweise lockerer angesetzt als das SLO, damit das Team gewarnt ist, bevor der Vertrag verletzt wird.

Das SLO macht aus Verfügbarkeit ein Budget. Ein monatliches SLO von 99,9 % erlaubt, dass 0,1 % der Anfragen fehlschlagen; bei 2 Millionen Anfragen pro Monat sind das 2000 fehlgeschlagene Anfragen oder etwa 43 Minuten Totalausfall. Teams geben dieses Error Budget für Risiken aus: Releases, Experimente, Migrationen. Ist es aufgebraucht, treten sie kürzer und investieren in Zuverlässigkeit. So verbinden sich die abstrakten Neunen dieses Abschnitts mit alltäglichen Entscheidungen.

Häufige Fehler

Neunen versprechen, ohne die Abhängigkeiten mitzuzählen: Ein Dienst mit 99,99 %, der auf einer einzigen Datenbank mit 99,9 % aufbaut, kann sein Ziel nicht erreichen. Redundanz hinzufügen, ohne gemeinsame Ursachen zu beseitigen (dasselbe Release, derselbe Konfigurations-Push, dasselbe Zertifikat, das um Mitternacht auf jedem Knoten abläuft). Verfügbarkeit innerhalb des Systems messen, wo alles grün aussieht, während Benutzer es wegen DNS oder eines Content Delivery Network nicht erreichen. Failover planen, aber nie proben; Chaos Engineering gibt es genau dafür, diese Pfade bewusst zu üben (Chaos Engineering). Schließlich: einer Zahl um ihrer selbst willen nachjagen. Ein Dienstplansystem, das während der Bürozeiten genutzt wird, braucht keine fünf Neunen, und das Geld ist anderswo besser angelegt.

Um Verfügbarkeit testbar zu machen, schreiben Sie sie als Szenario (Abschnitt 2.3): Fällt der primäre Datenbankserver während der Stoßzeiten aus, erkennt das System dies innerhalb von 10 Sekunden und nimmt innerhalb von 60 Sekunden wieder Bestellungen an, ohne eine bestätigte Bestellung zu verlieren. Jeder Teil dieses Satzes wird zu einer Designentscheidung und zu einem Test.