Introduction à l'identification des problèmes

Quels sont les symptômes du problème ?

Les questions suivantes permettent de créer une description du problème :

• Par qui ou par quoi le problème est-il signalé ?
• Quels sont les codes et les messages d'erreur ?
• Comment se produit la défaillance du système ? (par exemple, boucle, blocage, panne totale, dégradation des performances, résultat erroné) ?
• Quel est l'impact sur l'activité ?

Où le problème se produit-il ?

Il n'est pas toujours facile de déterminer où le problème prend sa source, mais c'est l'une des phases les plus importantes pour la résolution des problèmes. Un grand nombre de couches peuvent en effet être présentes entre le composant qui signale le problème et le composant effectivement défaillant. Les réseaux, les disques et les pilotes figurent parmi les composants à examiner lorsque vous travaillez sur des problèmes.

Les questions suivantes vous aident à vous concentrer sur l'endroit où le problème se produit afin d'isoler la couche du problème :

• Le problème est-il spécifique à une plateforme ou un système d'exploitation, ou est-il commun à plusieurs plateformes ou systèmes d'exploitation ?
• L'environnement et la configuration en cours sont-ils pris en charge ?
• Une passerelle est-elle impliquée ?

Rappelez-vous que même si le problème n'est signalé que par une seule couche, cela ne signifie pas pour autant que le problème provient de cette couche. L'identification de l'endroit où se produit un problème consiste en partie à comprendre l'environnement de ce dernier. Prenez le temps nécessaire pour décrire de manière complète l'environnement du problème : système d'exploitation, version de celui-ci, ensemble des logiciels correspondants avec leurs numéros de version, et matériel. Vérifiez que l'environnement d'exécution est bien une configuration prise en charge : de nombreux problèmes sont imputables à des niveaux de logiciels incompatibles qui n'ont pas été prévus pour fonctionner ensemble ou dont le fonctionnement concomitant n'a pas encore fait l'objet de tests exhaustifs.

Quand le problème se produit-il ?

Reconstituez la chronologie détaillée des événements qui ont conduit à l'échec, particulièrement dans les cas où le problème ne s'est produit qu'une seule fois. Il est plus facile d'effectuer cette tâche en s'aidant de l'historique. Commencez au moment où l'erreur a été signalée aussi précisément que possible (même à la milliseconde près) et remontez dans les journaux et informations disponibles. Normalement, il vous suffit de remonter dans les journaux de diagnostic jusqu'au premier événement suspect ; cela dit, il n'est pas toujours aisé de détecter ce premier indice et cela demande une certain pratique. Savoir à quel moment s'arrêter est particulièrement ardu lorsque plusieurs couches de technologies interviennent, chacune fournissant ses propres informations de diagnostic.

Pour développer une chronologie détaillée des événements, répondez aux questions suivantes :

• Le problème se produit-il uniquement à un moment précis du jour ou de la nuit ?
• A quelle fréquence se produit-il ?
• Quelle séquence d'événements précède-t-elle l'heure à laquelle le problème est signalé ?
• Le problème se produit-il après une modification de l'environnement, telle que la mise à niveau ou l'installation de logiciels ou de matériels ?

La réponse à ce genre de questions vous fournit un cadre de référence pour analyser le problème.

Dans quelles circonstances le problème se produit-il ?

Il est important de savoir quels étaient les systèmes et les applications en cours d'exécution au moment de la survenue d'un problème pour arriver à le résoudre. Ces questions sur votre environnement vous aident à identifier la cause du problème :

• Le problème se produit-il toujours lors de l'exécution de la même tâche ?
• Une certaine séquence d'événements est-elle nécessaire à l'apparition du problème ?
• D'autres applications subissent-elles une panne au même moment ?

La réponse à ces types de questions vous aidera à décrire l'environnement dans lequel se produit le problème et à faire le rapprochement entre d'éventuelles dépendances. N'oubliez cependant pas que la simultanéité de plusieurs problèmes ne signifie pas nécessairement que ces problèmes sont tous liés les uns aux autres.

Le problème peut-il être reproduit ?

Du point de vue du processus de traitement des incidents, le problème idéal est celui qui peut être reproduit. En général, il existe de nombreux outils ou procédures permettant d'analyser les problèmes reproductibles. Par conséquent, les problèmes pouvant être reproduits sont souvent plus faciles à déboguer et résoudre. Mais ils peuvent présenter un inconvénient : mieux vaut éviter de répéter tout problème ayant un impact négatif important sur l'activité. Dans la mesure du possible, recréez le problème dans un environnement de test ou de développement qui offrent davantage de marge de manoeuvre.

• Le problème peut-il être recréé sur une système de test ?
• Plusieurs utilisateurs ou applications rencontrent-ils le même type de problème ?
• Le problème peut-il être recréé par l'exécution d'une seule commande, d'un ensemble de commandes, d'une application particulière, ou d'une application autonome ?