Naviguer dans les pannes d’infrastructure : Cicatrices de guerre et enseignements tirés

L’une de mes grandes passions est l’exploitation des infrastructures. J’ai d’abord travaillé dans le domaine de l’ingénierie des réseaux, puis, à mesure que le cloud devenait plus répandu, je me suis tourné vers ce que nous appelons aujourd’hui l’infrastructure ou l’exploitation du cloud. Les moments les plus stressants ont probablement été les pannes. Au cours des deux dernières décennies, j’ai participé à de nombreuses pannes, certaines plus graves que d’autres, mais j’arbore fièrement mes cicatrices de combat opérationnel. Dans ce billet, je vous ferai part de quelques enseignements et observations tirés de ces incidents.

Ce qui m’a incité à écrire ce billet

Je pourrais écrire de nombreux articles sur les incidents “épiques” auxquels j’ai participé. Bien que stressantes sur le moment, elles donnent lieu à de bonnes histoires de guerre par la suite. Ces dernières années, des entreprises comme Facebook et Cloudflare ont commencé à partager publiquement leurs rétrospectives de pannes (chronologie, causes profondes et enseignements tirés), que j’aime lire. L’apprentissage est gratuit !

Il y a quelques jours, Rogers a publié son résumé d’incident public, couvrant les aspects typiques d’une rétrospective de panne. La panne elle-même a été importante. Rogers est le deuxième fournisseur d’accès à Internet et le deuxième opérateur de téléphonie mobile du Canada.

Lire : Panne de Rogers : Que savons-nous après deux mois ?

Il y a deux ans, elle a connu une panne nationale de 24 heures qui a touché tous ses clients du téléphone (y compris le 911) et de l’internet. Oui, une journée entière de travail ! C’est pourquoi, en tant que client de Rogers et passionné d’opérations Internet, je me suis empressé de lire le rapport publié par Rogers (deux ans plus tard !).

La panne de Rogers

Bien que ce ne soit pas l’objet principal de cet article, examinons brièvement la panne.

Lors d’une maintenance planifiée, le personnel de Rogers a supprimé une politique de routage du réseau, ce qui a entraîné l’inondation interne des routes (BGP ou OSPF/ISIS). Le plan de contrôle s’en est trouvé submergé, ce qui a entraîné toutes sortes de problèmes et a fini par provoquer une panne ou par rendre les routeurs principaux inopérants.

La prochaine étape logique serait d’essayer d’annuler ce changement, mais les routeurs eux-mêmes n’étaient plus gérables en raison des problèmes liés au plan de contrôle et, pour aggraver les choses, le réseau de gestion hors bande était également hors service.

Il s’est avéré que le réseau hors bande dépendait d’une manière ou d’une autre du réseau de données de production, de sorte que lorsque ce dernier tombait en panne, le réseau hors bande en faisait autant, ce qui rendait le dépannage et la remédiation impossibles.

Finalement, des ingénieurs ont dû être dépêchés sur place pour obtenir manuellement l’accès à la console.

Réflexions sur la panne de Rogers

Les pannes, ça craint. Ils sont très stressants et, comme le montre l’incident de Rogers, peuvent avoir des conséquences importantes dans le monde réel. Toute organisation qui souhaite s’améliorer en permanence doit impérativement procéder à des rétrospectives après coup afin d’identifier les causes profondes, les enseignements tirés, etc.

Une chose qui m’a frappé est l’article de CBC.ca (un grand média au Canada), dont le titre est le suivant : “Une erreur humaine a déclenché une panne de service massive chez Rogers en 2022, selon un rapport”. S’il est vrai que le changement a donné le coup d’envoi d’une série d’événements, déclarer qu’il s’agit de la cause première est une vision à court terme.

Nombre de ces pannes sont comparables à des enquêtes sur des accidents d’avion, où de multiples facteurs contribuent à la défaillance, qui a parfois commencé des années plus tôt ou qui a été mal conçue au départ.

Réflexion sur les pannes : Pouvons-nous les éliminer ? Devrions-nous le vouloir ?

Il est toujours facile de s’en prendre à une panne depuis les coulisses, mais je tiens à préciser que ce n’est pas mon intention. J’ai appris de première main que la merde arrive ! Ainsi, en gardant à l’esprit la panne de Rogers et l’expérience passée, tirons-en quelques leçons générales.

Tout d’abord, l’élimination totale des pannes est probablement trop ambitieuse pour la plupart d’entre nous. Oui, une partie du processus de rétrospective des pannes devrait consister à éviter que la même panne ne se reproduise à l’avenir. Pourtant, les architectures évoluent, les technologies changent et même une légère modification des paramètres peut entraîner à nouveau une panne similaire.

