1. Bonjour Alexis, peux-tu me dire quels sujets t'amènes ici au Paris DevOps Days ?
DevOps Days, c'est une conférence dont on est sponsor. Cela fait depuis plus ou moins 2010 que l'on suit DevOps Days, principalement aux États-Unis et en Europe. Ma boite DataDog, une boite de monitoring, nos clients sont en fait à DevOps Days donc pour nous c'est très intéressant de les rencontrer, de comprendre ce qu'ils cherchent, de voir l'évolution de leurs besoins.
C'est ce pour quoi je suis là, pour essayer de comprendre comment est la scène française finalement. Je suis venue en Allemagne, a Hambourg, en 2010 et je pense qu'a ce moment-là la composition des participants était très orientée opération, très Ops et pas tellement Dev. Depuis ça a changé et d'après le nombre de personnes qui sont là, je pense que ça prend de l'importance et c'est une très bonne chose.
Parce que c'est quelque chose qui est crucial, quelque chose qui en temps qu'ingénieur n'était pas du tout évident à l'origine. Initialement c'est moi qui m'occupé des clients et comme on est une boite d'ingénieur, on a essayé d'attaquer le problème en ingénieur: quel est le problème, comment on peut mesurer notre impact, comment est-ce que l'on sait que l'on va dans la bonne direction. Et quand on mesure les choses, la performance d'une machine, d'un serveur, d'un service, c'est très objectif, c'est relativement facile à comprendre comment ça se passe. Quand on parle des clients, si on n'a pas de métrique, c'est facile de se laisser influencer soit par le dernier client que l'on a entendu, ou alors par le client qui fait le plus de bruit et donc c'est vraiment important pour nous de développer des métriques sur le support client et des métriques qui ne soit pas purement financières du genre combien ça me coute.
Je pense qu'elle le devrait. Mais il faut faire attention, il ne faut pas que ça se transforme en une chasse à l'optimisation, une chasse au chiffre. La métrique est là pour servir les objectifs, ce n’est pas une fin en soi. Ma thèse c'est que les métriques c'est crucial pour comprendre les systèmes complexes. Les applications web sont des systèmes complexes, le support client et les clients ça forme un système complexe et donc il y a besoin de métriques pour ça. Il y a besoin d'outils pour les visualiser, pour les analyser. Il y a besoin d'un langage commun pour comprendre quand l'on parle d'une métrique qu’est-ce que ça veut dire. Pour gérer la complexité, il est essentiel d'avoir des métriques.
5. Est-ce que pour le support client, il y a des contraintes particulières ?
La difficulté c'est une définition relativement précise de la mesure. C'est une des principales difficultés parce que quand on mesure le CPU d'une machine c'est relativement objectif comme mesure alors que lorsque l'on mesure le support client, c'est beaucoup moins bien défini. Il faut vraiment se mettre d'accord avant de se lancer: voilà ce que l'on mesure, voilà ce que ça veut dire, voilà ce que j'espère en tirer de mes métriques sinon c'est du flou et ça devient vraiment difficile.
6. Comment déterminer quelles métriques sont pertinentes ?
Dans mon expérience, on n'a pas commencé avec le jeu de métriques qu'il fallait. C'est vraiment un processus itératif. De toute façon, dans tout ce qui est développement informatique, c'est toujours un processus itératif parce que le système qui est mesuré change en permanence. Et donc ça n'a pas de sens de fixer des métriques qui sortent de nulle part et puis décider que c'est le jeu de métriques que l'on va suivre. C'est constamment: est-ce que mes métriques sont valables, est-ce qu'elles disent quelque chose ? C'est vraiment se poser en permanence ce type de questions.
Au départ, je pensais qu'il y aurait des réticences, mais en fait on n’en a pas eu. Les individus sont mus par la même volonté de faire du bon boulot. Mais je pense que fondamentalement c'est ça. C’est-à-dire si les gens sont investis dans leur travail, de voir que si le code qu'ils écrivent il sert à quelque chose et à quelqu'un, alors ils demandent à s'occuper du support client, car c'est vraiment quelque chose qui permet d'apprendre. Ça permet de mieux comprendre la qualité de son travail. Après il y a eu des difficultés qui sont plus dans l'ordre de la gestion du temps parce que ça peut très vite prendre beaucoup de temps. Nous, on a essayé de laisser les gens relativement libres dans leur expression, mais de manière générale il faut quand même avoir des règles de base de courtoisie, de choses vraiment élémentaires. On a eu des questions pour faire tourner le support client sur de grosses structures et là je peux comprendre que ça ne se passe pas de la même manière. Mais je pense que c'est vraiment ce que je voulais éviter, c'était d'avoir un support client qui soit complètement déconnecté des ingénieurs. Quand les ingénieurs font le support client, l'avantage c'est que lorsqu'ils voient un problème, ils sont capables de le régler par eux même, ils ne sont pas complètement impuissants. Ils ne sont pas coincés entre le développement et le client. Ils ne sont pas dans la situation "J'ai un problème, mais je ne peux pas le régler". Je pense que quand le support client est dans cette situation là ce n'est pas agréable. D'un côté une personne n'est pas contente et de l'autre c'est des gens qui n'ont pas que ça à faire. C'est aussi une des raisons pour laquelle des ingénieurs font le support client.
La règle cardinale c'est que la personne qui écrit les logs soit aussi la personne qui les lisent. En tant que développeur, naturellement on a tendance à logger un maximum parce que l'on sait jamais et après quand je lis les logs, il y a plein d'information qui sont en fait pas exploitable. Ça permet de revenir sur le code et de se dire "ok, ça je pensais que c'était de l'information, mais en fait c'est du debug". C'est utile au début pour régler un peu le software, mais après opérationnellement ce n’est pas utilisable. C'est, je pense, la règle de base. Et que ce ne soit pas une personne qui écrit les logs et une autre personne qui les lisent sinon ça ne marche pas. Il faut vraiment cette boucle de feedback. Ensuite il faut investir du temps dans une librairie de logging, qui soit utilisé par tout le monde et facile à utiliser. Utiliser des choses comme StatsD, ça, c'est vraiment intéressent, ça permet de collecter des métriques en temps réel sans impacts sur la performance, ça, c'est très important. Après ça va dépendre de chaque environnement, mais de manière générale, écrire les logs, les lire, voir ce qui marche, ce qui ne marche pas. C'est de toute façon un processus itératif, c'est un apprentissage constant.
Le cout du monitoring il est négligeable, tu vas avoir un impact en terme de performance. Il y a plus ou moins 4 ressources de base, CPU, mémoires, réseau et stockage disque. CPU et mémoires tu peux garder ça à faible niveau. Réseau, avec la compression c'est pareil et les réseaux maintenant sont plus ou moins haut débit donc ce n’est pas un problème. Le stockage c'est plus ou moins le seul problème qui existe. En terme de logs ça veut dire faire cet exercice d'aller lire les logs en permanence et voir ce qu'il faut enlever et ajouter. En terme de métrique pure, c'est négligeable. Si c'est mesurer la performance ou faire le monitoring d'une application, collecter un ensemble de chiffres qui arrivent en permanence, ce n’est rien.
Merci Alexis pour avoir répondu à toutes ces questions pour InfoQ.