Identification et résolution des problèmes

Quels sont les symptômes de l'incident ?

Lorsque vous commencez à décrire un problème, la question la plus évidente est "Quel est le problème ?" Cette question peut sembler simple ; toutefois, vous pouvez la scinder en plusieurs questions plus concentrées qui permettent d'avoir une vue plus descriptive du problème. Ces questions peuvent inclure les points suivants :

• Par qui ou par quel élément l'incident est-il signalé ?
• Quels sont les messages et les codes d'erreur ?
• Quelle est la nature de la panne du système ? Par exemple, boucle, arrêt, plantage, dégradation des performances, résultat incorrect.
• Quel est l'impact commercial du problème ?

Où le problème se produit-il ?

Il n'est pas toujours aisé de déterminer où se produit l'incident, mais il s'agit pourtant de l'une des étapes les plus importantes. De nombreuses couches technologiques peuvent exister entre les composants signalés et les composants défectueux. Les réseaux, les disques et les pilotes ne sont que quelques-uns des composants à prendre en compte.

Les questions suivantes vous aideront à déterminer la source de l'incident, afin d'identifier la couche qui pose problème :

• L'incident est-il spécifique à une plateforme ou à un système d'exploitation, ou se produit-il sur toutes les plateformes et tous les systèmes d'exploitation ?
• L'environnement et la configuration courants sont-ils pris en charge ?

N'oubliez pas ce n'est pas parce qu'une couche signale le problème que celui-ci provient obligatoirement de cette couche. L'identification de l'origine d'un problème consiste en partie à comprendre l'environnement dans lequel il survient. Prenez le temps de décrire l'environnement de manière aussi détaillée que possible : système d'exploitation et version, logiciels utilisés et versions, informations sur le matériel. Assurez-vous que vous travaillez dans un environnement correspondant à une configuration prise en charge. Bon nombre d'incidents sont liés à l'exécution de versions de logiciels incompatibles, qui ne sont pas prévues pour être utilisées simultanément ou qui n'ont pas été entièrement testées à cet effet.

Quand le problème s'est-il produit ?

Dressez un tableau chronologique des événements survenus jusqu'à l'incident, notamment pour les cas qui ne se produisent qu'une seule fois. Pour ce faire, procédez à l'envers : partez du moment où une erreur a été signalée (aussi précisément que possible, même à la milliseconde près), et remontez en arrière à l'aide des journaux et des informations disponibles. Il vous suffit généralement de remonter jusqu'au premier événement suspicieux signalé dans un journal de diagnostic ; toutefois, cette procédure n'est pas simple à réaliser et demande de la pratique. Il est difficile de savoir quand arrêter la recherche lorsque plusieurs couches de technologie sont impliquées et que chacune de ces couches dispose de ses propres données de diagnostic.

Pour établir la chronologie détaillée des événements, répondez aux questions ci-dessous :

• Le problème se produit-il uniquement à une certaine heure du jour ou de la nuit ?
• Quelle est la fréquence de l'incident ?
• Quelle est la suite d'événements qui conduit au moment où l'incident est signalé ?
• L'incident se produit-il après une modification de l'environnement, par exemple la mise à niveau ou l'installation d'un composant logiciel ou matériel ?

En répondant à ces questions, vous définissez un cadre de référence dans lequel mener vos recherches.

Dans quelles conditions l'incident se produit-il ?

Il est très important de savoir quelles applications et quels systèmes étaient en cours d'exécution lorsque l'incident s'est produit. Les questions suivantes concernant votre environnement vous aident à identifier la cause première de l'incident :

• L'incident se produit-il systématiquement lors de l'exécution d'une tâche particulière ?
• L'incident se produit-il chaque fois suite à une séquence d'événements ?
• Une défaillance apparaît-elle simultanément au niveau d'une ou plusieurs autres applications ?

La réponse à ces questions vous aide à avoir une idée plus claire de l'environnement dans lequel survient l'incident et à mettre en corrélation les dépendances éventuelles. Notez cependant que si plusieurs incidents se produisent de manière quasi-simultanée, cela ne signifie pas nécessairement que ces incidents sont liés.

L'incident peut-il être reproduit ?

Dans le contexte du processus d'identification et de résolution des incidents, l'incident idéal est celui qui peut être reproduit. En effet, vous disposez généralement d'un plus grand nombre d'outils ou de procédures pour en savoir plus sur ces problèmes. Par conséquent, les problèmes que vous pouvez reproduire sont souvent plus faciles à déboguer et résoudre. Toutefois, ces problèmes présentent un inconvénient : si le problème en question a un impact commercial considérable, vous ne voulez pas qu'il se reproduise. Si possible, recréez l'incident dans un environnement de test ou de développement afin de disposer de davantage de souplesse et de maîtrise pendant vos investigations.

• L'incident peut-il être reproduit sur un système de test ?
• Plusieurs utilisateurs ou applications rencontrent-ils le même type d'incident ?
• Le problème peut-il être recréé en exécutant une seule commande, un jeu de commandes, une application particulière ou une application indépendante ?