Die Entwicklung von SRE bei Google

• Google SRE hat Ausfälle auch bei wachsender Service-Größe reduziert, sah die bisherigen Methoden allein aber als unzureichend für Verluste, die unbedingt verhindert werden müssen, etwa Datenschutzverletzungen oder Datenverlust, und führte deshalb STAMP ein
• STAMP konzentriert sich weniger auf den Ausfall einzelner Komponenten als auf Systeminteraktionen und Kontrollversagen; CAST wird für Unfalluntersuchungen, STPA für Risikoanalysen genutzt
• Datenflussmodelle und lineare Kausalketten stoßen angesichts von RPC-Diagrammen mit mehr als 100 Knoten, veralteten Architekturmodellen und fehlenden Anforderungen zunehmend an Analysegrenzen
• Bei einem internen Vorfall mit einem quota rightsizer im Jahr 2021 führten falsches Feedback zur Ressourcennutzung und eine nicht weitergeleitete pending change über Wochen zu einem riskanten Zustand, der schließlich in einen Ausfall mündete
• Google investiert in STPA-Analysen Aufwand in der Größenordnung von engineer-weeks, findet dabei Hunderte Szenarien und erweitert den SRE-Ansatz auf Sicherheitsdesigns für Google Cloud, interne Netzwerke und mehrere Produkte

---

Grenzen des bisherigen SRE-Ansatzes

• Google-Produkte werden täglich von Milliarden Menschen weltweit genutzt; in den vergangenen 25 Jahren ist die Service-Größe stark gewachsen, Ausfälle sind jedoch seltener geworden
• SRE hat Zuverlässigkeit bislang mit SLOs, Fehlerbudgets, Isolationsstrategien, gründlichen Postmortems und schrittweisen Rollouts skaliert
• Die Aufgabe besteht heute nicht mehr nur darin, die Häufigkeit von Ausfällen zu senken, sondern Verluste zu behandeln, deren Auftreten von vornherein verhindert werden muss
  • Datenschutzverletzungen
  • Datenverlust
  • Verstöße gegen regulatorische Vorgaben
• Herkömmliche Fehlerbudgets passen meist gut zu Webdiensten mit wenig Zustand, reichen aber nicht aus, um Verluste zu behandeln, bei denen das Fehlerbudget nahe 0 liegt
• Da AI und ML zum Kern fast aller Produkte werden und Automatisierung Skalierbarkeit ermöglicht, werden Kosten- und Energieeffizienz ebenso wichtig wie Nutzerfunktionen

Die Struktur der bisherigen SRE-Denkweise

• Traditionelle Risikoanalyse besteht im Wesentlichen aus drei Elementen
  • der Art, wie ein System modelliert wird
  • einer Kausaltheorie, die erklärt, wie Probleme entstehen
  • einem Suchalgorithmus, der Risiken findet
• Der bisherige Ansatz von Google SRE wurde zwar nicht als explizite Theorie formalisiert, analysierte Risiken aber vor allem anhand von Softwarearchitektur und Datenflussmodellen
• Datenflussmodelle zeigen, wie Netzwerkanfragen oder Daten zwischen verschiedenen Teilen eines Systems wandern
• Dieses Modell führt auf natürliche Weise zu linearem Ursache-Wirkungs-Denken
  • Man betrachtet die SLOs jeder Komponente, um Zuverlässigkeitszusagen zu verstehen
  • Man prüft, ob sie die Anforderungen der Aufrufer erfüllen oder übertreffen
• In Postmortems kommt induktives Schließen zum Einsatz, das aus einzelnen Ereignissen allgemeine Muster ableitet
  • Es geht nicht darum, nur ein einzelnes Ereignis zu beheben, sondern Wege zu finden, ganze Klassen ähnlicher Ereignisse zu verhindern
  • Wiederkehrende Alerts sollen in Engineering-Lösungen überführt werden, die die Ursachen des Problems beseitigen

Grenzen von Datenflussmodellen und linearer Ursachenanalyse

• Da die Systemkomplexität jedes Jahr zunimmt, fällt es Datenflussmodellen immer schwerer, die Komplexität im Google-Maßstab zu bewältigen
• RPC-Diagramme und Softwarearchitekturmodelle werden ohne konsistente Abstraktion schnell übermäßig komplex und bleiben meist unvollständig oder veraltet
• Solche Modelle zeigen die Dynamik eines Systems nicht ausreichend
  • welche RPCs einen Ablauf starten können
  • wie sich Fehler ausbreiten
  • welche Komponenten schwerwiegende Ausfälle verursachen können und welche nur kleinere Probleme auslösen
  • ob bestimmte Interaktionen in einem Kontext sicher, in einem anderen aber unsicher sind
  • welches Ziel das Gesamtsystem verfolgt
  • welche Verantwortung jede Komponente gegenüber dem Gesamtziel hat
