STPA – Schulung zu Googles neuer Methode zur Vermeidung von Ausfällen

• STPA (System Theoretic Process Analysis, systemtheoretische Prozessanalyse) ist eine Methode zur Modellierung von Kontroll-Feedback-Schleifen in komplexen Systemen auf Basis von System- und Regelungstheorie
  • Google nutzt STPA, um Softwaresysteme zu analysieren und potenzielle Risiken zu erkennen
• STPA behandelt Systemsicherheit als Kontrollproblem und analysiert alle Kontrollhandlungen, durch die ein System in einen gefährlichen Zustand geraten kann
• Statt sich auf die Ergebnisse einzelner Handlungen zu konzentrieren, liegt der Fokus auf gefährlichen Zuständen, um Grundursachen zu finden
  • Wenn man die Kontrollhandlungen versteht, die zu gefährlichen Zuständen führen, kann man sie verhindern oder eine automatische Wiederherstellung ermöglichen
  • Wenn eine automatische Wiederherstellung schwierig ist, kann stattdessen ein menschlicher Operator gewarnt werden

Warum Google die STPA-Schulung anpasst

• Mit STPA häufen sich erfolgreiche Fälle, in denen unentdeckte Probleme im Voraus gefunden und Ausfälle verhindert wurden
• Vorhandene STPA-Schulungsmaterialien sind auf physische Systeme ausgerichtet und daher schwer auf Softwareumgebungen übertragbar
• Deshalb wurde eine maßgeschneiderte Schulung für Googles reine Softwaresysteme notwendig

Erste Versuche mit STPA-Schulungen

• Seit 2021 laufen erste Schulungen (für 40 Google-Ingenieure)
• Es wurden Beispiele aus physischen Systemen verwendet (z. B. der Absturz des Mars Polar Lander) → geringe Identifikation bei Softwareingenieuren
• Daraus entstand die Einsicht, dass reale Beispiele aus Google-Systemen nötig sind

Schulung des Konzepts der Kontrollstruktur

• Eine Kontrollstruktur (control structure) besteht aus einer grundlegenden Kontroll-Feedback-Schleife
  • Ein Controller steuert Zustandsänderungen → überprüft den Zustand über Feedback und entscheidet dann über die nächste Handlung
• Anwendungsbeispiele in Softwareumgebungen
  • Beispiel: Löschen oder Korrigieren fehlerhafter Inhalte in einer Datenbank für nutzergenerierte Inhalte
  • Wenn die Feedback-Schleife nicht korrekt entworfen ist, können fehlerhafte Kontrollhandlungen auftreten
• Herausforderungen in der Schulung
  • In begrenzter Zeit ist es schwierig, den Entwurf nützlicher Kontrollstrukturen zu vermitteln
  • Da sich die Kontrollstrukturen je nach Softwaresystem unterscheiden, ist gezieltes Feedback schwer zu geben

Strategien zur Verbesserung der STPA-Schulung

• Schulung aller STPA-Schritte → damit Ingenieure STPA eigenständig durchführen können
• Nutzung realer Google-Beispiele → nach der Theorie folgt die Anwendung auf echte Fälle
• Fokus auf die Verstärkung der Feedback-Pfade in der Kontrollstruktur
  • Analyse von Fällen, in denen fehlerhaftes Feedback → fehlerhafte Kontrollhandlung → Ausfall verursacht hat
  • Unzureichendes Feedback an menschliche Operatoren → gefährliche Zustände entstehen

Die Bedeutung von Feedback

• In einem Google-System führte fehlerhaftes Feedback 30 Tage später zu einer falschen Kontrollhandlung → Ausfall
• Ursache waren fehlerhaftes Feedback und unzureichendes Feedback an menschliche Operatoren
• Mit richtigem Feedback-Design lassen sich Ausfälle verhindern
• Auch die Explosion der Ariane-5-Rakete ist ein Beispiel für einen Feedbackfehler
  • Beim Umwandeln von Fließkommadaten in Integer trat ein Fehler auf
  • Feedbackfehler → falsche Zustandserkennung → Fehler in der Raketensteuerung und Explosion

Datenflussdiagramm vs. Kontrollstruktur

• Datenflussdiagramm (Dataflow Diagram)
  • Zeigt, wie Daten zwischen Softwarekomponenten übertragen werden
  • Feedback und Kontrollstruktur sind nicht klar ersichtlich
• Kontrollstruktur (Control Structure)
  • Zeigt Kontrollhandlungen und Feedback → die Hierarchie der Steuerung wird klar
  • Erleichtert das Erkennen von Feedbackproblemen → Ursachen in komplexen Systeminteraktionen lassen sich zurückverfolgen

Wirkung des STPA-Einsatzes

• In komplexer Software lässt sich der Bereich mit hoher Problemwahrscheinlichkeit von Millionen Codezeilen auf wenige Hundert eingrenzen
• Gefährliche Kontrollhandlungen werden als Szenarien modelliert → problematischer Code kann identifiziert werden
• In realen Fällen wurden nach dem Aufbau der Kontrollstruktur fehlende Feedbacks erkannt und korrigiert

Veränderungen in der Schulungsstrategie

