Blog

Mythe et réalité : les leçons de fiabilité tirées de la panne du 19 juillet

par Paula Thrasher 10 septembre 2024 | 8 min de lecture

Il était 3 heures du matin à l'aéroport international de Newark Liberty. J'étais groggy, j'attendais dans la file pour récupérer ma carte d'embarquement, et je me suis retrouvé face à un écran bleu au kiosque d'enregistrement. Ayant besoin d'un café, j'ai appris que le vendeur n'acceptait que les espèces.

Il y avait clairement une panne importante et j’ai rapidement vérifié nos systèmes chez PagerDuty. Les pannes majeures se produisent plusieurs fois par an, si fréquemment que nous avons un tableau de bord interne (appelé familièrement « les internets sont en panne »). Effectivement, le graphique indiquait que je n’étais pas le seul à avoir eu une mauvaise expérience client ce jour-là. Et en effet, une vérification rapide de mon application PagerDuty sur mon téléphone indiquait que tous les systèmes fonctionnaient bien. Soulagé, je suis retourné boire mon café et rattraper mon retard dans la lecture.

Puis, comme par hasard, la personne assise à côté de moi a reçu un bip. Mais plutôt que de paniquer, le son familier de la notification PagerDuty m'a rassuré sur le fait que notre plateforme faisait exactement ce pour quoi elle avait été conçue : maintenir les services critiques en activité lorsque tout le reste s'effondrait.

Ce moment a mis en lumière une leçon clé en matière de leadership. En tant que leader, vous avez besoin d’un système de pratiques – un système dont vous pouvez être sûr qu’il fonctionnera même lorsque vous êtes injoignable – coincé dans un aéroport sans café – pour créer une expérience client fiable pour vos clients. Lorsque les enjeux sont élevés, ce qui compte vraiment n’est pas seulement d’avoir un système en place, mais d’avoir un système de systèmes – un cadre intégré de technologies, de processus et de protocoles qui garantit la résilience face à une défaillance potentielle.

Il existe une idée fausse très répandue sur la fiabilité, qui revient souvent dans les conversations avec les clients et les pairs. Cette idée suppose que la fiabilité est une caractéristique singulière ou que nous pouvons l'atteindre grâce à une simple redondance. Si certains pensent que le simple fait de disposer d'un serveur de sauvegarde ou d'un cloud redondant est synonyme de fiabilité, la réalité est bien plus complexe.

Mythe n°1 : la redondance est synonyme de fiabilité

L'un des mythes les plus tenaces sur la fiabilité est que si vous avez deux exemplaires de chaque chose, vous êtes couvert. Dans cette vision trop simplifiée, avoir deux fournisseurs de cloud, deux serveurs ou deux bases de données devrait rendre votre système invincible. Cependant, cet état d'esprit ignore les complexités qui surviennent lorsque vous introduisez plusieurs systèmes qui doivent fonctionner en tandem.

L'ajout de composants supplémentaires ne rend pas nécessairement votre système plus fiable. En fait, cela peut introduire de nouveaux points de défaillance. Lorsque deux systèmes sont interdépendants, la probabilité de défaillance ne diminue pas de moitié ; elle augmente. Ajoutez à cela la complexité des systèmes connectés modernes et la complexité d'un système à elle seule peut devenir le plus grand risque en matière de fiabilité.

Mythe n°2 : le seul objectif est d’éviter l’échec

Une autre idée fausse courante est que la clé de la fiabilité réside dans la prévention totale des pannes. Si vous pouvez prévenir les pannes, vous n'aurez pas à vous soucier des temps d'arrêt, n'est-ce pas ?

Malheureusement, aucun système, aussi bien conçu soit-il, n’est à l’abri d’une panne. Plutôt que de concevoir des systèmes avec l’espoir irréaliste qu’ils ne tomberont jamais en panne, nous les concevons selon le principe de « supposer une panne » et de gérer les pannes avec élégance. Cette approche implique la mise en œuvre de mesures de protection telles que le masquage des pannes, où les composants défaillants sont isolés et n’affectent pas le système global, et l’impact limité, qui limite l’effet des pannes à de petites zones gérables de l’infrastructure.

Un bon exemple de cette approche est notre pratique des « vendredis de panne ». Nous testons régulièrement les modes de défaillance non seulement dans les environnements de test, mais aussi dans les environnements de production. Nous simulons divers scénarios de défaillance pour garantir la résilience de nos systèmes dans des conditions réelles, allant des pannes de serveur aux pannes de réseau. Cette pratique nous a permis de gérer en toute confiance le pic de trafic du 19 juillet sans interruption majeure.

Mythe n° 3 : plus il y a de répondants, plus le problème est résolu rapidement

En temps de crise, de nombreuses organisations pensent que plus elles impliquent de personnes dans le processus de réponse aux incidents, plus la résolution sera rapide. C'est une hypothèse logique : plus il y a de cerveaux, plus le problème sera résolu rapidement.

Mais la réalité est souvent tout autre. Ajouter trop d'intervenants à un incident peut entraîner de la confusion, des doublons et des goulots d'étranglement dans la communication. Chez PagerDuty, nous avons appris que l'automatisation est souvent un moyen plus efficace d'améliorer les délais de résolution que le simple ajout d'intervenants humains.

