2 octobre 2017
3 minutes
DevOps, n'auriez-vous pas oublié quelque chose ?
Le Digital et le besoin d'agilité conduisent les entreprises à déployer des programmes DevOps essayant de raccourcir le délai de mise en production des nouvelles versions d'applications.
La démarche n'est surement pas contestable mais le raccourci pris par les entreprises de l'automatisation à outrance du processus DevOps est risqué. D'autres points indispensables doivent être mis en place pour que la qualité des applications soit au rendez-vous, proposant aux utilisateurs une Performance optimum.Spécialiste de la mesure de la performance des SI, nous rencontrons régulièrement des clients qui se lancent dans des programmes DevOps mais qui n'arrivent pas à en tirer le meilleur parti. Ils se trouvent face à des utilisateurs frustrés de voir des applications intéressantes, répondant à leurs enjeux mais avec des temps de réponses déplorables. Ces temps de réponses ne sont pas simplement dus à des débits réseau trop faibles, mais très souvent causés par le non-respect de bonnes pratiques : des requêtes aux bases de données non optimisées, des appels à des ressources externes ne tenant pas compte du délai de réponse.... La liste est longue, dépendant bien souvent de l'architecture du SI et des choix de technologies pour le développement.
A de nombreuses reprises nous avons mis en place des services de métrologie pour analyser les causes des dysfonctionnements et des lenteurs, facilitant ainsi la factualisation de la cause et simplifiant l'échange entre les équipes projets DevOps. Au cours de ces missions, nous avons identifié des gisements d'optimisation des programmes DevOps par l'apport de la mesure de la performance. Prenons un premier exemple : mesurer la performance d'une application en pré-production en utilisant une solution d'APM de type "Agent d'introspection". A ce stade déjà bien avancé de l'application, la métrologie va permettre d'identifier rapidement, par exemple, les maillons faibles dans le code. Ils correspondent souvent à des appels mal optimisés vers les bases de données.
Deuxième exemple : mesurer la performance de l'application en production. En dehors de la surveillance de l'application pour détecter des ruptures de service, il est opportun d'analyser quelques indicateurs dans une approche d'amélioration continue. Il est simple en effet d'identifier les TOP 10 des transactions les plus lentes ou le TOP 10 des pages les plus lentes. L'analyse de ces cas avec les équipes de développement permettra d'une part d'améliorer les performances médiocres, répondant ainsi aux remarques des utilisateurs, mais aussi, de mettre à jour les règles des bonnes pratiques de développement pour les développeurs. Ce cas est particulièrement important dans le cas d'utilisation de ressources externes.
Nous pourrions passer en revue l'ensemble des points d'amélioration identifiés, mais il est pragmatique de se focaliser sur quelques-uns, en fonction du contexte du client.
Il en ressort que l'IT Performance peut servir avantageusement les programmes DevOps, et que ceux-ci ne se limite pas à l'automatisation d'allocation de ressources.
