Was ist Reliability Engineering?

Was ist Reliability Engineering?

Reliability Engineering (Zuverlässigkeitstechnik) ist die Praxis, Systeme so zu entwerfen, zu betreiben und zu verbessern, dass sie ein messbares Zuverlässigkeitsziel erreichen, etwa den Anteil erfolgreicher Anfragen oder ein Latenz-Perzentil. Das Ziel wird festgeschrieben und gemessen, und das Team wägt dagegen ab, zum Beispiel schneller ausliefern oder erst die Stabilität verbessern. Site Reliability Engineering (SRE) ist die bekannteste Variante in der Softwarewelt.

Reliability Engineering, SRE und DevOps

Die Begriffe überschneiden sich, meinen aber Verschiedenes. Reliability Engineering ist das Ziel: Das System erreicht seine Vorgaben. SRE ist Googles Betriebsmodell dafür. Laut dem SRE-Buch hat Benjamin Treynor Sloss es 2003 bei Google begonnen, und es beschreibt SRE als „what happens when you ask a software engineer to design an operations team“. Google begrenzt operative Arbeit auf 50 % der Zeit eines SRE, der Rest geht in Engineering. DevOps ist eine Kultur samt Werkzeugen, die die Lücke zwischen Entwicklung und Betrieb schließt.

Ein praktischer Test: Wenn Ihr Team eine Zuverlässigkeitszahl hat, die es verteidigt, betreiben Sie Reliability Engineering, egal welche Jobtitel auf den Visitenkarten stehen.

Die zentralen Bausteine

• SLI (Service Level Indicator). Eine sorgfältig definierte, quantitative Kennzahl für einen Aspekt des Dienstes, etwa Antwortzeit oder Fehlerrate.
• SLO (Service Level Objective). Ein Zielwert oder Zielbereich für einen SLI, zum Beispiel „99,9 % der Anfragen sind erfolgreich“.
• SLA (Service Level Agreement). Ein Vertrag mit Konsequenzen, falls die Ziele verfehlt werden. Gibt es keine ausdrückliche Konsequenz, handelt es sich meist um ein SLO. Siehe SLA-Management.
• Error Budget. Eins minus Verfügbarkeitsziel. Bei 99,99 % bleiben 0,01 %, die für Releases und Experimente ausgegeben werden können. In Googles Modell werden Releases angehalten, wenn das Budget aufgebraucht ist.
• Incident Response und blameless Postmortems. Postmortems konzentrieren sich auf die beitragenden Ursachen, ohne eine Person oder ein Team zu beschuldigen, und werden für wesentliche Vorfälle geschrieben.
• Toil-Reduktion. Toil ist manuelle, wiederkehrende, automatisierbare Arbeit, die mit dem Dienst wächst. Das SRE-Ziel ist, sie unter 50 % der Zeit jedes Ingenieurs zu halten.
• Kapazität und Architektur. Redundanz, Isolation von Abhängigkeiten und kontrollierte Funktionsabstufung, belegt durch Kapazitätstests.

Beispiel: ein SLO und sein Budget

Die Zahlen sind beispielhaft. Angenommen, der SLI ist der Anteil der /checkout-Anfragen, die in unter 1.500 ms erfolgreich sind, und das SLO liegt bei 99,9 % über 30 Tage. Das Error Budget beträgt 0,1 %. Bei 1.000.000 Checkout-Anfragen im Zeitraum sind das 1.000 fehlerhafte Anfragen. Ist das Budget schon in der ersten Woche zur Hälfte verbraucht, bremst das Team riskante Releases und arbeitet an der Stabilität. Wird es kaum angetastet, kann das Team schneller ausliefern oder das SLO verschärfen.

Das SRE-Buch gibt nützliche Hinweise zur Wahl der Zahlen: Gehen Sie von dem aus, was Nutzern wichtig ist, nutzen Sie wenige Indikatoren, bevorzugen Sie Perzentile gegenüber Durchschnitten (warum Perzentile Durchschnitte schlagen, auf Englisch), übernehmen Sie nicht einfach Ihre aktuelle Leistung als SLO und starten Sie mit einem lockereren Ziel, das Sie später verschärfen. Nachlesen können Sie das im Kapitel zu Service Level Objectives (auf Englisch).

Kennzahlen von Reliability-Teams