• Datenflussdiagramme mit mehr als 100 Knoten sind bereits als Ausgangspunkt für die Fehlersuche überwältigend
• Wenn Sicherheitsanforderungen in der Anforderungsdefinition fehlen oder falsch sind, kann die Systemsicherheit verletzt werden, selbst wenn das Design die Anforderungen perfekt umsetzt
• Aus Ausfalldaten zu lernen hat Grenzen, wenn es darum geht, Verluste vorherzusagen und zu verhindern, die noch nie eingetreten sind

Wie STAMP die Denkweise verändert

• Google SRE übernimmt Systemtheorie und Regelungstheorie und setzt auf das von Nancy Leveson am MIT entwickelte STAMP-Framework
• STAMP betrachtet Unfälle nicht als Kette von Komponentenausfällen, sondern als Ergebnis unzureichender Systemkontrolle
• CAST wird für Untersuchungen nach einem Unfall genutzt, STPA für Risikoanalysen
• STAMP behandelt Sicherheit nicht als Eigenschaft einzelner Komponenten, sondern als emergente Eigenschaft auf Systemebene
• Auch die Analysefragen ändern sich
  • Bisherige Frage: Welcher Softwaredienst ist ausgefallen?
  • STAMP-Frage: Welche Interaktionen zwischen den Teilen des Systems wurden nicht ausreichend kontrolliert?
• Viele Unfälle in komplexen Systemen können daraus entstehen, dass jede Komponente zwar wie vorgesehen funktioniert, gemeinsam aber einen unsicheren Zustand erzeugen

Vier Bedingungen der Regelungstheorie

• Die Kontrollbedingungen aus W.R. Ashbys „An Introduction to Cybernetics“ sind in Levesons STAMP-Methodik integriert
• Um einen Prozess zu steuern, sind vier Bedingungen erforderlich
  • Zielbedingung: Der Controller muss ein Ziel haben
  • Handlungsbedingung: Der Controller muss den Systemzustand beeinflussen können
  • Modellbedingung: Der Controller muss ein Modell des Systems besitzen
  • Beobachtbarkeitsbedingung: Der Controller muss den Systemzustand erfassen können
• In der SRE-Praxis können diese Bedingungen als Kriterien dienen, um die Elemente zu identifizieren, die nötig sind, um komplexe Systeme wirksam zu kontrollieren

Handlungsspielraum durch gefährliche Zustände

• Das Modell linearer Kausalketten zeigt meist nur zwei Zustände: Normalbetrieb und Verlustbetrieb
• Der Übergang vom Normalbetrieb in den Verlustbetrieb erfolgt meist abrupt, sodass kaum Zeit bleibt, den Verlust zu verhindern
• Dass SREs schnelle und langsame burn SLOs gemeinsam einsetzen, dient ebenfalls dazu, Probleme vor dem tatsächlichen Schaden zu erkennen; solche SLOs sind jedoch meist Eigenschaften einzelner Komponenten
• STAMP formalisiert dies als gefährlichen Zustand auf Systemebene
  • Ein gefährlicher Zustand ist ein Systemzustand oder eine Menge von Bedingungen, die in Kombination mit bestimmten Worst-Case-Umgebungsbedingungen für einen oder mehrere Stakeholder einen Verlust verursachen
• Gefährliche Zustände sind keine Phänomene auf Ebene einzelner Ereignisse oder einzelner Komponenten
• Ein System kann lange vor einem Unfall in einem gefährlichen Zustand verharren
  • Ein Bug wurde eingeführt, aber noch nicht getriggert
  • Ein Alert wurde ausgelöst, aber niemand hat ihn erhalten
  • Ein Server ist unterprovisioniert, erhält aber plötzlich Traffic von einem beliebten Feature
• Das Engineering-Ziel besteht nicht darin, jeden einzelnen Fehler zu eliminieren, sondern zu verhindern, dass das System in einen gefährlichen Zustand gerät, oder es aus diesem wieder in den Normalbetrieb zurückzuführen

Beispiel: quota rightsizer im Jahr 2021

• Google setzt in seiner internen Infrastruktur Ressourcen-Quotas für bestimmte Software fest und erzwingt sie
• Um die Effizienz zu erhöhen, wird überwacht, wie viel der Quota jeder Service nutzt; bei dauerhaft geringer Nutzung wird die Quota automatisch reduziert
• Aus STPA-Sicht besitzt der quota rightsizer die Kontrollaktion, Service-Quotas zu reduzieren
• Unsicher ist diese Aktion, wenn der rightsizer die Quota unter den tatsächlichen Bedarf des Services senkt
  • Der Service gerät in Ressourcenknappheit
  • In STPA wird dies als unsichere Kontrollaktion bezeichnet, also als UCA
