Analyse de causes profondes et outils de supervision : Le match parfait
Les analyses de causes profondes et les outils de supervision ont été liés pendant une longue période, mais savez-vous ce que les analyses de causes profondes sont vraiment (ACR) et comment il est appliqué dans le monde de la supervision des applications et des réseaux ?
Les analyses de causes profondes sont une méthode de résolution de problèmes qui tente de résoudre les problèmes de la manière la plus efficace, en les empêchant de se reproduire. Cela nécessite de déterminer la cause première et de prendre des mesures pour l’éliminer.
ACR est essentiellement une méthode réactive. Cela signifie qu’en cas de problème, les procédures ACR commencent à identifier les causes profondes pour éviter que le même problème ne se reproduise. Cependant, une fois qu’il a été implémenté et avec une exécution constante, ACR devient une méthode prédictive de problèmes.
.
Mais l’ACR implique également une procédure de consultation itérative. C’est-à-dire qu’avec un problème bien identifié, nous ferons une première analyse des causes en sachant deux choses ; Tout d’abord, cette première approche n’identifie pas la véritable cause profonde, ce qui rend un processus de requête persistant absolument nécessaire. Une technique d’interrogation itérative qui correspond assez bien à l’ACR et qui peut être citée comme exemple pour le point précédent est la technique des 5 pourquoi, largement utilisée par les enfants ennuyeux.
Lorsque nous rencontrons un problème, nous nous posons une première question : Pourquoi est-il passé ? Nous saurons immédiatement la réponse ; cela s’est produit parce que… « Cause 1 » comme base de la deuxième question : pourquoi la « Cause 1 » s’est-elle produite ? Et ainsi de suite jusqu’à ce que cinq pourquoi soient complétés. En théorie, la « cause 5 » est la cause profonde. Au-delà de cette technique, l’idée est que, pour être efficace, l’ACR doit se faire systématiquement, en approfondissant le problème jusqu’à ce que la cause profonde soit atteinte. Pour continuer à évoquer les bases de la mise en œuvre de l’ACR, il faut prendre en compte ces trois points saillants :
- Définir et décrire correctement le problème. Il est important de définir le problème ou de décrire l’événement avec des faits. Y compris la magnitude, l’emplacement et l’heure. La conclusion est simple : la première chose à faire est de comprendre le problème.
- Établissez une chronologie de la situation normale jusqu’à l’échec. L’idée est de visualiser chaque comportement, condition et action liés au problème, dans une séquence chronologique.
- Faire la distinction entre le facteur causal et les causes profondes. En regardant la chronologie, vous devez classer les causes en deux catégories : les facteurs causaux qui se rapportent au problème et y contribuent, et les causes qui perturbent réellement la séquence une fois éliminées.
Vous pouvez trouver dans la littérature spécialisée de nombreux exemples réussis d’implémentations d’ACR dans différents domaines, du monde de la sécurité avec l’analyse des accidents au monde médical avec l’analyse des fautes professionnelles médicales. Mais, que peut faire une méthode de dépannage comme ACR pour ceux qui s’intéressent au monde de l’analyse et de la supervision des réseaux et des applications ?
Chaque liste d’objectifs d’une plateforme d’analyse et de supervision inclut la détection et la prévention des pannes pouvant affecter les performances ou la panne des services.
C’est ici, dans la poursuite de l’objectif, qu’une bonne relation entre l’analyse des causes profondes et les outils de supervision pourrait être utile.
Imaginez que vous disposez d’une plate-forme bien supervisée et d’une application Web qui s’exécute sur plusieurs serveurs. Pour l’un de ces serveurs, la capacité du disque atteint un niveau dangereux, au-dessus de votre seuil. Votre plateforme de supervision produit une alarme. De cette manière, il est possible de recevoir l’alarme et de prendre les mesures appropriées pour éviter un problème de performance ou un défaillance du service Web.
Dans ce cas, la supervision basée sur les ressources pour vérifier le comportement de chaque élément du réseau et des serveurs fonctionne parfaitement et c’est une plate-forme simple, ici la mise en œuvre d’ACR n’est pas vraiment nécessaire.
Cependant, l’histoire n’est pas si simple lorsque nous parlons de plates-formes complexes avec plusieurs applications qui s’exécutent sur leurs propres serveurs, dans le Cloud, sur des serveurs virtualisés, dans des schémas de communication Wan avec différentes technologies et fournisseurs, etc.
Pensons à ce scénario : une entreprise dispose d’une plateforme complexe mais bien supervisée. Un jour, le service marketing lance une campagne promotionnelle. Ils ont décidé d’utiliser l’espace publicitaire d’une émission de télévision, orienté vers leur marché cible. Le programme de télévision est diffusé de 9h00 à 10h00 le soir. Le lancement est un succès, l’application web enregistrant une augmentation de 100 % des demandes d’accès.
À partir de 21h30, vous recevez plusieurs alarmes d’un groupe de serveurs, commutateurs réseau, routeurs et applications. Vous avez décidé de tester votre application web et de vérifier le temps de réponse, et oui, il est trop élevé. Vous savez que vos clients sont frustrés et que l’entreprise perd de l’argent.
La première réponse à ce problème de performances pourrait être: « Notre plate-forme n’a pas pu prendre en charge cette augmentation de la demande Web ». De toute évidence, cette réponse n’est pas suffisante, donc à ce stade, vous pouvez utiliser ACR pour lutter contre différents facteurs de causalité.
La clé de la question est ici : Combien de temps faut-il pour effectuer une analyse des causes profondes et quelle assistance notre plate-forme de supervision offre-t-elle ? Sérieusement, pour plus de support de notre plate-forme de supervision, moins de temps pour identifier la cause première.
Alors, sur quelle base les outils de supervision et d’analyse des causes profondes peuvent-ils fonctionner ?
Afficher par services
Afin d’effectuer efficacement une analyse des causes profondes, vous devez vérifier l’ensemble du groupe d’éléments liés au service problématique. Si votre plateforme de supervision peut vous offrir dans une vue intégrée l’état de tous ces éléments, il pourrait être intéressant de réduire le temps d’analyse que cela pourrait prendre.
Tenez compte des dépendances entre les éléments
Prenons un exemple classique pour illustrer ce point : vous avez un commutateur réseau et cinq serveurs qui y sont connectés. À un moment donné, votre commutateur échoue, vous n’avez pas vraiment besoin des cinq alarmes de chaque serveur indiquant qu’elles ne sont pas joignables, vous n’avez besoin de voir qu’une seule alarme, l’alarme de commutation.
La solution pourrait commencer par une carte de dépendance entre les éléments, mais ce serait encore mieux si en plus de la solution vous disposiez d’informations sur le type de trafic partagé entre les éléments ou en mesurant la réponse temporelle à chaque étape.
Informations historiques
Comme nous l’avons mentionné au début, ACR est essentiellement une méthode réactive, il est donc indispensable de conserver les données historiques. L’effort et les coûts associés à la gestion de ce type de données pourraient être justifiés pour d’autres activités, telles que la planification des capacités, entre autres. Cela pourrait être très intéressant si vous pouviez maintenir une base de données de connaissances avec la relation entre le problème et ses principales causes.
Comme mentionné, la relation entre l’analyse des causes profondes et les outils de supervision existe déjà ; peut-être pouvez-vous vérifier ces implémentations de plus près dans un autre post. Cependant, vous pouvez voir ce domaine comme l’une des prochaines frontières qui seront éventuellement conquises sur le marché de la supervision.
