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 l'ingénierie des réseaux, puis, à mesure que l'informatique dématérialisée s'est imposée, dans ce que l'on appelle aujourd'hui les opérations d'infrastructure ou d'informatique dématérialisée. Les périodes les plus stressantes étaient probablement celles des pannes. Au cours des deux dernières décennies, j'ai participé à de nombreuses pannes, certaines pires que d'autres, mais je porte fièrement mes cicatrices de combat opérationnel. Dans ce billet, je vais vous faire part de quelques enseignements et observations tirés de ces incidents.

Je pourrais écrire de nombreux articles sur les incidents "épiques" auxquels j'ai participé. Bien qu'ils soient stressants sur le moment, ils donnent lieu à de bons récits 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. C'est un apprentissage 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 était 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, ils ont connu une panne nationale de 24 heures qui a touché tous leurs clients du téléphone (y compris le 911) et de l'internet. Oui, une panne totale pendant une journée entière ! Alors naturellement, en tant que client de Rogers et passionné des opérations Internet, quand ils ont publié leur rapport (deux ans plus tard !), j'ai dû le lire.

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 provoqué 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.

Les pannes, ça craint. Elles sont très stressantes et, comme le montre l'incident de Rogers, elles peuvent avoir des répercussions importantes dans le monde réel. Toute organisation désireuse de s'améliorer en permanence doit impérativement procéder à des rétrospectives après coup et s'intéresser aux causes profondes, aux 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 déclenché 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.

Il est toujours facile de parler d'une panne depuis la ligne de touche, 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. Cependant, 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 pannes, 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 au pilotage d'un avion de ligne), vous ne voudrez pas nécessairement 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 si vous essayez d'éliminer complètement les pannes.

Acceptons donc que des pannes se produisent et utilisons plutôt cette idée 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.

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 intitulée "plus de surveillance". Cela indique que nous oublions toujours une mesure et que, pour une raison ou pour 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 devriez ajouter et, plus important encore, alerter. Qu'il s'agisse d'un ping ou d'un simple test HTTP, vous serez instantanément certain 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 en panne ; vous en êtes responsable et devez être le premier à le savoir !

Pouvons-nous limiter l'impact d'une panne ? La panne de Rogers est un excellent exemple du pire des cas : un changement a brisé l'ensemble du réseau - une 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 à réfléchir à cette question. Avec AWS, vous pensez toujours à Multi-AZ ou Multi-région. Certains vont plus loin en optant pour le multi-cloud (pensez multi-fournisseurs dans le domaine des réseaux).

Toutefois, 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 votre base de données principale, par exemple. 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 chargées de l'infrastructure sont souvent considérées comme des centres de coûts. Bien que la haute disponibilité et la fiabilité soient considéré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. Cependant, ne laissez jamais un bon désastre se perdre ! 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. La proposition de valeur est la plus forte dans l'immédiat, alors saisissez l'occasion.

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, vous n'avez même plus la possibilité de l'éteindre ou de le mettre hors service. 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 personnes qui utilisent du matériel physique que pour celles qui utilisent, par exemple, 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 des cas. Assurez-vous que vous disposez d'un accès OOB et qu'il est isolé de votre accès au réseau en bande. 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 commande pour le résoudre, est terrible.

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 allaient mal et vous avez simplement annulé votre changement. Vous pouvez voir 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 :

Cela signifie que l'appareil se rechargera 5 minutes après votre changement, à moins que vous n'exécutiez la dernière commande. En supposant que vous ne perdiez pas l'accès, vous exécutiez no reload, ce qui annulait le rechargement puisqu'il n'était pas nécessaire. Juniper a par la suite 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é.

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 fonctionnelle connue. Savoir que vous pouvez revenir rapidement en arrière est un gage de confiance. Évidemment, cela dépend de nos thèmes précédents, à savoir : "être le premier à savoir" et "être le premier à savoir" : "être le premier à savoir" et l'accès à la gestion.

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 le possédez) est que vous ne jetez plus une nouvelle version du logiciel par-dessus le mur et ne demandez plus à 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 possèdent 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. Par conséquent, en cas de panne, il devrait être facile de faire appel au 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 dépanner le bogue que vous avez introduit. Par conséquent, créez un groupe WhatsApp ou tout autre outil que vous utilisez uniquement pour votre équipe ou votre propre canal hors bande pour l'aide d'urgence.

Les pannes sont accablantes. 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 résolviez les problèmes. Une seule personne ne peut pas le faire. 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 résoudre ce problème. N'oubliez pas : une équipe, un rêve.

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 atelier "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 disposez d'outils prêts à annuler rapidement les changements pour revenir au dernier bon état connu. Enfin, saisissez l'occasion d'apprendre avec votre équipe par le biais de rétrospectives et d'en ressortir encore plus fort. Avec une dynamique d'équipe saine, les pannes peuvent étonnamment devenir des expériences précieuses pour resserrer les 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.