Die Entwicklung von SRE bei Google

• Googles Produkte werden von Milliarden Menschen weltweit genutzt, und es ist wichtig, dass diese Produkte zuverlässig funktionieren. Das SRE-Team von Google hat im Laufe der Zeit verschiedene Methoden entwickelt, um die Zuverlässigkeit von Diensten zu verbessern.
• Konventionelle SRE-Praktiken wie Error Budgets und Post-Mortems haben dabei wesentlich dazu beigetragen, dass Google Webdienste in großem Maßstab ausbauen konnte.
• Durch KI/ML ist die Systemkomplexität stark gestiegen, sodass neue Ansätze erforderlich wurden.
• Systemtheorie und Regelungstheorie sind nützlich, um komplexe Interaktionen systematisch zu erfassen.
• Anstatt einfach nur „nach dem Auftreten eines Problems“ zu reagieren, ist ein Ansatz erforderlich, der die Sicherheit von Beginn an auf Systemebene grundsätzlich sicherstellt.

STAMP-Übersicht

• Das von der MIT-Professorin Nancy Leveson vorgeschlagene STAMP (System-Theoretic Accident Model and Processes) analysiert Unfälle (Ereignisse) aus der Perspektive komplexer Systeminteraktionen statt aus der Perspektive einzelner Bauteilfehler.
• Anstatt der herkömmlichen Kausalität („Bug vorhanden, deshalb fällt etwas aus“) steht im Mittelpunkt die Frage, „in welchen fehlerhaften Kontrollflüssen das gesamte System stecken geblieben ist“.
• Unfälle werden mit der Causal Analysis based on Systems Theory (CAST) rekonstruiert, und mit der System-Theoretic Process Analysis (STPA) werden Gefahrenquellen im Voraus identifiziert.

Grundlagen der Regelungstheorie – vier Bedingungen

• In der Regelungstheorie sind vier Voraussetzungen für wirksame Kontrolle nötig:
  • Zielbedingung: Es muss ein Ziel existieren (z. B. das Halten bestimmter Kennzahlen).
  • Aktionsbedingung: Das System muss den Zustand beeinflussen können, um das Ziel zu erreichen.
  • Modellbedingung: Es wird ein Modell zur Systemerfassung benötigt (intern wie extern).
  • Beobachtungsbedingung: Es braucht ein Beobachtungssystem wie Sensoren, um den aktuellen Systemzustand zu erfassen.

Ausfälle als Kontrollproblem behandeln

• Früher wurde Ausfall häufig mit „Kettenausfällen“ beschrieben.
• STAMP interpretiert dies als eine Frage unzureichender Kontrolle und Interaktion und stellt so die Sicherheit auf Systemebene sicher.
• Anstatt nur herauszufinden, „wo der erste Fehler begann“, wird umfassend geprüft, „welcher Kontroll-/Feedback-Fluss abnormal war“.

Zeit durch Hazard-Zustände gewinnen

• Traditionelle Kausalmodelle gehen davon aus, dass ein System vom Normalzustand in einem Moment in den Ausfallzustand wechselt, weshalb die Reaktionszeit extrem kurz ist.
• STAMP führt den Begriff des Hazard-Zustands ein, um den Punkt zu identifizieren, an dem ein Risiko vor dem vollständigen Ausfall erreicht wurde.
• Nach der Erkennung eines Hazard-Zustands schafft aktives Eingreifen die Möglichkeit, einen tatsächlichen Ausfall zu verhindern.

Konkrete Beispiele

• Googles internes „Quota Rightsizer“-Tool weist Ressourcen basierend auf der Service-Nutzung neu zu.
• Aus STPA-Sicht lässt sich frühzeitig eine Situation erkennen, in der aufgrund falscher Auslastungsinformationen zu wenig Ressourcen im Vergleich zum tatsächlichen Bedarf bereitgestellt werden.
• Im Designprozess lag der Fokus meist nur auf einer „korrekten Steuerlogik“, doch mit STPA wurden Probleme im Feedback-Pfad (z. B. im Prozess der Ressourcenverbrauchsberechnung) aufgedeckt.
• Im Jahr 2021 führte angesammelte fehlerhafte Rückmeldung zu einem großen Problem, und es gibt einen Fall, bei dem das System wochenlang im Hazard-Zustand war, ohne dass es erkannt wurde.

