Duquesne Group Duquesne Group

English version
Blog des experts

Les avis et les commentaires exprimés dans les blogs sont ceux des experts individuels. Ils ne représentent pas nécessairement l'opinion du cabinet. Contactez-nous pour en savoir +
French version
Blogs

In these blogs, individual experts freely express their own opinions and comments. They do not necessarily reflect the opinion of the firm. Contact us to find out more


Panne Orange : premières réactions


Orange a connu une panne massive qui a touché les vingt six millions de clients mobiles de l'opérateur vendredi 6 Juillet, ainsi que les clients des MVNO hébergés et ceux de Free Mobile.

Suite à la conférence de presse de samedi 7/7 quelques éléments ont été rendus publics qui permettent de formuler des hypothèses. Voici les miennes avec mes commentaires.



Difficile de communiquer en cas de crise

Dans toute situation de panne de grande ampleur, la communication est difficile.

On peut néanmoins remarquer qu'Orange a fait preuve de professionnalisme :

  • en communiquant assez vite sur les défauts de service;
  • en cadençant sa communication : des communiqués puis une conférence de presse le samedi;
  • en utilisant judicieusement les lieux : conférence de presse au centre de surveillance.

Les précautions oratoires recommandées en pareil cas (ne pas dire "on ne sait pas" mais "on cherche") étaient respectées.

Les messages principaux émis étaient justes, même s'ils étaient peu précis : "panne logicielle sur un élément de coeur de réseau".

Le coup de la panne... logicielle

Le logiciel incriminé dans la panne est le NG HLR (New Generation Home Location Register).

C'est un système qui centralise les informations de localisation des abonnés. Dans sa nouvelle génération, il est implémenté en architecture 3-tiers : les frontaux, les serveurs centraux et les bases de données (source : conférence de presse de samedi via RT).

Chaque "tiers" est réalisé sur une certain nombre d'éléments techniques répartis sur le territoire et -probablement- correctement redondés.

Sans connaître le détail de la panne, il est possible d'imaginer des désagréments qui peuvent surgir quand un élément commence à dysfonctionner.

En effet, contrairement aux architectures centralisées, les architectures n-tiers sont caractérisées par :

  • des éléments distincts qui collaborent : l'un appelle l'autre via un réseau et attend sa réponse
  • des timers : si la réponse tarde à venir on ré-émet la demande
  • si la réponse finit par arriver alors qu'on a ré-émis la demande : que fait-on ? on la prend ? ou on attend la seconde ?
  • l'élément qui est trop lent dispose d'automatismes pour dérouter les demandes qui lui arrivent vers un autre élément similaire

Comme on le voit dans cet exemple, il est très difficile en cas de lenteur à répondre de la part d'un élément interrogé par tous d'éviter des situations d'augmentation des volumes des messages échangés...et ce, dans des proportions très importantes.

Comme on le comprend dans l'exemple précédent -volontairement simplificateur- un élément central qui ralentit se trouve submergé de demandes qui le mettent à plat ! On se trouve alors face à un système divergeant ! L'abondance des messages échangés dans tous les sens génère un trafic inutile et consommateur qui devient impossible à maîtriser. Il est possible que cela soit cela qu'Orange a vécu.

Pour peu que les messages échangés correspondent à des 'commits' de bases de données (pure spéculation de ma part), l'intégrité peut éventuellement être perdue, nécessitant des retour-arrière sur les bases de données (ce qui est un moindre mal, mais qui pour un réseau mobile provoque la perte de l'abonné qui a bougé entre temps).

Le problème des automatismes de reprise

Un autre point est intéressant à noter dans ce type de situation : la différence entre une optimisation locale et une optimisation globale.

Il est fort probable que les systèmes en place pris individuellement mettent en oeuvre de bonnes pratiques de continuité :

  • les messages sont mis dans des files d'attentes
  • les réceptions sont acquittées
  • les messages non acquittés sont conservés pour être ré-émis s'il le faut
  • tout ceci est journalisé par le système

La conséquence de cela est que lorsqu'on arrête un de ces systèmes et qu'on le redémarre, il se met automatiquement à inspecter les files d'attente et à ré-émettre ce qui n'a pas été acquitté, etc.

Ce comportement est tout à fait judicieux lorsqu'un seul de ces systèmes est en panne et redémarre, mais lorsqu'une proportion importante de systèmes est dans ce cas, le redémarrage peut générer un trafic insurmontable qui ne tarde pas à saturer : c'est le fameux effet "boule de neige" qui fut cité lors de la conférence de presse.

La seule solution pour s'en sortir est de purger les logs ou files d'attente et -au passage- d'accepter des pertes de données. Cette purge nécessite de désactiver les automatismes et donc d'intervenir à la main. Cela prend forcément du temps et il faut de plus coordonner les actions pour redémarrer autant que possible sur un point "propre". Encore une fois, je ne dispose pas des détails mais cette situation semble plausible.

Clairement l'optimisation générale n'est pas la somme des optimisations locales.

On le voit sur cet exemple, ce n'est pas qu'une panne de logiciel, c'est aussi un problème général et très difficile de régulation d'ensemble qui diffère des régulations individuelles.

Des facteurs aggravants

La presse en a peu parlé, mais je vois dans cette panne trois facteurs légèrement aggravants:

Les résultats du bac paraissaient ce jour là quelques instants avant la panne. Or les jeunes concernés ont probablement dû envoyer grand nombre de SMS à leurs connaissances sur une courte période.

Les jeunes en question sont plus que d'autres des adeptes des opérateurs à bas coût : Free (qui emprunte des moyens Orange) ou autre Sosh (filiale Orange) sans parler de Virgin...à chaque fois le SMS ou l'appel peut être amené à passer par des éléments rares du réseau (augmentant le phénomène décrit plus haut).

Enfin les départs en vacances avec les déplacements ont augmenté la perception de la panne par l'usager : en effet celui qui se déplace provoque une mise-à-jour dans la base HLR. Si cette mise à jour est impossible, il devient injoignable et ne peut plus passer d'appels. Malheureusement il va insister et générer des appels supplémentaires nécessitant tous un accès au HLR...

Bien sûr, ces éléments n'expliquent aucunement la panne ; mais ils la situent dans un contexte un peu plus difficile que d'autres jours.

Emmanuel Besluau
Lundi 9 Juillet 2012

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Articles du même auteur :

Halte aux PCA bidons ! - 19/01/2014

1 2