Software fällt aus. Wiederherstellung zählt

9 Min. Lesezeit

Versprechen Sie nicht mehr, dass Software nie ausfällt

Die Besprechung nach einem Ausfall beginnt meist mit Belegen und endet mit Theater. Jemand zeigt den zeitlichen Ablauf. Jemand fragt, warum die Testumgebung das Problem nicht entdeckt hat. Ein Lieferant erklärt, dass sich die Produktion anders verhalten habe. Dann fällt der Satz, mit dem alle gerechnet haben: „Können Sie garantieren, dass das nie wieder passiert?“

Die Runde kann der Wahrheit über Risiko und Wiederherstellung ins Auge sehen. Oder sie kann Perfektion versprechen, drei weitere Freigabestufen einführen und den nächsten Fehler größer machen.

Die zweite Variante ist erstaunlich beliebt. Sie erzeugt sichtbare Aktivität: mehr Unterschriften, eine längere Checkliste und vielleicht einen neuen Ausschuss mit eindrucksvollem Namen. Nichts davon muss Erkennung, Eindämmung oder Wiederherstellung verbessern. Es muss Fehler nur auf einer Folie unwahrscheinlicher aussehen lassen.

Sobald Fehlerfreiheit zum Ziel wird, wirkt Widerstand gegen Veränderungen vernünftig. Releases werden größer, damit sie seltener stattfinden können. Ein Rollback wird schwieriger, weil ein Deployment nun drei dringende Korrekturen, eine Datenbankmigration, zwei regulatorische Änderungen und die Funktion enthält, die der CEO bereits angekündigt hat. Das Unternehmen strebte nach Perfektion und baute eine Geiselnahme.

Software verlangt trotzdem solide Qualitätsarbeit: automatisierte Tests, kontinuierliche Integration, Beobachtbarkeit, sorgfältigen Entwurf, Sicherheit, Wiederherstellungspläne und kompetente Entwickler. Qualität bedeutet jedoch nicht, jeden Fehler auszuschließen. Sie bedeutet, das von Nutzern benötigte Verhalten mit der vom Unternehmen geforderten Zuverlässigkeit bereitzustellen und dabei die Fähigkeit zur nächsten Änderung zu bewahren.

Ein vollkommen stabiles System, das niemand gefahrlos ändern kann, ist kein Triumph. Es ist ein Museumsstück mit Gehaltsliste.

MTBF belohnt das falsche Verhalten

Die mittlere Betriebsdauer zwischen Ausfällen wirkt intuitiv sinnvoll. Beobachten Sie ein System, zählen Sie die Ausfälle und berechnen Sie den durchschnittlichen Abstand. Länger klingt besser. Bei physischen Geräten, deren Bauteile altern und irgendwann ersetzt werden müssen, kann das eine nützliche Betriebsinformation sein.

Software ist kein Kugellager.

Code wird bis Freitag nicht dünner und rostet auch nicht nach einer weiteren Million Anfragen. Nur sein Betriebsumfeld weigert sich, stillzustehen. Teams führen Änderungen ein. Nutzer finden neue Kombinationen. Datenmengen wachsen. Zertifikate laufen ab. Verkehrsmuster ändern sich. Anbieter aktualisieren Dienste. APIs von Lieferanten interpretieren plötzlich Felder neu, die angeblich stabil waren. Angreifer probieren Eingaben aus, an die niemand gedacht hat.

MTBF ist nicht nutzlos. Bei einem stabilen Dienst kann die Kennzahl die Häufigkeit von Vorfällen beschreiben und Personal- oder Kapazitätsentscheidungen unterstützen. Gefährlich wird sie, wenn die Führung sie zum wichtigsten Ziel der Softwarebereitstellung macht.

Es gibt eine wunderbar einfache Methode, die Zeit zwischen fehlgeschlagenen Deployments zu verlängern: keine Deployments mehr.

Die Kennzahl verbessert sich sofort. Das Geschäft nicht.

Änderungen sammeln sich zu größeren Paketen. Rückmeldungen kommen später. Entwickler vergessen, warum Entscheidungen getroffen wurden. Produktion wird zu heiligem Boden, den niemand aus der Entwicklung berühren darf – eine raffinierte Methode, um die Fehler von heute vor den Korrekturen von morgen zu schützen.

