Heinrich Hartmann - A Systems Perspective toward Reliability Engineering at Zalando

[00:00:05] d'être venu ici. Hum, j'ai euh voyagé et je suis arrivé hier et j'ai eu cette drôle d'expérience où je venais, euh, je venais à l'hôtel et je me suis dit, c'est terriblement familier. Je connais cet endroit quelque part. Et puis j'ai vérifié, la dernière fois que j'étais à Paris, c'était il y a 11 ans, c'était quand j'étais, euh, en train de traîner avec des doctorants. Et ma ma femme était dans le groupe, juste un groupe d'amis qui, euh, nous avons visité Paris, nous sommes en fait allés voir, euh, du football. Et il s'avère que c'était exactement le même hôtel. Il y a 11 ans, et je n'avais pas réservé celui-ci, donc c'était une drôle de coïncidence, mais je me suis tout de suite senti chez moi et je savais où tout se trouvait. Donc c'était sympa. Euh, oui, je veux parler de l'ingénierie de fiabilité, donc je m'identifie vraiment comme un ingénieur de fiabilité. Je fais ça depuis 10 ans. Euh, dans une vie antérieure, j'étais mathématicien, et d'une certaine manière, j'ai été aspiré par, euh, l'informatique et l'ingénierie pour diverses raisons, euh, diverses causes. Mais cela m'a toujours frappé que la fiabilité est vraiment un problème non résolu. Alors, quand j'ai exploité mes premières instances WordPress, c'était comme, ok, pourquoi ça tombe toujours en panne ? Et pourquoi mes clients ou mes utilisateurs me le disent et pourquoi cette chose ne peut-elle pas simplement ne pas fonctionner ? Et j'ai travaillé comme scientifique de données pour un fournisseur de surveillance, Sikus pendant environ cinq ans, euh, avant de partir chez Zalando et, euh, d'y diriger l'ingénierie de fiabilité pendant deux ans et demi. Euh, oui. Pour le menu, euh, je vais vous donner un peu de contexte autour de Zalando, juste pour que nous connaissions l'environnement et ce que nous résolvons. Euh, et ensuite je vais présenter un angle systèmes sur l'ingénierie de la fiabilité. Alors pour cette conférence, j'essaie vraiment de faire le lien, euh, juste l'ingénierie de la fiabilité d'un point de vue technique, euh, à l'ingénierie de la fiabilité sur un aspect plus processus, personnes et réunions. Alors, comment le gérez-vous réellement dans une organisation plus grande ? Et l'outil que je trouve le plus prometteur ici est la théorie des systèmes, et nous en parlerons un peu plus. Euh, ensuite nous passerons en revue les différentes pratiques, euh, en tant qu'ingénieur de fiabilité, alors qu'est-ce que nous faisons ? Et enfin, j'ai une étude de cas pour vous, notre plus grand incident de ces dernières années. Euh, c'était avec un, euh, avec un, oui, un truc appelé Madeupda. Nous allons comprendre ce que c'est. D'accord. Euh, Zalando. Beaucoup d'entre vous le connaissent peut-être, euh, c'est euh une plateforme de mode en Europe. C'est relativement euh nouveau, elle a été fondée en 2008, euh, et elle compte 3 000 ingénieurs logiciels. Donc l'organisation technique est assez importante, vous pourriez demander, pourquoi avez-vous besoin de 3 000 personnes pour un site web ? Et c'est une très bonne question. Euh, la réponse, ou une partie de la réponse, est qu'elle est en fait intégrée horizontalement de manière assez large, donc nous avons notre propre banque, nous avons notre propre réseau logistique, euh, et du côté de la demande, nous nous intégrons avec des partenaires, euh, nous avons aussi une plateforme publicitaire, donc il y a juste beaucoup de, euh, technologie qui soutient, euh, une grande partie de la chaîne de valeur. Euh, oui, c'est assez grand, c'est assez fragmenté. Et du côté technique, voici à quoi cela ressemble. Euh, l'image est un graphe de services, euh, prise en 2019. J'aimerais vraiment en faire une nouvelle, mais c'est l'image que j'utilise toujours pour cela. Euh, et cela montre, je pense à l'époque, 1 500 microservices, maintenant nous sommes à plus de 3 000 microservices, donc c'est devenu un peu plus encombré. Et vous voyez vraiment pas beaucoup de structure là-dedans, vous voyez quelques points centraux, mais c'est une sorte de grande complexité impliquée dans, euh, les systèmes Zalando. Euh, la charge de travail au pic est d'environ 200 000 RPS à la périphérie, euh, nous traitons quelques milliers de commandes par minute. En termes d'infrastructure, nous sommes le plus grand client AWS à Francfort, je pense. Au moins là-bas, nous sommes les plus grands, avec plus de 10 000 nœuds EC2 que nous louons au pic. Oui, et encore une fois, nous avons environ 3 000 ingénieurs logiciels répartis dans environ 300 équipes. Alors quand je travaillais comme ingénieur de fiabilité chez Zalando, la quête que j'ai toujours eue était : comment rendons-nous cela fiable ? Ou pourquoi est-ce fiable, n'est-ce pas ? Cela semble si complexe, si déroutant, comment diable feriez-vous pour le rendre fiable ? Et si vous regardez cela d'un point de vue technologique, cela semble juste désespéré, n'est-ce pas ? Il y a tellement de choses qui se passent, euh, vous avez tellement de conteneurs, comment allons-nous obtenir une compréhension de bout en bout de tout cela, le mettre quelque part où nous pouvons comprendre et le rendre agréable ? Et d'une manière ou d'une autre, l'enseignement ici, euh, est que si vous ne regardez que la technologie, vous ne le résoudrez pas. Vous devez considérer les personnes, la structure organisationnelle avec la technologie et y penser de manière plus holistique. Et c'est vrai, nous pouvons déjà le voir dans les fondamentaux de la gestion, euh, des entreprises de logiciels, euh, qui est la loi de Conway, donc vous avez toujours, euh, les structures d'équipe qui reflètent votre, euh, structure technologique, qui reflètent vos structures d'équipe, et vous l'avez aussi dans le mantra DevOps, vous le construisez, vous l'exécutez. C'est comme, on ne peut pas penser technologie sans les gens. Et, euh, d'une certaine manière, la triste nouvelle pour moi en tant qu'ingénieur en fiabilité est que plus l'entreprise grandit, plus l'aspect humain devient complexe et problématique. Euh, donc moi, je viens vraiment de ce point de vue mathématique, j'ai fait beaucoup d'ingénierie logicielle, je suis vraiment content si je peux juste bricoler des logiciels, mesurer les choses très précisément et écrire un bon compilateur. Mais si je veux résoudre les problèmes de fiabilité pour Zalando et rendre Zalando fiable, ce n'est pas le bon endroit où regarder. Euh, nous nous penchons sur, euh, les réunions, la gestion des risques, les communautés de pratique, euh, ce qui est le moteur de la fiabilité en général, et déjà dans les entreprises de taille moyenne, euh, ces pratiques de partage des connaissances, comme la gestion des incidents, les playbooks, euh, cela devient de plus en plus important pour gérer efficacement la fiabilité.
[00:06:20] Euh, alors voici un modèle de haut niveau que j'utilise tout le temps pour raisonner sur ces compromis et sur la couche sur laquelle nous opérons. Euh, c'est fondamentalement le modèle de système socio-technique à trois couches, si vous voulez, n'est-ce pas ? Donc, au sommet, il y a vraiment une chaîne de management, qui donne une structure et une organisation à tout. Ensuite, nous avons en dessous l'ingénierie, où nous avons cette cartographie des équipes d'ingénierie vers, euh, les points qui sont des applications, c'est là que le côté technique rencontre le côté humain. Et oui, juste la chose que je n'ai pas mentionnée sur la diapositive précédente, je pense que c'est très important ou très bien si vous avez une cartographie d'une application ou d'une pièce technologique à un propriétaire unique. Vous avez aussi des organisations qui réalisent de grandes applications possédées par plusieurs équipes. Cela simplifie énormément de choses si vous ne faites pas cela, si chaque pièce de technologie a une propriété claire, donc ce genre de pyramide fonctionne beaucoup mieux. Et en dessous, vous avez la plateforme. Euh, cela semble plutôt évident, comme vous pouvez dessiner cette image, mais qu'en faites-vous ? Euh, donc si vous voulez obtenir un certain résultat, comme rendre un logiciel fiable ou rendre des choses fiables, vous pouvez toujours l'attaquer sur ces trois niveaux. Vous pouvez mener un grand projet par le biais de la gestion, en y intégrant des KPI, en y plaçant des chefs de projet, euh, en le faisant avancer par la chaîne de gestion et en le faisant exécuter par l'organisation. Vous pouvez le placer au niveau de l'ingénierie, de sorte que vous facilitez un processus que les équipes exécutent de manière autonome. Par exemple, les mises à jour de sécurité, vous n'avez pas un grand projet qui passe par, rendons tout sécurisé ou ayons les dernières versions, mais vous donnez aux équipes la capacité de comprendre et les incitations à optimiser cela. Et enfin, les éléments de la plateforme, euh, c'est le cas où les équipes n'ont plus à y penser, c'est juste fait pour elles. Ainsi, l'exécution de serveurs n'est plus un problème, ni l'exécution de matériel, ni l'acquisition de matériel, ce n'est plus une tâche des équipes, c'est quelque chose dont la plateforme s'occupe. Et le schéma général est toujours de pousser vers le bas. Si quelque chose était un projet que vous exécutez, essayez d'en faire une capacité d'équipe, si quelque chose était une capacité d'équipe, essayez de l'enlever, de le mettre sur la plateforme afin que les équipes n'aient pas à y penser. Et oui, c'est un modèle utile du moins. Maintenant, en allant un pas plus loin, quand ce n'est plus si simple et que vous avez besoin d'un peu, euh, de meilleurs outils, euh, pour comprendre vos modèles. Alors, la meilleure approche théorique que je connaisse est la théorie des systèmes. Euh, et ici, je veux citer le livre de Donella Meadows, euh, Penser en Systèmes, c'est assez populaire, je pense que beaucoup d'entre vous le connaissent, euh, mais ça a été vraiment une révélation de le lire pour la première fois. Euh, puisque c'est un cadre qui vous permet de raisonner sur les systèmes technologiques et humains en même temps et de dessiner des diagrammes amusants, et tout le monde aime les diagrammes.
[00:09:18] Euh, et je dois admettre que je n'ai pas vraiment utilisé avec succès la théorie des systèmes pour la modélisation avancée. Euh, ce que j'en ai vraiment retenu du côté pratique est assez basique, et il s'agit essentiellement de boucles de rétroaction et je peux le présenter en deux diapositives. Donc si vous avez, oui, vous dessinez des diagrammes entre des boîtes qui représentent certaines quantités, certains processus, euh, de choses. Et vous pouvez avoir des interactions qui vont, euh, dans le Ok, laissez-moi juste expliquer l'exemple.
[00:09:53] Donc, dans l'exemple de la boucle de rétroaction renforçante, vous examinez un compte bancaire et les paiements d'intérêts, donc plus vous avez sur un compte bancaire, plus vous obtiendrez d'intérêts. Et cela vous donne une boucle de rétroaction, donc l'intérêt lui-même augmentera votre solde, vous obtiendrez plus d'intérêts, cela finira par échapper à tout contrôle ou, espérons-le, croître énormément. Euh, et de l'autre côté, vous avez des boucles de rétroaction qui sont, euh, comme équilibrantes. Donc si vous avez faim, vous pourriez manger quelque chose, et ensuite vous avez moins faim. Donc, cela contrebalance en quelque sorte cela. Et le comportement que vous obtenez de ces deux boucles de rétroaction différentes est très différent : l'une est une sorte de croissance exponentielle, l'autre est plus comme un pendule ou comme un ressort en physique. Euh.
[00:10:38] Maintenant, les boucles de rétroaction de renforcement sont souvent la cause de problèmes, donc vous ne voulez pas que vos mesures deviennent trop importantes car votre système pourrait alors ne plus être en mesure de les supporter. Et la chose fondamentale que vous pouvez faire est de contrebalancer de telles boucles de rétroaction positives avec une boucle de rétroaction négative du côté qui la contrôle. Euh, il y a diverses variantes, comme par exemple, les systèmes de chauffage sont aussi un bon exemple de cela, et si vous regardez l'ingénierie d'infrastructure plus large, vous en trouverez beaucoup, euh, la théorie du contrôle et l'ingénierie des processus. Euh, mais pour l'exemple de l'équilibre, vous avez peut-être l'habitude, plus votre compte bancaire est important, plus vous dépensez, cela m'arrive souvent en fait. Donc je réussis très bien à contrôler mon solde pour qu'il ne devienne pas trop important, juste en augmentant les dépenses.
[00:11:27] D'accord. Et au cœur de tout cela, euh, l'ingénierie de la fiabilité consiste vraiment à mettre en place les bonnes boucles de contrôle. Donc, vous examinez le comportement du système dans son ensemble et vous essayez de comprendre comment contrôler ce système, euh, afin qu'il se stabilise et prenne en charge avec succès les charges de travail de production.
[00:11:50] C'est un peu typique, c'est une sorte d'image floue, mais je pense qu'il y a tellement de vérité là-dedans. Si vous travaillez sur le logiciel en tant que développeur de logiciels, euh, vous avez ces différents types de boucles de rétroaction qui vous aident à comprendre et à contrôler fondamentalement le comportement de votre système. Euh, en commençant par le premier, le linter, c'est si vous tapez le code, vous voyez les soulignements rouges entre les choses. Rétroaction directe, très, très rapide. Euh, vous exécutez peut-être des compilateurs qui vous donnent du feedback, puis des tests, et ensuite quand ça passe par le CI, vous avez déjà un niveau de confiance élevé que ça fonctionne peut-être réellement. La prochaine étape est vraiment cette charge de travail en production, que j'appellerais la boucle de contrôle DevOps, mais c'est probablement que l'ensemble peut aussi être considéré comme une boucle de contrôle DevOps. Euh, mais vous avez cette sorte de production, vous le déployez, vous le surveillez, s'il échoue, vous voulez être alerté, et ensuite vous commencez le débogage, et c'est quelque chose que le développeur fait à nouveau. Et puis enfin, quand j'ai eu mon premier backlog de travail, je n'avais rien de tout ça, c'étaient juste mes clients qui me disaient quand ça cassait et puis je redémarrais mon SQL en quelque sorte. Euh, ici, le mantra est que la vitesse est la fiabilité. Vous voulez donc que toutes ces boucles de rétroaction soient rapides, efficaces, sans trop de délais, et idéalement, vous voulez travailler vers l'intérieur. Vous ne voulez pas que votre client vous dise que quelque chose est cassé, vous voulez que vos systèmes de surveillance ou vos tests vous le disent. Et oui, en montant d'un cran. Voici le flux de travail actuel de Zalando pour la fiabilité, au niveau d'une grande entreprise. Nous aborderons certaines de ces choses plus tard, euh, mais je veux juste Ceci a été fait par un gars qui ne fait pas de théorie des systèmes, euh, il est juste arrivé à ça, donc naturellement si vous cartographiez les processus, vous voyez apparaître ces boucles de rétroaction plus complexes. Donc, j'ai commencé à en parler début 2024, euh, et c'était tellement génial pour moi de voir que Google est en fait sur la même longueur d'onde. Ils ont donc publié un grand article dans login en décembre 2024, euh, avec Ben Trainor, Sloss et Tim Falsona, donc Ben Trainor Sloss est le gars qui a inventé SRI et l'a introduit en 2003, lorsque Google pour la première fois automatisait ses opérations de centre de données et euh Tim Falsona est, je pense chez Google depuis une période également longue, euh, dirigeant le SRI. Et ils ont adopté les pratiques d'ingénierie des systèmes et d'ingénierie de la sécurité, euh, de l'ingénierie de la sécurité, euh, du côté plus physique de l'ingénierie, euh, à leurs, euh, oui, opérations. Et, euh, ils citent une méthodologie appelée, euh, Stamp, et il y a un manuel pour cela, qui contient tellement d'acronymes et vous ne les, ils ne correspondent jamais vraiment, mais c'est fondamentalement la même chose. Euh, et ici j'ai juste mis cette citation que je vais vous lire, euh, de l'article original de Google. Euh, la sécurité est une propriété émergente qui ne peut être analysée qu'au niveau du système, plutôt que comme un attribut de composants système individuels. Les accidents sont des interactions complexes entre les composants du système, y compris les opérateurs humains et les logiciels. Il n'y a donc jamais une seule cause profonde pour quoi que ce soit, c'est toujours une interaction complexe, euh. La méthodologie Stamp offre un cadre robuste pour comprendre et atténuer les risques dans les systèmes complexes, les systèmes socio-techniques complexes. Donc ça vous dit, euh, vous devez regarder l'ensemble du système, euh, et il y a des humains et des opérateurs dans la boucle et essentiellement l'ingénierie des systèmes, la pensée systémique est le cadre qui vous permet de progresser. Alors, examinons certaines de nos pratiques d'ingénierie de la fiabilité sous cet angle et voyons à quoi elles ressemblent et comment elles s'y intègrent. La première chose est donc l'alerte. Euh, vous êtes tous familiers avec les alertes, alors pourquoi faisons-nous cela ? Nous voulons réduire notre temps de détection des problèmes.
[00:15:54] L'alerte est, euh, oui, elle se situe à un endroit critique entre une boucle de contrôle automatisée et la boucle de contrôle humaine, c'est donc l'endroit où vous changez de domaine, où vous impliquez un humain. Euh, dans ce diagramme, j'ai représenté un système en fonctionnement normal qui peut avoir une défaillance d'une sorte ou d'une autre, puis vous basculez dans un autre état, que j'ai simplement appelé fonctionnement défectueux. Euh, dans un cas idéal, vos applications gèrent ce problème d'elles-mêmes. Ainsi, vous pouvez avoir des composants d'infrastructure qui redémarrent simplement votre service, donc vous avez cette boucle de contrôle automatisée, qui est parfois appelée propriétés d'auto-réparation, par exemple de Kubernetes ou de System D, et je mettrais aussi la gestion automatique des erreurs, euh, dans cette chose. Donc vous avez une exception, vous êtes capable de fermer et de stabiliser le système, euh, par vous-même. L'alerte est vraiment un dernier recours. Euh, le système ne peut plus s'en sortir, nous devons passer dans le domaine humain, faire intervenir un opérateur, espérons-le, ils peuvent l'atténuer, donc nous sommes de retour à un fonctionnement normal.
[00:16:55] Il a également sa place dans cette boucle DevOps, euh, au centre lorsque le développeur est à nouveau impliqué. Euh, voici à quoi ressemble l'alerte chez Zalando. Euh, ce que je veux souligner, c'est que, euh, une bonne description d'alerte devrait vous informer de l'impact, donc ici, il s'agit par exemple d'un certain flux qui a eu un certain taux d'erreur, nous savons donc que certains utilisateurs sont déjà, euh, impactés. Et il devrait vous dire quoi faire idéalement, et nous avons dans ce cas, euh, 12 playbooks ou 15 playbooks qui correspondent réellement. Donc les gens ont, euh, en configurant cette alerte, ce n'est pas juste un signal, un serveur est malheureux, c'est un signal que des interactions utilisateur très spécifiques échouent en ce moment. Voici 5 à 10 choses que vous pouvez essayer pour le résoudre, et voici ce que nous savons de ce problème, et voici des indications sur la façon de le déboguer. Euh, donc ça essaie de vous lancer en quelque sorte dans l'aventure et de rendre cette boucle de rétroaction plus rapide.
[00:17:57] Euh, le processus d'incident.
[00:18:00] Oui.
[00:18:03] C'est une version générée par machine. Oui. 15 Playbox qui correspondent réellement. Les gens ont, euh, lors de la configuration de cette alerte, ce n'est pas seulement un signal qu'un serveur est malheureux, c'est un signal que des interactions utilisateur très spécifiques échouent en ce moment. Voici cinq à dix choses que vous pouvez essayer pour y remédier, et voici ce que nous savons de ce problème et des indications sur la façon de le déboguer. Euh, donc ça essaie de vous lancer dans ce voyage et de rendre cette boucle de rétroaction plus rapide.
[00:17:56] le processus d'incident. Oui.
[00:18:07] C'est un généré par une machine.
[00:18:15] Oui, beaucoup de gens considèrent le processus d'incident comme quelque chose d'assez ennuyeux, d'accord, vous rédigez ces rapports une fois que quelque chose s'est produit et d'accord, vous en avez fini. Vous ne pouvez pas attendre de faire un autre travail. Euh, je considère les post-mortems, euh, comme une sorte de mine d'or pour l'ingénierie de la fiabilité. Donc, si vous réfléchissez vraiment à comment rendre Zalando plus fiable ? Quelle est la meilleure idée ? Comme si vous le saviez à ce moment-là, n'est-ce pas ? Votre intégration. Alors, comment feriez-vous réellement des progrès ? Lire les post-mortems des 12 derniers mois est un excellent début. C'est une sorte de faisceaux laser vers les parties les plus fragiles de votre système, où vous savez déjà que des choses se sont brisées et sont les plus vulnérables. Et souvent, ils vous mènent vraiment vers de très bons endroits pour commencer à optimiser. C'est un peu les points faibles de votre organisation. Donc, euh, c'est vraiment
[00:19:12] les gens me disent qu'ils ont des problèmes de fiabilité complexes dans certains domaines. C'est la première question que je pose : avez-vous un processus post-mortem, un processus d'incident, quelle est son efficacité, quelle est la culture autour de lui ? Les gens en tirent-ils vraiment des leçons ? Vous voulez d'abord établir ce genre de boucle de rétroaction de haut niveau avant de commencer à parler, avez-vous du traçage ? Avez-vous des choses techniques qui sont là ? Est-ce que vous en parlez avec les bonnes personnes au bon rythme ? C'est très, très important. Alors, comment faisons-nous, faisons-nous cela ? Pour la gestion des incidents, le théâtre des incidents lui-même, nous avons un, euh, un chatbot qui, euh, fonctionne avec Google Chat, que nous utilisons. Euh, je pourrais en parler plus longuement, mais en substance, c'est, euh, une technologie relativement bien connue. Et puis nous avons un modèle de post-mortem. Là aussi, euh, il y a de l'automatisation autour, c'est créé automatiquement. Euh, mais il n'y a rien de trop surprenant ici. Nous avons essentiellement pris le modèle de Google, euh, et, euh, nous l'avons réutilisé.
[00:20:16] Du point de vue du système, ma perspective sur, euh, le processus d'incident est comme une boucle de contrôle de second ordre. Donc vous avez en quelque sorte cette boucle de contrôle Dev DevOps que le développeur, euh, opère au cœur de celle-ci, et une fois que cela échoue à maintenir le système stable, la boucle de contrôle de second ordre entre en jeu. Et le résultat que nous voulons obtenir du post-mortem est des améliorations, des améliorations du système, mais aussi des améliorations du processus. Donc, parfois, nous apprenons que notre pratique de test n'était pas assez bonne, nos politiques ne sont pas assez bonnes en matière de déploiement. Nous pourrions donc en fait corriger les boucles et pas seulement les systèmes dans le cadre du processus post-mortem.
[00:20:57] Donc la réunion hebdomadaire d'examen opérationnel. Euh, c'est peut-être quelque chose dont vous avez entendu parler, mais je sais que de nombreuses entreprises ne le pratiquent pas et Zalando a récemment commencé à vraiment l'adopter comme moyen de renforcer la fiabilité. Et le principe de base derrière cela est une sorte de mantra de gestion, vous obtenez ce que vous inspectez. Alors, que diriez-vous si vous voulez des systèmes fiables, nous commençons à inspecter les pratiques opérationnelles et la fiabilité. Et l'outil clé qui nous permet de faire cela est le rapport que nous avons appelé le rapport de fiabilité. Euh, je dirais que c'est les 500 lignes de Python les plus impactantes que, euh, mon domaine ait jamais écrites. Euh, c'est donc un script Python qui extrait simplement les données de partout et, euh, crée un document Google. Et c'est très important que ce soit un Google Doc. Pourquoi est-ce important ? Euh, chez Zalando, nous organisons toutes les réunions avec Google Doc et nous avons ce genre de lecture silencieuse au début, puis nous en discutons. Euh, et nous utilisons beaucoup la fonction de commentaire. Et nous ne voulions pas créer un rapport qui soit simplement lu par quelqu'un et envoyé à la boîte mail de quelqu'un. Nous voulions faciliter une réunion. Nous voulions rendre très, très facile pour toutes sortes d'organisations la mise en place d'une réunion d'examen hebdomadaire où elles lisent un document ensemble. Et afin d'établir cela, l'alimentation de ce processus était extrêmement importante. Euh, c'est malléable, tout le monde peut le modifier, s'il y a des problèmes de données ou des données manquantes, il suffit de les écraser. Euh, c'est une cascade, donc nous examinons cela au niveau du département, au niveau de l'équipe parfois, mais cela va en quelque sorte aux unités commerciales, cela va au niveau mondial de l'entreprise. Et chaque manager est en quelque sorte euh, invité à résumer ses documents et à contribuer ces sections. S'il y a des erreurs dans leur rapport, ils peuvent également corriger les erreurs dans le document plus grand suivant, afin que vous puissiez en quelque sorte le corriger de cette manière si l'automatisation n'est pas parfaite. Et puis finalement,
[00:23:00] c'est très récent en fait, donc le ver a été utilisé pour se déplacer vers les mardis il y a environ trois semaines au début du mois de mars afin d'alimenter efficacement la réunion de pilotage commercial de Zalando. Donc maintenant, le pilotage commercial est en aval de la réunion de guerre. Donc, en gros, notre vice-président de l'ingénierie obtient une compréhension globale des opérations de la semaine dernière, le mardi matin, afin qu'il puisse se rendre le mardi après-midi auprès des parties prenantes commerciales et leur expliquer les KPI qui étaient mis en avant en raison de problèmes opérationnels, de problèmes opérationnels potentiels ou d'autres choses qui nécessitent une attention. Donc, euh,
[00:23:37] Oui, je pense que c'est un grand succès d'avoir des sujets opérationnels qui remontent aux parties prenantes. C'est assez récent d'être vraiment structuré, euh, clair.
[00:23:50] Alors, à quoi ressemble l'examen ? Je veux juste vous montrer un peu plus le, euh, le contenu de ce document. Le premier est l'examen des incidents, donc pour chaque incident qui s'est produit, euh, qui serait idéalement peut-être 10, parfois c'est 20, parfois c'est un. Euh, mais nous avons environ 10 lignes comme celle-ci dans le document global. Euh, c'est toujours, la structure est en haut, il y a un domaine commercial, donc c'est, c'est regroupé en différents domaines, et chaque domaine a un représentant, idéalement un seul représentant à chaque réunion. Ainsi, la logique de reporting doit en quelque sorte s'adapter au niveau de la réunion que vous tenez et aux niveaux des parties prenantes qui y sont présentes. Donc dans ce cas, cela vient de notre ver d'infrastructure, et nous avons un sous-groupe qui s'appelle l'infrastructure cloud, et le responsable de l'infrastructure cloud gère en quelque sorte cette section. Euh, ensuite nous avons le titre de l'alerte, nous avons quelques métadonnées autour, l'heure de détection et ensuite l'impact. L'impact est un peu intéressant, je peux parler des gravités et de la façon dont nous les définissons, mais regardez, euh, l'impact est multidimensionnel. Et dans ce cas, cela a affecté 20 employés, c'est la seule dimension d'impact que nous avons pu déterminer. Avec des incidents plus importants face aux clients, nous aurons probablement aussi un impact sur la VM brute, comme combien de revenus avons-nous perdus ? Et puis, euh, l'action à entreprendre, c'est là qu'intervient le pilotage managérial. Chaque propriétaire est invité à résumer de manière concise trois choses : quel a été l'impact ou l'effet, quelle en a été la cause et quelles actions entreprenez-vous. Et c'est liant à cet examen, euh, de méta-niveau. Donc nous ne discutons pas de ce qui a mal tourné, euh, comme comment cela a pu arriver, euh, ou des détails du post-mortem. Nous essayons de comprendre lors de cette réunion si l'équipe est efficace pour s'aider elle-même ? Ont-ils, comme, réussi à le diagnostiquer, ont-ils, prennent-ils des mesures sensées ? Nous essayons donc essentiellement de voir si la machine fonctionne, au lieu d'aller plus loin et de voir ce qui a exactement mal tourné dans cet incident. C'est en quelque sorte en aval de cette réunion.
[00:25:55] Euh, nous avons aussi un tableau SLO, qui suit une structure similaire, similaire. Donc encore une fois, vous avez ce regroupement en domaines et vous avez, euh, euh, oui, dans ce cas, des lignes qui ne correspondent pas à des incidents pour effectuer des opérations commerciales. Donc nos SLO ne sont pas ancrés dans les applications, ils sont ancrés dans des processus que nous voulons soutenir, qui sont idéalement significatifs pour nos clients. Et ensuite, la logique SLO vous dit, était-ce fiable ou non ? Si c'est rouge, nous voulons des commentaires à ce sujet. Alors pourquoi est-ce rouge, que faites-vous pour améliorer ?
[00:26:30] Et c'est un peu le modèle, n'est-ce pas ? C'est donc toujours du contenu managérial de ce côté, toujours regroupé par domaines, et en gros, si vous préparez une telle réunion, vous cherchez simplement vos sections et vous remplissez les commentaires là où c'est approprié.
[00:26:44] Euh, voici un autre rapport sur la santé de l'astreinte qui suit la même structure et il y a aussi ce genre de ligne qui devient rouge avec la gestion, c'est toujours facile. On utilise toujours le rouge, l'orange, le vert et puis ils savent quoi faire. Euh, vous ne voulez pas être rouge, n'est-ce pas ? C'est comme ça. D'accord. Euh, et si c'est rouge, vous expliquez en quelque sorte pourquoi. Euh, ici, il s'agit de la santé des astreintes. Il s'agit donc du nombre d'interruptions qu'ont eues les ingénieurs individuels. C'est à nouveau regroupé par organisation, donc dans ce cas c'est le domaine de l'infrastructure, nous avons comme 10 équipes d'astreinte. Chaque équipe d'astreinte a un seul ingénieur qui était d'astreinte cette semaine-là. Nous ne mettons pas le nom ici, mais chaque ligne correspond effectivement à l'expérience d'un seul ingénieur. Et nous voyons quel jour de la semaine ils ont eu combien d'interruptions. Donc un gars a eu 15 interruptions, euh, mardi. Euh, et un total de 16, les autres jours étaient plutôt bien. Et puis vous en discutez, n'est-ce pas ? Ce n'est en fait pas quelque chose que nous aimons. Je pense que dans ce cas, c'était probablement juste un incident qui a déclenché 15 alertes en très peu de temps, donc probablement pas quelque chose sur lequel vous voulez passer beaucoup de temps. Euh, mais dans d'autres cas, vous avez simplement vu une charge constante. Et le simple fait de présenter ce rapport à la direction a énormément aidé à améliorer la situation de nombreux intervenants en cas d'incident qui étaient en quelque sorte invisiblement piégés dans une situation où ils étaient constamment interrompus. Euh, et oui, je veux dire, selon la charge de travail de l'équipe, ce n'est peut-être que parfois la meilleure chose à faire, mais le fait que cela soit constamment mis en évidence aide vraiment à y prêter attention et à résoudre finalement ces problèmes. Également en aval de cette réunion, euh, à partir des données qui sont discutées, si vous les mettez dans une feuille de calcul ou si vous avez une certaine automatisation autour, vous pouvez facilement repérer des schémas et ensuite, espérons-le, orienter des investissements plus importants. C'est donc juste l'un des rapports que nous faisons chaque année. Euh, nous examinons simplement tous les incidents et nous les décomposons en plusieurs catégories et nous regardons comment nos causes, par exemple, nous causent le plus de problèmes. Donc si vous demandez en tant que plateforme, quel type de domaine devrait s'améliorer, alors c'est un bon point de départ. Oui.
[00:29:05] D'accord, je vais juste passer ça.
[00:29:09] Gestion des risques. Euh, c'est donc la dernière sorte de méthode dans la pratique de l'ingénierie de la fiabilité dont je veux parler un peu. Alors, pourquoi faisons-nous de la gestion des risques ? Il y a donc un événement spécifique chaque année qui nous tient beaucoup à cœur, c'est la Cyberweek. À la Cyberweek, c'est comme un très grand événement commercial. Euh, nous menons beaucoup de campagnes, nous générons beaucoup de trafic. Euh, je pense, oui, je ne sais pas, mais c'est, c'est très significatif quand il s'agit du revenu total de l'année. comment nous nous débrouillons pendant la Cyberweek, nous voulons donc nous assurer que nous sommes fiables à ce stade. Et nous ne voulons pas utiliser une boucle post-mortem pour obtenir cette fiabilité. Parce que cela signifie que nous devons gérer 10, 15 Cyberweeks ou je ne sais pas, et chaque fois que nous échouons, nous trouvons comment faire mieux la prochaine fois. Maintenant, nous voulons que ce soit déjà fiable cette fois-ci. Et donc, en plus de ce type de boucle de rétroaction réactive que nous avons avec les post-mortems, nous voulons en fait avoir une boucle de rétroaction proactive. Le point de départ n'est donc pas les défaillances, mais les risques que les ingénieurs identifient dans le cadre de leur, euh, de leur fonctionnement quotidien ou de leur compréhension du système. Euh, vous pouvez donc considérer la création d'un risque comme quelque chose de similaire à un post-mortem ou à un incident. C'est quelque chose qui est signalé. Et puis vous avez un processus similaire à celui des incidents où vous, euh, triez cela d'une certaine manière, ce qui se passe également dans le théâtre des incidents, euh, mais dans le processus post-mortem, vous collectez réellement des données à ce sujet, puis vous en déduisez des actions à entreprendre, et ici c'est similaire, vous évaluez un risque, s'il vaut vraiment la peine d'être résolu, quel est son impact, quelle est la probabilité que cela se produise, et puis vous suivez un processus, qui idéalement aboutit à des mesures d'atténuation, qui stabilisent le système avant qu'il ne devienne incontrôlable. Euh, voici à quoi cela ressemble.
[00:31:07] C'est, euh, juste un exemple de risque, euh, que nous avons dans notre registre. Euh, voici en fait des incidents où cela s'est produit par le passé, euh, voici les actions possibles que nous pouvons prendre pour, euh, pour, euh, l'atténuer. Il est très important d'avoir une propriété claire, nous devons donc être capables de cartographier le risque à des domaines et dans ce cas, euh, le chef de l'ingénierie ou en fait une équipe, l'observabilité est une équipe, est propriétaire de ce risque. Ils sont donc examinés pour l'atténuation. Et comme vous pouvez l'imaginer, lors de l'examen opérationnel hebdomadaire, nous avons un tableau avec le profil de risque de chaque organisation, et s'il y a trop de rouge ou de retard, nous nous attendons à ce que le gestionnaire laisse une note. Et ici, c'est comme, oui, nous voulons revoir cela d'ici la fin du mois, alors attendez-vous à un certain mouvement dans les prochains jours. Ce que l'infrastructure a également fait, c'est qu'elle a déjà atténué 52 risques, ce qui signifie qu'elle a plutôt bien réussi à réduire les risques connus. Euh, au-dessus, il y a le tableau de notre réduction de la mitigation des risques pour la Cyberweek l'année dernière. La ligne bleue représente donc le nombre de risques ouverts, et vous voyez qu'en août, septembre probablement, les équipes sont devenues très actives en signalant tous ces risques, ce que nous leur avons demandé de faire de manière centralisée. Et puis pour la Cyberweek, nous avons géré les risques pertinents pour la Cyberweek, c'est ce qui est représenté ici, vraiment à la baisse, espérons-le, à près de zéro. Euh, donc nous sommes au moins satisfait de l'état. Tout n'est pas nécessairement entièrement atténué, mais nous disons suffisamment atténué pour que nous soyons heureux de participer à cet événement. Et comme vous pouvez le voir, les chiffres sont assez élevés, nous passons donc beaucoup de temps à atténuer les risques avant cet événement. Qu'en est-il du processus ?
[00:32:51] Oui, bien sûr. Euh, nous avons un projet qui est, euh, responsable de la préparation de tout et ce sont des conversations qui se déroulent sur ce type de projet. Il y a aussi le côté commercial qui planifie les campagnes et il y a le côté technique qui prépare le système. Et c'est à ce moment-là que ces conversations ont lieu, comme, sommes-nous d'accord pour faire cela, que pouvez-vous faire en tant que parties prenantes commerciales pour nous aider ? Mais le processus de risque, tel que je l'ai décrit ici, est vraiment quelque chose que nous examinons au niveau de l'ingénierie, euh. Et ce que je n'ai pas dit, c'est que cela a commencé avec la Cyberweek, mais nous faisons vraiment en sorte que cela soit quelque chose que nous faisons tout au long de l'année, tout le processus est durable et c'est quelque chose que nous attendons des équipes techniques. Et qu'en est-il du travail en retard ? Euh, ici dans ce tableau. Oui, c'est juste en retard. Nous avons donc des SLA essentiellement pour toutes les étapes, donc cela devient rouge si vous ne l'avez pas examiné dans le délai imparti. Comment les SLA sont-ils définis ?
[00:33:54] les SLA sont sur le temps que vous avez pour chaque étape. Nous nous attendons donc à ce que vous l'ayez trié et mis en bon état dans les 10 jours. Et puis vous avez en fait dans le processus de risque une étape de décision où un, euh, manager dit en fait que nous voulons faire passer cela à l'exécution, à la mitigation, donc vous définissez un calendrier pour cela. Ou nous remettons à plus tard. Vous avez donc le droit de mettre un risque en pause et de dire, maintenant nous ne donnons pas la priorité à cela pendant six mois environ. Et puis nous revenons. Et tout cela sera vert. Nous examinons ici, la machine de mitigation des risques fonctionne-t-elle ? Nous sommes et c'est, c'est vraiment un bon point. Nous ne regardons en fait pas tant le niveau de risque que nous avons dans le système. Nous ne regardons pas ici les domaines qui deviennent rouges s'ils sont vraiment risqués, ils deviennent rouges s'ils ne trient pas efficacement leurs risques et ne gèrent pas le processus.
[00:34:45] D'accord, euh, Je pense que j'ai, j'ai cinq minutes.
[00:34:50] Je peux donc vous raconter l'histoire de l'incident de metapeda, qui est aussi, euh, touchant à certaines des choses que nous avons vues.
[00:35:00] Le cadre est donc le mardi 17 novembre, et c'est le moment fort de la Cyberweek. C'est le Cyber Tuesday. Euh, vendredi, c'est le grand événement, mais déjà le mardi, nous avons beaucoup de trafic. Nous venons de passer par cet exercice d'atténuation et, euh, nous avons beaucoup d'attention sur nos systèmes, euh, à ce moment-là, euh, juste pour voir s'ils sont, il y a des bruits que vous pouvez entendre. que vous pouvez déjà corriger de manière préventive. Euh, mais oui. Jusqu'à présent, tout va bien.
[00:35:29] Euh, à 12h56, cette PR est fusionnée par une équipe d'infrastructure. Euh, l'intention de cette pull request est de supprimer certains privilèges d'accès à un processus automatisé dans les clusters de test.
[00:35:45] Donc, malgré la Cyberweek, ce n'est pas réellement un système jugé pertinent pour la production. Parce que c'est, euh, si ça tombe en panne, rien ne se passe. C'est un système qui gère l'infrastructure AWS. Nous ne voulons donc pas apporter de modifications pendant la Cyberweek, donc le système, s'il tombe en panne, rien ne se passe, il a donc été jugé très peu risqué. Euh, aussi ce changement était censé aller juste au test. Donc vraiment, comme d'habitude.
[00:36:12] Euh, malheureusement, il y a eu un P qui s'est retrouvé dans l'un des fichiers de configuration et au lieu de métadonnées, ce fichier lit maintenant metapeda. Euh, si vous regardez le nom du fichier, euh,
[00:36:25] certains d'entre vous pourraient déjà avoir peur. C'est slash root slash Route 53 hosted zones/HTM certificates/f.yml. C'est donc nos modèles racines pour configurer Route 53, c'est le DNS dans tous nos clusters AWS. Et malheureusement, il n'y avait plus d'entrée de métadonnées.
[00:36:45] Ainsi, lorsque cette PR a été fusionnée, euh, nous avons un composant appelé AWS Lifecycle Manager qui lisait cette configuration et ne pouvait plus trouver les informations DNS, les configurations DNS. Euh, il a donc décidé, euh, eh bien, apparemment, vous n'avez plus besoin de DNS.
[00:37:02] Et il, euh, il a supprimé les zones hébergées dans AWS. C'est ce que cette chose gère. Maintenant, si vous êtes familier avec l'infrastructure cloud, vous pourriez dire, eh bien, ce n'est pas si grave, n'est-ce pas ? Parce que vous ne pouvez pas supprimer une zone hébergée, comme une zone DNS, si vous avez toutes ces entrées DNS dedans. Sûrement AWS vous empêchera de faire cela. Il s'est avéré que nous avions déjà rencontré ce problème lorsque nous supprimions des comptes AWS. C'est aussi une chose de routine que nous faisons souvent. Pour une raison quelconque, nous avons environ 300 comptes AWS, c'est donc vraiment quelque chose de fréquent. Et l'équipe avait déjà optimisé cela, elle avait donc cette petite fonction lambda qui nettoyait avec enthousiasme les zones DNS hébergées, euh, comme une sorte de processus supplémentaire qui était boulonné. Cette opération a donc été incroyablement efficace et, environ 10 minutes plus tard, nous avons supprimé des dizaines de milliers d'entrées DNS pour tous nos services internes pendant la Cyberweek et, euh, oui, Zalando était en panne. Euh, malheureusement, tous nos outils de surveillance internes étaient hébergés sur la même infrastructure. seul AWS vous empêchera de faire cela. Il s'est avéré que nous avions déjà rencontré ce problème lorsque nous supprimions des comptes AWS. C'est aussi une chose de routine que nous faisons souvent. Pour une raison quelconque, nous avons environ 300 comptes AWS, c'est donc vraiment quelque chose de fréquent. Et l'équipe a déjà optimisé cela, donc elle avait cette petite fonction lambda qui nettoyait avec enthousiasme les zones hébergées DNS comme une sorte de processus supplémentaire qui était boulonné. Donc cette opération a été incroyablement efficace, et à peine 10 minutes plus tard, nous avons supprimé des dizaines de milliers d'entrées DNS pour tous nos services internes au cours de notre semaine. Et euh oui, donc Londres était en panne. Malheureusement, tous nos outils de surveillance interne étaient hébergés sur la même infrastructure.
[00:38:05] Donc, mais Google chat a fonctionné. Alors, euh, comment nous en sommes-nous sortis ? Euh, l'équipe infrastructure est devenue euh active relativement vite, quelques minutes après aussi, les alertes se déclenchaient. Euh la courbe des commandes euh est tombée avant que tous nos systèmes d'alerte ne tombent, donc nous avons reçu ces alertes. Euh et puis vous pouviez voir que c'était un problème DNS, parce que le DNS était juste très évident. Et il n'y avait pas beaucoup de déploiements, donc vous pouviez aussi facilement identifier le coupable relativement tôt. Donc cette chose a été annulée, mais vous ne pouvez pas vraiment annuler ce changement. C'était dans un état partiellement défaillant et cette fonction lambda qui nettoyait les enregistrements n'était pas réversible. Euh, donc nous sommes retournés comme dans les années 90, euh et euh avons écrit, à l'époque vous n'aviez pas de noms DNS du moins si vous faisiez vos LAN parties et ainsi de suite. Donc ce que vous pouviez faire, c'est simplement partager des adresses IP et les mettre dans des tables. Et nous avions un Google Doc où nous avons fait exactement cela. Donc, avec certains composants d'infrastructure critiques, nous mettions vraiment cela dans un fichier /etc/hosts, pour revenir en quelque sorte dans les comptes AWS. Et puis nous avons fait une très, très longue liste de milliers d'enregistrements DNS avec environ 200 ingénieurs dans le chat vidéo, euh pour remettre nos systèmes en marche. Et nous avions environ 10 ingénieurs qui étaient activement en train de restaurer ces entrées euh d'une manière assez manuelle. Mais ce fut assez efficace, en euh trois heures, donc 2h45, euh nous euh étions de nouveau opérationnels. La surveillance a donc commencé à se rétablir vers 2h30, euh les commandes sont revenues à 3h40, 45. Et puis à 20h, tous les systèmes étaient de nouveau pleinement opérationnels et c'était la courbe de commande, n'est-ce pas ? Donc il est tombé pratiquement à zéro pendant une longue période, puis il est remonté. Donc beaucoup de choses euh ont, ont mal tourné ici. Et euh, le plus flagrant est vraiment que nous n'avions pas de bon retour d'information à ce sujet. Ces changements AWS étaient vraiment du type « lancer et oublier ». Donc vous créiez un changement et à ce moment-là, cette automatisation d'infrastructure ne vous donnait aucun retour. Il n'y avait donc aucun retour indiquant que ce PS était en fait illégal. Votre linter n'était donc pas là, vous n'avez pas de validation de schéma pour cela. Euh, il n'y avait pas de prévisualisation qui vérifiait l'intention de votre pull request par rapport à ce qui se passerait en production, une fonctionnalité relativement standard pour les outils de gestion d'infrastructure à ce moment-là, mais nous n'avions pas intégré cela à nos outils. Et puis euh notre politique de déploiement était inefficace.
[00:40:51] Euh, nous avons juste regardé les systèmes s'ils tombaient en panne, ils pouvaient impacter la semaine, ce qui nous n'avons pas regardé les systèmes qui s'ils font quelque chose, ils peuvent impacter la semaine. Et nous avons également examiné les modifications de code et les déploiements, donc ce que nous appelons les politiques de déploiement, nous avons examiné les choses où nous modifions le code. Nous n'avons pas examiné les changements de configuration et cela passait inaperçu sous le nom de changement de configuration. Donc beaucoup d'enseignements ici euh sur le genre de euh déploiement et euh ouais. à cette boucle de rétroaction, mais aussi à la boucle de rétroaction de gestion des risques un petit peu. Hum. Donc, oui, beaucoup, beaucoup de boucles de rétroaction qui étaient soit manquantes, soit ne fonctionnaient pas correctement. Donc avec cela, euh, je veux conclure ici. Euh, juste avec une citation rappelant à tout le monde qu'il s'agit vraiment de boucles de contrôle pour stabiliser les systèmes de production et c'est ce qu'est l'ingénierie de la fiabilité. Merci.
[00:42:07] Bonjour, merci pour la présentation. Alors, que se passerait-il si la PR était à nouveau fusionnée maintenant après cet incident ?
[00:42:14] Euh, oui. En fait, beaucoup de choses. Laissez-moi remettre cette diapositive. Donc, nous avons maintenant une validation dans le euh pour le, pour l'ensemble du manifeste. Donc, cela serait soit signalé dans votre éditeur, soit dans un hook de pré-commit, donc vous ne pouvez pas réellement l'enregistrer si vous avez ce genre de fautes de frappe. Euh, mais je dirais que la chose la plus efficace que nous ayons construite et qui aide à prévenir une grande variété de ce genre de défaillances intentionnelles est une fonctionnalité de prévisualisation. Donc, ce à quoi cela ressemble, c'est qu'une fois que vous soumettez la pull request, vous recevez un nouveau commentaire injecté qui vous dira exactement quelles choses ce n'est pas 100%, mais sont susceptibles de changer. Il y a encore un peu de risque ici, mais dans ce cas, cela vous dirait, vous supprimez environ 200 zones hébergées ou 30 000 entrées DNS avec ce changement. Et la dernière chose dont je n'ai pas parlé est vraiment la mise en scène. Nous avions déjà cela pour notre infrastructure Kubernetes, à savoir que nous ne déployons pas seulement des choses sur tous nos comptes AWS, mais que nous avons un processus en plusieurs étapes. Nous déployons d'abord euh sur certains clusters de test internes, puis sur tous nos clusters et comptes de test, puis sur le premier ensemble de comptes de production, et ainsi de suite. Donc, il est très probable que nous l'aurions intercepté dans les premières phases de staging. Oui.
[00:43:46] Vous parliez de l'atténuation des risques. Quels sont les critères pour prioriser les actions d'atténuation des risques par rapport au développement de fonctionnalités et au déploiement de nouvelles fonctionnalités ?
[00:43:58] Oui, c'est une très bonne question. Hum.
[00:44:05] Je n'ai pas vraiment de réponse générale à cela. Euh, les informations que nous collectons sont euh la sévérité, euh donc quel impact pensez-vous que cela va avoir ? Et la probabilité. Donc, pensez-vous que cela pourrait se produire une fois tous les cinq ans, une fois tous les 10 ans ou des estimations approximatives ? Euh, mais essentiellement, nous disons aux managers à chaque niveau,
[00:44:29] comme, regardez ça et faites votre travail. en priorisant ces choses. Et euh, pour la Cyber Week, c'est vraiment saisonnier, la plupart du temps, les équipes d'ingénieurs ne s'en soucieront pas beaucoup. Mais si vous foutez en l'air la Cyber Week et que vous avez des risques ouverts, ce sera un problème. Et notre direction très senior, je pense, a donné le ton ici. Fait intéressant, le manager n'était pas responsable de l'ensemble du domaine, mais il parrainait en quelque sorte les efforts de la Cyber Week. Et il était assez efficace pour fixer une barre haute, laissez-moi le dire ainsi pour ces choses, et aussi pour communiquer cela à leurs collègues. Donc, je pense qu'il y a beaucoup de sensibilisation et d'attention accordées à cela par la haute direction, ce qui influencera finalement ces compromis. Mais, euh,
[00:45:21] Je pense que si vous voulez piloter cela de manière entièrement quantitative, c'est soit impossible, soit beaucoup trop cher. Donc, vous devez avoir une bonne dose de jugement humain là-dedans. Et je pense que c'est probablement mieux ancré dans la ligne hiérarchique.
[00:45:48] Merci. Je vous remercie pour la présentation. Euh, pour le registre des risques, je n'ai pas euh je n'ai pas pu entendre euh combien de temps euh vous euh découvrez euh vous euh enregistrez le risque avant la Cyber Week ?
[00:46:06] Euh, c'est environ six mois. Euh, je pense qu'en général, c'est une pratique continue maintenant. Donc à chaque instant, si vous découvrez un risque et c'est souvent le cas avec un incident où par l'incident nous découvrons un risque qui n'est peut-être pas matérialisé, peut-être qu'il y a eu un quasi-accident, donc nous avons maintenant ce euh ce genre de levier si vous voulez.
[00:46:29] Donc si quelque chose comme ça arrive, ils se disent, d'accord, enregistrons cela comme un risque. Donc vous vous assurez en quelque sorte que cela ne soit pas oublié, ce qui arrive beaucoup d'ailleurs avec les éléments d'action des post-mortems. Donc parfois vous vous dites, ok, ouais, c'était vraiment mauvais, faisons ces cinq choses. Et c'est plus comme une liste de souhaits et vous en faites peut-être un et puis ça glisse en quelque sorte. Et avec les risques, c'est quelque chose qui vivra et qui fera surface tout le temps. Donc, c'est en général continu, euh pour la Cyber Week, nous demandons vraiment à toutes les équipes, euh, oui, en juillet, août, pour se préparer pour novembre. Euh et si vous regardez la courbe, nous sommes à peu près fin août, septembre où ils commencent vraiment à enregistrer les risques. Et réouvrir beaucoup de risques. Donc, à ce stade, nous faisons ça pour la cinquième, sixième année comme ça, euh vous voyez beaucoup d'amis connus qui réapparaissent chaque année et puis c'est comme, oui, nous devrions regarder ça à nouveau. Et il y a beaucoup de changements d'architecture. Donc beaucoup de choses, d'accord, ça pourrait tomber en panne, c'est un peu un risque générique de cela, mais ça arrive, et oui, les mitigations que vous avez prises l'année dernière pourraient ne plus être efficaces, donc c'est probablement bon de vérifier à nouveau.
[00:47:35] Merci.
[00:47:42] Hi. Uh. Vous montrez un document de rapport assez impressionnant euh et euh.
[00:47:55] Je me demandais, euh, dans la vraie vie, ce que j'ai vu, j'ai travaillé un peu chez Doctor, donc ils ont de grandes équipes et j'ai vu maintes et maintes fois euh des post-mortems pourris.
[00:48:07] Et je me demandais, comment faites-vous pour garder vos équipes motivées, ou quel genre de procédure mettez-vous en place pour évaluer la qualité des données que les euh IC produisaient ? Pour qu'au final, vous ayez des rapports agréables et utilisables.
[00:48:24] C'est une bonne question. Et nous avons certainement une grande variance. Euh, quand j'ai commencé, nous traitions pratiquement chaque alerte comme un incident, et nous avions des centaines d'incidents chaque semaine, donc il devrait y avoir des centaines de documents post-mortem chaque semaine. Et 95% d'entre eux étaient complètement nuls. Euh et ce que nous avons fait ensuite, nous avons vraiment relevé la barre de ce qu'est un incident de manière significative, nous avons introduit le concept d'anomalie, qui était juste un hoquet organisationnel qui ne mérite pas un post-mortem.
[00:48:55] Donc, en ce moment, nous parlons vraiment de 10, 11 postmortems par semaine pour 3 000 ingénieurs logiciels. Donc, vous n'écrivez pas autant de post-mortems tout le temps. Donc, je pense que c'est une chose qui a vraiment aidé, donc ceux que vous écrivez méritent de l'attention. Et ensuite Je veux dire, en fin de compte, je pense que vous obtenez ce que vous inspectez est l'angle le plus efficace. Si votre chaîne de direction se soucie et lit ces documents, ils s'améliorent comme par magie. Euh c'est comme c'est toujours, euh si personne ne s'en soucie, les ingénieurs prendront les raccourcis. Et euh il y a des pratiques autour de ça comme euh les rôles. Ainsi, chaque post-mortem nécessite un réviseur, qui devrait être un ingénieur principal. Et chaque post-mortem a un propriétaire, qui, selon la gravité, est soit un chef, un directeur ou un VP. Donc, euh, vous avez en quelque sorte des rôles formels qui assistent cela. Vous avez aussi une forte recommandation que chaque post-mortem devrait avoir une, avoir une revue. Mais, euh, oui, je veux dire, faire moins de post-mortems, se soucier davantage des post-mortems, être vraiment sérieux quant à l'attente des apprentissages. Je pense que c'est une bonne approche. Et la prochaine chose, je pense que nous verrons l'année prochaine, c'est l'IA qui y contribuera. Donc, euh, si vous prenez simplement l'historique de chat d'un incident et que vous le donnez à un LLM, avec la bonne invite, vous pouvez en fait aller assez loin avec au moins la chronologie, le résumé, les sections d'impact. Euh et probablement aussi des actions à mener. Donc c'est, oui, ce que je veux faire et aider les ingénieurs à faire l'année prochaine, c'est qu'ils n'aient pas à faire autant de travail.
[00:50:59] Bonjour, merci pour votre présentation. Euh, il semble que vous ayez un grand événement commercial au cours de l'année, comme le Black Friday.
[00:51:12] Euh, votre direction euh est-elle euh suffisamment confiante dans euh cette euh boucle de rétroaction sur euh votre système de fiabilité, euh ou est-ce que euh euh ou avez-vous une période de gel, euh quelques jours avant un grand événement pour éviter et limiter euh un grand risque ?
[00:51:28] Oui, je veux dire, les déploiements sont gelés pendant toute la Cyber Week. Euh et bien avant, donc nous ne voulons pas que le système change pendant la Cyber Week. Cela fait partie de la routine. Oui.
[00:52:05] Merci pour cette excellente présentation. J'avais une question. Vous avez dit, euh, si quelque chose dans le projet, nous en faisons une capacité d'équipe pour le pousser. Avez-vous un exemple à ce sujet ?
[00:52:19] Oui, je pense que le test de charge est un bon exemple, euh aussi l'atténuation des risques si vous voulez. Donc, les tests à faible charge ont vraiment commencé comme un projet où euh nous demandions, oui, simplement à toutes les équipes, dans un cadre de projet, de créer ces scénarios. Ensuite, vous auriez trois ou quatre tests de charge organisés de manière centralisée qui simulent la charge globale. Et puis vous oubliez ça et vous le refaites l'année prochaine. Et maintenant, nous avons une infrastructure de tests de charge que toutes les équipes ont à leur disposition dans le cadre de leur cycle de vie d'application, elles écrivent des tests de charge de manière automatisée, elles peuvent les gérer avec le code, euh vous avez des tests de charge réguliers tout au long de l'année. Chaque mois, par exemple, vous pouvez participer à l'un de ceux-là ou vous y serez invité. Euh, je veux dire, il y a une trajectoire, mais vous pouvez en quelque sorte voir comment cela devient euh juste une partie de euh ce que sont les routines de l'équipe. Et vous pouvez aussi aller plus loin quand vous travaillez chez Facebook. Ils ont euh de l'ingénierie du chaos sur leur plateforme, donc ils vont régulièrement retirer des centres de données entiers. Et vous ne le savez probablement même pas en tant qu'équipe parce que cela arrive si fréquemment, donc juste votre infrastructure de déploiement et vos directives sur la façon dont vous écrivez le code imposent en quelque sorte ce niveau de fiabilité. Donc vous n'avez pas à y penser autant.
[00:53:42] Une autre question.
[00:53:45] Non?
[00:53:47] D'accord, merci, enrichir.

Transcription (Traduit)