• Es gibt vier Typen von UCAs
  • Eine erforderliche Kontrollaktion wird nicht bereitgestellt
  • Eine falsche oder unzureichende Kontrollaktion wird bereitgestellt
  • Eine Kontrollaktion wird zum falschen Zeitpunkt oder in der falschen Reihenfolge bereitgestellt
  • Eine Kontrollaktion wird zu früh beendet oder zu lange angewendet
• Eine Reduzierung der Quota unter den tatsächlichen Bedarf entspricht dem zweiten UCA-Typ

Schwachstellen im Feedbackpfad

• Die Sicherheitsanforderung lässt sich so formulieren: „Der quota rightsizer darf die Quota nicht unter den aktuellen Bedarf des Services senken“
• Diese Anforderung ist nützlich für künftiges Design, Testpläne und das Systemverständnis
• STPA strukturiert die Analyse so, dass konkrete Szenarien gefunden werden, die zu einer Verletzung dieser Sicherheitsanforderung führen
• Im rightsizer-Beispiel lassen sich vier repräsentative Szenarien untersuchen
  • Der rightsizer selbst funktioniert falsch
  • Der rightsizer erhält falsches Feedback oder gar kein Feedback
  • Der rightsizer versucht, eine Aktion zu senden, aber das Quota-System erhält sie nicht
  • Das Quota-System selbst funktioniert falsch
• Das in der Praxis auffällige Szenario war, dass das Feedback zur aktuellen Ressourcennutzung zu niedrig berechnet wurde
  • Die Berechnung der Ressourcennutzung umfasst mehrere Datensammler und komplexe Aggregationslogik
  • Wenn das Berechnungsergebnis niedriger als die tatsächliche Nutzung ist, funktioniert der rightsizer zwar wie vorgesehen, senkt die Quota aber fälschlicherweise
• Zuvor lag viel Aufmerksamkeit auf dem Algorithmus zur Quota-Anpassung und der Genauigkeit seiner Ausgaben; der Feedbackpfad wurde weniger gut verstanden
• STPA hilft, nicht nur Probleme im Kontrollpfad, sondern auch im Feedbackpfad zu finden; auch bei Analysen mehrerer Google-Systeme zeigte sich häufig, dass Feedbackpfade weniger gut verstanden waren

Wie der Vorfall zum Verlust führte

• Beim Vorfall im Jahr 2021 wurde falsches Feedback zu den von einem wichtigen Service der Google-Infrastruktur genutzten Ressourcen an den rightsizer gesendet
• Der rightsizer berechnete eine neue Quota, wodurch deutlich weniger Ressourcen zugewiesen wurden als tatsächlich genutzt wurden
• Als Schutzmaßnahme wurde die Quota-Reduzierung nicht sofort angewendet, sondern mehrere Wochen zurückgestellt, um Zeit für menschliches Eingreifen zu geben
• Das Feedback zur pending change wurde jedoch an niemanden weitergeleitet
• Das System befand sich mehrere Wochen lang in einem gefährlichen Zustand; weil aber nicht danach gesucht wurde, ging die Chance verloren, den Verlust zu verhindern
• Einige Wochen später wurde die Quota-Reduzierung angewendet, was zu einer erheblichen Störung führte
• Google nutzte STPA, um ähnliche Probleme in mehreren Systemen im Voraus vorherzusagen

Wohin sich Google SRE entwickelt

• Google SRE betrachtet Komplexität nicht als Bug, sondern bewegt sich mithilfe von Regelungstheorie, STPA und CAST zu einem umfassenderen und proaktiveren Zuverlässigkeitsansatz
• Ziel ist es, nicht nur auf Ausfälle zu reagieren, sondern von Anfang an sicherere Systeme zu entwerfen
• Google hat einige seiner komplexesten Systeme mit STPA analysiert und pro Analyse mit Aufwand in der Größenordnung von engineer-weeks Hunderte Szenarien mit unterschiedlichen Auswirkungen gefunden
• Die gefundenen Szenarien werden entschärft, bevor sie zu Ausfällen führen
  • schnelle temporäre Fixes
  • sorgfältiger geplantes Software Engineering
  • Nutzung der regulären Planungsprozesse von Google zur Minimierung von Kosten und Unterbrechungen
• Die aktuelle Arbeit konzentriert sich auf sehr komplexe Google-Cloud-Systeme, große interne Netzwerksysteme und mehrere Google-Produkte
• Der Wechsel von SRE hin zu Methoden der Systemsicherheit bietet Engineers eine neue Art, die von ihnen gebauten Systeme zu verstehen, und zielt darauf ab, stärkere Garantien über deren Funktionsweise zu geben