Twitter, Royal Bank of Scotland, Orange, O2… Autant de noms associés ces derniers mois à des pannes SI majeures liées à des dysfonctionnements logiciels. Ces derniers restent aujourd’hui complexes à traiter et font souvent office de « parent pauvre » des PRA, qui se focalisent essentiellement sur les incidents matériels.
La panne logicielle : un incident complexe à diagnostiquer et à traiter
Les pannes logicielles sont difficiles à diagnostiquer du fait d’interconnexions toujours plus importantes au sein des systèmes d’information, d’une supervision plus complexe et plus « spécifique » que pour les problèmes matériels ainsi que d’impacts plus diversifiés et difficilement prévisibles.
Le PRA se focalise bien souvent sur les pannes matérielles, dont le traitement suit un principe simple : un matériel de secours remplace, de façon plus ou moins automatique, un matériel défaillant.
Ce principe n’est généralement pas applicable pour les pannes logicielles, plus complexes à traiter, à différents niveaux de la chaîne de liaison applicative :
- Données : la réplication fréquemment utilisée pour traiter des pannes matérielles entraîne la propagation rapide de données corrompues vers les infrastructures de secours. Afin de s’en prémunir, des mécanismes de réplication logicielle peuvent être mis en place afin de pouvoir revenir à des états cohérents exempts de données corrompues. En dernier ressort, la restauration de clones ou de sauvegardes (plus longue) peut être utilisée.
- Systèmes applicatifs : développés en interne par l’entreprise ou par des éditeurs tiers, ils visent à répondre à certains besoins métiers précis. Leur déploiement peut ainsi être limité, ce qui réduit les expertises existantes et le nombre de tests conduits lors des changements, pour raisons économiques. Les premiers à migrer en font parfois les frais ! Par ailleurs, le fait de les placer sur des infrastructures de haute-disponibilité de type cluster ne change pas le problème : si le logiciel dysfonctionne, ce sera sur l’ensemble de l’infrastructure, car il n’est souvent pas possible de faire cohabiter plusieurs versions d’un logiciel sur un même cluster.
- Frontaux : ils utilisent souvent des logiciels largement répandus, extrêmement stables, et sont assez peu souvent à l’origine de problèmes logiciels. Des effets de bord sur les systèmes applicatifs peuvent néanmoins apparaître.
Toutefois, l’entreprise n’est pas totalement démunie face à ce type d’incidents, et peut en réduire le nombre en respectant quelques principes évoqués ci-après.
Porter une grande attention à la gestion des changements critiques
Les incidents récents le confirment une nouvelle fois : la majorité des pannes logicielles majeures interviennent lors de changements. Outre les bonnes pratiques généralement évoquées (tester largement et sur des infrastructures proches de la production, préparer le retour arrière sur les aspects techniques et organisationnels, renforcer les équipes et définir des astreintes, …), l’entreprise doit porter une attention particulière aux changements critiques. Elle doit ainsi :
- Identifier ces changements et les partager largement au sein des équipes ;
- Réduire le nombre de changements critiques simultanés (a fortiori s’ils présentent des interdépendances), afin de ne pas accroître les risques et complexifier le diagnostic ;
- Renforcer le contrôle des opérations très sensibles (deux personnes pour une même manipulation par exemple).
Privilégier les architectures asynchrones
Une certaine dichotomie existe pour le traitement des pannes matérielles et logicielles. Si les architectures synchrones sont bien adaptées aux premières, un asynchronisme peut grandement faciliter le traitement des pannes logicielles.
Les architectures asynchrones permettent en effet de ne pas propager immédiatement les erreurs et de revenir plus facilement dans des états cohérents, puis de rejouer les transactions jusqu’à l’instant de la panne. Le découpage du SI qu’elles induisent permet également d’éviter la panne globale des systèmes, en rendant possible l’interruption de certains composants sans impact immédiat pour les autres.
Se mettre en capacité de gérer les erreurs de manière pro-active
L’incident d’Orange l’a montré : les pannes logicielles peuvent se produire de manière progressive, en surchargeant peu à peu le SI.
La mise en place de systèmes de mesure et de supervision, la définition de valeurs de charges et de temps de réponse normatifs et leur comparaison régulière avec l’état actuel des systèmes peut permettre de prévenir les incidents avant que des indisponibilités majeures ne surviennent.
Orange a en ce sens, contrairement à ce qu’évoquent certains observateurs, bien assuré sa gestion de crise. Nombre de ses ingénieurs ont été mis en alerte après les premiers signes de fléchissement du réseau, et la communication qui a accompagné et suivi la panne a été bien maîtrisée.
Utiliser des méthodes de validation formelle ?
Des méthodes reposant sur la preuve formelle permettent d’assurer la sûreté logicielle. Elles nécessitent des expertises pointues et un processus de développement bien plus lourd et long que les méthodes traditionnelles, et restent aujourd’hui confinées aux systèmes embarqués critiques.
Leur utilisation pour d’autres usages pourra être envisagée, mais le compromis entre coûts de développement et couverture de risques s’avèrera difficile à trouver !