MTBF misst den Abstand zwischen sichtbaren Fehlern. Die Kennzahl misst weder die Größe der Änderungspakete noch Angst vor Releases, Wiederherstellungsfähigkeit oder die Chancen, die verloren gehen, während alle auf das perfekte Release warten.

DORA misst das Liefersystem

Das bekannte DORA-Modell war als „Four Keys“ bekannt: Deployment-Häufigkeit, Durchlaufzeit für Änderungen, Fehlerquote bei Änderungen und mittlere Wiederherstellungszeit.

Das Modell hat sich weiterentwickelt. DORA beschreibt heute fünf Kennzahlen für die Leistungsfähigkeit der Softwarebereitstellung, gegliedert in Durchsatz und Instabilität. Die Geschichte dieser Kennzahlen erklärt, warum die frühere Bezeichnung MTTR durch Wiederherstellungszeit nach fehlgeschlagenen Deployments ersetzt und die Nacharbeitsquote bei Deployments ergänzt wurde.

Sicht	Kennzahl	Was sie zeigt
Durchsatz	Durchlaufzeit für Änderungen	Wie lange es dauert, bis eine bestätigte Änderung erfolgreich in Produktion gelangt
Durchsatz	Deployment-Häufigkeit	Wie oft das Unternehmen Änderungen in Produktion bringen kann
Durchsatz	Wiederherstellungszeit nach fehlgeschlagenen Deployments	Wie lange die Wiederherstellung dauert, wenn ein Deployment den Dienst beeinträchtigt und ein Eingriff nötig ist
Instabilität	Fehlerquote bei Änderungen	Welcher Anteil der Deployments einen Rollback, Hotfix, Patch oder eine andere sofortige Korrektur braucht
Instabilität	Nacharbeitsquote bei Deployments	Welcher Anteil der Deployments aus ungeplanter Arbeit besteht, die ein Problem in Produktion behebt, das Nutzer betrifft

Der Wert liegt in der Spannung zwischen den Kennzahlen. Deployment-Häufigkeit ohne Fehlerquote belohnt blindes Tempo. Fehlerquote ohne Deployment-Häufigkeit belohnt Untätigkeit. Durchlaufzeit ohne Nacharbeit kann eine Pipeline feiern, die sehr schnell Unsinn ausliefert. Wiederherstellungszeit ohne nutzerseitige Zuverlässigkeit lässt wiederholte Vorfälle effizient aussehen.

Zusammen beschreiben die Kennzahlen, ob ein Liefersystem nützliche Änderungen sicher in Produktion bringt. Die DORA-Forschung widerlegt die bequeme Annahme, Geschwindigkeit und Stabilität seien Gegensätze. Leistungsstarke Organisationen schneiden meist bei beidem gut ab. Kleinere Änderungen liefern früher Erkenntnisse und lassen sich leichter rückgängig machen.

Die Kennzahlen gehören zu einer Anwendung oder einem Dienst in seinem eigenen Kontext. Alle Teams zu einer einzigen Unternehmenszahl zusammenzumischen, erzeugt einen eindrucksvollen Durchschnitt und sehr wenig Wahrheit. Eine mobile Anwendung mit einem regulierten Großrechnersystem zu vergleichen, ist Managementtheater mit Nachkommastellen.

Nutzen Sie DORA, um zu erkennen, ob sich ein Liefersystem im Zeitverlauf verbessert, nicht um eine Rangliste zu bauen. Sobald eine Kennzahl zur Zielvorgabe wird, lernen Menschen, die Vorgabe zu erfüllen. Die Software interessiert sich weiterhin nicht für das Bonussystem.

Wiederherstellung ist Teil der Lieferfähigkeit

MTTR stellte die Fantasie infrage, Vorbeugung sei die einzige respektable Zuverlässigkeitsstrategie. Mittlere Zeit bis zur Wiederherstellung, Reparatur oder Lösung – wählen Sie Ihre Lieblingsdeutung und beginnen Sie den Streit über das Akronym – lenkte den Blick von Schuld auf Fähigkeit.