Lors de la panne de juillet, l’un de nos clients nous a fait part d’une anecdote qui illustrait parfaitement cette approche. Son équipe venait tout juste de commencer à mettre en œuvre AIOps lorsque la panne a eu lieu. Avant AIOps, ils devaient faire face à une quantité raisonnable de bruit système, mais pendant la panne, ce bruit s’est transformé en une vague d’alertes écrasante. Cependant, grâce à l’automatisation de la gestion des alertes, ils ont pu rapidement éliminer le bruit et identifier la cause profonde des problèmes, donnant ainsi à leurs intervenants humains l’espace nécessaire pour se concentrer sur les incidents hautement prioritaires et garantir la restauration des systèmes critiques.

La résilience est la somme de plusieurs parties

En fin de compte, la fiabilité n'est pas une réussite ponctuelle, mais un processus continu. C'est pourquoi nous avons investi dans l'automatisation, les informations basées sur l'IA et les tests continus.

Notre engagement et notre travail ont porté leurs fruits. Notre plateforme a délivré plus de 60 000 notifications par minute au plus fort de la panne, tout en restant dans notre délai moyen de notification de 15 secondes. Nous avons maintenu nos objectifs de niveau de service internes et les clients ont résolu les incidents seulement 29 % plus lentement qu'un jour normal, malgré une augmentation de 192 % du volume d'incidents. Et pour les intervenants configurés pour les appareils mobiles et Slack, les notifications se sont produites en moins de 500 millisecondes, soit littéralement en un clin d'œil.

Quality Delivery Process - Avoid It, System Reliability Process - Mask It, Bound it, Incident Response Process - Fix it Fast

Quelles sont les autres choses que vous pouvez faire dans vos choix de conception de système ? Nous essayons de suivre un cadre approfondi de fiabilité dans notre conception de système. C'est-à-dire que, en supposant que vous ayez fait beaucoup d'autres choses dans votre processus et dans la conception de votre système pour éviter les échecs, les choses échouent toujours. Donc, si vous supposez qu'un certain nombre d'échecs sont inévitables, vous pouvez adopter d'autres stratégies pour créer de la résilience. Par exemple, vous pouvez masque L'échec. Des exemples de cette stratégie en action sont l'orchestration de cluster, les basculements automatisés, la réplication d'état et l'élection de leader. Chez PagerDuty, bon nombre de nos systèmes utilisent ces stratégies, et nous les testons et les validons en production avec des tests d'échec quotidiens réguliers pour nous assurer qu'ils fonctionnent comme prévu.

Parfois, il n'est pas toujours possible de masquer les échecs ou cela ne couvre pas tous les cas d'utilisation. La prochaine chose que vous pouvez faire est lié l'échec. La meilleure et la plus simple façon d'y parvenir est d'utiliser des canaris et des déploiements par phases. Nous effectuons des déploiements par phases pour tous les changements, qu'il s'agisse de mises à jour d'infrastructure ou de fonctionnalités, en augmentant progressivement le trafic.

Si vous ne pouvez pas éviter, masquer ou limiter une défaillance, l’objectif suivant est de la réparer rapidement. C’est évidemment là qu’un processus de réponse aux incidents efficace et réactif entre en jeu. Et c’est certainement vrai : plus vite vous pouvez récupérer vos systèmes, plus vite vous pouvez restaurer les services pour vos clients et votre mission. Un autre cas d’utilisation ici est celui des restaurations rapides, qui vous permettent d’annuler rapidement les modifications apportées lors d’un incident. Il s’agit d’une excellente tâche complémentaire aux canaris. Exemple concret : chaque équipe de PagerDuty doit disposer d’un mécanisme de restauration pouvant être exécuté en moins de cinq minutes. Ces types d’automatisation nous aident à réagir plus rapidement aux incidents et à maintenir les systèmes critiques de nos clients en état de fonctionnement. Je partage également souvent cela comme une excellente première étape mesurable et facile à mettre en œuvre que toute organisation peut prendre pour améliorer sa fiabilité et sa réactivité à l’aide de nos outils d’automatisation : demandez à chaque équipe de mettre en œuvre des événements de changement, des canaris et des restaurations rapides, et pendant votre processus de réponse aux incidents, vous pouvez permettre à vos commandants d’incident d’exécuter un script de restauration d’équipe s’il semble que l’incident soit causé par un changement récent (comme corrélé par nos événements de changement). En interne, le fait de disposer de ces outils nous permet d’éviter au moins une demi-douzaine d’incidents par an que nous pouvons détecter, limiter, annuler et restaurer avant qu’ils ne deviennent un incident majeur.

Les leçons tirées de la panne du 19 juillet réaffirment que la véritable fiabilité ne se résume pas à un seul composant ou à une solution miracle. Il s'agit de construire un système de systèmes résilient, capable d'assumer les pannes et conçu pour s'en remettre rapidement. Nous nous engageons à aider nos clients à atteindre ce niveau de résilience et nous pensons qu'avec les bonnes stratégies, les bons outils et la bonne mentalité, toute organisation peut atteindre une véritable fiabilité opérationnelle, quels que soient les défis que l'avenir lui réserve.

Vous souhaitez en savoir plus sur la préparation aux pannes ? Consultez ce webinaire : Tirer les leçons des incidents pour se préparer à la prochaine panne .