Des bugs de mémoire ont fait tomber le commutateur central de Salesforce et son basculement - 900 000 abonnés privés d'accès

Le 6 janvier 2009, salesforce.com est devenu inaccessible. À partir de 20 h 39 UTC (environ midi heure du Pacifique), les clients ne pouvaient plus se connecter ni accéder à leurs données CRM ; The Register a rapporté que plus de 900 000 abonnés étaient privés d'accès aux applications avec lesquelles ils font tourner leur activité. Business Insider a estimé la panne totale entre 30 et 40 minutes. Pour une entreprise dont l'argument était que les sociétés pouvaient lui confier leurs données les plus importantes dans son cloud, la majeure partie d'une heure de défaillance totale est survenue pendant la journée de travail.

L'explication de Salesforce, publiée par la suite : « un équipement réseau central est tombé en panne en raison d'erreurs d'allocation de mémoire. La panne l'a empêché de continuer à transmettre des données, mais n'a pas déclenché correctement un basculement transparent vers le système redondant, car les erreurs d'allocation de mémoire étaient également présentes sur le système de basculement. » Autrement dit, l'équipement redondant est tombé en panne de la même manière que l'équipement principal, et la plateforme a dû être rétablie par des étapes manuelles.

L'incident a également révélé une défaillance de second ordre. Le tableau de bord public de statut « trust » de Salesforce - la page qui fait la promotion de sa fiabilité - était hors service en même temps que le produit, si bien que les clients ne pouvaient pas savoir s'ils étaient les seuls touchés. Des centaines de personnes se sont tournées vers Twitter pour confirmer la panne, une démonstration précoce que, lorsqu'une plateforme SaaS tombe, sa couche de communication tombe avec elle, à moins qu'elle ne soit délibérément maintenue hors de la zone d'impact.

Environ 40 minutes de défaillance totale du service pour plus de 900 000 abonnés, en pleine journée de travail, sans basculement fonctionnel.

L'équipement de basculement présentait le même défaut d'allocation de mémoire que l'équipement principal défaillant, de sorte que le chemin « redondant » n'a jamais pris le trafic.

Le basculement ne s'est pas déclenché de manière transparente ; le rétablissement complet du service a nécessité des étapes de récupération manuelles de la part de l'équipe d'exploitation.

Le tableau de bord public de confiance se trouvait dans le même domaine de défaillance, laissant les clients dans l'aveuglement et les poussant à diagnostiquer eux-mêmes la panne sur Twitter.

Une redondance construite à partir de composants identiques hérite de défauts identiques. Si l'unité de secours présente le même défaut que l'unité principale, elle est un miroir, pas une marge - il faut diversifier le chemin de basculement.

Salesforce a publié son explication sur le site de confiance, a indiqué que la cause racine avait été « traitée par le contournement » et que son équipe continuerait à travailler avec les fournisseurs de matériel pour détailler la cause racine et identifier d'autres correctifs. The Register et la presse économique ont présenté la panne comme la « doublure sombre » du cloud computing pour une entreprise qui vendait la disponibilité comme son avantage principal face aux logiciels CRM installés. Les observateurs de la fiabilité en ont tiré une leçon différente : tout tombe en panne, et ce qui distingue les opérateurs, c'est de savoir si les clients peuvent découvrir ce qui se passe - c'est la communication, et non la disponibilité, qui a fait défaut.