Amis développeurs, pensez à votre production !


Parmi les choses qui m’étonneront toujours dans mon métier, c’est le manque d’intérêt de beaucoup de développeurs pour ce qui se passe en production. C’est pourtant la destination ultime du code qu’un développeur produit chaque jour, et également l’endroit où le logiciel créé, la nouvelle feature disruptive, le bugfix corrigeant ce soucis tellement ennuyeux va enfin amener sa réelle valeur ajoutée. Alors pourquoi ce désintérêt ? C’est finalement l’environnement le plus important de votre SI.

Quelles sont les choses à connaître sur les spécificités et les besoins d’un système de production ? Pourquoi est-il important de surveiller correctement sa production ? Et comment le faire efficacement ? Quelques pistes de réponse…

Des devs et des ops

Pourtant, ça marche sur mon poste !

Vous l’imaginez bien le développeur qui vous balance ça en commençant à vous tourner le dos pour retourner au codage de la prochaine feature super importante de votre application ? En même temps, on l’a tous plus ou moins dit / pensé dans notre jeunesse de codeur…

Cependant, c’est bel et bien la production l’environnement le plus important de tous. Pas parce que c’est le plus gros et le plus compliqué, mais parce que c’est la raison d’être d’un applicatif : rendre service à ses utilisateurs finaux (vous savez, ces gens bizarres qui crée des tickets de bug parce qu’ils n’ont rien compris à l’informatique :D). Notre premier objectif à nous, informaticiens, est de rendre service à nos utilisateurs finaux, ceux à qui nous apportons plus de facilité dans la vie de tous les jours, des features qui leur sont vitales parfois et qui leur économise un temps précieux.

Et quand je dis « informaticiens », je parle bien de tous. Les ops, bien sûr, dont le job est de faire en sorte que la plate-forme soit la plus stable possible, et à qui incombe les réparations du matériel, la stabilité du réseau et des composants systèmes. Mais aussi les devs, dont le job est de faire en sorte que l’applicatif fonctionne, sans bug, et gère aussi de manière souple les cas d’exception (= ne crash pas lamentablement avec un message abscon comme « Internal server error »).

Les ops, en général, sont bien conscients des enjeux d’une production qui fonctionne car en première ligne, souvent même en astreinte les soirs et les week-ends pour assurer cette stabilité.

Par contre, les développeurs peuvent facilement oublier ce point. Pas toujours par je-m’en-foutisme, mais aussi parfois parce que la pression des deadlines et des décisions politiques pousse à aller de plus en plus vite. Et c’est souvent la production, qui arrive en bout de projet, qui est le grand oublié.

Il y a pourtant des contraintes à garder en tête tout au long d’un développement pour bien atterrir en production.

Les logs

D’abord il faut avoir une bonne traçabilité des actions réalisées par le logiciel, des erreurs rencontrées et pourquoi.

Il ne faut cependant pas tomber dans l’excès inverse : vouloir logguer les moindres faits et geste des utilisateurs, sous peine de ralentir son application et de saturer l’espace disque des machines pour des choses qu’on ne lira pas.

Mais ce n’est pas le tout de logguer, encore faut-il aussi les consulter à la recherche d’éventuels problèmes. Non seulement le contenu de ces logs est important mais aussi l’évolution des messages rencontrés en fonction du temps, pour révéler des impacts lors d’un déploiement, d’une intervention sur une base de données ou un firewall,…

De ce fait, il est plus qu’intéressant de centraliser ces logs et de les indexer dans un outil d’analyse type ELK, ou Sentry.

Une log de base à collecter quand on travaille sur du web (applicatif ou web services) est l’access log du serveur web. C’est en soi déjà une mine d’information intéressante.

La redondance

Eh oui, ami développeur. Très souvent, le système sur lequel tu travailles n’est pas comme ton blog perso : il est critique et nécessite de pouvoir continuer de fonctionner en cas de perte d’une machine. C’est pourquoi il va très souvent devoir fonctionner sur plusieurs machines, contrairement généralement aux environnements de développement et de recette.

