La première étape du processus consiste à décrire complètement le problème. La description de l'incident vous permet, et permet également au technicien de maintenance IBM, de savoir où commencer à chercher la cause de l'incident. A cette étape, vous devez vous poser les questions de base suivantes :
Les réponses à ces questions permettent généralement de décrire avec précision le problème, ce qui vous permet de le résoudre.
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 sont notamment les suivantes :
Il n'est pas toujours aisé de déterminer où se trouve le problème, mais il s'agit pourtant de l'une des étapes les plus importantes. De nombreuses couches technologiques peuvent exister entre le composant qui signale l'incident et le composant défaillant. Les réseaux, la grille de données et les serveurs ne sont que quelques exemples de composants à prendre en compte lorsque vous cherchez à en savoir plus sur les problèmes rencontrés.
Les questions suivantes vous aident à vous concentrer sur l'endroit où survient le problème pour isoler la couche de problème :
Ce n'est pas parce qu'une couche signale le problème que celui-ci provient obligatoirement de cette couche. Pour identifier l'endroit d'où provient un problème, vous devez comprendre l'environnement dans lequel ce problème se produit. Prenez quelques instants pour décrire complètement l'environnement du problème, notamment le système d'exploitation et sa version, tous les logiciels correspondants et leur version, ainsi que les informations sur le matériel. Vérifiez que la configuration de votre environnement est prise en charge ; de nombreux problèmes peuvent être provoqués par l'utilisation de logiciels incompatibles qui ne sont pas destinés à être exécutés ensemble ou dont l'exécution simultanée n'a pas été testée.
Dressez la liste chronologique des événements qui ont conduit à l'apparition de l'incident, en particulier si l'incident ne s'est produit qu'une seule fois. Vous pouvez très aisément dresser une liste chronologique en procédant à 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.
Pour dresser une liste chronologique détaillée des événements, répondez aux questions suivantes :
En répondant à ces questions, vous définissez un cadre de référence dans lequel mener vos recherches.
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 l'environnement vous aideront à identifier la cause de l'incident :
En répondant à ces questions, vous pouvez décrire l'environnement dans lequel l'incident se produit, et identifier les éventuelles dépendances. 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.
Du point de vue de l'identification et de la résolution, le problème idéal est celui qui peut être reproduit. En général, lorsqu'un problème peut être reproduit, vous disposez 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, garantissant davantage de souplesse et de contrôle lors de l'analyse.