DORA hat den Begriff aus gutem Grund eingegrenzt. Die Wiederherstellungszeit nach fehlgeschlagenen Deployments umfasst Beeinträchtigungen, die durch Änderungen in Produktion entstehen. Sie vermischt diese Fehler nicht mit dem Ausfall eines Rechenzentrums, einem durchtrennten Netzwerkkabel oder anderen Vorfällen, die einen Dienst beeinträchtigen können. Dadurch misst sie die Softwarebereitstellung sauberer.

Das breitere Gespräch über Wiederherstellung bleibt wichtig. Dienste fallen auch ohne Deployment aus, und Kunden interessiert nicht, wessen Infrastruktur den Ausfall verursacht hat. Ein CTO sollte die Fragen trotzdem getrennt halten:

• Hat unser Lieferprozess den Fehler verursacht?
• Wie schnell erhielten Nutzer wieder einen akzeptablen Dienst?
• Haben wir das Problem erkannt, bevor Nutzer es meldeten?
• Nutzte die Wiederherstellung den normalen Weg oder brauchte sie privilegierte Improvisation?
• Wie viel Folgearbeit hat der Vorfall erzeugt?

Ein einzelner Durchschnitt kann viel verbergen. Zehn zweiminütige Rollbacks und eine achtstündige Katastrophe können immer noch einen respektablen Mittelwert ergeben. Schweregrad, Wirkungsradius, Erkennungszeit und die Verteilung der Wiederherstellungszeiten zählen. Kennzahlen sind Instrumente, keine Absolution.

Schnelle Wiederherstellung ist kein Trick des Betriebs, der erst beginnt, wenn die Entwickler fertig sind. Sie ist eine Eigenschaft des gesamten Liefersystems und wird bereits gestaltet, wenn die Änderung geplant wird.

Eine kleine Änderung lässt sich leichter verstehen, testen, beobachten, rückgängig machen und ersetzen. Ein automatisiertes Deployment führt die Notfallkorrektur über denselben Weg wie jede gewöhnliche Änderung. Ein Feature-Flag kann Deployment und Freigabe voneinander trennen. Ein Canary-Release begrenzt den Wirkungsradius. Nützliche Überwachung macht Schäden für Nutzer sichtbar. Klare Verantwortung verhindert die zehnminütige Telefonkonferenz darüber, wer handeln darf. Ein getesteter Rollback verhindert, dass die Datenbank zur Einbahnstraße wird.

Keine dieser Praktiken garantiert Erfolg. Sie machen Fehler kleiner und weniger dramatisch.

Deshalb verstärken sich die technischen Praktiken, die Geschäftsergebnisse vorantreiben gegenseitig. Tests erhöhen das Vertrauen. Kontinuierliche Integration deckt unvereinbare Änderungen auf, solange sie noch klein sind. Refactoring hält Wiederherstellungswege verständlich. Häufige kleine Releases verringern die Unsicherheit jedes Deployments.

Das Ergebnis ist Kontrolle in der einzigen Form, die komplexe Software erlaubt: die Wirklichkeit beobachten und auf sie reagieren, ohne alles schlimmer zu machen.

Lange Freigabeketten verbessern die Wiederherstellung selten. Sie können einige Fehler verhindern, aber Erkenntnisse aus der Produktion nicht ersetzen. Wenn etwas ausfällt, wird derselbe Freigabeweg Teil des Ausfalls. Die Notfalländerung wartet, weil die einzige Person mit Freigaberecht in einem Flugzeug sitzt.

Wenn der normale Weg für die Wiederherstellung zu langsam ist, ist der normale Weg zu langsam.

Zuverlässigkeit braucht ein Geschäftsziel

DORA misst die Leistungsfähigkeit der Softwarebereitstellung. Service-Level-Indikatoren und -Ziele für die von Nutzern erlebte Zuverlässigkeit ersetzt das Modell jedoch nicht.

Diese Unterscheidung verhindert zwei gleich schlechte Schlüsse. Das Produktteam kann häufige Deployments nicht als Beweis für einen gesunden Dienst verwenden. Der Betrieb kann Verfügbarkeit nicht als Beweis für ein gesundes Liefersystem verwenden. Ein Dienst kann zuverlässig aussehen, weil niemand ihn zu ändern wagt. Ein Team kann häufig deployen, während Nutzer wiederholt Beeinträchtigungen erleben. Beide Dashboards können grün sein.