Ainsi, bien que nous puissions limiter les risques de panne, vous ne pourrez pas les éliminer à 100 %. En fait, compte tenu du coût de l’élimination complète des pannes et en fonction de votre secteur d’activité (par exemple, Facebook par rapport à un avion de ligne), vous n’avez pas nécessairement intérêt à viser cet objectif. Les coûts financiers, les coûts de processus, les coûts d’agilité ou les coûts de rentabilité sont réels lorsque l’on essaie d’éliminer complètement les pannes.

Acceptons donc que des pannes se produisent et utilisons cette connaissance pour nous concentrer sur la limitation de leurs dommages et de leur impact ! Cette approche nous permet de donner la priorité à des stratégies efficaces, dont je parlerai plus loin.

Il est temps de détecter – ou d’être le premier à savoir !

Une surveillance suffisante permet de réduire le temps nécessaire à la détection et à l’identification des causes profondes. Cela semble évident, n’est-ce pas ? Pourtant, presque toutes les rétrospectives de pannes comportent une action d’amélioration appelée “plus de surveillance”. Cela indique que nous oublions toujours une mesure et que, pour une raison ou une autre, nous ne semblons jamais disposer de tous les contrôles et de toutes les mesures. C’est pourquoi je suis un grand fan de la surveillance synthétique de la disponibilité.

Ce contrôle doit reproduire l’expérience d’un utilisateur typique. Ainsi, même si vous remplacez un composant essentiel, vous serez toujours en mesure de voir l’impact sans ajouter d’autres mesures. Parce que vous ne pouvez pas facilement manquer quelque chose, c’est le premier contrôle que vous devez ajouter et, surtout, sur lequel vous devez être vigilant. Qu’il s’agisse d’un ping ou d’un simple test HTTP, vous aurez ainsi la certitude immédiate que votre service fonctionne. C’est ce que j’appelle le principe “être le premier à savoir”. Vous ne voulez pas que vos clients vous disent que votre service est défectueux ; vous en êtes responsable et devriez être le premier à le savoir !

Limite du rayon d’explosion

Pouvons-nous contenir l’impact d’une rupture ? La panne de Rogers est un excellent exemple du pire des cas : un changement a brisé l’ensemble du réseau – la séparation logique, qu’elle soit géographique ou fonctionnelle, aurait pu l’éviter. Les fournisseurs de services en nuage modernes, comme AWS, nous encouragent activement à y réfléchir. Avec AWS, vous pensez toujours à Multi-AZ ou Multi-région. Certains vont plus loin en optant pour le multi-cloud (pensez au multi-fournisseur dans le domaine des réseaux).

Cependant, le passage d’une région unique à une région multiple ou à un nuage multiple peut devenir exponentiellement complexe et coûteux. Il en va de même dans le domaine des réseaux, où le passage d’un fournisseur unique à un fournisseur multiple peut rapidement devenir très complexe.

Certains services sont plus faciles à rendre multirégionaux que d’autres (je ne pense même pas encore au multi-cloud). Prenez par exemple votre base de données principale. Cela s’accompagne de coûts de complexité réels, et il est compréhensible que cela ne soit pas toujours le cas.

Je comprends : les équipes d’infrastructure sont souvent considérées comme des centres de coûts. Bien que la haute disponibilité et la fiabilité soient présentées comme des priorités, les besoins urgents, le développement de fonctionnalités et les pressions sur les coûts prennent souvent le dessus. Mais ne gaspillez jamais une bonne catastrophe ! Après une panne importante, les budgets et les priorités changent souvent. C’est l’occasion pour vous de plaider en faveur d’investissements dans la résilience. C’est dans l’immédiat que la proposition de valeur est la plus forte, alors saisissez ce moment.

Accès à la gestion

Les pannes qui me hantent encore et me donnent un “Ops PTSD” sont celles où nous avons perdu l’accès à la gestion pendant la panne. C’est ce qui est arrivé à Rogers, et un incident similaire s’est produit lors de l’une des plus grandes pannes de Facebook. C’est un véritable scénario cauchemardesque : vous ne pouvez pas dépanner ou remédier au problème puisque vous avez perdu la possibilité de faire quoi que ce soit sur l’appareil. Souvent, il est même possible de l’éteindre ou de le retirer de la rotation. Tant que vous n’avez pas rétabli une forme d’accès à la gestion de l’appareil, vous êtes bloqué.

Ce problème se pose davantage pour les utilisateurs de matériel physique que pour ceux qui travaillent, par exemple, sur AWS. Par conséquent, si vous gérez vos propres centres de données, ne faites jamais de compromis sur l’accès au réseau hors bande sans envisager le pire. Assurez-vous que vous disposez d’un accès OOB et qu’il est isolé de votre accès au réseau in-band. Ce n’est pas toujours facile, mais si vous ne l’avez pas, votre temps de panne passera de quelques minutes à plusieurs heures (voir l’exemple de Rogers et Facebook). Le sentiment d’impuissance, même si vous connaissez le problème et qu’il suffit d’une seule commande pour le résoudre, est terrible.

