Prendre du recul sur la Rules-based Approach

Depuis quelques décennies, les règles et les seuils régissent le monitoring et la supervisions IT. Ceux d’entre vous qui surveillent les infrastructures au quotidien considèrent probablement l’approche fondée sur les règles comme une alliée. Avec les outils de surveillance traditionnels, nous utilisons une combinaison d’expressions logiques pour définir des alertes – “Si X se produit, alors faire Y” pour traiter chaque problème connu.

Cependant, au fur et à mesure que nous développons nos infrastructures, nous découvrons de nouveaux problèmes et nous ajoutons sans cesse des règles et des seuils – les scale ups et larges entreprises peuvent gérer de quelques centaines à des milliers de “moniteurs manuels”.

Cette approche, bien que très imparfaite, a pu fonctionner avec des inefficacités modérées sur des infrastructures monolithiques. Mais avec les infrastructures éphémères de l’ère moderne et l’explosion correspondante des données générées (logs/métriques/traces), continuer à utiliser une approche basée sur des règles pourrait s’avérer catastrophique.

Quels sont donc les principaux enjeux d’une rules-based approach et comment pouvons-nous mieux utiliser la technologie, i.e l’intelligence artificielle, pour faire face à ces challenges?

Les règles donnent l’illusion de la simplicité

Gestion d’incidents inconnus i.e les black swans: 

Lorsque que nous utilisons la rules-based approach, la première chose à laquelle nous pensons est de définir un ensemble de règles permettant de monitorer les différents paramètres de l’infrastructure IT. A première vue, cela semble simple et évident. Mais avez-vous pensé à créer des règles pour les exceptions, autrement dit les événements encore jamais rencontrés? Il est en effet très compliqué de créer des règles manuellement pour faire face à tous les scénarii envisageables car dès que cet ensemble de règles fait face à une exception au sein de l’environnement IT, la logique pour laquelle cette règle a initialement été programmée cesse de fonctionner. Afin de faire face à cette situation, une nouvelle règle doit être créée. C’est un processus sans fin, truffé de confusion et de complexité, qu’il faut éviter à tout prix.

Ce n’est pas simple mais exponentiellement complexe : 

Si nous prenons comme cas de figure les scale ups ou les grandes entreprises , nous pouvons aisément comparer la rules-based approach à une myriade de complexité. Les organisations reçoivent en moyenne quelques milliers à des millions d’alertes par jour. Il est facile d’en déduire que c’est impossible d’essayer de traiter toutes ces alertes par une approche fondée sur des règles.

Et si la seule solution pour faire face à un grand nombre de scénarios était d’augmenter en conséquence le portefeuille de règles ? Si l’on réfléchit une seconde, cette relation linéaire ne parvient pas à être pragmatique dans les scénarios de la vie réelle.

Cette approche ne va pas seulement accroître la complexité, car il sera plus difficile de déterminer si les règles sont cohérentes entre elles, mais le calcul des combinaisons potentielles pour un ensemble de règles est une fonction factorielle et nous amène à un problème mathématique. Par exemple, avec cinq règles, il y a 120 combinaisons possibles: 5! i.e 5*4*3*2*1 = 120. Avec six règles, il y en a 740. Dix règles génèrent 3 628 800 combinaisons possibles. Maintenant imaginez des milliers de règles!

Un autre enjeu se présente avec la rules-based approach: tester le portefeuille de règles afin de garantir une précision constante. Chaque combinaison de règles doit être vérifiée afin d’éviter les faux positifs ou les incidents critiques manquants. Les data scientists appelle cela le “problème NP-complet”, car il n’existe aucun ordinateur capable de répondre à cette exigence.

Si vous ne deviez retenir qu’une chose de ce paragraphe: dire que l’utilisation d’un système fondé sur des règles pour les opérations informatiques est “simple” serait une erreur ! Pour des infrastructures complexes, elles compliquent énormément le monitoring et la remédiation.

Le véritable coût des règles

Ne serions-nous pas arrivés à la conclusion que les règles ne sont pas aussi simples à mettre en place qu’elles le paraissent? Alors pourquoi toujours les utiliser? Est-ce parce que cette méthode s’avère moins coûteuse que l’investissement dans l’IA ?

Si nous reprenons le raisonnement décrit précédemment, nous constatons qu’un monitoring fondés sur les règles requiert de:

• Créer de nombreuses règles pour faire faces aux différentes situations,
• Vérifier la cohérence de chaque règle avec l’ensemble,
• Le nombre de combinaisons croît de manière exponentielle jusqu’à des niveaux où il n’existe aucun ordinateur capable de répondre à cette exigence, et devient finalement impossible à gérer.

Comprendre le coût réel des règles implique donc un processus sans fin de création, de vérification et de révision. C’est un problème de maintenance quotidienne et de taille gargantuesque. 

De plus, qui au sein de votre équipe IT est formé et qualifié pour gérer cette maintenance? Compte tenu du volume, de la mise à jour permanente des règles et de leurs interactions, seuls des experts sont capables de faire face à cette charge de travail. Et pour le gérer efficacement, il faudrait une armée d’experts.

Avec la prolifération des conteneurs et des micro-services qui apparaissent et disparaissent à la demande, le nombre de règles requises a explosé. Lorsque les règles ne fonctionnent pas comme prévu, ou lorsqu’il y a des conflits entre les règles, leur exactitude en souffre et les ingénieurs sont  inondés d’alertes non pertinentes. 

Pour remédier à la fatigue générée par le flux d’alertes, les analystes cessent souvent d’utiliser les règles pour la corrélation des événements. Il en résulte des coûts plus élevés en raison des temps d’arrêt.

Ce genre de scénario incite à penser que la solution est de diminuer le nombre de règles. Vous aurez deviné que cette stratégie peut s’avérer risquée, car l’outil de surveillance ne révèle qu’une indication partielle d’un nouveau problème, et si l’indicateur de cet indice est désactivé, le problème ne sera pas détecté. Au moment où un incident devient critique, les ingénieurs n’auront jamais vu venir le problème. Il sera alors trop tard.

Les règles sont donc bien plus complexes et coûteuses que nous le pensons.

Et si la règle était de se passer des règles?

Toutes ces problématiques incitent de nombreuses entreprises à se tourner vers des solutions de monitoring autonome utilisant l’intelligence artificielle et le machine learning pour résoudre les problèmes que les règles sont censées traiter (mais ne peuvent pas traiter). Ces outils permettent aux équipes IT de traiter toutes les données, même les exceptions, sans être limités par les règles.

Un outil de monitoring autonome élimine la nécessité de créer des règles pour chaque combinaison possible d’événements. Au lieu de cela, il peut ingérer toutes les données opérationnelles de votre infrastructure et appliquer automatiquement des algorithmes pour déterminer quels événements sont importants et lesquels ne le sont pas. 

Contrairement à un système basé sur des règles, une solution basée sur du machine learning apprend automatiquement est en train de devenir essentielle pour assurer la performance optimales des infrastructures IT. Prendre du recul sur la rules-based approach vous ouvrira de nouvelles perspectives et facilitera le quotidien de vos SRE’s!

PacketAI is the world’s first autonomous monitoring solution built for the modern age. Our solution has been developed after 5 years of intensive research in French & Canadian laboratories and we are backed by leading VC’s. To know more, book a free demo and get started today!

Follow @PacketSAS on Twitter or PacketAI Company page on LinkedIn to get the latest news!