Googles SRE-Leitfaden zum bewussten Umgang mit Risiken macht den unbequemen Punkt deutlich: 100 Prozent Zuverlässigkeit sind meist das falsche Ziel. Extreme Zuverlässigkeit verursacht nichtlinear steigende Kosten. Nutzer können den letzten Zuwachs oft nicht wahrnehmen, und der Aufwand dafür kann weder Funktionen verbessern noch technische Schulden oder Betriebskosten senken.

Die nützliche Alternative besteht aus einem ausdrücklich festgelegten Service-Level-Ziel und einem Fehlerbudget. Entscheiden Sie, welche Zuverlässigkeit Nutzer brauchen und was das Unternehmen rechtfertigen kann. Messen Sie die tatsächliche Nutzererfahrung an diesem Ziel. Wenn der Dienst zu viel von seinem Fehlerbudget verbraucht, investieren Sie in Zuverlässigkeit und bremsen riskante Änderungen. Wenn der Dienst deutlich innerhalb des Budgets arbeitet, verbessern Sie das Produkt weiter.

Bei sicherheitskritischem, datenschutzkritischem oder finanziell kritischem Verhalten kann das vertretbare Budget winzig sein. Das Prinzip bleibt gleich: Machen Sie das Risiko ausdrücklich sichtbar, wählen Sie Kontrollen, die zu den Folgen passen, und überprüfen Sie sie. „Niemals ausfallen“ ist keine Kontrolle. Es ist ein Wunsch mit Krawatte.

MTBF kann für Geräteflotten, Infrastrukturkomponenten und die Analyse von Vorfällen nützlich bleiben. Die Kennzahl kann weder ein Service-Level-Ziel ersetzen noch zum Leitstern einer Organisation werden, deren Aufgabe darin besteht, Software zu ändern.

Was ein CTO glaubwürdig versprechen kann

Der Vorstand braucht keinen Vortrag über verteilte Systeme. Er braucht eine glaubwürdige Aussage über Risiken und Belege dafür, dass das Unternehmen sie beherrschen kann:

Wir können nicht garantieren, dass Software niemals ausfällt. Wir können zeigen, dass Änderungen klein, unabhängig rückgängig zu machen und in Produktion beobachtbar sind. Wir wissen, wie oft Deployments einen Eingriff brauchen, wie schnell wir den Dienst wiederherstellen, wie viel ungeplante Nacharbeit Fehler erzeugen und ob Nutzer die vereinbarte Zuverlässigkeit erhalten. Wenn sich diese Signale verschlechtern, investieren wir in den Engpass, statt ihn hinter einem Release-Stopp zu verstecken.

Diese Zusage ist stärker als „nie wieder“. Sie ist messbar, gibt der Führung eine Entscheidungsregel und macht Zuverlässigkeit zu einem gemeinsamen geschäftlichen Anliegen statt zu einer moralischen Last, die nach jedem Vorfall bei den Entwicklern abgeladen wird.

Sie gibt dem CTO auch bessere Fragen für die nächste Besprechung:

• Führen wir seltener Änderungen ein, weil das System stabil ist, oder weil Veränderungen Angst machen?
• Wie groß ist eine typische Änderung in Produktion?
• Lässt sich eine fehlgeschlagene Änderung ohne Sonderbesprechung rückgängig machen?
• Nutzt unser Wiederherstellungsweg dieselbe getestete Pipeline wie ein gewöhnliches Release?
• Welches Service-Level-Ziel bildet die tatsächliche Nutzererfahrung ab?
• Nimmt ungeplante Korrekturarbeit zu, obwohl die Zahl der Vorfälle stabil aussieht?

Diese Antworten verraten weit mehr, als es eine längere MTBF je könnte.

Software lebt in einer Welt, die sich verändert. Die reife Antwort darauf ist weder Resignation noch Nachlässigkeit. Sie besteht darin, bekannte Fehler beharrlich zu verhindern, unbekannte Fehler sichtbar zu machen, ihre Auswirkungen einzudämmen und den Dienst wiederherzustellen, solange der Vorfall noch klein ist.

Perfektion ist nicht der Maßstab. Ein Liefersystem, das die Wahrheit sagt und Dienste ohne Heldentaten wiederherstellt, ist es.