L’évolution du SRE chez Google

• Le SRE de Google a réussi à réduire les incidents malgré la croissance de l’échelle des services, mais a estimé que les approches existantes ne suffisaient pas pour les pertes qui doivent absolument être évitées, comme les atteintes à la vie privée ou la perte de données, et a donc adopté STAMP
• STAMP se concentre sur les interactions du système et les défaillances de contrôle plutôt que sur les pannes de composants isolés ; CAST est utilisé pour l’enquête après incident et STPA pour l’analyse des risques
• Les modèles de flux de données et les chaînes causales linéaires montrent rapidement leurs limites analytiques face à des diagrammes RPC de plus de 100 nœuds, des modèles d’architecture obsolètes et des exigences manquantes
• Lors de l’incident interne du quota rightsizer en 2021, un retour erroné sur l’usage des ressources et un pending change non communiqué ont créé pendant plusieurs semaines une situation dangereuse, qui a fini par provoquer une panne
• Google consacre à l’analyse STPA un effort de l’ordre de plusieurs engineer-weeks, identifie des centaines de scénarios et élargit le périmètre du SRE à la conception sûre de Google Cloud, du réseau interne et de plusieurs produits

---

Les limites auxquelles se heurte l’approche SRE existante

• Les produits Google sont utilisés chaque jour par des dizaines de milliards de personnes dans le monde, et si l’échelle des services a fortement grandi au cours des 25 dernières années, les pannes sont devenues plus rares
• Jusqu’ici, le SRE a fait évoluer la fiabilité grâce aux SLO, aux budgets d’erreur, aux stratégies d’isolation, aux analyses postmortem rigoureuses et aux déploiements progressifs
• Le défi n’est plus seulement de réduire la fréquence des pannes, mais de traiter des pertes dont il faut empêcher l’apparition même
  • atteinte à la vie privée
  • perte de données
  • échec de conformité réglementaire
• Les budgets d’erreur traditionnels convenaient globalement bien aux services web avec peu d’état, mais ne suffisent pas pour des pertes qui exigent un budget d’erreur proche de 0
• Alors que l’IA et le ML deviennent au cœur de presque tous les produits, et que l’automatisation rend possible le passage à l’échelle, le coût et l’efficacité énergétique deviennent eux aussi aussi importants que les fonctionnalités pour les utilisateurs

La structure de la pensée SRE traditionnelle

• L’analyse de risque traditionnelle se compose en grande partie de trois éléments
  • la manière de modéliser le système
  • la théorie causale qui explique comment les problèmes surviennent
  • l’algorithme de recherche servant à identifier les risques
• L’approche historique du SRE chez Google n’a pas été formalisée comme une théorie explicite, mais elle a analysé les risques principalement à travers l’architecture logicielle et les modèles de flux de données
• Les modèles de flux de données montrent comment les requêtes réseau ou les données circulent entre les différentes parties du système
• Ce modèle conduit naturellement à un raisonnement linéaire de cause à effet
  • on examine les SLO de chaque composant pour comprendre les garanties de fiabilité
  • on vérifie s’ils satisfont ou dépassent les exigences des appelants
• Dans les postmortems, on utilise un raisonnement inductif pour dégager des schémas généraux à partir d’incidents particuliers
  • il ne s’agit pas seulement de corriger un incident unique, mais de trouver comment empêcher toute une classe d’incidents similaires
  • on cherche à transformer les alertes récurrentes en solutions d’ingénierie pour éliminer la cause du problème

Les limites des modèles de flux de données et de l’analyse causale linéaire

• Avec une complexité système qui augmente chaque année, les modèles de flux de données ont de plus en plus de mal à absorber la complexité à l’échelle de Google
• Les diagrammes RPC et les modèles d’architecture logicielle deviennent excessivement complexes si l’abstraction n’est pas utilisée de manière cohérente, et ils restent le plus souvent incomplets ou obsolètes
• Ces modèles ne montrent pas suffisamment la dynamique du système
  • quelles RPC peuvent initier un flux
  • comment les erreurs se propagent
  • quels composants peuvent provoquer une panne grave et lesquels ne causent que des problèmes mineurs
  • pourquoi certaines interactions sont sûres dans un contexte mais pas dans un autre
  • quels sont les objectifs globaux du système
  • quelles responsabilités chaque composant porte vis-à-vis de ces objectifs
