STPA - nouvelle formation de Google SRE pour prévenir les incidents

• STPA (System Theoretic Process Analysis) est une méthode qui modélise les boucles de contrôle-rétroaction de systèmes complexes à partir de la théorie des systèmes et du contrôle
  • Google utilise STPA pour analyser des systèmes logiciels et découvrir des risques potentiels
• STPA traite la sûreté du système comme un problème de contrôle et analyse toutes les actions de contrôle pouvant faire basculer le système dans un état dangereux
• L’approche cherche les causes profondes en se concentrant sur les états dangereux plutôt que sur le résultat d’actions individuelles
  • Comprendre les actions de contrôle qui mènent à un état dangereux permet de les prévenir ou d’automatiser la reprise
  • Si la reprise automatique est difficile, il est possible d’alerter un opérateur humain

Pourquoi Google personnalise la formation STPA

• Les cas de réussite où STPA permet de découvrir à l’avance des problèmes non identifiés et de prévenir des incidents se multiplient
• Les supports de formation STPA existants sont centrés sur les systèmes physiques, ce qui les rend difficiles à appliquer à des environnements logiciels
• Une formation sur mesure adaptée aux systèmes purement logiciels de Google est devenue nécessaire

Premières tentatives de formation STPA

• Début de la formation initiale dès 2021 (pour 40 ingénieurs Google)
• Utilisation de cas issus de systèmes physiques (ex. le crash de Mars Polar Lander) → faible adhésion des ingénieurs logiciels
• Prise de conscience de la nécessité de cas réels appliqués aux systèmes Google

Enseigner le concept de structure de contrôle

• Une structure de contrôle (control structure) est constituée d’une boucle de contrôle-rétroaction de base
  • Un contrôleur pilote les changements d’état → vérifie l’état via le retour d’information puis décide de l’action suivante
• Exemples d’application dans un environnement logiciel
  • Ex. suppression ou modification de contenus erronés dans une base de données de contenus générés par les utilisateurs
  • Si la boucle de rétroaction est mal conçue, des actions de contrôle erronées peuvent se produire
• Défis pédagogiques
  • Il est difficile, dans un temps limité, d’enseigner la conception de structures de contrôle réellement utiles
  • Comme chaque système logiciel a sa propre structure de contrôle, il est difficile de fournir un retour pertinent

Stratégie d’amélioration de la formation STPA

• Enseigner toutes les étapes de STPA → aider les ingénieurs à mener STPA de manière autonome
• Utiliser des cas réels de Google → expliquer la théorie puis l’appliquer à des cas concrets
• Mettre l’accent sur le renforcement des chemins de rétroaction dans les structures de contrôle
  • Analyse de cas où un mauvais retour d’information → action de contrôle erronée → incident
  • Manque de retour d’information pour les opérateurs humains → apparition d’un état dangereux

L’importance du retour d’information

• Dans un système Google, un retour d’information erroné a entraîné, 30 jours plus tard, une mauvaise action de contrôle → incident
• La cause était à la fois un retour d’information erroné et l’absence de retour suffisant vers les opérateurs humains
• Une conception correcte du retour d’information peut prévenir les incidents
• L’explosion de la fusée Ariane 5 est aussi un exemple d’erreur de retour d’information
  • Une erreur s’est produite lors de la conversion de données en virgule flottante en entier
  • Erreur de retour d’information → mauvaise perception de l’état → erreur d’orientation de la fusée puis explosion

Diagramme de flux de données vs. structure de contrôle

• Diagramme de flux de données (Dataflow Diagram)
  • Montre comment les données circulent entre les composants logiciels
  • Le retour d’information et la structure de contrôle n’y apparaissent pas clairement
• Structure de contrôle (Control Structure)
  • Montre les actions de contrôle et le retour d’information → la hiérarchie de contrôle est claire
  • Facilite l’identification des problèmes de rétroaction → permet de remonter plus facilement à la cause dans les interactions de systèmes complexes

Effets de l’application de STPA

• Dans des logiciels complexes, permet de réduire de plusieurs millions de lignes de code à quelques centaines les zones où un problème est le plus susceptible de se produire
• La mise en scénario d’actions de contrôle dangereuses permet d’identifier le code problématique
• Dans des cas réels, la construction de la structure de contrôle a permis d’identifier puis de corriger un manque de retour d’information

Évolution de la stratégie de formation

