Il faut systématiquement identifier l'incident pour pouvoir le résoudre.
Le but est de déterminer pourquoi quelque chose ne fonctionne pas comme prévu et de savoir comment résoudre l'incident.
La première étape du processus d'identification des incidents consiste à décrire l'incident de manière exhaustive. Sans description de l'incident, ni vous-même ni IBM® ne saura par où commencer pour en trouver la cause. Pendant cette étape, vous devez vous poser des questions de base, telles que :
- Quels sont les symptômes de l'incident ?
- Où l'incident s'est-il produit ?
- Quand l'incident s'est-il produit ?
- Dans quelles conditions l'incident s'est-il produit ?
- L'incident peut-il être reproduit ?
Généralement, les réponses à ces questions vous permettent de décrire correctement l'incident, point de départ vers sa résolution.
Quels sont les symptômes de l'incident ?
Lorsqu'on commence à décrire un incident, la première question qui vient à l'esprit est "Quel est le problème ?" Cela semble être une question directe, que vous pouvez cependant diviser en plusieurs questions plus spécifiques, ce qui crée une image plus descriptive de l'incident. Parmi ces questions, on trouve :
- Qui, ou quoi, a généré l'incident ?
- Quels sont les codes et les messages d'erreur ?
- Comment le système est-il tombé en panne ? Par exemple, y a-t-il eu une boucle, un blocage, une panne, une performance diminuée ou un résultat incorrect ?
- Quelle est l'impact de l'incident sur votre activité ?
Où l'incident s'est-il produit ?
Déterminer le lieu d'origine de l'incident n'est pas toujours facile, mais c'est l'une des étapes les plus importantes dans sa résolution. Plusieurs couches de technologie peuvent exister entre les composants générés et les composants défectueux. Les réseaux, les disques durs et les pilotes sont les seuls composants à examiner lorsque vous recherchez la cause des incidents.
Les questions suivantes peuvent vous aider à mettre en évidence le lieu d'origine de l'incident afin d'en isoler la couche.
- L'incident est-il spécifique à une plateforme ou système d'exploitation, ou bien est-il commun à plusieurs plateformes ou systèmes d'exploitation ?
- L'environnement et la configuration actuels sont-ils pris en charge ?
- L'application s'exécute-t-elle sur le serveur local de la base de données ou sur un serveur éloigné ?
- Une passerelle est-elle impliquée ?
- La base de données se trouve-t-elle sur des disques individuels ou sur un ensemble de disques RAID ?
Gardez à l'esprit que, même si une couche peut générer l'incident, cela ne signifie pas pour autant que l'incident trouve son origine dans cette couche. Une partie de l'identification du lieu d'origine de l'incident consiste à comprendre l'environnement dans lequel il se trouve.
Prenez le temps de décrire de manière exhaustive l'environnement de l'incident, en indiquant le système d'exploitation, sa version, tous les logiciels et versions correspondants et les informations du matériel. Vérifiez que votre exécution se trouve bien dans un environnement qui est une configuration prise en charge ; beaucoup d'incidents sont liés à des niveaux de logiciel incompatibles qui ne sont pas prévus pour s'exécuter ensemble ou qui n'ont pas été correctement testés ensemble.
Quand l'incident s'est-il produit ?
Créez un tableau chronologique des événements qui ont conduit à un incident, particulièrement les cas uniques. Cela se fait facilement en travaillant en amont : démarrez au moment où une erreur s'est produite (en détaillant à la milliseconde) et reculez dans le temps grâce aux journaux et au informations disponibles. De manière générale, vous pouvez arrêter lorsque vous trouvez le premier événement douteux dans un journal de diagnostic ; cependant, ce n'est pas toujours chose aisée et cela demande de l'entraînement. Savoir quand arrêter de chercher est particulièrement difficile quand plusieurs couches de technologie sont impliquées et que chacune d'elles a ses propres informations de diagnostic.
Pour créer un tableau chronologique des événements, essayez de répondre à ces questions :
- L'incident se produit-il seulement à un moment du jour ou de la nuit ?
- A quelle fréquence l'incident se produit-il ?
- Quelle série d'événements a conduit au moment du rapport de l'incident ?
- L'incident s'est-il produit après une modification de l'environnement, telle qu'une mise à jour ou une installation de logiciel ou de matériel ?
- Questions spécifiques au produit
Répondre à de telles questions peut vous aider à fournir un cadre de référence pour examiner l'incident.
Dans quelles conditions l'incident s'est-il produit ?
Pour identifier l'incident, il est également important de connaître les autres systèmes et applications en cours d'exécution lorsque l'incident se produit. Ces questions sur votre environnement peuvent vous aider à identifier la cause initiale de l'incident :
- L'incident se produit-il toujours lors de l'exécution de la même tâche ?
- Faut-il qu'une série particulière d'événements se produise pour que l'incident apparaisse ?
- D'autres applications échouent-elles au même moment ?
- Questions spécifiques au produit
Répondre à ce genre de questions vous aide à expliquer l'environnement dans lequel l'incident se produit et à mettre en relation des éléments dépendants. Gardez à l'esprit que ce n'est pas parce que que plusieurs incidents se produisent en même temps qu'ils sont automatiquement liés.
L'incident peut-il être reproduit ?
A partir d'un point d'identification d'incidents, l'incident "idéal" serait un incident qu'on pourrait reproduire. De manière générale avec des incidents qu'on peut reproduire, vous avez à votre disposition une grande variété d'outils et de procédures qui aident à étudier l'incident.
Par conséquent, les incidents qu'on peut reproduire sont souvent faciles à déboguer et à résoudre. Cependant, les incidents qu'on peut reproduire ont un inconvénient : si le problème a un impact significatif sur votre activité, vous ne voulez pas le reproduire !
Si possible, recréez l'incident dans un environnement de test ou de développement qui vous offre plus de flexibilité et de contrôle pendant votre étude.
- L'incident peut-il être reproduit sur une machine de test ?
- Plusieurs utilisateurs ou applications rencontrent-ils le même type d'incident ?
- L'incident peut-il être reproduit en exécutant une simple commande, un ensemble de commandes, une application particulière ou une application autonome ?
- Questions spécifiques au produit