• SLO-Erreichung: der Anteil des SLO-Ziels, der pro Dienst im Zeitraum erreicht wurde.
• Burn Rate des Error Budgets: wie schnell das Budget verbraucht wird und wann es in diesem Tempo aufgebraucht ist.
• MTTD (Mean Time to Detect): vom Beginn eines Vorfalls bis zum ersten Alarm.
• MTTR (Mean Time to Restore): vom Beginn eines Vorfalls bis zur für Nutzer sichtbaren Wiederherstellung.
• Change Failure Rate: der Anteil der Deployments, die einen Vorfall oder Rollback auslösen.
• Toil-Anteil: der Teil der Arbeitszeit, der auf manuelle, wiederkehrende Aufgaben entfällt.

Häufige Fehler

• 100 % anstreben. Das SRE-Buch sagt, 100 % sei wahrscheinlich nie das richtige Zuverlässigkeitsziel: Nutzer merken den Unterschied nicht, und die Kosten steigen steil.
• Zu viele Indikatoren. Eine Handvoll repräsentativer genügt, um den Zustand eines Systems zu beurteilen.
• Nach Durchschnitten urteilen. Ein guter Mittelwert kann einen langsamen Rand verbergen, den echte Nutzer spüren.
• Ein Error Budget, nach dem niemand handelt. Es wirkt nur, wenn ein aufgebrauchtes Budget ändert, was das Team tut.
• SLOs, die nie überprüft werden. Gleichen Sie sie mit dem echten Nutzerverhalten und den Produktplänen ab.
• Postmortems ohne Konsequenz. Weisen Sie jede Maßnahme einer Person zu und verfolgen Sie sie bis zum Abschluss.
• Nie unter Last testen. Ein Latenz-SLO, das Sie nur zu ruhigen Zeiten gesehen haben, ist eine Vermutung.

Wo Lasttests und Monitoring ins Bild passen

Ein Latenz-SLO lässt sich nur verteidigen, wenn belegt ist, dass das System unter realistischer Parallelität liefert. Lasttests vor Launches und nach großen Änderungen liefern diesen Beleg. Mit LoadFocus Load Testing setzen Sie Pass/Fail-Schwellen für P95- und P99-Antwortzeit, Fehlerrate und Durchsatz, sodass jeder Lauf ein Urteil bekommt, und eine GitHub Action kann ein Deployment blockieren, wenn eine Schwelle verletzt wird. So wird Ihr SLO zum Release-Gate.

In Produktion prüft API-Monitoring Ihre Endpunkte nach Zeitplan aus mehreren Regionen und alarmiert bei fehlgeschlagenen Assertions. LoadFocus API Monitoring hat einen kostenlosen Plan mit Prüfungen alle 5 Minuten. Statusseiten können die aus diesen Prüfungen berechnete Verfügbarkeit zeigen und Vorfälle melden. Metriken, Logs und Traces behandelt Observability, und unser Leitfaden zu Monitoring Best Practices (auf Englisch) beschreibt die Gewohnheiten drumherum.

Häufige Fragen

Was ist der Unterschied zwischen Reliability Engineering und SRE?

Reliability Engineering ist die Disziplin, ein System messbare Zuverlässigkeitsziele erreichen zu lassen. SRE ist ein konkreter Weg dorthin, bei Google entstanden: Softwareingenieure betreiben die Produktion mit SLOs, Error Budgets und einer Obergrenze für operative Arbeit.

Was ist ein Error Budget?

Es ist eins minus Verfügbarkeitsziel. Bei einem Ziel von 99,99 % beträgt das Budget 0,01 %. Teams geben es für Releases und Experimente aus und bremsen oder stoppen riskante Änderungen, wenn es aufgebraucht ist.

Was ist der Unterschied zwischen SLO und SLA?

Ein SLO ist ein internes Ziel für ein Service-Level, das ein SLI misst. Ein SLA ist ein Vertrag mit Nutzern, der Konsequenzen enthält, wenn die Ziele verfehlt werden. Ohne ausdrückliche Konsequenz handelt es sich meist um ein SLO.

Sind 100 % Verfügbarkeit ein gutes Ziel?

Meistens nicht. Das SRE-Buch argumentiert, dass 100 % wahrscheinlich nie das richtige Ziel sind, weil Nutzer den Unterschied selten bemerken und jede weitere Neun mehr kostet. Wählen Sie ein Ziel, das zu dem passt, was Nutzer brauchen und was Sie sich leisten können.

Wie fange ich an?

Wählen Sie eine für Nutzer kritische Strecke, definieren Sie dafür einen SLI, setzen Sie ein lockeres SLO und messen Sie es aus Produktionsdaten. Berechnen Sie das Error Budget, legen Sie fest, was passiert, wenn es aufgebraucht ist, und führen Sie nach jedem wesentlichen Vorfall ein Postmortem ohne Schuldzuweisung durch.