IBM Cloud a subi lundi sa deuxième panne majeure en deux semaines, empêchant les utilisateurs du monde entier de se connecter, de gérer les ressources ou d'accéder aux services essentiels. L'incident, qui a duré plusieurs heures, a commencé à 11h05 le 2 juin. Il a perturbé 41 services, notamment IBM Cloud, AI Assistant, DNS Services, Watson AI, Global Search Service, Hyper Protect Crypto Services, les bases de données et le Security and Compliance Center. L’incident a été résolu mardi à 01h10. Selon le rapport d'IBM sur l'état de la situation, les utilisateurs n'ont pas pu se connecter à IBM Cloud via la console, le CLI ou l'API. Pendant cette période, ils n'ont pas pu non plus gérer ou approvisionner les ressources du cloud. De plus, des échecs d'authentification IAM se sont produits, l'accès au portail de support a été perturbé et les chemins de données pour les applications des clients peuvent avoir été affectés.
Big blue a commencé son enquête et pris des mesures d'atténuation préliminaires puis démarré un processus de récupération contrôlé pour restaurer le système. Après avoir terminé ses principales actions de restauration, et les utilisateurs ont pu vérifier l'état de leurs applications. L’événement a été classé de gravité 1 (Sev-1). Les clients ont reçu des courriels sur l'échec de l'authentification IAM, l'impossibilité d'accéder au portail de support, et les impacts potentiels sur les chemins de données des applications des clients. Le fournisseur n'a pas répondu immédiatement à une demande de commentaire.
Un incident similaire quinze jours avant
« Les interruptions de connexion au cloud, même si elles sont de courte durée, retardent l'accès aux applications clés, ralentissent la coordination interne et interfèrent avec les flux automatisés. Les pannes du cloud qui affectent la connexion des utilisateurs ou l'accès à la plateforme ne déclenchent pas toujours un chaos immédiat, mais elles introduisent des frictions qui s'aggravent rapidement », a déclaré Sanchit Vir Gogia, analyste en chef et directeur général de Greyhound Research. Selon M. Gogia, un impact multirégional ne se résume pas à un bogue d'authentification, mais pointe généralement vers un composant back-end partagé, comme une couche de résolution DNS globale, un contrôleur d'orchestration ou un service de télémétrie. « Contrairement aux pannes de calcul ou de stockage le plus souvent localisées, les faiblesses du plan de contrôle se répercutent sur les zones, rendant la panne plus difficile à contenir et plus perturbante pour les équipes qui gèrent des charges de travail distribuées. L'absence de découplage régional dans les fonctions de base de la plateforme reste une préoccupation pour les DSI qui doivent trouver des compromis de conformité, de performance et d'isolation », a poursuivi M. Gogia.
Le 20 mai, soit à peine plus de quinze jours avant, un incident similaire s’était déjà produit. Il avait duré deux heures et dix minutes et avait affecté 14 services, dont IBM Cloud, Client VPN for VPC, Code Engine et Kubernetes Service, entre autres. Au cours de cette panne globale de la plateforme cloud, les utilisateurs ont essuyé plusieurs échecs lorsqu'ils essayaient de se connecter via l'interface utilisateur (UI), l'interface de ligne de commande (CLI) et même l'authentification basée sur la clé API. « Quand les services de connexion ou d'IAM tombent en panne, les charges de travail critiques peuvent s'arrêter, déclenchant des perturbations en cascade à travers les services et les régions », a expliqué Prabhu Ram, vice-président du groupe de recherche sur l'industrie chez CMR.
Une question sur la résilience du cloud à se poser
De telles perturbations récurrentes mettent en évidence des implications plus larges de la stratégie informatique de l'entreprise, ce qui amène souvent les entreprises à se concentrer sur l'amélioration de la résilience de leur cloud au-delà des contrats avec les fournisseurs. « Pour atteindre une véritable résilience, les entreprises doivent s’employer en priorité à mettre en place des protections techniques solides, telles que des stratégies multi-cloud et des architectures géo-distribuées, et opter pour des protections contractuelles solides, y compris des accords de niveau de service (SLA) complets. Même si une seule panne n'entraîne pas nécessairement un changement immédiat, des pannes répétées ou une réponse inadéquate aux incidents peuvent obliger les entreprises à diversifier leurs fournisseurs de services cloud », a ajouté M. Ram.
Selon M. Gogia, aujourd'hui, le renforcement de la résilience va bien au-delà du stockage de secours et des centres de données secondaires. « Les entreprises investissent désormais dans l'observabilité multicouche, les outils d'orchestration multiplateforme et les voies d'accès secondaires qui restent disponibles même en cas d'interruption de la plateforme du fournisseur. Cela peut impliquer l'hébergement de portails d'administration légers en dehors du fournisseur principal, le déploiement d'une télémétrie en miroir dans une région distincte ou l'utilisation d'une gestion DNS indépendante. » Sans être catastrophiques, ces exemples récents de pannes du cloud constituent des tests de résistance utiles pour identifier les points faibles de l'architecture et de la politique.