Un bug latent a transformé une maintenance de routine du centre de données de Gmail en une panne mondiale de trois heures

Le 24 février 2009, Gmail est tombé en panne pour des utilisateurs du monde entier. Le rapport d'incident de Google destiné à ses clients Apps situe la perturbation entre environ 9 h et 12 h GMT — soit environ trois heures —, la reprise étant échelonnée de sorte que chaque utilisateur ait perdu l'accès pendant une durée variable. Aucune donnée n'a été perdue.

Le mécanisme résultait de l'interaction entre deux décisions récentes. Google avait déployé un nouveau logiciel destiné à optimiser l'emplacement des données des utilisateurs. Ce matin-là, les ingénieurs ont entamé une maintenance de routine dans un centre de données européen — une opération conçue pour être invisible, puisque le trafic est automatiquement redirigé ailleurs. Mais ce basculement a déclenché un bug latent dans le nouveau code de localisation : la destination a été surchargée et, à mesure que le trafic était automatiquement redirigé, les surcharges se sont propagées en cascade d'un centre de données à l'autre. Les ingénieurs ont mis environ une heure à maîtriser la cascade, et plus longtemps encore à rééquilibrer l'ensemble.

Google a géré les suites de l'incident avec une transparence inhabituelle pour l'époque : Acacio Cruz, responsable de la fiabilité de Gmail, a expliqué la cascade sur le blog officiel de Gmail le jour même, et Google a publié un rapport d'incident formel destiné aux clients Apps. L'entreprise s'est également engagée à créer un outil qui n'existait pas encore pour le service — un tableau de bord public de l'état du service —, reconnaissant qu'un fournisseur de cloud doit à ses clients une information rapide pendant une panne, et non le silence et une correction.

Gmail inaccessible jusqu'à trois heures le 24 février 2009, la reprise étant échelonnée par centre de données ; aucune donnée perdue

Le chemin de basculement — le trafic redirigé vers un second centre de données — n'avait pas été testé face au nouveau logiciel de localisation des données, si bien que le bug latent ne s'est déclenché que pendant la maintenance.

La réaction à la surcharge a amplifié la défaillance : à mesure que les utilisateurs étaient automatiquement redirigés, chaque destination subissait la même condition de surcharge, la propageant en aval.

La conception de la maintenance supposait des transferts propres entre centres de données, mais le nouveau code d'optimisation a modifié les hypothèses sur lesquelles le basculement avait été bâti.

La communication a pris du retard sur l'incident : le propre post-mortem de Google a admis qu'il fallait reconnaître les pannes rapidement, ce qui a directement conduit au tableau de bord d'état des Apps.

Les chemins de basculement méritent autant de tests que les chemins principaux : un nouveau code qui réorganise l'emplacement des données a transformé une maintenance de routine en cascade. Et une panne de cloud appelle la publication d'un rapport d'incident.

Google a corrigé le bug et déployé des changements, publié le rapport d'incident et lancé le tableau de bord d'état de Google Apps quelques semaines plus tard, institutionnalisant ainsi la communication publique sur les pannes. L'épisode « gfail » est devenu un modèle précoce de rapport d'incident cloud — un compte rendu formel, destiné aux clients, des causes et des mesures correctives — à une époque où la plupart des services web grand public n'offraient aucune explication.