Évolution du SRE chez Google

• Les produits Google sont utilisés par des milliards de personnes dans le monde, et il est crucial qu’ils fonctionnent de manière fiable. L’équipe SRE de Google a développé diverses méthodes pour améliorer la fiabilité de ses services.
• Les techniques SRE traditionnelles (error budget, postmortem, etc.) ont largement contribué à l’expansion de l’échelle des services web chez Google.
• Avec la montée en puissance de l’IA et du ML, la complexité des systèmes a fortement augmenté, ce qui rend nécessaire de nouvelles approches.
• La théorie des systèmes et la théorie du contrôle sont utiles pour appréhender de manière systématique les interactions complexes.
• Il est essentiel d’adopter une approche qui garantit la sécurité dès la conception au niveau du système, plutôt que de simplement “résoudre après-coup” les incidents.

Vue d’ensemble de STAMP

• Proposé par la professeure Nancy Leveson du MIT, le STAMP (System-Theoretic Accident Model and Processes) analyse les incidents (accidents) sous l’angle des interactions complexes d’un système, plutôt que sous celui d’une défaillance d’un composant unique.
• Plutôt que la causalité classique (« un bug provoque une panne »), il met l’accent sur la question : « le système dans son ensemble s’est-il retrouvé dans un flux de contrôle incorrect ? »
• Il reconstruit les incidents avec le Causal Analysis based on Systems Theory (CAST) et identifie les facteurs de risque à l’avance avec le System-Theoretic Process Analysis (STPA).

Fondements de la théorie du contrôle – quatre conditions

• En théorie du contrôle, quatre conditions sont nécessaires à un contrôle efficace
  • Condition d’objectif : il faut un objectif (par ex. maintenir un indicateur précis)
  • Condition d’action : le système doit pouvoir influencer son état pour atteindre cet objectif
  • Condition de modèle : des modèles (internes et externes) du système sont nécessaires pour le comprendre
  • Condition d’observabilité : des mécanismes d’observation, comme des capteurs, sont nécessaires pour connaître l’état actuel du système

Aborder les pannes (Outage) comme un problème de contrôle

• Auparavant, on avait plutôt tendance à expliquer les incidents comme des « pannes en chaîne ».
• STAMP les interprète comme des problèmes de « contrôle et d’interactions inappropriées », assurant la sécurité au niveau du système.
• Plutôt que de chercher uniquement « d’où vient la première panne », on examine globalement « quel flux de contrôle/feedback était anormal ».

Gagner du temps à partir de l’état de danger (Hazard)

• Les modèles causaux traditionnels passent d’un état normal à un état d’incident de façon abrupte, ce qui laisse très peu de temps de réaction.
• STAMP introduit la notion d’« état de hazard » pour repérer, avant un accident complet, le point où l’on entre dans une situation dangereuse.
• Après détection de l’état de danger, une intervention proactive permet d’avoir une chance de prévenir le problème avant qu’il ne devienne un incident réel.

Cas concrets

• En interne, le « Quota Rightsizer » de Google réaffecte les ressources en fonction de la consommation des services.
• Du point de vue de STPA, il est possible d’identifier à l’avance une situation où des informations de charge erronées réduisent les ressources en dessous des besoins réels.
• En phase de conception, on se concentrait surtout sur une « logique de contrôle précise », mais l’application de STPA a permis de détecter des problèmes dans les chemins de feedback (tels que le calcul de l’utilisation des ressources).
• Un cas réel survenu en 2021 montre qu’un feedback incorrect accumulé a fini par provoquer un incident majeur, alors que l’on est resté en état de hazard pendant plusieurs semaines sans s’en rendre compte.

Pistes futures

• L’équipe SRE de Google poursuit un niveau supérieur de sûreté et de gestion de la complexité grâce à des approches fondées sur la théorie des systèmes, comme STAMP, STPA et CAST.
• Même un investissement en ingénierie relativement modeste (de quelques semaines) permet de détecter de nombreux scénarios de risque potentiels dans les grands systèmes.
• Combinée à la culture de fiabilité existante, l’analyse basée sur la théorie du contrôle augmente les chances de fournir des services stables à l’ère de l’IA et du ML

[GN⁺]

Avis Hacker News

• L’approche d’ingénierie de Google peut être nuisible pour une startup : les SRE ont parfois un syndrome du sauveur et ont tendance à vouloir revoir les conceptions techniques des autres équipes

  • C’est similaire à des équipes juridiques qui veulent faire fonctionner l’entreprise

• Il y a des points communs avec les ouvrages de Sidney Dekker

  • Il analyse pourquoi on en vient à croire que les décisions prises étaient les bonnes, en évaluant le système global et l’état mental des acteurs impliqués dans l’incident
  • Il explique comment des changements indépendants dans des systèmes complexes peuvent affecter la sécurité

• L’approche CAST est séduisante

  • Elle exige beaucoup d’analyses de défaillances et de quasi-accidents, et la partie la plus difficile à implémenter est l’humain

• Il existe une similitude intéressante entre CAST et le travail d’analyse mécanique

  • Elle offre un cadre pour analyser la manière dont les composants d’un système interagissent entre eux

• Je me demande s’il existe des exemples d’application d’un cadre officiel d’ingénierie de la sécurité à l’analyse de réseaux de neurones

  • Une telle méthode peut être utile pour suivre des causalités complexes et des comportements à l’échelle du système

• Même si l’exemple du « rightsizer » avait été analysé avec une méthode classique, on aurait peut-être obtenu le même résultat

  • La nouvelle approche est plus simple et plus facile à appliquer

• La raison de la répulsion pour les tests logiciels vient des défauts causés par des facteurs externes

  • Cette approche pourrait aider à résoudre ce problème

• CAST ressemble à l’analyse des causes profondes multi-facteurs

  • Je soutiens le CAST de la professeure Nancy Leveson du MIT

• Question de savoir si SRE/DevOps fait partie du fonctionnement opérationnel quotidien

  • Dans bien des cas, il ne s’agit que d’un rebranding d’un rôle d’exploitation existant

• Le trait le plus marquant des SRE de Google est que l’aide des SRE est nécessaire lorsqu’on lance de nouveaux produits

  • Un nombre limité de SRE permet d’améliorer de bonnes idées

• L’article est trop long et il est difficile d’en saisir les points essentiels

  • Les mentions de CAST et de STPA sont les plus importantes et les plus précieuses

• Je me demande si cette approche a une valeur à des échelles hors FAANG

  • Il y a une tendance à investir beaucoup dans l’évitement des risques

• Comme avec DevOps, le périmètre de SRE continue de s’élargir

  • Les SRE remplissent plusieurs rôles, de l’écriture de logiciels à la gestion des pannes système