Tribune : ce que la supervision doit au DevOps (et vice versa)

Autrefois était le monitoring IT. Un joli couteau suisse où chacun pouvait y trouver la solution à ses problématiques de supervision. Mais ça, c’était avant… Avant le Cloud, le Saas, le serverless, l’agilité, l’automatisation, le machine learning, l’IA…

En quelques années, la supervision a fait une grande mue. Tout d’abord pour faire face aux nouvelles pratiques de l’IT portées par l’agilité et la transformation digitale qui lie étroitement le business au SI. Ensuite pour s’adapter aux infrastructures Cloud. Et enfin pour pouvoir (enfin) marcher main dans la main avec les équipes de développement au sein du mouvement DevOps qui replace la supervision au cœur de performance du SI. Tour d’horizon de ce que la supervision doit à DevOps (et vice-versa).

DevOps ou la réconciliation des frères ennemis

Au-delà du buzzword, DevOps est un mouvement de fond né il y a presque 10 ans lors de conférences professionnelles successives. Le terme DevOps a été inventé par Patrick Debois et vient de la concaténation des premières lettres du mot Développement et de l’abréviation Ops qui désigne l’exploitation en anglais.
DevOps prend ses racines dans le Lean Management et le manifeste agile auxquels il emprunte des méthodes visant à améliorer de façon continue la valeur pour le client, à réduire les gaspillages mais aussi à développer la collaboration entre les acteurs des projets IT et mieux structurer les équipes.
Les principaux gains se situent en termes d’agilité, de productivité mais aussi de qualité de produits et de satisfaction client. Les équipes mettent à disposition des utilisateurs des services plus rapidement et avec une meilleure adéquation avec leurs attentes. Cela permet ainsi de réduire le « time to market » pour l’entreprise et de rester en phase avec son marché.

DevOps s’appuie sur la coopération entre les différents intervenants de l’IT, autour de bonnes pratiques afin de créer, développer et mettre en exploitation des applications de façon plus rapide, moins coûteuse et plus qualitative. Il réconcilie ainsi les équipes de développement et d’exploitation autour du célèbre principe de Werner Vogels, CTO d’Amazon : « you build it, you run it ». Celui qui conçoit est aussi celui qui déploie. L’équipe est donc un des outils principaux de DevOps.

Un impact sur les processus IT traditionnels … et la supervision

La démarche DevOps, contrairement à ITIL par exemple, n’est pas formalisée ou normée. C’est un ensemble de bonnes pratiques qui impactent directement les processus IT traditionnels car elles nécessitent de :
●    Replacer l’utilisateur au cœur du processus,
●    Se focaliser sur des cycles courts et maîtrisés reposant sur une intégration continue,
●    Revoir la façon de concevoir, de développer, de produire l’IT,
●    Repenser la relation avec les équipes métiers et de façon plus large la relation client,
●    Organiser différemment les processus, services et produits au sein de la DSI,
●    Partager autrement les responsabilités entre les équipes,
●    Structurer les processus autour d’équipes restreintes, autonomes et polyvalentes pilotées par un Product Owner.

C’est donc la fin du fonctionnement en silos, qui coupait structurellement les Dev des Ops.
Concrètement, pour les équipes Exploitation et Développement, il s’agit de :
●    Développer une culture centrée sur la collaboration pour dépasser le cloisonnement traditionnel,
●    Automatiser au maximum les tâches opérationnelles pour la mise en production, la gestion des versions, la supervision pour gagner en qualité et en productivité, limiter les erreurs et renforcer le self-service,
●    Mesurer la performance pour permettre l’amélioration continue avec des indicateurs propres à DevOps (fréquence des déploiements, vitesse de restauration, etc.),
●    Partager les outils et l’expérience, dans une logique d’échange et de décloisonnement.
Cette nouvelle philosophie s’accompagne d’une nouvelle relation entre les équipes et de nouveaux outils qui facilitent l’automatisation, favorise les cycles courts et consomme des indicateurs. La supervision se place donc au cœur du dispositif DevOps car elle seule est en mesure de produire ces outils.

La supervision au cœur des dispositifs DevOps

Avec DevOps, l’idée est de collecter un maximum de données au sein de la supervision qui seront ensuite analysées afin que l’entreprise gagne en agilité et corrige plus rapidement le tir. Le périmètre de la supervision s’élargit et se diversifie. Il s’agit de collecter des données de types différents, avec différents niveaux de lecture et dans des cas d’utilisation (user case) variés. Dans le système DevOps, l’analyse des données passe en priorité mais elle ne peut se faire sans une collecte quasi exhaustive des données du SI. Et ce, quel que soit le modèle d’infrastructures, le type d’applications ou de systèmes supervisés. Le tout dans un environnement IT en perpétuelle évolution (principalement en raison du cloud). La supervision doit elle aussi évoluer afin de collecter des données capables d’alimenter des indicateurs métier et fonctionnels. Les techniciens ne sont plus les seuls à utiliser les dashboards de la solution de supervision. Tous les métiers doivent pouvoir l’exploiter.