• Passage de longues formations à des sessions plus courtes
  • Tutoriels de 30 à 60 minutes → amener les ingénieurs intéressés à participer à des ateliers
• Introduction d’un modèle d’apprentissage autonome
  • Courtes vidéos + exercices → encourager l’application de STPA à des systèmes réels
  • Renforcement de la formation pour permettre d’effectuer une première analyse STPA sans intervention d’experts

Stratégie de diffusion de STPA chez Google

• Former des experts STPA → capables de diffuser STPA au sein de leurs équipes
• Succès initiaux → extension à d’autres équipes → application de STPA à l’échelle de l’organisation
• Après la formation STPA, les facteurs de risque peuvent être éliminés dès la phase de conception

Applicable aussi dans d’autres entreprises

• STPA est un outil puissant pour trouver des « risques non identifiés » dans des systèmes logiciels complexes
• Il est possible de commencer dans une petite équipe puis d’étendre la pratique sous l’impulsion d’experts STPA
• Le point clé est de développer une formation STPA adaptée à l’entreprise
• Après quelques tâtonnements initiaux, il est possible de corriger la trajectoire → et, au final, d’améliorer la stabilité et la fiabilité du système

[GN⁺]

Commentaires sur Hacker News

• Chez Google, il y a eu un cas où un contrôleur logiciel a reçu un retour erroné et a exécuté une action de contrôle dangereuse

  • Cette action avait été planifiée pour être exécutée 30 jours plus tard
  • Il y avait des signes indiquant qu’une action dangereuse allait se produire, mais aucun ingénieur ne surveillait cela
  • Finalement, 30 jours plus tard, l’action de contrôle dangereuse a eu lieu et a provoqué une interruption de service
  • Certains se demandent s’il s’agit de l’incident de suppression d’une base de données gouvernementale
  • La tentative de généralisation sans blâme est appréciée, mais le style est tellement ampoulé qu’il n’y avait rien à en tirer

• Le cours sur la STPA est bien structuré, et l’exemple de Google a été utile

  • En revanche, l’article lui-même ne contenait pas d’exemples concrets

• La STPA est un framework de revue de conception destiné à trouver des modes de défaillance moins évidents

  • La FMEA est plus populaire, mais elle ne fait qu’énumérer les modes de défaillance déjà connus
  • La STPA permet de combler les angles morts, en mettant au jour des modes de défaillance auxquels on n’avait pas pensé

• Certains disent que c’est difficile à comprendre, mais qu’ils veulent quand même en apprendre davantage

  • Il faudrait une explication concrète de la manière dont cela s’applique à un service précis chez Google
  • L’explication de pourquoi « B manque de feedback de C » est problématique n’est pas suffisante

• Cela aurait été plus convaincant s’il y avait eu des cas réels où la STPA a permis de résoudre des problèmes de fiabilité chez Google

• STAMP/STPA fonctionne bien comme modèle et méthodologie pour les systèmes complexes

  • Certains s’intéressaient à la quantification du risque cyber
  • Les autres approches ne fournissent pas de modèle permettant de comprendre facilement les actions de contrôle dangereuses
  • Davantage d’entreprises devraient l’adopter

• Après avoir construit une structure de contrôle en collaboration avec des experts système, il est devenu immédiatement clair que le contrôleur C manquait de feedback vers B

  • Il existe une boucle de feedback via D
  • Certains se demandent pourquoi le problème de l’absence de connexion directe de B vers D ne s’applique pas lui aussi
  • En relisant, ils ont compris que la direction verticale est importante pour représenter le contrôle et le feedback

• Il s’agit d’un récit d’entreprise exagéré, plein de buzzwords, qui tente de faire passer de vieilles idées pour quelque chose d’innovant

  • Il y a une tentative maladroite de relier une histoire de réparation de radio pendant l’enfance à la STPA
  • Google affirme qu’appliquer la STPA au logiciel est une innovation, alors qu’il s’agit d’une méthode ancienne
  • L’essentiel du contenu repose sur des concepts d’ingénierie de base autour des boucles de feedback et des structures de contrôle
  • Le vrai message est que Google a créé un programme de formation interne
  • La fin ressemble à une stratégie d’entreprise classique disant qu’on ne peut pas se passer de la STPA

• Certains disent qu’ils aimeraient que Google reste silencieux pendant un an, en faisant juste un bruit d’aspirateur