WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Présentation de l'identification et de la résolution des incidents

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 :

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 ?

concept Rubrique concept

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/ctro_how.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).