Quoi surveiller ?

Et une fois le code en production, ce n’est pas le problème des autres. Beaucoup de problèmes peuvent être évités en jetant un œil à quelques indicateurs de votre application afin de vous assurer de sa bonne santé.

  • Les temps de réponse des requêtes, à la fois en valeur absolue (est-ce que ce sont des temps satisfaisants ?) et en évolution (est-ce que ça se dégrade ?)
  • L’évolution du trafic (en nombre de hits global, et feature par feature)
  • Des indicateurs sur le serveur lui-même (CPU consommée, mémoire utilisée et restante, load average). Ce sont des éléments qui pourraient corréler une dégradation des performances à une saturation des machines, et déclencher en avance de phase une augmentation du nombre de noeuds/containers, de l’ajout de RAM
  • La bonne exécution des traitements batch (qu’ils tournent la nuit ou journée) s’il y en a. Car parfois ça peut planter…
  • Taille des queues de traitement si vous faites de l’asynchrone (via Kafka, RabbitMQ, …) pour diagnostiquer au plus tôt un engorgement.

On ne le dira jamais assez : un problème détecté tôt par les équipes elles-mêmes est toujours plus facile à traiter au calme qu’un problème remonté par des utilisateurs véhéments sous la pression du management, parfois haut placé.

Quelques outils intéressants

Analyse de logs

Le plus répandue et simple à mettre en œuvre reste la fameuse stack ELK (Elasticsearch, Logstash, Kibana). Je ne vais pas écrire un nième tutoriel sur l’installation et la mise en œuvre de ce service. Indexez-y en priorité les access logs de vos serveurs web : comme dit plus haut, c’est déjà une mine d’information intéressante. En y mettant les temps de réponse, d’éventuelles informations sur l’authentification (dans le cas d’une API pour logguer la clé), on a déjà de quoi faire des dashboards intéressants.

Un exemple de dashboard Kibana

Des solutions commerciales existent également comme Splunk (qui devient très vite cher) mais qu’importe l’outil, le plus important est de se créer des dashboards pertinents et parlants, pour que l’équipe puisse réagir rapidement et comprendre ce qu’il se passe sur la plateforme, et voire anticiper les remontées des utilisateurs.

Surveillance des performances : les APM

Ces outils permettent de se placer directement au cœur de votre code pour en analyser les performances, intrinsèques mais aussi des services sous-jacents.

Le plus facile à mettre en place est NewRelic qui fonctionne en SaaS. La version gratuite offre une vision sur les dernières 24 heures, globalement et, si vous utilisez un framework reconnu pour votre langage, route par route, avec les appels externes à des bases de données, des caches, des webservices,… Si vous avez un peu de sous, la version payante donne plus de rétention, des traces complètes pour des requêtes lentes, une analyse plus fine des erreurs rencontrées, et également la capacité de faire du cross-application, c’est-à-dire de suivre les problèmes de performance d’application en application en creusant plus bas dans les services appelés par l’application mère.

Et si vous avez vraiment les moyens et voulez un APM on-premise, AppDynamics est un outil génial, très complet, et avec une roadmap très active.

Ce genre d’outil vous permet de régler plus facilement des problèmes de performance difficile à tracer avec les seules access logs, en vous mettant le doigt directement sur le problème

Conclusion

Suivre les performances et le fonctionnement de son application en production n’est pas que de l’apanage des ops. La curiosité du développeur devrait le pousser à se poser ce genre de question, et de voir si son travail porte ses fruits, si des améliorations sont possibles. Car c’est en s’intéressant à ces problématiques que l’on apporte encore plus de confort à ses usagers. Et plus de confort, c’est plus de satisfaction, plus de reconnaissance, et aussi plus de confiance.

Monter ce genre d’outil n’est pas très long, peut facilement se faire de manière incrémentale, et permet également de toucher du doigt les problématiques de la production, ce qui est toujours très enrichissant et permet de surcroît une meilleure collaboration avec les ops.

Bref, surveiller sa prod, c’est que du bonus !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *