L’auto-remédiation : un rempart contre les interruptions de services

Alors, l’auto-remédiation, qu’est-ce que c’est ?

L’auto-remédiation repose sur la capacité de prendre des mesures correctives ou préventives à la suite d'une vérification d'état. L'action corrective est une fonction autonome réalisée sans interaction humaine.

Cette capacité est aux ressources virtuelles, aux logiciels et aux composants applicatifs ce que le failover et la redondance est au matériel. La principale différence est l’absence d'intervention humaine. Alors que les pannes matérielles et les impacts sont perceptibles et relativement faciles à corriger, un logiciel auto-réparateur implique des changements fondamentaux de l'architecture de l'application. Cela n'était tout simplement pas possible jusqu'à ce que la virtualisation et les architectures de microservices fassent leur apparition. Avec cette approche granulaire, au composant, il devient possible d'ajouter des fonctions autonomes capables de corriger toutes formes de problèmes, à petite et grande échelle. Les mesures correctives peuvent comprendre des mesures préventives - elles évitent un incident -,  aux mesures réactives, fondées sur un incident.

Pour mettre en place ce dispositif, le monitoring est un bon point de départ. Les actions d'auto-remédiation s’adossent généralement à un événement qui se produit et déclenche une réaction. L'action réactive - les mesures prises pour réparer après une panne - est beaucoup plus facile à mettre en œuvre. L’aspect lié à la gestion des événements est bien compris dans les outils IT. En revanche, l'action préventive est beaucoup plus difficile. L'outil de monitoring recherche des indicateurs qui lui permettent d’interpréter que des mesures sont à prendre avant qu’une potentielle panne se produise. Par exemple, lorsqu'une utilisation excessive de mémoire est identifiée par l’outil de monitoring, la cause peut être une fuite de mémoire ou simplement un usage élevé de l’application. La méthode réactive, moins coûteuse et moins complexe, s’appuie sur un historique concret plutôt que sur des prédictions plus ou moins confuses.

Les logiciels ayant ces capacités d’auto-remédiation prennent des mesures correctives pour corriger la cause d'une panne. Cela peut être aussi simple qu'un redémarrage d'application ou aussi complexe que de devoir reconstruire ou créer une nouvelle instance ou un serveur virtuel. C’est pour cela que ces systèmes ont besoin de flexibilité. Il s’agit là de redémarrer quelque chose d'aussi petit qu'un service ou d’exécuter une tâche aussi grande que le déploiement d'un nouveau serveur.

Les mesures correctives doivent s'intensifier progressivement. Prenons exemple sur les actions réactives : le système doit d’abord essayer une action, puis si cela ne rétablit pas les opérations, passer à une action plus importante, et ainsi de suite, jusqu'à ce que l'application soit de nouveau opérationnelle. L'équipe opérationnelle décide le temps d’attente entre chaque étape, avant de passer à la suivante.

L’auto-remédiation en pleine évolution

Pour qu'un système de monitoring puisse prédire efficacement les événements, il a besoin d'une grande quantité de données historiques. Le choix évident serait d'enregistrer les données de performance au fil du temps, mais des prévisions précises impliquent un environnement statique. Chaque changement de système, mise à jour ou même patch peut avoir un effet sur le logiciel et l'infrastructure de base, et donc sur leurs performances et leurs réactions. L'autre difficulté consiste à extraire les bonnes données pour en dégager des tendances. Là encore, cela nécessite de prendre en compte le caractère statique – et pas dynamique - du système

Pour l’approche centrée sur la prédiction, il convient de se concentrer sur un sous-ensemble beaucoup plus réduit de données. Cela ne sera pas aussi efficace qu'avec un vaste ensemble de données historiques, mais offrira tout de même un avantage par rapport à la seule approche réactive.

Enfin la seule vraie façon de savoir si l'auto-remédiation et le déploiement de l'infrastructure fonctionne est de les tester en production. Un excellent exemple de test est celui mis en place par Netflix via  Chaos Monkey. Son objectif : stopper aléatoirement des instances dans l'architecture de microservices en production. Cette approche montre la capacité d'une équipe opérationnelle à maintenir un service en continu même lors d’événements imprévisibles.