Il était 3 heures du matin à l'aéroport international Newark Liberty. Encore ensommeillé, j'attendais mon tour pour obtenir ma carte d'embarquement, quand soudain, un écran bleu s'afficha à la borne d'enregistrement. Ayant besoin d'un café, j'appris que le vendeur n'acceptait que les espèces.

Il y avait manifestement une panne majeure et j'ai rapidement vérifié nos systèmes chez PagerDuty. Les pannes importantes surviennent plusieurs fois par an, si fréquemment que nous avons un tableau de bord interne (communément appelé « Internet est en panne »). Effectivement, le graphique indiquait que je n'étais pas le seul à rencontrer des problèmes ce jour-là. Et en effet, une rapide vérification de mon application PagerDuty sur mon téléphone a confirmé que tous les systèmes fonctionnaient correctement. Soulagé, j'ai repris mon café et ma lecture.

Puis, comme par hasard, la personne assise à côté de moi a reçu un appel. Au lieu de paniquer, la sonnerie familière de PagerDuty m'a rassuré : notre plateforme faisait exactement ce pour quoi elle avait été conçue : maintenir les services critiques en fonctionnement même quand tout le reste s'effondrait.

Ce moment a mis en lumière une leçon essentielle en matière de leadership. En tant que leader, vous avez besoin d'un système de pratiques fiables – un système dont vous pouvez être certain qu'il fonctionnera même lorsque vous êtes injoignable – coincé dans un aéroport sans café – afin de garantir une expérience client optimale. Lorsque les enjeux sont importants, ce qui compte vraiment, ce 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 aux défaillances potentielles.

Il existe une idée fausse répandue concernant la fiabilité, qui ressurgit souvent lors des échanges avec les clients et les collègues. Cette idée suppose que la fiabilité est une caractéristique unique ou qu'on peut l'obtenir par une simple redondance. Si certains pensent qu'un serveur de sauvegarde ou un cloud redondant suffisent à garantir la fiabilité, la réalité est bien plus complexe.

Mythe n° 1 : Redondance = Fiabilité

L'un des mythes les plus tenaces concernant la fiabilité est que posséder deux exemplaires de chaque élément garantit l'invulnérabilité. Selon cette vision simpliste, disposer de deux fournisseurs de cloud, de deux serveurs ou de deux bases de données rendrait votre système invincible. Or, ce raisonnement ignore les complexités qui surgissent lorsqu'on introduit plusieurs systèmes devant fonctionner de concert.

L'ajout de composants ne rend pas nécessairement votre système plus fiable. En réalité, cela peut même introduire de nouveaux points de défaillance. Lorsque deux systèmes sont interdépendants, la probabilité de panne ne diminue pas de moitié ; elle augmente. Si l'on ajoute à cela la complexité des systèmes connectés modernes, la complexité d'un système à elle seule peut devenir le principal risque pour sa fiabilité.

Mythe n° 2 : Prévenir l’échec est le seul objectif

Une autre idée fausse répandue est que la clé de la fiabilité réside dans la prévention totale des pannes. Si l'on parvient à éviter les pannes, on n'aura plus à se soucier des temps d'arrêt, n'est-ce pas ?

Malheureusement, aucun système, aussi bien conçu soit-il, n'est à l'abri des pannes. Plutôt que de concevoir des systèmes en espérant, de manière irréaliste, qu'ils ne tomberont jamais en panne, nous les concevons selon le principe de « prévoir la défaillance » et de la gérer avec élégance. Cette approche implique la mise en œuvre de mécanismes de protection tels que le masquage des défaillances, qui isole les composants défaillants et les empêche d'affecter le système global, et l'impact limité, qui restreint l'impact des défaillances à des zones restreintes et gérables de l'infrastructure.

Un excellent exemple de cette approche en pratique est notre initiative des « Vendredis de l'échec ». Nous testons régulièrement les modes de défaillance, non seulement en préproduction, mais aussi en production. Nous simulons divers scénarios de défaillance afin de garantir la résilience de nos systèmes en conditions réelles, notamment les pannes de serveur et les interruptions de réseau. Cette pratique nous a permis de gérer sereinement le pic de trafic du 19 juillet sans interruption majeure.

Mythe n° 3 : Plus de répondants signifie une résolution plus rapide

En temps de crise, de nombreuses organisations pensent que plus elles mobilisent de personnes pour gérer l'incident, plus la résolution sera rapide. C'est une hypothèse logique : plus il y a de personnes compétentes, plus le problème est vite résolu.

Mais la réalité est souvent tout autre. Multiplier les intervenants sur un incident peut engendrer de la confusion, des doublons et des problèmes de communication. Chez PagerDuty, nous avons constaté que l'automatisation est souvent plus efficace pour améliorer les délais de résolution que le simple ajout d'intervenants humains.

