La ligne de code qui coupa le téléphone

Un réseau conçu pour ne jamais tomber

À la fin des années 1980, le réseau longue distance d'AT&T reposait sur 114 commutateurs électroniques appelés 4ESS, répartis dans tout le pays et reliés par un réseau de signalisation, le CCS7. Chacun pouvait router des centaines de milliers d'appels par heure. Le système était pensé pour la fiabilité : si un commutateur tombait, ses voisins reprenaient le trafic. C'est cette redondance, paradoxalement, qui a permis à la panne de se propager.

L'étincelle

Le 15 janvier, en début d'après-midi, un commutateur de New York détecte une anomalie sur un équipement et lance sa procédure de récupération : il se réinitialise, ce qui prend quatre à six secondes, et prévient les autres qu'il n'accepte plus de trafic. Jusqu'ici, tout est normal — c'est exactement le comportement prévu. Le problème survient quand ce commutateur revient en service et annonce son retour aux autres.

Le défaut, précisément

Quand un commutateur voisin recevait ce message de retour, il commençait à mettre à jour son état. Si un second message arrivait moins de dix millisecondes après le premier, alors que le traitement du premier n'était pas terminé, le programme aurait dû mettre ce second message en attente. Au lieu de cela, à cause d'une instruction break mal placée dans une branche else, il sortait prématurément du traitement et écrasait des données critiques en mémoire. Le logiciel de correction détectait l'écrasement et déclenchait… une réinitialisation du commutateur.

switch (message) {
  case INCOMING_MESSAGE:
    if (sending_switch_out_of_service) {
      if (ring_write_buffer_empty)
        send_in_service_to_status_map();
      else
        break;   /* <-- sort du switch trop tot : ecrase les donnees */
    }
    process_incoming_message();
    break;
}

La cascade

Le piège est là : en se réinitialisant, le commutateur touché renvoyait à son tour un message de retour à ses voisins. Si l'un d'eux recevait deux messages trop rapprochés, il subissait le même écrasement, se réinitialisait, et propageait le message à l'étape suivante. La panne se répandait donc par le mécanisme même censé la corriger. Comme les 114 commutateurs exécutaient le même logiciel — déployé mi-décembre, passé au travers de tous les tests et resté invisible pendant les fêtes — la réaction en chaîne s'est propagée à l'ensemble du réseau.

La sortie de crise, contre-intuitive

On aurait pu croire qu'il fallait relancer les commutateurs. C'est l'inverse qui a fonctionné : les ingénieurs ont réduit la charge de messages sur le réseau CCS7. Avec moins de messages, les commutateurs cessaient de recevoir ces paires trop rapprochées, pouvaient enfin terminer leurs réinitialisations, et le réseau s'est stabilisé. Le correctif logiciel définitif a été déployé ensuite.