Zukünftige Ausrichtung

• Google SRE verfolgt mit den systemtheoretischen Ansätzen STAMP, STPA und CAST ein höheres Maß an Sicherheit und Komplexitätsmanagement.
• Schon mit einem vergleichsweise kleinen Engineering-Aufwand (nur wenigen Wochen) lassen sich in Großsystemen zahlreiche potenzielle Gefahrenszenarien identifizieren.
• Wird die auf Kontrolle basierende Analyse neben der bestehenden Zuverlässigkeitskultur eingeführt, steigt die Wahrscheinlichkeit, auch im KI/ML-Zeitalter einen stabilen Dienst bereitzustellen können.

[GN⁺]

Hacker News Kommentar

• Der Engineering-Ansatz von Google kann für Startups schädlich sein. SREs entwickeln oft ein Heldensyndrom und neigen dazu, technische Entwürfe anderer Teams neu zu machen.

  • Das ähnelt dem Phänomen, dass die Rechtsabteilung versucht, das Unternehmen zu führen.

• Er erinnert stark an das Buch von Sidney Dekker.

  • Er bewertet das Gesamtsystem und analysiert den Denkstatus der an einem Vorfall Beteiligten, um zu erklären, warum sie davon überzeugt waren, die richtige Entscheidung getroffen zu haben.
  • Er erklärt, wie unabhängige Veränderungen in komplexen Systemen die Sicherheit beeinflussen können.

• Der CAST-Ansatz wirkt überzeugend.

  • Er erfordert umfangreiche Analysen von Ausfällen und Beinahe-Ausfällen, wobei der menschliche Faktor bei der Umsetzung am schwierigsten ist.

• Es gibt eine interessante Ähnlichkeit zwischen CAST und mechanischer Ursachenanalyse.

  • Er liefert ein Framework, mit dem sich analysieren lässt, wie sich die Systemkomponenten gegenseitig beeinflussen.

• Ich frage mich, ob es Beispiele dafür gibt, dass ein formales Sicherheits-Engineering-Framework auf Neural-Network-Analysen angewendet wurde.

  • Ein Ansatz, der komplexe Kausalbeziehungen und Systemverhalten auf Systemebene nachverfolgt, könnte nützlich sein.

• Auch beim Beispiel rightsizer wäre möglicherweise dasselbe Ergebnis mit einem traditionellen Ansatz erzielt worden.

  • Der neue Ansatz ist jedoch einfacher und umsetzbarer.

• Der Grund, warum Menschen Softwaretests ablehnen, liegt in Fehlern durch externe Faktoren.

  • Dieser Ansatz kann helfen, das zu lösen.

• CAST ähnelt einer Multi-Factor-Root-Cause-Analyse.

  • Es unterstützt das CAST von Nancy Leveson, Professorin am MIT.

• Es gibt die Frage, ob SRE/DevOps Teil der alltäglichen Rolle ist.

  • In vielen Fällen ist es nur ein Rebranding vorhandener Operations-Rollen.

• Das größte Merkmal von Google SRE ist, dass man bei der Einführung neuer Produkte SRE-Hilfe benötigt.

  • Die begrenzte Anzahl an SREs macht gute Ideen besser.

• Der Artikel ist viel zu lang und schwer, den Kern zu treffen.

  • Die Erwähnung von CAST und STPA ist am wichtigsten und nützlichsten.

• Ich frage mich, ob dieser Ansatz auch für Größen außerhalb von FAANG wertvoll sein kann.

  • Es gibt eine starke Tendenz, viel in Risikovermeidung zu investieren.

• Wie bei DevOps erweitert sich auch die Bedeutung von SRE.

  • SRE übernimmt verschiedene Rollen, vom Schreiben von Software bis hin zur Verarbeitung von Systemausfällen.