DevOps, le monitoring des applications Web comme point d’entrée


De nos jours, les applications web connaissent un boom incroyable. Tout le monde a compris qu’internet est un outil business très efficace qui permet d’augmenter la visibilité de l’entreprise (Marketing), étendre ses marchés (boutique en ligne),…etc.

Voici quelques chiffres sur la situation du commerce en ligne en 2013 :

  • Le nombre des acheteurs en ligne a augmenté de 5% en 2013.
  • La fréquence des achats en ligne est en progression avec une moyenne de 18 transactions par an et par acheteur, contre 16 en 2012.
  • Le nombre de sites marchands actifs a dépassé les 138 000.

* Statistiques avancées par  Elioweb (http://www.elioweb.com/statistiques-e-commerce-france.html)

Donc, contrairement aux débuts d’internet qui étaient constitués de sites vitrines essentiellement. On se retrouve, aujourd’hui, avec des applications Web capables de récolter et de capter les actions des utilisateurs.

Cette révolution a considérablement complexifié les applications Web : logique métier complexe, sécurité, performances…etc.

En outre, de plus en plus d’entreprises abandonnent le développement d’applications lourdes et les remplacent par des applications Web. Cela permet de réduire, voir d’éliminer, les processus de déploiement des applications et des mises à jour sur les postes utilisateurs.
De ce fait, les applications Web apportent un gain de temps considérable et une réactivité presque immédiate quand il s’agit de résoudre des bugs ou de déployer de nouvelles versions.

Du point de vue des équipes informatiques, l’enjeu est énorme. Les applications sont plus complexes, plus sensibles et ont un réel impact financier. Il faut donc avoir un niveau de qualité très élevé en même temps qu’une productivité accrue.

En général, les équipes informatiques sont organisées en plusieurs sous-équipes : les développeurs d’un côté et les opérationnels (administrateurs système, réseau, base de données, messagerie, etc…) d’un autre côté.
Les développeurs ont pour rôle de créer l’application et de la faire évoluer au fil du temps. Ils sont aussi responsables de la correction des éventuels bugs détectés. Les opérationnels, quant à eux, sont responsables de la mise en place des environnements techniques, du déploiement de l’application et du monitoring de l’infrastructure.

Chaque équipe possède ses propres méthodes de travail, ses propres priorités et ses propres métriques.
Cette organisation pose un réel souci pour la collaboration des équipes. Il n’est pas rare de rencontrer l’analyse suivante suite à un problème de performance, par exemple :

  • Admin réseau : « Pas de congestion, tous les routeurs fonctionnent ».
  • Admin système : « Les serveurs ont suffisamment de CPU et de mémoire ».
  • Devs : « Le code de l’application est bon, le même code fonctionne correctement sur l’environnement de pré-production ».

Au lieu de travailler ensemble pour identifier le problème, chaque équipe va analyser le problème de son point de vue et tenter de démontrer que « ça ne vient pas de chez nous »; voire dans certaines cas, essayer de mettre en cause les autres équipes. Mais, malheureusement, il y a bien un problème du point de vue des utilisateurs.

Ce genre de situation peut coûter cher à l’entreprise : perte de clients pour un site e-commerce, planification de stock erronée pour une usine, etc….

Afin d’éviter de tomber dans ce type de situation, une entreprise doit faire évoluer sa culture pour se concentrer sur l’humain, l’organisation du travail et le bon choix des outils de gestion du cycle de vie des applications et des infrastructures.

Cette culture est le cœur même de la philosophie DevOps visant à rapprocher les équipes Dev et Ops. Ce rapprochement permettra aux équipes de communiquer plus efficacement, de partager les mêmes objectifs et de réfléchir continuellement aux différentes pistes d’améliorations de leur travail.

La Journée DevOps Day, qui a eu lieu le 25 novembre 2014 à Paris, s’est penchée sur la problématique de mise en place du processus DevOps dans les projets informatique (voir l’article Tour d’horizon du Microsoft DevOps Day – « Infrastructure as Code » pour avoir une idée sur le contenu de cette journée).

La mise en place d’une culture DevOps au sein d’une entreprise nécessite un travail de sensibilisation et de conviction des équipes. Il ne s’agit pas d’installer un outil, mais de changer complètement les mentalités, la façon de travailler des collaborateurs voire même l’organisation des équipes. Toute tentative de mise en place d’une culture DevOps par simple décision émanant de la direction subira inévitablement un échec et engendrera plus de méfaits que de bienfaits ; la conduite du changement a une place prépondérante ici.

La notion de DevOps est une notion vaste qui couvre tout le cycle de vie d’une application, de son développement à sa mise en production en passant par les différents environnements techniques. Il est vital de mettre en place le processus DevOps de façon graduelle. Vouloir adopter ce processus dans tous les aspects du cycle de vie applicatif en même temps peut s’avérer complexe, voire même périlleux.

Un point d’entrée intéressant pour la mise en place de DevOps est le monitoring des applications déjà en production. Les équipes Dev et Ops pourront coopérer pour mieux réagir aux problèmes rencontrés sur les applications en production.
Le monitoring est, en fait, un bon point de coopération pour les Dev et les Ops. Un mauvais comportement d’une application engagera la responsabilité des Dev et des Ops en même temps. Si les deux parties sont convaincues qu’ils forment la même équipe, ils mettront toutes leurs compétences et leur énergie pour améliorer le processus de monitoring :

  • Choix des bons outils qui reflètent le réel état des applications.
  • Mettre à disposition des Devs des rapports afin qu’ils puissent anticiper les éventuels problèmes lors des prochaines versions.
  • Collaborer en temps réel pour la résolution des problèmes urgents
  • …etc

Se baser sur le monitoring pour une première mise en place de DevOps a pour avantage de démontrer l’intérêt de cette approche (applications plus stable, réaction plus efficace aux problèmes de production…etc.) et, donc, de faciliter son adoption pour les autres étapes du cycle de vie applicatif.

Cela-dit, il faut garder à l’esprit que le DevOps n’est pas un objectif en soi, mais une quête vers une amélioration continue de la collaboration des équipes Devs et des Ops.
La façon de mettre en place DevOps varie inévitablement d’une entreprise à une autre, voire même, d’un service à un autre au sein d’une seule et même entreprise. C’est un processus lent qui nécessite beaucoup de patience et une implication sans failles des différents acteurs.

Cependant, une fois sur les rails, DevOps apportera énormément à l’entreprise: des équipes soudées, un environnement de travail sain et des livrables de meilleur qualité, donc, des utilisateurs satisfaits [et il faut malheureusement trop souvent rappeler que c’est ce pourquoi nous travaillons tous].  

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s