• Un diagramme de flux de données avec plus de 100 nœuds est déjà accablant comme simple point de départ pour la recherche de défaillances
• Si des exigences de sécurité sont omises ou erronées au stade de la définition des exigences, la sécurité du système peut être compromise même si la conception implémente parfaitement ces exigences
• L’apprentissage à partir des données de panne reste limité quand il s’agit de prédire et prévenir des pertes qui ne se sont encore jamais produites

Comment STAMP change la manière de penser

• Le SRE de Google adopte la théorie des systèmes et la théorie du contrôle, et retient le framework STAMP développé par Nancy Leveson au MIT
• STAMP considère un accident non comme une chaîne de défaillances de composants, mais comme le résultat d’un contrôle du système insuffisant
• CAST est utilisé pour les enquêtes après accident, et STPA pour l’analyse des risques
• STAMP traite la sécurité non comme une propriété de composants individuels, mais comme une propriété émergente au niveau du système
• Les questions d’analyse changent elles aussi
  • question classique : quel service logiciel a échoué ?
  • question STAMP : quelles interactions entre les différentes parties du système n’ont pas été suffisamment contrôlées ?
• Dans les systèmes complexes, de nombreux accidents peuvent résulter du fait que chaque composant a fonctionné comme prévu, tout en produisant ensemble un état non sûr

Les quatre conditions de la théorie du contrôle

• Les conditions de contrôle décrites par W.R. Ashby dans An Introduction to Cybernetics sont intégrées à la méthodologie STAMP de Leveson
• Pour contrôler un processus, quatre conditions sont nécessaires
  • condition d’objectif : le contrôleur doit avoir un objectif
  • condition d’action : le contrôleur doit pouvoir agir sur l’état du système
  • condition de modèle : le contrôleur doit disposer d’un modèle du système
  • condition d’observabilité : le contrôleur doit pouvoir connaître l’état du système
• Dans la pratique SRE, ces conditions peuvent servir de critères pour vérifier les éléments nécessaires à un contrôle efficace des systèmes complexes

La marge d’action créée par les états dangereux

• Le modèle linéaire de chaîne causale ne montre généralement que deux états : fonctionnement normal et fonctionnement avec perte
• La transition du fonctionnement normal vers le fonctionnement avec perte est souvent brutale, ce qui laisse très peu de temps pour réagir et éviter la perte
• Si le SRE utilise à la fois des SLO de burn rapide et de burn lent, c’est justement pour détecter des problèmes avant les dommages réels ; mais ces SLO restent généralement des propriétés de composants individuels
• STAMP formalise cela sous la forme d’un état dangereux au niveau du système
  • un état dangereux est un état du système, ou un ensemble de conditions, qui combiné à certaines conditions environnementales défavorables peut entraîner une perte pour une ou plusieurs parties prenantes
• Un état dangereux n’est pas un phénomène au niveau d’un événement isolé ou d’un composant isolé
• Le système peut rester longtemps dans un état dangereux avant qu’un accident ne survienne
  • un bug a été introduit mais n’a pas encore été déclenché
  • une alerte a été émise mais personne ne l’a reçue
  • un serveur est sous-provisionné mais reçoit soudain du trafic sur une fonctionnalité populaire
• L’objectif d’ingénierie n’est pas d’éliminer toutes les défaillances unitaires, mais d’empêcher le système d’entrer dans un état dangereux, ou de le ramener à un fonctionnement normal s’il y entre

Le cas du quota rightsizer en 2021

• Google définit et applique des quotas de ressources pour certains logiciels dans son infrastructure interne
• Pour gagner en efficacité, l’entreprise surveille la part de quota effectivement utilisée par chaque service et réduit automatiquement le quota quand l’usage reste durablement faible
• Du point de vue STPA, le quota rightsizer possède une action de contrôle consistant à réduire le quota d’un service
• Cette action devient non sûre lorsque le rightsizer réduit le quota en dessous du besoin réel du service
  • le service se retrouve en manque de ressources
  • dans STPA, on appelle cela une action de contrôle non sûre, ou UCA
