L'identification des incidents est une approche systématique de résolution des incidents.
L'objectif est de déterminer pourquoi quelque chose ne fonctionne pas comme prévu et comment y
remédier.
La première étape du processus d'identification des incidents consiste à décrire l'incident de façon
exhaustive. Si aucune description de l'incident n'est fournie, ni vous ni IBM® n'êtes en mesure de savoir comment
identifier l'origine de l'incident. Cette étape implique que vous vous posiez des questions de base
comme :
- Quels sont les symptômes de l'incident ?
- Où l'incident se produit-il ?
- Quand l'incident se produit-il ?
- Dans quelles conditions l'incident se produit-il ?
- L'incident peut-il être reproduit ?
Les réponses à ces questions permettent généralement une bonne description de l'incident et cela
constitue la meilleure méthode pour commencer à le résoudre.
Quels sont les symptômes de l'incident ?
Lorsque l'on commence
à décrire un incident, la question la plus évidente est : "Quel est le problème ?" Cela peut sembler une question simple ; cependant, vous pouvez la fractionner en
questions plus ciblées qui permettent de dégager un tableau plus descriptif de l'incident. Par
exemple :
- Qui, ou qu'est-ce qui, fait état de l'incident ?
- Quels sont les codes d'erreur et les messages générés ?
- Quel type d'échec le système rencontre-t-il ? Par exemple, fonctionne-t-il en boucle ? Connaît-il un
blocage, un arrêt brutal, une dégradation des performances ? Génère-t-il des résultats incorrects ?
- Quel est l'impact de l'incident sur l'activité ?
Où l'incident se produit-il ?
Déterminer l'endroit où se produit l'incident n'est pas toujours chose facile, mais c'est une des
étapes les plus importantes. Plusieurs couches technologiques peuvent se trouver entre les composants
rapportant l'incident et les composants défectueux. Réseaux, disques et pilotes de périphérique ne sont que
quelques-uns des composants à examiner pour rechercher des solutions.
Les questions suivantes peuvent vous aider à trouver l'emplacement de l'incident afin d'isoler la
couche responsable.
- Est-ce que l'incident est spécifique à une plateforme ou un système d'exploitation ou est-il
présent sur plusieurs plateformes ou systèmes d'exploitation ?
- L'environnement et la configuration en cours sont-ils pris en charge ?
Souvenez-vous que si l'incident est consigné pour une couche, cela ne signifie pas nécessairement que cette couche en est à l'origine. L'identification, au moins partielle, de l'origine d'un incident repose
sur la compréhension de l'environnement utilisé. Prenez le temps de décrire complètement
l'environnement de l'incident, notamment le système d'exploitation, sa version, les logiciels et leurs
versions, le matériel. Vérifiez que la configuration du système est prise en charge ; souvent, les
incidents sont dus à des logiciels incompatibles ou qui n'ont pas été testés complètement ensemble.
Quand l'incident se produit-il ?
Etablissez un tableau chronologique des événements aboutissant à un échec, surtout pour ceux qui ne
se produisent qu'une fois. Pour cela, le plus simple est de procéder rétrospectivement : commencez au
moment où l'erreur a été mentionnée (aussi précisément que possible, au niveau de la milliseconde
éventuellement), puis remontez dans le temps en vous aidant des journaux et des informations
disponibles. Généralement, vous devrez seulement remonter au premier événement suspect mentionné dans
un journal ; cependant, cela n'est pas toujours chose aisée et demande une certaine expérience. Savoir
où s'arrêter est particulièrement difficile lorsque plusieurs couches technologiques sont impliquées
et que chacune dispose de ses propres informations de diagnostic.
Pour établir un tableau chronologique détaillé des événements, répondez aux questions suivantes :
- L'incident se produit-il à un moment précis du jour ou de la nuit ?
- A quelle fréquence survient-il ?
- Quelle séquence d'événements a précédé le moment où l'incident a été rapporté ?
- L'incident se produit-il après une modification de l'environnement, comme l'installation de
logiciels ou de matériel, ou leur mise à niveau ?
La réponse à ces questions peut vous aider à définir un cadre de référence dans lequel vous
effectuerez vos recherches.
Dans quelles conditions l'incident se produit-il ?
Savoir quels autres systèmes et applications s'exécutent au moment où l'incident survient est
important pour l'identifier. Ces questions, parmi d'autres, peuvent vous aider à identifier l'origine profonde de l'incident :
- L'incident se produit-il toujours lors de l'exécution d'une même tâche ?
- Est-ce qu'une séquence d'événements déterminée doit se produire pour que l'incident
apparaisse ?
- D'autres applications échouent-elles au même moment ?
La réponse à ce type de questions vous permet d'expliquer l'environnement dans lequel l'incident se
produit et de mettre en lumière d'éventuelles dépendances.
N'oubliez pas que même si plusieurs
incidents se produisent à peu près en même temps, ils ne sont pas liés pour autant.
L'incident peut-il être reproduit ?
Dans le cadre de l'identification des incidents, l'incident "idéal" est celui que l'on
peut reproduire. En effet, dans ce cas, vous disposez d'un plus large choix d'outils et de
procédures pour faire vos recherches. Par conséquent, les incidents reproductibles sont
souvent plus faciles à déboguer et à résoudre.
Cependant, les incidents reproductibles peuvent avoir
un inconvénient : s'ils ont une incidence importante sur l'activité de votre entreprise, vous ne
voudrez pas les voir se reproduire ! Si possible, recréez l'incident dans un environnement de tests ou de développement qui vous offre
généralement plus de souplesse et de contrôle.
Conseil : Simplifiez le scénario afin d'isoler l'incident sur le composant qui semble être à
l'origine de cet incident.
Les questions suivantes peuvent vous aider à reproduire l'incident :
- L'incident peut-il être reproduit sur une machine de tests ?
- Plusieurs utilisateurs ou plusieurs applications rencontrent-ils le même type d'incident ?
- Est-ce que l'incident peut être reproduit en exécutant une seule commande, un ensemble de
commandes, une application particulière ou une application autonome ?