Les pires pannes de réseau et de service de l'année 2022 ont eu des conséquences considérables. Des vols ont été annulés, des réunions virtuelles ont été perturbées et les communications ont été interrompues.
Les causes à l'origine des pannes subies par les principaux fournisseurs d'infrastructures et de services étaient également variées, selon une analyse réalisée par ThousandEyes, une société de cyber-intelligence détenue par Cisco qui surveille le trafic Internet et le trafic cloud. Les erreurs liées à la maintenance ont été mentionnées à plusieurs reprises : l'opérateur canadien Rogers Communications a subi une panne massive à l'échelle nationale dont l'origine a été attribuée à une mise à jour de maintenance, et une erreur dans un script de maintenance a causé des problèmes à l'éditeur de logiciels Atlassian.
Les erreurs de configuration du BGP figurent également parmi les principales causes de pannes. Le protocole BGP (Border Gateway Protocol) indique au trafic Internet quel itinéraire emprunter, mais si les informations de routage sont erronées, le trafic peut être détourné vers un itinéraire incorrect, comme cela s'est produit avec Twitter. (Pour en savoir plus sur les pannes aux États-Unis et dans le monde, consultez notre rapport hebdomadaire « Internet Health Check ».
Voici les 10 bouleversements majeurs de l'année, par ordre chronologique.
British Airways subit une panne de son système en ligne : 25 février
Le 25 février, les services en ligne de British Airways ont été inaccessibles pendant plusieurs heures, entraînant l’annulation de centaines de vols et perturbant les opérations de la compagnie aérienne. Il était impossible de réserver des vols et les voyageurs ne pouvaient pas s’enregistrer en ligne. La compagnie aurait été contrainte de revenir à des procédures papier lorsque ses systèmes en ligne sont devenus inaccessibles, et les répercussions se sont fait sentir dans le monde entier. ’ Notre surveillance montre que le chemin réseau menant aux services en ligne (et aux serveurs) de la compagnie aérienne est accessible, mais que les réponses du serveur et du site dépassent le délai d’attente “, a indiqué ThousandEyes dans son analyse de la panne, qui a attribué la défaillance à un serveur d’applications qui ne répondait plus – et non à des problèmes de réseau.
“ La nature du problème et la réponse apportée par la compagnie aérienne laissent penser que la cause première pourrait résider dans un référentiel central back-end sur lequel s’appuient plusieurs services front-end. Si tel est le cas, cet incident pourrait inciter British Airways à refondre ou à restructurer ses Catalysts afin d’éviter les points de défaillance uniques et de réduire le risque de récidive. Cependant, il est tout aussi probable que la succession d’événements ayant conduit à la panne soit rare et puisse être largement maîtrisée à l’avenir. ” L’avenir nous le dira », a déclaré Thousand Eyes.
Twitter piraté par BGP : 28 mars
Le 28 mars, le fournisseur russe d’accès à Internet et de communications par satellite JSC RTComm.RU a annoncé par erreur l’un des préfixes de Twitter (104.244.42.0/24), ce qui a entraîné le réacheminement du trafic vers Twitter vers certains utilisateurs et provoqué une interruption du service. Certains utilisateurs ne peuvent plus accéder à Twitter. Après le retrait de l'avis BGP de RTComm, les utilisateurs concernés ont pu à nouveau accéder au service Twitter. ThousandEyes souligne qu'une mauvaise configuration du BGP peut être utilisée pour bloquer le trafic de manière ciblée – mais il n'est pas toujours facile de déterminer si la situation est accidentelle ou intentionnelle.
“ Nous savons que l’incident survenu le 28 mars sur Twitter a été provoqué par RTComm, qui s’est déclaré comme l’origine du préfixe Twitter avant de le retirer. Bien que nous ignorions ce qui a conduit à cette annonce, il est important de comprendre que les erreurs de configuration accidentelles du BGP ne sont pas rares, et étant donné que le FAI a retiré cette route, il est probable que RTComm n’ait pas eu l’intention de provoquer une interruption du service Twitter ayant un impact mondial. Cela dit, dans certaines régions, des FAI ont eu recours à une manipulation localisée du BGP pour appliquer des politiques d’accès locales visant à bloquer le trafic ”, a déclaré ThousandEyes dans son analyse de la panne.
Pour faire face aux fuites et aux détournements de routes, les entreprises peuvent notamment mettre en place une surveillance permettant une détection rapide et protéger le BGP à l’aide de mécanismes de sécurité tels que l’infrastructure à clé publique pour les ressources (RPKI), un mécanisme de sécurité cryptographique utilisé pour garantir l’authentification de la source des routes. Le RPKI est efficace contre les détournements et les fuites BGP, mais son adoption n’est pas encore généralisée. “ Même si votre entreprise a peut-être mis en place le RPKI pour se protéger contre les menaces BGP, ce n’est pas forcément le cas de votre opérateur télécom. C’est un élément à prendre en compte lors du choix d’un FAI ”, a déclaré ThousandEyes.
Atlassian exagère l'impact de la panne : 5 avril
Atlassian a signalé des problèmes affectant plusieurs de ses principaux outils de développement dans la matinée du 5 avril, notamment Jira, Confluence et OpsGenie. Une erreur dans un script de maintenance a entraîné l'interruption de ces services pendant plusieurs jours, mais n'a concerné qu'environ 400 clients d'Atlassian.
Dans son analyse de la panne, ThousandEyes a souligné l'importance des pages d'état des fournisseurs lors du signalement de problèmes : la page d'état d'Atlassian affichait une “ multitude d'indicateurs orange et rouges ” signalant une panne grave, et l'entreprise a déclaré qu'elle mobiliserait des centaines d'ingénieurs pour remédier à l'incident, mais que pour la plupart des clients, il n'y avait aucun problème.
Les pages d’état sous-estiment souvent l’ampleur d’une panne, mais elles peuvent aussi en exagérer l’impact, prévient ThousandEyes : “ C’est un équilibre très difficile à trouver : si l’on en dit trop peu ou trop tard, les clients s’inquiéteront de la réactivité ; si l’on en dit trop, en faisant preuve d’une transparence excessive, on risque d’inquiéter inutilement un grand nombre de clients non concernés, ainsi que d’autres parties prenantes. ».
Une panne d'électricité chez Rogers perturbe le service dans tout le Canada : 8 juillet
Une mise à jour de maintenance ratée a provoqué une longue panne à l'échelle nationale sur le réseau de l'opérateur canadien Rogers Communications. Cette panne a affecté les services téléphoniques et Internet d'environ 12 millions de clients et a entravé le fonctionnement de nombreux services essentiels à travers le pays, notamment les transactions bancaires, les services publics et les capacités d'intervention d'urgence.
Selon ThousandEyes, Rogers a retiré ses préfixes en raison de problèmes de routage internes, ce qui a rendu les fournisseurs de niveau 1 inaccessibles sur Internet pendant près de 24 heures. “ Cet incident semble avoir été déclenché par le retrait d’un grand nombre de préfixes de Rogers, ce qui a rendu leur réseau inaccessible depuis l’Internet mondial. Toutefois, le comportement observé sur leur réseau pendant cette période suggère que le retrait des routes BGP externes pourrait avoir été causé par des problèmes de routage internes ”, a indiqué ThousandEyes dans son analyse de la panne.
La panne de Rogers nous rappelle à quel point la redondance est indispensable pour les services critiques ; ThousandEyes recommande de faire appel à plusieurs fournisseurs de réseau, de mettre en place des plans de secours en cas de panne et de s'assurer de disposer d'une visibilité proactive. “ Aucun fournisseur n’est à l’abri des pannes, quelle que soit sa taille. Ainsi, pour les services critiques tels que les hôpitaux et les banques, il convient de prévoir un fournisseur de réseau de secours capable de limiter la durée et l’ampleur de la panne ”, écrit ThousandEyes.
Panne de la région Est des États-Unis d'AWS : 8 juillet
Une coupure de courant survenue le 28 juillet a perturbé le service au sein de la zone de disponibilité 1 (AZ1) d’Amazon Web Services (AWS) dans la région US East 2. “ Cette panne a affecté la connectivité vers la région et a provoqué l’arrêt des instances EC2 d’Amazon, ce qui a eu des répercussions sur des applications telles que Webex, Okta, Splunk, BambooHR et d’autres ”, a indiqué ThousandEyes dans son analyse de la panne. Tous les utilisateurs et services n’ont pas été touchés de la même manière ; par exemple, les composants Webex hébergés dans les centres de données de Cisco continuent de fonctionner normalement. AWS a indiqué que la panne n’avait duré qu’environ 20 minutes, mais qu’il a fallu jusqu’à trois heures pour que certains services et applications de ses clients soient rétablis.
Il est important d’intégrer un certain degré de redondance physique dans les applications et services fournis dans le cloud, écrit ThousandEyes : “ Il n’y a pas d’atterrissage en douceur en cas de panne d’un centre de données : lorsqu’il y a une coupure de courant, les systèmes qui en dépendent en pâtissent. Qu'il s'agisse d'une panne du réseau électrique ou des systèmes associés ( Dans de telles circonstances, la résilience architecturale et la redondance des services numériques sont cruciales.
Google Search et Google Maps ne sont plus disponibles : 9 août
Cette brève interruption a affecté Google Search et Google Maps, ces services Google très utilisés ayant été indisponibles pour les utilisateurs du monde entier pendant environ une heure. “ Les tentatives d'accès à ces services ont généré des messages d'erreur provenant des serveurs périphériques de Google, notamment des réponses HTTP 500 et 502, qui indiquent souvent des problèmes internes au niveau du serveur ou de l'application ”, a rapporté ThousandEyes.
Selon certaines informations, la cause première serait une mise à jour logicielle qui a mal tourné. Non seulement les utilisateurs finaux n'ont pas pu accéder à Google Search et à Google Maps, mais les applications qui s'appuyaient sur les fonctionnalités logicielles de Google ont également cessé de fonctionner pendant cette panne.
Les professionnels de l’informatique s’intéressent aux pannes pour plusieurs raisons, a noté ThousandEyes. “ Premièrement, cela met en évidence le fait que même les services les plus stables, tels que Google Search, pour lesquels nous rencontrons rarement des problèmes ou n’entendons guère parler de pannes, restent soumis aux mêmes forces susceptibles de perturber tout système numérique complexe. Ensuite, cet incident a révélé à quel point certains systèmes logiciels sont omniprésents, étroitement liés aux nombreux services numériques que nous utilisons quotidiennement sans avoir conscience de ces dépendances logicielles.
Une panne de Zoom perturbe les réunions virtuelles : 15 septembre
Lors de la panne survenue le 15 septembre, les utilisateurs n'ont pas pu se connecter ni rejoindre des réunions Zoom pendant environ une heure, ce qui a entraîné l'apparition d'erreurs « Bad Gateway » (502) pour les utilisateurs du monde entier. Les utilisateurs n'ont pas pu se connecter ni rejoindre des réunions, et dans certains cas, ceux qui participaient déjà à une réunion en ont été déconnectés.
La cause première n'a pas été confirmée, “ mais elle semble provenir des systèmes backend de Zoom, plus précisément de leur capacité à traiter, acheminer ou redistribuer le trafic ”, a indiqué ThousandEyes dans son analyse de la panne.
L'agent Zscaler subit une perte de paquets 100% : 25 octobre
Le 25 octobre, le trafic vers un sous-ensemble de points de terminaison proxy Zscaler a subi une perte de paquets de type 100%, affectant les clients utilisant le service Zscaler Internet Access (ZIA) sur leur réseau Zscaler Cloud Network 2. Selon l'analyse de l'incident réalisée par ThousandEyes, la perte de paquets la plus importante a duré environ 30 minutes, bien que certains problèmes d'accessibilité et des pics de perte de paquets aient persisté de manière intermittente sur certains sites d'utilisateurs pendant les trois heures qui ont suivi.
Zscaler qualifie ce problème de “ problème de transfert du trafic ” sur sa page d'état. Lorsque l'adresse IP virtuelle du proxy est inaccessible, le trafic ne peut pas être transféré.
ThousandEyes a expliqué comment cette situation avait empêché certains clients utilisant le service de sécurité Zscaler d’accéder à des outils métier essentiels et à des applications SaaS : “ Cela a pu affecter diverses applications chez les clients professionnels utilisant le service Zscaler, car dans les implémentations de ce service de sécurité (ce qui est courant dans le cadre d’une architecture SSE), le proxy gère non seulement le trafic web, mais aussi d’autres outils métier essentiels et services SaaS tels que Salesforce.com, ServiceNow et Microsoft Office 365. Par conséquent, le proxy se trouve sur le chemin des données de l’utilisateur, et lorsque celui-ci est inaccessible, l’accès à ces outils est perturbé ; la résolution du problème nécessite souvent une intervention manuelle pour rediriger les utilisateurs concernés vers une passerelle alternative.
WhatsApp suspend son service de messagerie : 25 octobre
Une panne de deux heures survenue le 25 octobre a empêché les utilisateurs de WhatsApp d'envoyer ou de recevoir des messages sur la plateforme. Ce logiciel gratuit, propriété de MetaWiki, est l'application de messagerie la plus populaire au monde : 31% de la population mondiale utilise WhatsApp, selon les données de 2022 de la plateforme d'intelligence numérique Similarweb.
D'après l'analyse de ThousandEyes, cette panne était liée à une défaillance du service d'application backend plutôt qu'à une défaillance du réseau. Elle s'est produite pendant les heures de pointe en Inde, où l'application compte des centaines de millions d'utilisateurs.
Nouvelle panne dans la région Est des États-Unis d'AWS : 5 décembre
Amazon Web Services (AWS) a subi une deuxième panne dans sa région « US East 2 » début décembre. Selon AWS, cette panne a duré environ 75 minutes et a entraîné des problèmes de connectivité Internet vers et depuis la région « US East 2 ».
ThousandEyes a constaté une perte de paquets entre deux sites internationaux et la région US-East-2 d’AWS pendant plus d’une heure. Cet incident a affecté les utilisateurs finaux qui se connectaient aux services AWS via leur FAI. “ Cette perte ne se produit qu'entre les utilisateurs finaux connectés via leur FAI et ne semble pas affecter la connectivité entre les instances au sein d'une même région ou entre différentes régions ”, a indiqué ThousandEyes dans son analyse de la panne.
Plus tard dans la journée, AWS a publié un article de blog indiquant que le problème avait été résolu. “ Les connexions entre les instances au sein d’une même zone, entre les zones, ainsi que les connexions directes ne sont pas affectées par ce problème. Le problème a été résolu et la connectivité a été entièrement rétablie ”, indiquait l’article.
