Ma vision pour résoudre les problèmes qui durent

J’ai la chance que l’on me confie souvent des problèmes complexes à résoudre, qui durent en général depuis pas mal de temps, et où plusieurs personnes s’y sont déjà, comment dire… »cassé les dents » ?

Je parle bien de chance, car c’est à travers ces expériences que j’apprends souvent le plus. Toutes les solutions classiques ont déjà été essayées plusieurs fois, et il faut donc « innover » pour trouver le grain de sable, le petit détail qui va faire la différence !

Voici les quelques règles/approches que j’applique :

• Ne pas se faire expliquer tout ce qui a été essayé. On construit un diagnostic à partir d’hypothèse, que l’on vérifie, et dont on considère ensuite les résultats comme réputés « surs ». Il va ensuite se passer un long moment avant que l’on remette en question ces résultats et que l’hypothèse soit évaluée à nouveau. Si la personne qui a passé X jours ou heures dessus vous explique tout ce qu’elle a fait et les résultats qu’elle a eu, et qu’elle est convaincante, vous allez vous aussi construire ensuite à partir de ces informations et arriver à la même impasse. Il peut s’avérer que certains résultats soient erronés, ou qu’ils soient arrivés avec un concours de circonstance ou ne soient plus d’actualité. Vous avez la chance unique d’avoir un regard neuf, absent de tout cela. Et vous n’avez qu’un essai, car vous allez vous aussi émettre bientôt des hypothèses et rentrer dans l’entonnoir ! L’inconvénient est que vous allez certainement perdre du temps en essayant des choses qui ont déjà été testées à maintes reprises, mais c’est le prix à payer pour résoudre le problème. L’objectif est de comprendre juste le problème.
• Avoir accès à tout ce qui est nécessaire. Il est crucial de pouvoir s’incruster dans toutes les couches (système/réseau/sécurité), afin de comprendre l’ensemble. Bien sûr cela se complique avec la taille de la structure et sa segmentation. Cela passe parfois par des ruses techniques afin de ne devoir attendre une validation organisationnelle ou technique.
• Pouvoir reproduire le même le test ou scénario. Pour vérifier les idées et hypothèses, il faut valider le changement de comportement ou non en fonction des modifications, et donc pouvoir reproduire le problème à volonté.
• Utiliser ses propres outils. Vous travaillez tout le temps avec Wireshark et là il n’y a que Network Monitor ? Il faut se battre pour utiliser ce que vous connaissez, pour plusieurs raisons. Déjà c’est un gain de temps immédiat. Un outil n’a d’intérêt que si l’on sait s’en servir. Aucun doute que l’on peut arriver au même résultat avec 2 outils, mais il faut être parfaitement à l’aise, afin de se concentrer sur que l’on voit (dans l’exemple, les paquets réseaux), et non pas sur comment mettre un filtre pour masquer ou afficher certains détails.
• Valider les hypothèses majeures 2 fois et par deux outils si possible. Se tromper sur une hypothèse de ce type, et on risque de ne pas trouver avant longtemps. Si l’on construit d’après des connaissances d’une version précédente (sous Windows 2003 ça fonctionnait comme cela) alors qu’on est sur du Windows 2008, vérifier la documentation officielle pour entériner l’hypothèse.
• Ne pas hésiter à générer des erreurs. Si l’on pense qu’un paramètre est complètement hors de cause, ne pas hésiter à le rendre faux et valider qu’il n’impacte toujours pas le problème.

Comme tout « sport », on prend des réflexes au fur et à mesure 🙂

Et vous, comment résolvez-vous vos problèmes ?

Le mot de la fin : Si vous aussi vous avez des cadavres et autres problèmes de préférence « insolubles », pensez à moi !