Scénarios de retour en arrière

Un autre outil précieux dans votre boîte à outils pour réduire l’impact d’une panne est de veiller à ce que sa durée soit limitée. Vous avez effectué le changement, vous avez rapidement constaté que les choses n’allaient pas bien et vous avez simplement annulé le changement. Vous pouvez constater que pour que cela fonctionne, vous avez besoin d’un accès à la gestion (voir ci-dessus).

Dans les premiers temps de Cisco IOS, nous procédions de la manière suivante :

# reload in 5
# conf t
# < do your change >
# no reload

Cela signifie que l’appareil se rechargera 5 minutes après votre modification, à moins que vous n’exécutiez la dernière commande. En supposant que vous ne perdiez pas l’accès, vous exécuteriez une non-recharge, ce qui annulerait la recharge puisqu’elle n’était pas nécessaire. Juniper a ensuite introduit une solution plus élégante avec “commit confirmed”, qui annule automatiquement les modifications si elles ne sont pas confirmées dans un délai donné.

[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
# < On-call blows Up! >
user@host# rollback 1
user@host# commit

Si votre environnement est plutôt celui d’une équipe de développement de logiciels, envisagez d’utiliser les déploiements bleu-vert. Quel que soit votre choix d’apporter des modifications ou de déployer de nouvelles versions de votre logiciel, il est essentiel de pouvoir revenir rapidement à la dernière version connue. Le fait de savoir que vous pouvez revenir rapidement en arrière est un facteur de confiance. Cela dépend évidemment de nos thèmes précédents : “être le premier à savoir” et l’accès à la gestion.

Culture d’équipe – Ne soyez pas un héros.

Enfin, nous devons parler de la culture d’équipe. L’un des avantages du passage du modèle Ops traditionnel au modèle DevOps (vous le construisez, vous en êtes propriétaire) est que vous ne pouvez plus jeter une nouvelle version du logiciel par-dessus le mur et demander à votre équipe Ops de la déployer à l’improviste.

Inévitablement, à un moment donné, vous livrez une version défectueuse et votre responsable des opérations (c’était moi) n’a aucune idée de ce qui a changé ou de la manière de résoudre le problème. Cette situation est extrêmement stressante et franchement injuste.

De nos jours, la plupart des équipes de développement gèrent et déploient leurs propres changements et disposent de pipelines de déploiement modernes pour les déployer. Mais même dans ce cas, le logiciel est complexe et tous les membres de l’équipe n’en comprennent pas tous les composants. Ainsi, en cas de panne, il devrait être facile de faire venir le reste de l’équipe. N’hésitez pas à appeler les membres de votre équipe, même au milieu de la nuit. Dans une organisation saine, personne ne devrait se réveiller le lendemain matin en apprenant qu’il y a eu une panne de 4 heures et que quelqu’un de votre équipe a essayé de résoudre le bogue que vous avez introduit. Vous pouvez donc créer un groupe WhatsApp ou tout autre outil que vous utilisez pour votre équipe ou votre propre canal hors bande pour l’aide d’urgence.

Les pannes sont très nombreuses. Vous recevez de nombreuses alertes qui doivent toutes être prises en compte, et vous recevez des questions de la part des équipes d’assistance, des clients, de la direction, etc. On attend également de vous que vous dépanniez. Aucune personne ne peut le faire à elle seule. Vous avez besoin de quelques personnes pour résoudre les problèmes, gérer les alertes et coordonner l’ensemble du processus, y compris la communication. Ne jouez donc pas les héros. Faites appel à vos coéquipiers ; ensemble, vous pouvez faire face à cette situation. N’oubliez pas : une équipe, un rêve.

Des pannes se produiront inévitablement

Reconnaissons cette réalité et prenons des mesures proactives pour limiter leur impact et leur durée.

Soyez attentif à la réaction spontanée de la direction : “Nous avons besoin de plus de processus de gestion du changement !” À moins que vous ne soyez un véritable magasin YOLO, c’est rarement la solution.

Au lieu de cela, utilisez le principe “être le premier à savoir”, assurez-vous de l’accès à votre matériel à tout moment et ayez des outils prêts à revenir rapidement sur les changements pour revenir au dernier état connu. Enfin, saisissez l’occasion d’apprendre avec votre équipe par le biais de rétrospectives pour en ressortir encore plus fort. Avec une dynamique d’équipe saine, les pannes peuvent étonnamment devenir des expériences précieuses pour créer des liens. En vous préparant et en travaillant ensemble, vous transformerez les pannes en simples blips sur le radar.

Adapté de l’article original paru sur toonk.io

Andree Toonk est un technologue et un entrepreneur expérimenté, passionné par tous les aspects de l’infrastructure Internet.

Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l’Internet Society.