- Le SRE de Google a commencé avec de petits datacenters et des opérations basées sur des scripts Python, puis a formalisé son expérience d’amélioration de la fiabilité dans un environnement dont l’échelle de calcul a été multipliée par plus de 1 000 et celle du réseau par plus de 10 000
- En réponse aux incidents, la sécurité des mesures d’atténuation passe avant la rapidité d’action, car des procédures de reprise erronées peuvent aggraver des défaillances en chaîne au lieu de réduire la panne
- Les cas de YouTube et de Google Calendar montrent la nécessité des déploiements canary pour limiter les changements globaux, d’un Big Red Button permettant un retour arrière immédiat, et de tests d’intégration qui valident le chemin réel
- Comme lors de la panne des jetons OAuth en 2017, quand une dépendance critique s’effondre, non seulement les utilisateurs mais aussi le dispositif interne de réponse vacillent ; il faut donc des canaux de communication de secours et une dégradation gracieuse
- Des déploiements fréquents, une atténuation automatisée, des exercices de reprise après sinistre et la diversité matérielle sont des principes pratiques qui réduisent le MTTR et évitent les points uniques de défaillance dans les systèmes distribués complexes
Les changements d’échelle traversés par le SRE de Google en 20 ans
- Il y a 20 ans, Google exploitait deux petits datacenters, chacun avec plusieurs milliers de serveurs, reliés en anneau par deux liens réseau de 2,4 G
- À l’époque, l’exploitation reposait largement sur des scripts Python comme
Assigner,AutoreplaceretBabysitter, ainsi que sur des fichiers de configuration contenant les noms de serveurs individuels - Une petite base de données de machines appelée MDB servait à organiser et maintenir en continu les informations sur chaque serveur
- Aujourd’hui, la puissance de calcul a été multipliée par plus de 1 000 et le réseau par plus de 10 000, mais l’effort d’exploitation par serveur a diminué et la fiabilité de la pile de services s’est améliorée
- Les outils d’exploitation ont évolué d’un ensemble de scripts vers un écosystème de services, puis vers une plateforme intégrée fournissant une fiabilité de base
Principes de réponse tirés d’une panne de YouTube
- En 2016, YouTube a subi une panne mondiale de 15 minutes à cause d’un bug dans un système de cache mémoire distribué, interrompant la capacité de diffusion des vidéos
- Les mesures d’atténuation doivent être proportionnées à la gravité de l’incident
- Pendant la panne de YouTube, une procédure risquée de load-shedding n’a pas corrigé le problème et a provoqué des défaillances en chaîne
- Une mesure d’atténuation risquée peut, dans le meilleur des cas, résoudre la panne, mais dans le pire, mal fonctionner et prolonger la durée de l’incident
- Même lorsqu’une situation semble exiger de contourner les procédures standard, il faut d’abord observer et évaluer la gravité avant de choisir une action
- Les mécanismes de reprise doivent être suffisamment testés avant une véritable urgence
- Exécuter pour la première fois une procédure d’atténuation risquée pendant une panne revient à essayer une échelle pour la première fois lors de l’évacuation d’un incendie dans un immeuble de grande hauteur
- Il faut vérifier à l’avance que la procédure de reprise accomplit bien ce qui est nécessaire et que les responsables savent l’exécuter
- Les tests ont aussi pour effet de réduire le risque lié à l’exécution de cette mesure
- Tous les changements doivent limiter leur rayon d’impact via des déploiements canary
- Un changement de configuration du cache a fortement perturbé le service YouTube pendant 13 minutes à la suite d’un effet non intentionnel
- Si ce changement global avait été déployé progressivement avec une stratégie canary, l’incident aurait pu être contenu avant d’avoir un impact mondial
- Voir aussi l’article sur la stratégie canary et la vidéo de présentation à la SREcon
Ce que la panne de Calendar a appris sur le rollback et les tests
- Les changements risqués nécessitent un Big Red Button défini à l’avance
- Le Big Red Button est un dispositif de sécurité simple et facile à actionner pour annuler la cause d’un état indésirable
- Dans un cas, un ingénieur a de justesse évité une panne majeure en débranchant l’alimentation de son ordinateur de bureau avant que le changement ne se propage
- Lorsqu’on planifie un rollout important, il faut se demander : « Quel est mon Big Red Button ? » ; chaque dépendance de service doit disposer d’un mécanisme actionnable en urgence
- Voir aussi Generic Mitigations
- Les tests unitaires ne suffisent pas ; il faut des tests d’intégration
- Les tests unitaires vérifient qu’un composant individuel fonctionne comme prévu, mais ils ne reproduisent pas totalement l’environnement d’exécution ni les exigences de la production
- Les tests d’intégration servent à vérifier si les jobs et les tâches peuvent effectuer un cold start et si les composants forment ensemble le système attendu
- Lors de la panne de Calendar, le chemin testé différait du chemin réellement utilisé ; malgré de nombreux tests, cela n’a pas aidé à évaluer le comportement réel du changement
La panne des jetons OAuth de 2017 et la continuité opérationnelle
- En février 2017, des jetons OAuth indisponibles ont déconnecté des millions d’utilisateurs de leurs appareils et services, et 32 000 appareils OnHub et Google WiFi ont été réinitialisés aux paramètres d’usine
- Les échecs de connexion ont multiplié par 10 les demandes de récupération manuelle de compte, et il a fallu environ 12 heures à Google pour se rétablir complètement
- La réponse aux incidents nécessite des canaux de communication de secours distincts des canaux principaux
- À l’époque, les équipes pensaient pouvoir gérer l’incident avec Google Hangouts et Google Meet
- Mais dépendre de services Google alors que 350 millions d’utilisateurs avaient été déconnectés de leurs appareils et services n’était pas approprié
- Il faut préparer et tester des canaux de communication de secours dont les dépendances sont séparées
- Les services doivent continuer à fonctionner en graceful degradation même en situation exceptionnelle
- Il ne suffit pas de diviser la disponibilité entre « totalement normale » et « totalement interrompue »
- Maintenir un minimum de fonctionnalités en mode dégradé permet d’offrir une expérience utilisateur plus cohérente
- La dégradation peut même être invisible pour l’utilisateur ; les services doivent être conçus pour continuer à fonctionner dans des situations exceptionnelles
Sinistres, automatisation, rollouts et diversité matérielle
- La résilience face aux sinistres et les tests de reprise sont des éléments clés de la stratégie de continuité d’activité
- Les tests de résilience vérifient si un service ou un système peut tenir face à des pannes, des latences ou des interruptions
- Les tests de reprise vérifient si le service peut revenir à un état normal après un arrêt complet
- Il faut aussi envisager des situations extrêmes comme des catastrophes naturelles ou des cyberattaques, comme dans Weathering the Unexpected
- Il est également utile que les équipes examinent sous forme d’exercices sur table des scénarios comme : « Que se passe-t-il si une partie de la connectivité réseau disparaît de façon inattendue ? »
- Pour les incidents accompagnés de signaux clairs, l’automatisation de l’atténuation est un moyen de réduire le MTTR
- En mars 2023, plusieurs équipements réseau ont échoué presque simultanément dans plusieurs datacenters, provoquant d’importantes pertes de paquets
- Durant cette panne de 6 jours, environ 70 % des services ont été touchés à des degrés divers selon leur emplacement, leur charge et leur configuration au moment de la panne réseau
- Proportion de services affectés : {p:70}
- Si le signal indiquant qu’une défaillance donnée s’est produite est clair, on peut déclencher automatiquement des mesures d’atténuation manuelles afin de réduire le MTTR
- Il peut parfois être préférable d’éviter d’abord l’impact utilisateur, puis d’analyser la cause racine
- Plus l’intervalle entre les rollouts est long, plus il devient difficile d’évaluer la sûreté d’un changement
- En mars 2022, une panne du système de paiement a empêché les clients de finaliser leurs transactions, et une journée communautaire de Pokémon GO a dû être reportée
- La cause était la suppression d’un seul champ de base de données, un changement jugé sûr puisque son usage avait été supprimé du code
- Mais, à cause du cycle de rollout lent de certaines parties du système, le système en production utilisait encore ce champ
- Dans les systèmes complexes à multiples composants, de longs retards de rollout rendent très difficile l’évaluation de la sûreté d’un changement donné
- Des rollouts fréquents, combinés à des tests appropriés, permettent de réduire ce type de défaillances inattendues
- Une version matérielle globale unique peut devenir un point unique de défaillance
- Confier une fonction critique à un seul modèle d’équipement peut simplifier l’exploitation et la maintenance
- Mais si ce modèle rencontre un problème, cette fonction critique ne peut plus être assurée
- En mars 2020, un équipement réseau contenant un bug zero-day non détecté a révélé ce bug à la faveur d’un changement de trafic ; comme le même modèle et la même version étaient déployés à l’échelle du réseau, cela a provoqué une panne régionale importante
- Comme plusieurs backbones réseau existaient, il a été possible d’acheminer le trafic prioritaire vers des chemins alternatifs encore opérationnels, évitant ainsi une panne totale
- Les bugs potentiels dans l’infrastructure critique peuvent rester invisibles jusqu’à ce qu’un événement en apparence anodin les révèle, et la diversité de l’infrastructure peut faire la différence entre une panne problématique et une panne générale
1 commentaires
Avis sur Hacker News
L’article est excellent et semble largement applicable. Il n’y a rien qui donne vraiment l’impression de relever du « ça ne marche que chez Google »
Les canaux de communication, les canaux de secours, et même les canaux de secours des canaux de secours sont vraiment essentiels. Chez Netflix, quand on choisissait le fournisseur d’un système utilisé pendant les incidents, on vérifiait toujours qu’il ne reposait pas sur AWS ; chez reddit, il y avait un IRC de secours sur un serveur au bureau au cas où l’IRC habituel ne fonctionnerait plus
J’ai aussi entendu dire que Google avait un serveur IRC de secours sur AWS, mais ce n’est peut-être qu’une légende. L’essentiel est de disposer d’un canal de contact secondaire aussi indépendant que possible de sa propre infrastructure
Cette équipe se trouvait sur le chemin critique : si nos systèmes déclenchaient une alerte, il n’était pas du tout improbable que Google.com soit également hors service, en plus de Google Meet. À cause de Gmail, l’e-mail ne fonctionnait pas non plus ; avec Google Fi, le téléphone professionnel non plus ; et mon FAI à domicile étant Google Fiber/Webpass, il fallait encore une couche de secours supplémentaire
Donc oui, Google dispose bien d’un serveur IRC de secours pour les communications. Je ne dirai pas où il se trouve, mais c’est précisément pour cette raison qu’il est explicitement placé en dehors de l’infrastructure Google
Sur le thème « largement applicable et pas seulement pertinent chez Google », quelque chose que j’ai très rarement vu ailleurs, c’est la panic room d’exploitation : une salle sécurisée avec un VPN de secours vers l’environnement de production
Un jour, le SAN de production s’est mis à dysfonctionner, le datacenter on-premise est tombé, et Atlassian est tombé avec lui. Plus de Jira, plus de Confluence, probablement plus de CI/CD non plus, aucun runbook de reprise bien organisé, seulement de la connaissance tribale
Les gens étaient furieux, et ils avaient raison. Mettre les systèmes en contact avec les clients et les systèmes liés à l’infrastructure dans le même panier est vraiment dangereux
En tout cas, c’était vrai il y a deux ans, quand j’y travaillais encore
J’aimerais un jour entendre la solution au problème du cold start complet. Les entreprises qui ont une énorme stack maison ont des dépendances circulaires dans leur infrastructure critique
Avec le software-defined networking, certains logiciels doivent être en marche pour relancer le routage des paquets ; les machines sans disque ont besoin d’un stockage pour démarrer ; les services d’authentification ont besoin d’un accès au stockage pour amorcer l’autorisation de sécurité
Aujourd’hui, on gère cela en exploitant plusieurs régions indépendantes, et en amorçant un datacenter complètement éteint depuis l’infrastructure existante. Mais je n’ai jamais entendu parler d’une remise en marche de toute la stack depuis un état totalement hors tension
Même quand Facebook a complètement cassé son réseau d’exploitation il y a quelques années, les machines étaient encore allumées et une partie de la connectivité interne subsistait. Si un événement comme une tempête solaire majeure mettait durablement à terre les réseaux électriques dans le monde entier, jusqu’à épuiser les générateurs, rien ne garantit qu’un cloud comme AWS ou GCP puisse forcément revenir
Il existe probablement de petits datacenters dédiés, dotés d’une excellente alimentation de secours et capables d’être totalement isolés des surtensions du réseau électrique
En haut de la stack, c’était utile pour suivre les dépendances ajoutées discrètement par les auteurs de bibliothèques ; en bas, cela aidait à garantir que ce qui devait rester tout en bas y restait vraiment
On faisait aussi des démarrages et arrêts automatisés de clusters virtuels pour éviter que les procédures documentées ne deviennent obsolètes, et pendant mes six années comme SRE, j’ai vu ces procédures passer de 90 jours à moins d’une heure
On s’entraînait aussi régulièrement à redémarrer depuis zéro des éléments comme la gestion mondiale des clés de chiffrement, qui nécessite des objets physiques, et l’exercice annuel DiRT cherchait à vérifier qu’aucune personne, équipe ou bureau ne soit une condition indispensable à la continuité des systèmes
Si on commence tard, c’est très douloureux ; mais si on le fait dès le début, on s’y habitue vite, et on détecte tôt les changements cassants ou les dépendances étranges
Cela s’applique aussi au matériel. L’architecture évolue pour supporter qu’un élément soit débranché ou réinitialisé. Il faut davantage d’automatisation, de gestion de versions et de gestion du changement ; en retour, cela permet non seulement de prévenir les pannes et de récupérer plus vite, mais aussi de rendre tout le travail plus rapide et plus simple. C’est un grand changement culturel
D’après mes souvenirs, une partie de l’approche est considérée comme sensible, donc je n’entrerai pas dans les détails
Il serait aussi intéressant de savoir quel réseau électrique a effectué le plus de cold starts. Idéalement, ce serait déjà celui qui sait bien le faire. J’imagine que ce pourrait être quelque part dans les Caraïbes ou en Afrique
Cela dit, le cold start d’un petit réseau, par exemple une île isolée avec un générateur diesel et du solaire, est peut-être trop facile pour constituer une bonne étude de cas
Il est clair qu’Internet lui-même ne peut pas faire de cold start comme un réseau électrique en courant alternatif. Il y a trop d’AS. Il suffit de réfléchir un instant à ce que signifie AS pour comprendre pourquoi un cold start coordonné et répété à l’avance est impossible
Pour approfondir le sujet, je suis en train de lire presque intégralement Building Secure and Reliable Systems de Google ; ce n’est pas une lecture légère, c’est plutôt un vrai manuel.
C’est un livre assez intéressant, et beaucoup de choses semblent relever du bon sens, mais comme on dit parfois que l’expression « bon sens » est elle-même contradictoire, il m’a été utile pour remettre à jour l’ensemble de mes connaissances d’un coup.
J’ai entendu dire récemment que certaines entreprises avaient démantelé leur organisation SRE et transféré ses membres dans des équipes SWE. La rumeur dit que LinkedIn, Adobe et Robinhood l’auraient fait.
Cela m’a amené à me demander si le SRE n’était pas un sous-produit d’une économie de bulle où l’argent facile abondait. Ne pourrait-on pas fonctionner sans maintenir à grands frais une équipe SRE séparée ?
Comme les administrateurs système ou les testeurs QA ont en grande partie disparu et que beaucoup de leurs fonctions sont passées aux équipes de développement logiciel, je me demande si le SRE existera encore dans dix ans.
Mais avec les licenciements qui se poursuivent actuellement, peu d’entreprises semblent s’en soucier. Le fait de mobiliser des développeurs sur des problèmes qui ne relèvent pas de leur domaine d’expertise ne va pas disparaître : c’est une tendance de fond du secteur, et elle sera encore plus visible en période de ralentissement économique.
Les développeurs full-stack en sont un bon exemple : on fusionne deux rôles sans payer deux fois plus.
Cela dit, le reste de l’argument me paraît toujours juste. Avec DevOps aujourd’hui, l’éventail de compétences attendu des développeurs s’est élargi et recoupe fortement celui des SRE. Les entreprises vont probablement réduire les équipes SRE et répartir la responsabilité entre les développeurs.
Une autre grande raison est l’automatisation. En lisant longuement le site lié, on comprend qu’aux débuts de Google, les SRE effectuaient beaucoup de tâches manuelles, comme surveiller des graphiques à la main pendant les déploiements.
À l’époque, même Google n’avait pas encore suffisamment automatisé ses systèmes, ce qui rendait les SRE indispensables. L’histoire de Sisyphe https://www.usenix.org/sites/default/files/conference/protec... permet de comprendre dans une certaine mesure comment l’échec initial de Google à introduire une automatisation standardisée a garanti la sécurité de l’emploi des SRE.
Il n’est pas logique de confier à quelqu’un d’autre l’exploitation du logiciel que l’on a écrit. Il suffit de mettre les SWE d’astreinte. S’ils pensent que le travail manuel est la meilleure solution, qu’ils le fassent eux-mêmes ; et à ce niveau-là, ils devraient être licenciés comme mauvais ingénieurs.
C’est étrange de faire passer des entretiens aussi exigeants tout en ne sachant pas comment fonctionne l’ordinateur sur lequel on programme. Le fonctionnement des systèmes d’exploitation fait partie des cursus de premier cycle, et il est étrange de déléguer cela, avec de nombreux postes et intitulés, principalement à des anciens administrateurs système autodidactes.
Tous les bons SWE que je connais savaient comment fonctionnent les systèmes d’exploitation, les ordinateurs et les réseaux.
Les tâches que les SRE accomplissent aujourd’hui, comme l’automatisation générale, la fourniture d’outils de développement et l’amélioration de l’expérience développeur, migrent vers des équipes plateforme. Je pense que le rôle va fortement évoluer.
Une seule équipe SRE peut soutenir plusieurs équipes de développement, et les équipes de développement consacrent souvent très peu de temps aux aspects d’infrastructure complexe ou de systèmes distribués, car ce ne sont pas des sujets dont elles se préoccupent au quotidien.
Il est donc logique d’avoir une organisation infrastructure qui fonctionne comme une unité distincte des équipes de développement spécialisées. Qu’on l’appelle SRE, équipe SRE SWE ou simplement infrastructure, au-delà d’une certaine taille, les préoccupations transversales se multiplient et il devient moins coûteux de les séparer ainsi.
Avec des SRE dédiés, on dispose de vrais experts de l’exploitation, des systèmes associés, des outils, des alertes, etc., et d’une responsabilité claire sur les résultats. Mais comme ils ne possèdent pas complètement les systèmes qu’ils maintiennent, cela peut créer des problèmes d’organisation.
On peut se retrouver avec des situations du type « nous voulons lancer X, mais les SRE s’y opposent », ou l’inverse, et des personnes qui ne sont pas SRE peuvent finir par ne pas assumer la responsabilité d’un code difficile à prendre en charge.
À l’inverse, une équipe d’ingénierie sans SRE peut réduire ce genre de problèmes organisationnels et sociaux, mais la fiabilité opérationnelle devient alors une priorité parmi beaucoup d’autres.
En pratique, je pense que beaucoup d’entreprises sont en train de décider que la fiabilité n’est pas si importante que cela comme résultat business, surtout lorsque le coût d’opportunité du développement de fonctionnalités augmente.
L’atténuation automatique mérite vraiment une très longue réflexion. En 30 ans de carrière, j’ai vu plusieurs fois l’atténuation automatique aggraver les problèmes. Il faut donc bien se demander si l’auto-réparation est réellement nécessaire.
En 2014, j’ai créé une solution interne de reporting de crashs mobiles, et une partie du backend tournait sur un seul serveur avec Redis comme point de défaillance unique. La procédure de bascule était semi-automatique : quelqu’un devait d’abord vérifier que l’alerte était valide avant de la lancer.
Si le service tombait, il n’y avait pas de perte financière réelle ; dans le pire des cas, les développeurs d’apps mobiles étaient gênés un moment. En dix ans d’exploitation, le nombre de fois où il a fallu faire une bascule se comptait sur les doigts d’une main.
Même sans SLA, ce système avait une meilleure disponibilité que des systèmes internes bien plus importants.
À l’inverse, il suffit de regarder les cas GitHub : https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
Bien sûr, GitHub opère à une échelle beaucoup plus grande. L’idée, c’est que la redondance et l’atténuation automatique ajoutent de la complexité et, par définition, se déclenchent dans des situations imprévues où elles ont rarement été testées.
Il faut donc évaluer le SLA et le coût des pannes, puis les mettre en balance avec la complexité ajoutée pour les éviter. Vers 1998, ma première leçon a été avec deux NetApp configurés en haute disponibilité : l’un est tombé en panne et a détruit tous les disques de l’autre.
À peu près à la même époque, j’ai vu la même chose avec deux pare-feu Cisco PIX, et depuis je me méfie toujours de la haute disponibilité, du failover automatique et de l’atténuation automatique.
Je serais curieux de savoir comment, en pratique, les gros boutons rouges et la dégradation volontaire et progressive des performances sont gérés. En particulier, comment garantir qu’ils fonctionnent encore pendant que le système est en difficulté.
Par exemple, utilise-t-on des feature flags stockés en base de données ? Et dans ce cas, que fait-on si la base elle-même, ou l’API qui y donne accès, est surchargée ?
Ou bien utilise-t-on des flags statiques au démarrage, comme des variables d’environnement ? Dans ce cas, comment s’assurer qu’ils sont déployés assez vite ? Ou existe-t-il une approche complètement différente ?
Même sans redondance sur une partie du chemin critique, si le système est assez simple pour tenir dans la tête de tous les mainteneurs et peut être facilement redémarré ou rollbacké, cela peut être préférable.
Mais dès qu’une entreprise commence à promettre une disponibilité de type « cinq neuf », une certaine complexité devient nécessaire pour concevoir des systèmes capables de tenir cette promesse tout en continuant à développer et améliorer le produit.
Chez Google, quand un cluster donné était jugé en mauvaise santé, on faisait couramment du « drainage de backend », avec des systèmes capables de le gérer rapidement au niveau API/load balancer.
Ailleurs, j’ai aussi vu cela géré via des flags au niveau applicatif. C’était du genre
kubectl edit, donc clairement pas idéal, mais ça fonctionnait.Premièrement, rester simple. Une simple vérification de flag, sans logique sophistiquée ni datastore complexe, est préférable.
Deuxièmement, placer le mécanisme aussi près que possible de la source, sans faire trop confiance aux clients. Il peut y avoir d’anciennes versions, des délais de propagation ou des bugs ; l’idéal est donc que le client comme le serveur puissent choisir un mode dégradé, et si un seul côté est possible, mieux vaut le serveur.
Troisièmement, tester souvent avec du vrai trafic. Ne faites pas confiance à l’environnement de test : il faut de petits tests périodiques, par exemple à 0,1 %, ainsi que de grands tests planifiés. Si ce n’est pas testé, cela ne fonctionnera pas au moment voulu ; et si cela fonctionnait il y a un an, il est probable que ce ne soit plus le cas aujourd’hui. Un dispositif non testé peut causer plus de dégâts qu’il n’en résout.
Imaginons par exemple que l’on ajoute à Hacker News une nouvelle fonctionnalité affichant une photo de profil à côté des commentaires. Bien sûr, comme tout a été transformé en microservices, supposons que le générateur de pages frontend appelle un service de profil, lequel fait la recherche puis renvoie l’emplacement de l’image.
Dans le plan de lancement, on documente la procédure du gros bouton rouge à suivre si le nouveau composant surcharge le service de profil ou le stockage d’images. Autrement dit, on exécute une commande qui limite, au niveau réseau, le débit des requêtes sortantes de mon service — et en urgence, on le met probablement à 0.
Les recherches échouent, mais le générateur de pages est conçu pour se dégrader progressivement et continuer à rendre le texte des commentaires sans photo de profil.
Ce n’est ni un vrai document de conception, ni un conseil sur ce qu’il faut construire ou comment le faire ; c’est juste un schéma au crayon pour illustrer l’idée.
Je l’ai vu fait avec CDB (constant database) de djb, avec des fichiers de configuration JSON interrogés via une API, ou encore avec dbm/gdbm/Berkeleydb/leveldb.
Cette approche peut s’étendre à d’autres gros boutons rouges. Ce n’est pas élégant, mais j’ai exploité plusieurs fois des services qui vérifiaient l’existence d’un fichier pour décider s’ils devaient fournir un health check. Retirer un nœud de la rotation du load balancer devenait aussi simple que de créer un fichier.
L’essentiel est qu’en cas de panne de la base de données, le système utilise par défaut la dernière configuration connue comme saine.
Je tiens vraiment à insister sur la phrase : « les mécanismes de récupération doivent être entièrement testés avant l’urgence ». En tant que personne devenue SRE chez Google par hasard et connue dans toute l’entreprise pour avoir mal utilisé une double négation, je peux dire que c’est quelque chose de très important à faire correctement dès le départ.
Pour les Googlers curieux, cherchez mon nom d’utilisateur en interne : vous trouverez comment j’ai réussi à produire un impact d’une ampleur impossible à mesurer.
Le moyen le moins cher d’éviter les incidents est de les détecter tôt dans le cycle de vie. Les bugs logiciels ressemblent à de vrais insectes. Au départ, c’est un œuf, c’est-à-dire une idée de changement ; la nymphe qui éclot est le premier POC. Le temps qu’il atteigne l’environnement de production, c’est un adulte.
Il n’y a pas des stades avant l’adulte ? Si, exactement. Une application doit passer par plusieurs étapes avant d’arriver à maturité. Il est bien moins coûteux de trouver un bug avant qu’il n’ait fini de grandir et de pondre des œufs.
Si les déploiements canary sont difficiles et que les rollbacks posent aussi problème, il faut ajouter davantage de tests avant le déploiement en production. Linters, tests unitaires, tests de bout en bout, profileurs, moniteurs synthétiques, réplicas de production en lecture seule, tests de performance, etc. : il faut détecter les bugs le plus tôt possible, par tous les moyens.
Les feature flags, la rétrocompatibilité, etc. sont utiles aussi, mais rien ne bat le Shift Left.
Si vous êtes intéressé par une liste similaire du point de vue de quelqu’un qui a fait 15 ans de SRE dans la FinTech, la banque, les hedge funds et les cryptomonnaies, je recommande ce billet : https://x.com/alexpotato/status/1432302823383998471?s=20
Extrait : « 25. Si vous avez un moteur de règles dans lequel il est plus facile de créer une nouvelle règle que de retrouver une règle existante par ses critères de filtrage, vous finirez avec un tas de règles en double. »
« Un ingénieur qui avait soumis un changement risquant de provoquer un incident a évité de justesse une panne majeure en débranchant l’alimentation de son ordinateur de bureau avant que le changement ne se propage » : mais qu’est-ce que ça veut dire, au juste ?
Résultat : les SWE infra ne construisaient pas de vrais boutons, mais passaient leurs journées à écrire des CLI stupides. Quand je suis parti, ça avait beaucoup changé, cela dit.
Je pense que Google devrait rendre davantage publics ses incidents internes. Celui-ci, en particulier, était très célèbre en interne.
Même à une échelle énorme, les outils shell et les clients RPC en CLI peuvent contacter assez rapidement toutes les machines du monde.
pssh.C’était il y a dix ans, donc je ne sais pas s’ils l’utilisent encore ainsi, mais cette méthode était étonnamment rapide. C’était peut-être ce genre de situation.
Mais il y a 20 ans, c’était probablement plus courant, et cela peut encore arriver dans de petites organisations.