Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Passez au DevOps
  3. Mesurer et améliorer
Extrait - Passez au DevOps Votre nouvelle façon de travailler
Extraits du livre
Passez au DevOps Votre nouvelle façon de travailler
1 avis
Revenir à la page d'achat du livre

Mesurer et améliorer

L’observabilité

1. Le monitoring

Le paradigme classique de supervision d’une plateforme technique, tant au niveau système qu’applicatif, repose sur le monitoring. Cela consiste à mettre en œuvre, au niveau des systèmes et des applications, des sondes chargées de collecter des mesures et de déclencher des alertes si les mesures remontées sont incohérentes ou inattendues. Ces alertes disent que quelque chose ne va pas et qu’il est nécessaire d’intervenir. Les sondes peuvent aussi être complétées par des événements écrits dans les différents journaux maintenus par le système.

Dans un système monitoré, la compréhension de l’état du système est obtenue par la surveillance et l’inventaire des alertes déclenchées, et par l’analyse de leur historique jusqu’à un instant t. Le principe a été théorisé en 1960 par Kalman qui détermine mathématiquement que l’état d’un système peut être connu par les mesures effectuées à ses sorties, les sondes et les journaux étant autant de sorties valables pour connaître son état, et d’en suivre l’évolution dans le temps.

Les alertes déclenchées déterminent un problème sur un composant de l’application, voire sur une fonction d’un composant. La vision globale de l’état du système doit donc être reconstruite en analysant l’ensemble des alertes remontées pour l’ensemble des composants et en reconstruisant des liens possibles entre elles. C’est un point important car cette vision atomisée du système, construite à partir des alertes, peut diminuer fortement la capacité...

Les indicateurs DevOps

Indicateurs (ou métriques) et mesures sont deux choses différentes. La mesure est une donnée brute remontée par une sonde à un instant t. Elle ne porte d’autre information qu’elle-même. Un indicateur est un calcul réalisé à partir de l’agrégation des mesures. L’objectif d’un indicateur est d’apporter une vue sur l’évolution du système et la façon dont il répond au besoin de ses utilisateurs.

Par exemple, une mesure peut informer qu’un service consomme 80 % de ses ressources processeur disponibles. Peut-être est-ce le signe que quelque chose ne va pas, ou peut-être est-ce tout à fait normal. En revanche, un indicateur qui détermine que chaque mois l’utilisation des ressources augmente de 10 % vous informe de tout autre chose… D’une part, il va rapidement falloir augmenter les ressources disponibles, ou créer une nouvelle instance, et d’autre part il va falloir investiguer sur un éventuel problème de consommation des ressources.

Il en va de même pour les indicateurs que l’on utilise pour décrire le fonctionnement d’une équipe et/ou d’une organisation. Dire qu’un produit est livré tous les mois est peut-être intéressant pour mettre en évidence que l’équipe déploie à un rythme plutôt lent mais acceptable, mais fondamentalement cela ne dit rien sur la performance de son fonctionnement. En revanche dire que l’équipe améliore tous les mois son temps de déploiement de 5 % est significatif d’un mode de fonctionnement privilégiant l’amélioration continue et l’intégration des principes Lean. Par ailleurs, si l’on ajoute à cet indicateur un autre...