PCA : examinons bien les risques informatiques !

"Avant de guérir, il faut prévenir" dit le bon sens populaire.

Nous voyons de plus en plus des exploitations informatiques pour lesquelles la prévention est insuffisante. Les implémentations techniques, les choix réalisés et les méthodes d'exploitation ne permettent pas de fiabiliser l'exploitation.

Le risque d'interruption -potentiellement longue- est alors élevé. Toute mise en place d'un PCA (ou PCIT dans ce cas) doit être précédée par une analyse de la situation et le choix d'actions de réduction des risques.

Ces exploitations défectueuses présentent souvent les mêmes caractéristiques, listées ci-dessous.

Telle application exigeante en disponibilité tourne sur un simple serveur x-86 d'entrée de gamme où rien n'est redondé. Des éléments vitaux tels que l'alimentation, les branchements électriques et réseaux, la ventilation, etc. sont en un seul exemplaire. Le point unique de défaillance est constitué. Cette situation caricaturale se rencontre encore.

Plus sophistiqué mais plus dangereux car très pernicieux : tout est en double mais mal associé, par exemple :

• il y a deux alimentations sur deux prises, mais celles-ci aboutissent à la même armoire ou au même point d'alimentation

• le cluster actif-actif est réel ; mais il est malheureusement installé dans la même salle alors qu'il y en a deux indépendantes à disposition

• les connexions réseaux sont doublées mais passent par le même cheminement de câble

• le serveur est très résiliant, mais il n'y a pas de protection électrique par un générateur par exemple : le serveur ne tombera pas en panne...mais n'aura plus de courant pour fonctionner.

L'exploitant pense qu'il n'a pas de point unique de défaillance, alors qu'ils sont nombreux mais pernicieusement rendus invisibles.

Ces situations sont plus nombreuses qu'on le croit. Elles représentent un paradoxe : on a investi dans de la fiabilité mais on obtient de la non fiabilité coûteuse. "On aurait pu faire aussi mal à moins cher" entend-on parfois.

Souvent dues à l'absence de vision générale, des anomalies peuvent surgir :

• le SGBD fabrique bien une 'redo log' mais celle-ci demeure sur les mêmes disques que la base de données ; en cas de crash disque tout est perdu

• les sauvegardes sont faites mais restent dans la même salle dans un dérouleur situé dans le rack voisin : un simple feu et les données et leurs back-ups s'envolent

• la base de donnée centrale grossit : on ne peut plus la sauvegarder comme autrefois, car cela prend trop de temps : impossible de revenir en arrière

• de nombreux échanges de fichiers ont lieu, mais il n'y a pas de vision centrale de 'qui envoie quoi à qui' ; en cas de panne, ce serait un casse-tête épouvantable pour repartir sur des bases saines.

En 'toute bonne foi' l'exploitant se trouve confronté en cas de petit sinistre à des pertes graves.
L'absence de réflexion sur les risques et vulnérabilités amène à ces situations très délicates et peu perçues par l'exploitant.

Il faut absolument résoudre ces problèmes, avant même de penser à un PCIT, sauf à investir dans des secours inutiles.

Cette situation est la plus difficile - surtout si elle vient se superposer aux deux précédentes !

Il serait possible d'écrire un livre sur les erreurs à ne pas faire en exploitation ; citons cependant trois cas assez courants :

1 -Les machines de production ne sont pas protégées : les personnels pouvant intervenir dessus ne sont pas listés et pire, leur champ d'action n'est pas délimité. C'est la porte ouverte à l'erreur ou à la maladresse : telle machine est arrêtée à la place d'une autre ("je croyais qu'elle était en panne...")

2 -Les évolutions nécessaires ne sont pas faites : qu'elles soient logicielles (se tenir à jour) ou matérielles (prévenir les pannes), aucune évolution n'est répercutée. C'est souvent le cas des développements maisons ou des matériels spécifiques. Au bout d'un certain temps c'est la paralysie par impossibilité d'évoluer.

3 -La surveillance insuffisante : bien sûr on peut voir que telle lampe est verte et pas rouge (mais uniquement en heure ouvrable...) mais la vision applicative ou du service au client est complètement absente. Les pannes de service ne remontent pas d'alerte et tardent à être découvertes par l'exploitant. Il faut deux cents appels énervés au help-desk (conforme ITIL par ailleurs...) pour que l'exploitant se demande s'il n'y a pas un incident grave qui arrête le service.

Ces trois exemples sont caractéristiques de mauvaises règles d'exploitation qui vont conduire à nombres d'arrêts de production qui ne se traiteront pas par un PCA ou PCIT.

La moralité de tout cela est qu'il faut en permanence trouver un équilibre entre la prévention et la réaction.

La prévention passe par des comportements bien ancrés dans la pratique :

• choisir et implémenter dans la durée des configurations correctes

• appliquer des règles de bonnes pratiques pour les choix techniques

• déterminer les bonnes disciplines en exploitation et les faire respecter

Il est clair que l'application de tout cela à une exploitation fragile n'est pas simple et nécessite du temps et des efforts.

C'est à ce prix que l'on pourra enfin parler de production de service et commencer à mettre en place une réaction sensée face aux sinistres : le PCA.