• Lange Schulungszeiten → Umstellung auf kurze Trainingseinheiten
  • 30 bis 60 Minuten Tutorial → interessierte Ingenieure werden zur Teilnahme an Workshops motiviert
• Einführung eines selbstgesteuerten Lernmodells
  • Kurze Videos + Aufgaben → fördern die Anwendung von STPA auf reale Systeme
  • Die Schulung wird so ausgebaut, dass erste STPA-Analysen auch ohne Eingreifen von Experten möglich sind

Strategie zur Verbreitung von STPA bei Google

• Ausbildung von STPA-Experten → sie können STPA innerhalb ihrer Teams weiterverbreiten
• Erste Erfolge → Ausweitung auf andere Teams → STPA-Einsatz in der gesamten Organisation
• Nach der STPA-Schulung lassen sich Risikofaktoren bereits in der Entwurfsphase beseitigen

Auch in anderen Unternehmen anwendbar

• STPA ist ein leistungsfähiges Werkzeug, um in komplexen Softwaresystemen „unentdeckte Risikofaktoren“ zu finden
• Es kann in kleinen Teams beginnen und unter Leitung von STPA-Experten ausgeweitet werden
• Entscheidend ist die Entwicklung einer auf das Unternehmen zugeschnittenen STPA-Schulung
• Nach anfänglichen Fehlversuchen kann die Richtung angepasst werden → letztlich steigen Systemstabilität und Zuverlässigkeit

[GN⁺]

Hacker-News-Kommentare

• Bei Google gab es einen Fall, in dem ein Software-Controller fehlerhaftes Feedback erhielt und daraufhin eine gefährliche Steuerungsaktion ausführte

  • Diese Aktion war zur Ausführung in 30 Tagen geplant
  • Es gab Anzeichen dafür, dass eine gefährliche Aktion eintreten würde, aber es gab keinen Engineer, der dies überwachte
  • Am Ende trat die gefährliche Steuerungsaktion nach 30 Tagen tatsächlich ein und verursachte einen Dienstausfall
  • Es gibt einen Kommentar, der sich fragt, ob es sich dabei um den Vorfall mit dem gelöschten Regierungsdatenbank handelt
  • Der Versuch einer verallgemeinernden, schuldzuweisungsfreien Darstellung ist gut, aber der Stil war so überzogen, dass man nichts daraus lernen konnte

• Der STPA-Kurs war gut strukturiert, und das Google-Beispiel war hilfreich

  • Der Artikel selbst enthielt jedoch keine konkreten Beispiele

• STPA ist ein Framework für Design-Reviews, um weniger offensichtliche Fehlermodi zu finden

  • FMEA ist populärer, listet aber nur Fehlermodi auf, die man bereits kennt
  • STPA füllt die Lücken bei Fehlermodi, an die man nicht gedacht hat

• Es gibt Kommentare, die sagen, dass es schwer zu verstehen ist, man es aber verstehen möchte

  • Es braucht eine konkrete Erklärung, wie es bei Google auf einen bestimmten Service angewendet wird
  • Es wird nicht ausreichend erklärt, warum „B zu wenig Feedback von C erhält“ problematisch ist

• Wäre ein realer Fall gezeigt worden, in dem STPA bei Google tatsächlich ein Zuverlässigkeitsproblem gelöst hat, wäre das überzeugender gewesen

• STAMP/STPA funktioniert gut als Modell und Methodik für komplexe Systeme

  • Es gab Interesse an der Quantifizierung von Cyber-Risiken
  • Andere Ansätze liefern kein Modell, mit dem sich gefährliche Steuerungsaktionen leicht verstehen lassen
  • Es wäre wünschenswert, wenn mehr Unternehmen dies übernehmen würden

• Nach dem Aufbau einer Steuerungsstruktur in Zusammenarbeit mit Systemexperten wurde sofort klar, dass dem Feedback von Controller C an B etwas fehlt

  • Es gibt eine Feedback-Schleife über D
  • Es wird gefragt, warum das Problem einer fehlenden direkten Verbindung von B zu D nicht ebenfalls relevant ist
  • Nach erneutem Lesen wurde klar, dass die vertikale Richtung wichtig ist, um Steuerung und Feedback darzustellen

• Das ist eine typische Mischung aus Unternehmensübertreibung, Buzzwords und dem Versuch, alte Ideen als innovativ erscheinen zu lassen

  • Es gibt einen unbeholfenen Versuch, eine Kindheitserinnerung an die Reparatur eines Radios mit STPA zu verknüpfen
  • Google behauptet, die Anwendung von STPA auf Software sei innovativ, obwohl es sich um eine alte Methode handelt
  • Der Großteil des Inhalts sind grundlegende Engineering-Konzepte zu Feedback-Schleifen und Steuerungsstrukturen
  • Die eigentliche Aussage ist, dass Google ein internes Schulungsprogramm entwickelt hat
  • Das Ende wirkt wie eine typische Unternehmensstrategie nach dem Muster, man müsse unbedingt STPA verwenden

• Es gibt die Meinung, Google solle ein Jahr lang still sein und höchstens leise wie ein Staubsauger summen