Les systèmes informatiques sont comme une maison, avec le temps on accumule des choses. Certaines sont utiles et nous plaisent, d’autres, par contre, ne font que prendre de la place. Elles occasionnent du bruit, on les range pour ne plus les voir mais elles sont toujours là et une fois l’espace plein, elles débordent et en arrivent à cacher les choses importantes.

Ne plus voir les choses importantes est une source de gaspillages mais aussi une source de défauts potentiels.

Prenons l’exemple d’un système informatique avec des bases de données et des applications web. Situation qui est celle d’une équipe projet que j’accompagne actuellement. Tout le monde est aligné sur le fait qu’il faut monitorer cet environnement pour arriver à le contrôler, sinon il dérive. Et ce d’autant plus qu’il croit régulièrement en complexité et interconnexions. Comme dans toute mécanique, il arrive que les rouages se bloquent, des imprévus apparaissent et il est primordial d’intervenir au plus vite pour rétablir la disponibilité du système auprès de ses utilisateurs. Encore faut-il être informé de ces irrégularités et éviter que leur signalisation se fasse par des utilisateurs bloqués dans leur activité.

L’andon du système

Pour cela, il existe différents outils qui scannent en permanence les environnements informatiques et remontent des alertes dès qu’une anomalie est détectée mais ils ne les résolvent pas. Cette action nécessite que quelqu’un s’y intéresse et recherche les causes qui se cachent derrière ces alertes. Le travail n’est pas toujours simple surtout quand un outil de monitoring comme par exemple Sentry remonte, sur le périmètre d’une activité précise, plus de 200 alertes différentes touchant un nombre d’utilisateurs variés et pouvant avoir des milliers d’occurrences.

Le 5S pour y voir plus clair

Comment attaquer le traitement de ces alertes de façon efficace et pourquoi faut-il le faire ? Toutes les alertes ne représentent pas le même niveau de criticité pour les utilisateurs et il se mesure généralement selon les critères suivants :

·       Nombre de personnes impactées

·       Caractère bloquant de l’alerte en termes d’activité

Le danger est de ne traiter que les alertes considérées comme graves car l’interface de l’outil continue de remonter toutes les alertes non traitées et leur nombre augmentant sur la durée, leur analyse prend plus de temps et le risque d’occulter une alerte critique devient plus élevé.

Le lean met à disposition plusieurs outils qui ont pour objectifs principaux d’aider à déceler l’écart entre la situation actuelle et la situation voulue et de rendre visibles les problèmes empêchant de l’atteindre. La difficulté n’est pas seulement de choisir le bon outil mais aussi de savoir par où commencer sans se lancer dans une série d’analyses chronophages dénuée de prise d’action. Dans ce cas précis, nous avons décidé avec l’équipe projet d’appliquer les principes du 5S afin de conduire un nettoyage du système pour en éliminer les alertes parasites. Plus les alertes utiles sont noyées au milieu d’alertes inutiles, plus leur traitement est compliqué.

Comme point de départ, nous avons trié les alertes des 15 derniers jours selon leurs occurrences et avons commencé par les plus nombreuses. La première concernait une alerte sur un certificat obsolète et la seconde était causée par l’appel d’un « .gif » inexistant. Nous avons constaté que les liens cassés constituaient une cause d’alerte fréquente et que leur suppression, simple à réaliser, permettait de réduire rapidement le volume des alertes et de nettoyer le code.

Au fur et à mesure de l’élimination des causes générant des alertes, celles-ci diminuent et il devient plus facile de voir les problèmes qui peuvent avoir des conséquences sérieuses sur les systèmes. Là n’est pas le seul avantage. La résolution des défauts dans le code permet également, de mettre en place des standards de code et des routines de contrôle de ces standards pour sécuriser les améliorations obtenues.

Faire le tri, garder et organiser ce qui est utile ne représente que les 3 premiers « S » sur les 5. Ils sont les plus rapides, par contre la standardisation et le suivi sont les deux étapes clés pour s’assurer que les actions ont un réel impact sur la durée. Ils nécessitent de la rigueur et une prise en charge de l’effort par un responsable de la qualité du code pour que les solutions identifiées soient comprises, partagées et appliquées au niveau d’une équipe et deviennent la bonne manière de coder.

Le 5S ne doit pas être utilisé comme un outil pour faire du ménage mais pour faciliter la résolution de problèmes en vue d’un gain de qualité et de sécurité. Cela peut prendre la forme de l’application des principes « SOLID »* pour surveiller que le code ne dérive pas et que des critères tels que le nommage soient pris en compte au plus tôt dans un projet ou fasse l’objet d’un refactoring.

Concernant le projet évoqué ci-dessus, l’équipe a réduit, dès la première opération, les alertes parasites de 20 % et intègre dans chacun de ses nouveaux sprints un sujet d’amélioration de l’existant.

*A propos de SOLID : https://fr.wikipedia.org/wiki/SOLID_(informatique)

Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous avec le formulaire ci-dessous