Lors de la panne de juillet, un de nos clients nous a raconté une anecdote illustrant parfaitement cette approche. Son équipe venait de commencer à implémenter l'AIOps lorsque la panne est survenue. Avant l'AIOps, ils géraient un volume raisonnable d'alertes système, mais pendant la panne, ce volume a explosé, se transformant en un véritable raz-de-marée d'alertes. Grâce à l'automatisation de la gestion des alertes, ils ont pu rapidement éliminer ces alertes et identifier la cause première des problèmes, permettant ainsi à leurs équipes d'intervention de se concentrer sur les incidents prioritaires et de garantir le rétablissement des systèmes critiques.

La résilience est la somme de nombreuses parties

En définitive, la fiabilité n'est pas un acquis ponctuel, mais un processus continu. C'est pourquoi nous avons investi dans l'automatisation, les analyses basées sur l'IA et les tests continus.

Notre engagement et nos efforts ont porté leurs fruits. Notre plateforme a transmis plus de 60 000 notifications par minute au plus fort de la panne, tout en respectant notre délai de notification moyen de 15 secondes. Nous avons maintenu nos objectifs de niveau de service (SLO) internes et nos clients ont résolu les incidents avec un retard de seulement 29 % par rapport à une journée normale, malgré une augmentation de 192 % du volume d'incidents. Quant aux intervenants équipés d'applications mobiles et de Slack, les notifications ont été reçues en moins de 500 millisecondes, soit instantanément.

Quelles sont les alternatives possibles dans vos choix de conception système ? Nous nous efforçons de suivre un cadre de fiabilité rigoureux dans la conception de nos systèmes. En effet, même en prenant de nombreuses mesures pour éviter les défaillances, tant au niveau des processus que de la conception du système, des défaillances peuvent survenir. Par conséquent, si vous partez du principe qu'un certain nombre de défaillances sont inévitables, vous pouvez adopter d'autres stratégies pour renforcer la résilience. Par exemple, vous pouvez… masque L'échec. Cette stratégie se manifeste notamment par l'orchestration de clusters, les basculements automatiques, la réplication d'état et l'élection d'un leader. Chez PagerDuty, nombre de nos systèmes utilisent ces stratégies, que nous testons et validons en production grâce à des tests de défaillance quotidiens réguliers afin de garantir leur bon fonctionnement.

Parfois, le masquage des échecs n'est pas toujours possible, ou il ne couvre pas tous les cas d'utilisation. L'étape suivante consiste à… lié L'échec. La meilleure et la plus simple façon de procéder est d'utiliser des déploiements progressifs. Nous déployons tous les changements, qu'il s'agisse d'infrastructure ou de nouvelles fonctionnalités, en augmentant graduellement le trafic.

Si vous ne pouvez ni éviter, ni masquer, ni circonscrire une panne, l'objectif suivant est de la corriger rapidement. C'est là qu'un processus de réponse aux incidents efficace et réactif prend toute son importance. Et c'est indéniable : plus vous rétablissez rapidement vos systèmes, plus vite vous pouvez remettre en service vos clients et assurer la continuité de vos activités. Autre cas d'utilisation : les restaurations rapides, qui permettent d'annuler rapidement les modifications apportées lors d'un incident. C'est un excellent complément aux tests de sécurité. À titre d'exemple, chaque équipe chez PagerDuty est tenue de disposer d'un mécanisme de restauration exécutable en moins de cinq minutes. Ces types d'automatisation nous aident à réagir plus rapidement aux incidents et à maintenir la disponibilité des systèmes critiques de nos clients. Je recommande souvent cette première étape, simple et mesurable, que toute organisation peut franchir pour améliorer sa fiabilité et sa réactivité grâce à nos outils d'automatisation : chaque équipe doit implémenter les événements de changement, les tests de sécurité et les restaurations rapides. Lors de votre processus de réponse aux incidents, vous pouvez donner aux responsables d'incidents les moyens d'exécuter un script de restauration si l'incident semble être dû à une modification récente (corrélée 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, circonscrire, annuler et restaurer avant qu'ils ne deviennent un incident majeur.

Les enseignements tirés de la panne du 19 juillet confirment que la véritable fiabilité ne repose pas sur un seul composant ni sur une solution miracle. Il s'agit de bâtir un système de systèmes résilient, conçu pour anticiper les défaillances et s'en remettre rapidement. Nous nous engageons à aider nos clients à atteindre ce niveau de résilience et nous sommes convaincus qu'avec les stratégies, les outils et l'état d'esprit adéquats, toute organisation peut parvenir à une véritable fiabilité opérationnelle, quels que soient les défis à venir.

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