• Il existe quatre types d’UCA
  • une action de contrôle nécessaire n’est pas fournie
  • une action de contrôle incorrecte ou insuffisante est fournie
  • une action de contrôle est fournie au mauvais moment ou dans le mauvais ordre
  • une action de contrôle s’arrête trop tôt ou s’applique trop longtemps
• Réduire un quota en dessous du besoin réel correspond au deuxième type d’UCA

Les vulnérabilités révélées dans le chemin de retour d’information

• L’exigence de sécurité peut se résumer ainsi : « le quota rightsizer ne doit pas réduire un quota en dessous du besoin actuel du service »
• Cette exigence est utile pour les conceptions futures, les plans de test et la compréhension du système
• STPA structure l’analyse de façon à identifier les scénarios concrets qui peuvent conduire à la violation de cette exigence de sécurité
• Dans le cas du rightsizer, quatre scénarios représentatifs peuvent être étudiés
  • le rightsizer lui-même fonctionne mal
  • le rightsizer reçoit un retour d’information erroné, ou n’en reçoit aucun
  • le rightsizer tente d’envoyer une action, mais le système de quota ne la reçoit pas
  • le système de quota lui-même fonctionne mal
• Le scénario réellement mis en évidence était celui d’un retour sur l’usage actuel des ressources calculé trop bas
  • le calcul de l’usage des ressources implique plusieurs collecteurs de données et une logique d’agrégation complexe
  • si le résultat est inférieur à la réalité, le rightsizer fonctionne conformément à sa conception tout en réduisant le quota à tort
• Jusqu’alors, l’attention portait surtout sur l’algorithme d’ajustement des quotas et sur la précision de sa sortie, tandis que le chemin de retour d’information était moins bien compris
• STPA permet d’identifier non seulement les problèmes du chemin de contrôle, mais aussi ceux du chemin de retour d’information ; dans plusieurs analyses de systèmes chez Google, ce chemin de retour s’est souvent révélé moins bien compris

Le déroulé qui a conduit de l’incident à la perte

• Lors de l’incident de 2021, un retour erroné concernant les ressources utilisées par un service critique de l’infrastructure Google a été transmis au rightsizer
• Le rightsizer a calculé un nouveau quota, conduisant à allouer bien moins de ressources que l’usage réel
• Par mesure préventive, la réduction de quota n’a pas été appliquée immédiatement et est restée en attente pendant plusieurs semaines afin de laisser le temps à une intervention humaine
• Cependant, aucun retour sur ce pending change n’a été transmis à qui que ce soit
• Le système est resté pendant plusieurs semaines dans un état dangereux, mais comme personne ne le recherchait, l’occasion d’éviter la perte a été manquée
• Quelques semaines plus tard, la réduction de quota a été appliquée, provoquant une panne importante
• Google a depuis utilisé STPA pour prédire à l’avance des problèmes similaires dans plusieurs systèmes

La direction prise par le SRE chez Google

• Le SRE de Google ne considère pas la complexité comme un bug ; il évolue vers une approche de la fiabilité plus complète et plus proactive, en s’appuyant sur la théorie du contrôle, STPA et CAST
• L’objectif n’est plus seulement de réagir aux pannes, mais de concevoir dès le départ des systèmes plus sûrs
• Google a analysé avec STPA certaines de ses architectures les plus complexes et, pour un effort de l’ordre de plusieurs engineer-weeks par analyse, a identifié des centaines de scénarios aux impacts variés
• Les scénarios découverts ont été atténués avant qu’ils ne se transforment en panne
  • correctifs temporaires rapides
  • ingénierie logicielle planifiée avec davantage de prudence
  • recours aux processus de planification réguliers de Google pour minimiser les coûts et les interruptions
• Les travaux actuels se concentrent sur des systèmes Google Cloud très complexes, des systèmes réseau internes à grande échelle et plusieurs produits Google
• Le passage du SRE à une méthodologie de sûreté des systèmes propose aux ingénieurs une nouvelle manière de comprendre les systèmes qu’ils construisent, avec l’ambition d’offrir des garanties plus fortes sur leur fonctionnement