Identification des problèmes dans votre environnement de cloud

Editer en ligne

Le traitement des incidents est une approche systémique de la résolution d'un problème. L'objectif est de déterminer les raisons pour lesquelles quelque chose ne se passe pas comme prévu et la façon de résoudre le problème.

La première étape du processus de traitement des incidents est la description exhaustive de celui-ci. Sans description du problème, ni vous ni IBM® ne pouvez savoir par où commencer pour trouver la cause du problème. Cette étape implique de se poser des questions, comme :

Les réponses à ces questions permettent généralement d'obtenir une bonne description du problème, et c'est la meilleure façon de commencer à résoudre un problème.

Quels sont les symptômes du problème ?

Lorsqu'on commence à décrire un problème, la question la plus évidente est Quel est le problème ? qui peut sembler simple. Cependant, vous pouvez la décomposer en plusieurs questions plus spécifiques afin de brosser un état des lieux plus prescriptif du problème. Ces questions peuvent être :
  • Qui, ou quoi, signale le problème ?
  • Quels sont les codes d'erreur et les messages ?
  • Comment se produit la défaillance du système ? Par exemple, en fonctionnant en boucle, en se bloquant, en se verrouillant, en dégradant les performances ou en fournissant un résultat incorrect ?
  • Quel est l'impact métier du problème ?

Où le problème se produit-il ?

Il n'est pas toujours simple de déterminer l'origine du problème, mais c'est l'une des étapes les plus importantes pour résoudre un problème. De nombreuses couches de technologie peuvent exister entre le signalement et la défaillance des composants.

Rappelez-vous que si une couche signale le problème, le problème ne vient pas forcément de cette couche. Identifier la source d'un problème consiste, entre autres, à comprendre l'environnement dans lequel il existe. Prenez le temps de décrire complètement l'environnement du problème. Les questions ci-dessous peuvent vous aider à préciser l'origine du problème :
  • Si vous disposez de plusieurs abonnements de cloud, lesquels sont concernés ?
  • Quels sont les environnements de serveur de flux de travaux concernés (par exemple, Développement ou Production) ?
  • Quelles sont les applications concernées ?
  • Quelles sont les services appelés par les applications et quelles sont la version de logiciel et les informations matérielles ?

Quand le problème se produit-il ?

Etablissez une chronologie détaillée des événements qui ont conduit à une défaillance, surtout lorsqu'il s'agit d'un problème qui ne s'est produit qu'une fois. Vous pouvez le faire simplement en remontant la chronologie : commencez à l'heure à laquelle une erreur a été signalée (aussi précisément que possible, à la milliseconde près) et remontez dans les journaux et les informations disponibles. En général, vous devez remonter au premier événement suspect que vous trouvez dans un journal de diagnostic. Cependant, ce n'est pas toujours simple et cela demande de la pratique. Il est particulièrement difficile de savoir jusqu'où remonter lorsque plusieurs couches de technologie sont impliquées et lorsque chaque couche possède ses propres informations de diagnostic.

Pour développer une chronologie détaillée des événements, répondez aux questions suivantes :
  • Le problème se produit-il uniquement à un certain moment du jour ou de la nuit ?
  • A quelle fréquence se produit-il ?
  • Quelle séquence d'événements s'est produite juste avant l'heure à laquelle le problème a été signalé ?
  • Le problème se produit-il après un changement d'environnement, comme la mise à niveau ou l'installation de logiciels ou de matériel ?

La réponse à ces types de question peut vous fournir un cadre de référence pour étudier le problème.

Dans quelles conditions le problème se produit-il ?

La connaissance des autres systèmes et applications exécutés lorsqu'un problème se produit constitue une partie importante du traitement des incidents. Ces questions, ainsi que d'autres questions, sur votre environnement peuvent vous aider à identifier la cause principale du problème :
  • Le problème se produit-il toujours lors de l'exécution de la même tâche ?
  • Une séquence d'événements spécifique doit-elle se produire pour que le problème ait lieu ?
  • Une autre application échoue-t-elle au même moment ?

La réponse à ce type de questions peut aider à expliquer l'environnement dans lequel le problème survient et à mettre les dépendances en corrélation. Souvenez-vous que ce n'est pas parce que plusieurs problèmes peuvent s'être produits au même moment qu'ils sont nécessairement liés.

Le problème peut-il être reproduit ?

Du point de vue du traitement des incidents, le problème idéal est celui qui peut être reproduit. En général, avec des problèmes qui peuvent être reproduits, vous disposez de davantage d'outils ou de procédures pour étudier le problème. Les problèmes qui peuvent être reproduits sont souvent donc plus simples à déboguer et à résoudre. Cependant, les problèmes que vous pouvez reproduire s'accompagnent d'un inconvénient : si le problème possède un impact métier important, vous ne souhaitez pas qu'il se reproduise. Si possible, recréez le problème dans un environnement de test ou de développement, qui offre généralement plus de flexibilité et de maîtrise pendant les investigations.
Conseil: Simplifiez le scénario pour isoler le problème sur un composant soupçonné.
Les questions ci-dessous peuvent vous aider à reproduire le problème :
  • Le problème peut-il être reproduit dans d'autres environnements de cloud ? Par exemple, si le problème survient dans l'environnement de développement, se produit-il également dans l'environnement de production ?
  • Plusieurs utilisateurs ou plusieurs applications rencontrent-ils le même type de problème ?