Passez en mode collaboratif et oubliez le mode « Mean Time to Innocence »

Qu’est ce que le « Mean Time to Innocence » ? 

Cela désigne le fait que votre objectif principal est de prouver que vous n’êtes pas coupable, si quelque chose ne va pas !
Nous pouvons considérer que c’est une variante politiquement correcte de l’expression « CYA – Cover Your A… » (ou littéralement couvrir ses fesses).

L’idée est d’avoir un outil, dont l’usage principal (indépendamment de son « objectif officiel ») est de prouver que vous n’êtes en aucune façon responsable du problème (défaillance, ralentissement, plainte de l’utilisateur) qui a eu lieu dans votre infrastructure.

Parfois, même si personne ne veut l’admettre, du moins officiellement, ce peut être la vraie motivation de l’achat du produit.

Les symptômes du syndrome, « Mean Time to Innocence »

Quand les équipes sont plus dans un fonctionnement conflictuel / compétitif que coopératif, , vous verrez des tactiques telles que :

• L’équipe réseau veut prouver que ce n’est pas le réseau 
• L’équipe virtualisation veut prouver que ce n’est pas la virtualisation 
• L’équipe système veut prouver que ce n’est pas le système
• L’équipe applicative veut prouver ce n’est pas l’application 
• L’équipe de base de données veut prouver que ce n’est pas la base de données 
• L’équipe de stockage veut prouver que ce n’est pas le stockage 

Chaque équipe jette un œil à son propre outil. Toutes les équipes vont chercher (le moins longtemps possibles) les causes de dégradation récurrentes : 

• Connexion, retransmission, problèmes TCP…
• Mauvaises allocations de ressources, hôtes surchargés, problèmes de déplacements de machines virtuelles …
• Mises à jour logicielles mal appliquées, politiques obsolètes, problèmes de pilotes ou firmware …
• Des erreurs applicatives, temps de réponse des applications lents, problèmes de consommation de ressources … 
• Sollicitations des bases de données, erreurs SQL, requêtes lentes, …
• Saturations entrée / sortie, politique d’équilibrage de lecture / écriture, problèmes liés aux mécanismes de mise en cache…

Quelles sont les conséquences?

Les réunions au sein de la DSI deviennent désagréables, chacun essaye de prouver son innocence et finalement rejette la faute sur l’une des autres équipes plus ou moins au hasard, selon les affinités, bien plus que sur des raisons techniques réelles et objectives.

Finalement chacun aura réussi à prouver son innocence. Et alors ? Le problème est toujours là…
Je vous laisse imaginer l’ambiance lors de la prochaine réunion sur le même sujet !

Pour vos utilisateurs et vos clients, le temps passé et votre organisation perd de la productivité et des revenus !

Cette approche d’autojustification peut sembler triste, mais elle est réelle ! Certains l’affichent même directement sur leurs t-shirts : « It’s not the network! », écrit de manière visible. Dans ces cas, les gens ont tendance à oublier que la vraie priorité est de délivrer un service optimal pour leurs utilisateurs ou clients et non pas juste à prouver qu’ils ne sont pas fautifs si quelque chose ne va pas.

Comment parvenir à un travail collaboratif, efficace, dans une bonne ambiance de travail?

Les départements informatiques doivent se débarrasser de ces approches de troubleshooting qui consistent à montrer du doigt le coupable. Il est préférable d’adopter une approche de dépannage basée sur la coopérationpour que les résolutions soient les plus rapides et efficaces possibles.

En conclusion, partager des analyses de performances entre les équipes informatique (réseau, systèmes, applications, bases de données) peut s’avérer facile. Il est juste nécessaire d’aller dans la bonne direction pour résoudre les dégradations de performances informatiques.