La supervision se place ainsi au cœur du dispositif des projets DevOps en occupant une place essentielle. Ce point a été mis en avant dans la pyramide de Maslow (*) établie par Google pour illustrer sa méthodologie de développement SRE (Site Reliability Engineering) fortement inspiré des méthodes DevOps. La méthode Google repose sur une équipe technique de « fiabilité de site », supportant les activités de recherche et d’hébergement en Europe. Elle place la supervision comme la base du projet impliquant que rien ne peut se faire sans un monitoring IT pertinent et adapté.

Avec le Data driven business, la supervision évolue vers « l’observabilité »

Cet enjeu est devenu majeur dans les entreprises où le business est de plus en plus lié à la performance du SI. La donnée doit maintenant être contextualisée afin de mieux comprendre la déviation d’une métrique ou d’un comportement. La mise en production d’une modification, aussi mineure qu’un bouton sur un site e-commerce par exemple, peut avoir des impacts fort sur la performance des métiers. L’outil de monitoring doit être en mesure de mettre ce type de comportement en évidence.
Il devient essentiel d’obtenir de plus en plus d’indicateurs métiers en intégrant des données diverses (internes comme externes) et en les corrélant.

Le métier de la supervision évolue pour servir directement les équipes métier et quantifier le business.
Prenons l’exemple de Netflix : l’entreprise propose des films et séries télévisées en continu partout dans le monde via internet. Elle collecte de nombreuses informations dans sa supervision afin de disposer d’indications pour évaluer l’état des émissions dans différentes zones géographiques, de faire évoluer les infrastructures mais aussi de capter des tendances pour créer ses nouvelles séries en fonction des métriques collectées et analysées.
Les outils de monitoring s’appuient à présent sur des datawarehouses pour stocker historiser, contextualiser et analyser de gros volumes de données. Ils restituent aisément les données et offrent une vue globale sur l’ensemble de l’IT et sur les services rendus. La vision du SI est centralisée permettant ainsi de voir l’activité des différentes ressources.
Cela permet également de fournir aux directions métier des indicateurs qui leur sont propres afin d’alimenter le processus de l’amélioration continue, principe fondamental des processus ITIL et DevOps.

Cloud, supervision et automatisation : le trio inséparable pour une vue en temps réel de la performance IT et business

DevOps repose sur des cycles courts. Pour cela, il faut être en mesure de mettre en exploitation rapidement et donc d’automatiser une grande partie des opérations. Un impératif d’autant plus fort que les entreprises font évoluer leurs infrastructures vers le cloud. Le périmètre de l’IT évolue et celui de la supervision doit évoluer au même rythme. Elle ajuste le périmètre à monitorer quasiment instantanément en réalisant l’interface avec le cloud et les outils internes.

Arrêtons-nous un instant sur le principe du cloud, intimement lié à la transformation numérique et à la mise en œuvre de DevOps. Le cloud permet de créer et supprimer des machines en quelques secondes et de s’affranchir de la gestion matérielle des infrastructures. Les anciennes pratiques telles que l’alimentation de la CMDB pour les éléments d’infrastructure ne sont plus forcément applicables. Or le cloud n’est pas une boîte noire.
Les infrastructures évoluent clairement vers le serverless, ce qui ne signifie pas que le SI devra devenir monitoringless ! il faudra toujours s’assurer de la santé du SI et de nouvelles métriques devront être intégrées dans la supervision pour assurer un fonctionnement optimal.
La supervision doit entrer dans l’ère de l’automatisation, voire de l’auto-configuration grâce aux API, pour devenir un support aux équipes DevOps.

La boucle d’influence DevOps et supervision : travailler main dans la main pour créer de la valeur

Indéniablement, la supervision est impactée par la philosophie DevOps. La supervision doit être automatisée pour être efficace. Elle peut ainsi réduire les tâches à faible valeur ajoutée pour permettre aux équipes de se concentrer sur l’analyse et la corrélation des données afin de fournir les indicateurs les plus pertinents aux métiers et à l’IT.
Elle devient la pierre angulaire de la philosophie DevOps en permettant une meilleure coopération de tous les acteurs de la chaîne.

De l’autre côté, l’influence de la supervision est également importante dans la philosophie DevOps. Elle devient clairement source de création de valeur – principe fondamental de DevOps – en amenant de nouveaux services aux développeurs. Grâce au principe des équipes restreintes, multicompétentes et autonomes (appelées également PizzaTeams), la responsabilité est à présent partagée par tous, sur l’ensemble de la chaîne de valeur.
C’est la fin des silos entre exploitation et développement qui doivent rapprocher et partager les mêmes méthodes de travail.
La supervision n’est plus simplement l’outil des Ops mais bien un outil commun que partagent Dev et Ops.