Verfügbarkeit
Verfügbarkeit beschreibt, ob eine klar benannte Funktion zu einem bestimmten Zeitpunkt erfolgreich nutzbar ist. Jede Aussage braucht deshalb eine Funktion, einen Zeitraum und ein Erfolgskriterium.
- FunktionVerfügbarkeit gilt je Funktion.
- ZeitraumEine Aussage gilt für ein Zeitfenster.
- ZielDas Ziel legt fest, wie viel Ausfall erlaubt ist.
Einordnung
Warum das wichtig ist
Verfügbarkeit gilt je Funktion, nicht für „das System“. Sie ergibt sich aus der Ausfallhäufigkeit (MTBF) und der Wiederherstellungszeit (MTTR): Seltener oder kürzer ausfallen erhöht sie. Wie schnell ein Dienst zurückkehrt, behandelt Wiederherstellung.
Hier legst du fest und misst, ob eine Funktion nutzbar ist. Wie die Architektur das erreicht, zeigen die Taktiken unten; Ziele im Betrieb steuern SLIs, SLOs & Error Budgets.
Auf einen Blick · Verfügbarkeit je Funktion und Zeitraum
Zwei Funktionen, eine Störung
Der Shop kann eine Bestellung mit dem Status Klärung läuft annehmen, während der externe Zahlungsanbieter zeitweise nicht antwortet. Die Bestellannahme bleibt damit nutzbar; die Zahlungsautorisierung ist in diesem Zeitraum gestört.
So liest du das Bild
- Funktion Kacheln Bestellannahme und Zahlungsautorisierung zeigen bei derselben Störung verschiedene Zustände.
- Zeitraum Schalter 10:00, 10:04, 10:12; im Regler „pro Monat“ und „pro Jahr“.
- Ziel Regler „Was bedeuten die Neunen?“ übersetzt Prozent in erlaubte Ausfallminuten.
- läuftBestellannahmenimmt Bestellungen an
- läuftZahlungsautorisierungautorisiert Zahlungen
- läuftBestellung B-1042wird bezahlt
2 von 2Nutzbare Funktionen
Im Normalbetrieb sind beide Funktionen nutzbar. Die Aussage gilt je Funktion und Zeitraum.
Werte illustrativ
Was bedeuten die Neunen?
Taktiken
So erreicht die Architektur das Ziel
Dieser Baustein legt fest und misst, ob eine Funktion nutzbar ist; die Taktiken unten sind eigene Bausteine, die dieses Ziel erreichen.
Fehler erkennen
Im Shop merkst du, dass der Zahlungsdienst hakt, bevor Kunden an der Kasse scheitern.
Fehler abfangen
Antwortet der Zahlungsanbieter nicht, bleibt die Bestellannahme nutzbar, statt mit ihm auszufallen.
Wiederherstellen
Nach einem Ausfall kehren Bestellungen und Funktionen mit geprüften Verfahren zurück.
Nutzen & Grenzen
Hilft, wenn
- Eine geschäftskritische Funktion benötigt ein abgestimmtes Ziel für Unterbrechung und Wiederherstellung.
- Externe oder interne Abhängigkeiten können unterschiedliche Teile einer Leistung beeinträchtigen.
Grenzen
- Ein Prozentwert sagt nichts über die Verteilung der Ausfälle. 43 Minuten am Stück während einer Rabattaktion schaden anders als verteilte Minuten nachts. Ergänze daher die maximale Dauer einzelner Ausfälle und die kritischen Zeitfenster, und miss sie als SLO je Funktion.
- Redundanz garantiert keine schnelle Wiederherstellung und bleibt wirkungslos, wenn Instanzen dieselbe Fehlerquelle teilen, etwa dieselbe Datenbank oder denselben Zahlungsanbieter. Prüfe Wiederanlauf und Datenrückkehr mit Wiederherstellungsverfahren und benenne verbleibende gemeinsame Fehlerquellen.
In der Praxis
- Funktion und Nutzererfolg bestimmen. Lege fest, welches Ergebnis als verfügbar gilt und für wen. Das Ergebnis verankert die Verfügbarkeitsmessung in einer tatsächlichen Systemleistung.
- Ziel, Zeitraum und Fehlerbudget abstimmen. Vereinbare Messfenster und zulässige Abweichung mit Fachseite und Betrieb. Verknüpfe das Ziel mit SLIs und SLOs, damit Messwert und Steuerung zusammenpassen.
- Fehlergrenzen und Wiederherstellung erproben. Simuliere relevante Ausfälle und prüfe, wie Funktion und Daten zurückkehren. Wiederherstellung beschreibt die Verfahren, die das Ziel im Ernstfall stützen.
Ausführliche Erklärung lesen
Verfügbarkeit bezieht sich auf eine konkrete Funktion und einen Zeitraum. Ein technischer Prozess kann laufen, während die für Nutzer wichtige Leistung fehlschlägt. Deshalb müssen Erfolgskriterium, Messpunkt und Zeitfenster festgelegt werden. SLIs, SLOs & Error Budgets verbinden Messung und Ziel; Wiederherstellung behandelt Rückkehr nach einem Ausfall.
Architektur und Betrieb begrenzen Fehlerfolgen durch Redundanz, Isolation, Wiederanlauf und alternative Abläufe. Jede Maßnahme bringt Kosten und eigene Abhängigkeiten mit sich. Regelmäßige Ausfall- und Wiederanlauftests ergänzen den Zielwert um Fehlerursache und Wiederherstellungszeit und prüfen, ob die Zusage unter realistischen Bedingungen trägt.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viel Ausfall pro Monat erlaubt ein Ziel von 99,9 %?
Lösung mit Begründung ansehen
Rund 43 Minuten pro Monat (43,2 min bei 30 Tagen) und etwa 8,76 Stunden pro Jahr.
AnwendenAuf eine neue Lage übertragen
Ein Kunde gibt um 10:06 eine weitere Bestellung auf, während der Anbieter nicht antwortet. Was kann der Shop leisten?
Lösung mit Begründung ansehen
Er kann die Bestellung annehmen, denn die Bestellannahme bleibt nutzbar. Die Zahlungsautorisierung ist in diesem Zeitraum gestört, daher ist die Klärung noch offen.
BewertenEine Alternative abwägen
Soll der Shop bei ausbleibender Antwort sofort „Zahlung fehlgeschlagen“ melden, um den Kunden nicht warten zu lassen?
Lösung mit Begründung ansehen
Das gibt schnell Klarheit. Der Nachteil: Eine ausbleibende Antwort belegt keinen fachlichen Fehlschlag, und die Zahlung könnte doch autorisiert sein. Der Status Klärung läuft ist fachlich ehrlicher.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Google SRE · Availability Table (öffnet in neuem Tab)Übersetzt Verfügbarkeitsziele in tolerierbare Ausfallzeiten.
- Google SRE · Service Level Objectives (öffnet in neuem Tab)Leitet messbare Dienstqualität aus Nutzererwartungen ab.
- arc42 Qualitätsmodell · Availability (öffnet in neuem Tab)Ordnet Verfügbarkeit im Qualitätsmodell ein und nennt Szenarien und Maßnahmen.