Étant confronté à de nombreux problèmes sur des systèmes parfois totalement inconnus, parfois partiellement connus, il est nécessaire de procéder de manière logique et consciencieuse pour trouver une solution.
La première étape est de chercher comment reproduire le problème : pouvoir reproduire l’erreur à la demande permet de déterminer les conditions de déclenchement de l’erreur et d’analyser en détail les conditions qui mènent au problème. Enfin cela permettra également de déterminer si la solution mise en œuvre résout le problème ou non.

Pour trouver une solution à un problème, il est nécessaire de rassembler le maximum d’informations pour déterminer quels sont les axes de recherche et actions les plus pertinents. La première source d’information, même si elle paraît évident est l’éventuel message d’erreur qui apparait soit à l’écran directement, ou dans un journal (encore appelé « log »). Il peut être intéressant d’augmenter le niveau de verbosité concernant les messages d’erreur ou les logs dans l’application, afin d’avoir plus d’information ou des informations plus précises. Si la source de l’application est disponible et que le message d’erreur fait référence aux sources, les consulter vous permettra de déterminer plus précisément le contexte de l’erreur, notamment quelle est l’opération en cours pendant l’erreur.

Une fois ces informations récupérées, il est essentiel d’exploiter au mieux les ressources d’information à notre disposition.

La documentation ainsi que la foire aux questions de l’application permettent de se familiariser avec l’application et notamment avec l’éventuelle partie identifiée de l’application qui pose actuellement problème. Il est souvent utile de survoler la documentation, et approfondir les points s’approchant du contenu du message d’erreur.

Les « Howto » permettent souvent de déterminer la signification et une valeur « correcte » d’une directive de configuration, lorsque la configuration est en cause, et d’essayer de modifier cette valeur.

Dès lors qu’on dispose d’un message d’erreur explicite, il y a de grandes chances de pouvoir trouver une solution sur un moteur de recherche, mais encore faut-il savoir correctement chercher. En effet, pour rechercher un message d’erreur sur un moteur de recherche, il convient de ne conserver dans la requête que les éléments significatifs :

• un nom de fichier et le numéro de ligne dans ce fichier tout en supprimant le chemin vers ce fichier qui peut être totalement différent selon les installations
• le nom d’une fonction, en supprimant les paramètres qui sont souvent unique,
• les codes d’erreurs par opposition à un message d’erreur traduit qui limiteraient les résultats de recherches à la langue sélectionnée pour l’application.

De manière générale, rechercher du plus général au plus précis permet d’affiner les résultats de recherche pour trouver une solution sur un forum, un blog ou une liste de discussion.

Dans l’éventualité où la solution n’a pas encore pu être trouvée, il y a encore quelques pistes à explorer. Dans un premier temps, il peut être utile de démarrer le programme en mode « debug » et pousser la verbosité au maximum. Cette solution, aussi applicable aux services et démons permet de connaitre un détail des actions effectuées avant l’apparition du problème, et peut être avoir plus d’éléments permettant d’identifier une solution.

La dernière option à utiliser est celle de tracer l’exécution du service ou programme. Cette solution utilise des outils très verbeux, il est donc nécessaire de pouvoir faire le tri dans une masse d’information importante. Il est généralement nécessaire d’avoir quelques connaissances en développement pour pouvoir juger de la pertinence d’une information. L’outil le plus utilisé pour ce type d’analyse est « strace » sous Linux : cet outil permet de tracer tous les appels systèmes d’une application, de voir les paramètres utilisés et surtout la valeur de retour de ces appels systèmes. Il existe un équivalent sous Windows, appelé Process Monitor développé par Sysinternals. Une fois l’appel système posant problème identifié, en consultant la documentation de cet appel système avec le code de retour sous les yeux il sera possible d’identifier concrètement quelle est l’erreur rencontrée. Il restera ensuite à déterminer pourquoi l’appel système échoue, ce qui sera bien plus facile quand le code d’erreur est connu, car il est souvent plus clair qu’un message d’erreur.

Dans toutes les étapes de la résolution d’un problème, il convient d’essayer de comprendre comment fonctionne le service ou l’application posant problème : de cette manière, la résolution du problème n’en sera que plus évidente, puisqu’elle découlera d’un raisonnement logique.

Il arrive parfois de buter sur un problème. Si la durée de résolution du problème n’est pas une contrainte (c’est malheureusement rarement le cas), il est très souvent utile de revenir à cette tâche plus tard, afin d’avoir un point de vue différent qui facilitera peut-être le déclic pour trouver la solution.

Bonne chance !