La semaine dernière nous avons eut l’occasion de participer à un open-space sur le sujet des métriques. La question posée était : “Quelles sont les métriques à monitorer pour améliorer la collaboration entre les équipes de Développement et les équipes d’Éxploitation ?”.
On as eut pas mal d’idées, divergés sur d’autres sujets mais nous avons notés une liste de métriques intéressantes à mettre en place dans ce but. Sans plus attendre, les voici:
| Durée des tests | Tout déploiement devrait d’abord être validé par les tests, un build court profite à tout le monde | Le plus petit possible | Mocker plus de services côté dev ou installer et configurer un serveur de DB en RAM |
| Durée de déploiement | Plus un déploiement est long, plus on attendra pour avoir la dernière feature ou le dernier fix en production. Des déploiements plus courts c’est plus de déploiements possibles. | Le plus petit possible | Packager le code applicatif en ZIP / DEB / RPM ou installer un mirroir de package système / python / ruby pour accélerer les déploiements |
| Fréquence de déploiement | Des déploiements plus fréquents, c’est des features qui arrivent plus tôt pour les clients et des commerciaux plus content | Le plus proche du besoin produit | Travailler le workflow, réduire les points de douleur dans le déploiement, côté code applicatif ou côté migration de données |
| Taux de réussite du déploiement | Personne n’aime faire d’erreur mais ça arrive, il faut faire en sorte d’apprendre de ses erreurs | 100% | Monitorer les déploiements, passer à un outil de gestion de configuration, fixer chaque erreur pour éviter que ça se reproduise |
| Temps moyen pour déployer une nouvelle feature | Souvent les nouvelles features stagnent en attendant une release ou sont reportées parce que les besoins ont étés mal anticipés, nouveau serveur, nouvelle technologie… | Le plus petit possible | Faire participer les équipes d’exploitation aux réunions d’architecture, travailler le workflow, faire collaborer les équipes sur l’écriture de recettes de déploiement |
| Pourcentage de serveurs automatisés | Les serveurs non automatisés sont souvent ceux qui nous trahissent au plus mauvais moment | 100% | Écrire des recettes de configuration pour ces anciens serveurs |
| Pourcentage de tâches manuelles | Il reste souvent des tâches manuelles à faire lors du déploiement, à la création d’un nouveau client, etc… Ces tâches sont une source probable d’erreurs, on peut les oublier, la personne qui les fait d’habitude peut-être en maladie, en vacances, etc… | 0% | Écrire des scripts, intégrer les tâches dans le code applicatif |
| Pourcentage d’écarts entre les environnments | On ne peut pas souvent se permettre d’avoir des environnements parfaitement conforme à la production, souvent pour des question de coût. Ça peut-être une version de la DB différente, des règles réseau différentes. Ces différences sont une source de problèmes potentiels | 0% | Identifier les différences et les réduire. Donner la responsabilité de l’ensemble des environnements aux deux équipes |
| Temps de livraison d’une nouvelle machine / d’un nouvel environnement | Même si les déploiements sont entièrement automatisés et rapide comme l’éclair, il reste parfois des opérations qu’on fait peut souvent, à la création d’une nouvelle machine ou d’un nouvel environnement, ce qui nous ralentit si elles ne sont pas automatisées | Le plus petit possible | Identifier ces opérations et qualifier le ration temps à automatiser / (temps à faire à la main) * fréquence |
| MTTR, mean time to recover | Automatiser le déploiement c’est nécessaire, pouvoir fixer la production rapidement, ça l’est tout autant | Le plus petit possible | Améliorer le monitoring, automatiser la collection d’information, centraliser la collecte des logs, automatiser les actions courantes tel que mettre le site en maintenance, écrire et suivre une doc de réponse aux incidents |
Toutes ces métriques sont utiles pour identifier des améliorations réalisable par les efforts combinés des équipes de dévelopements et les équipes d’exploitation. Néanmoins en fin de session, on s’est demandé si il n’y aurait pas des métriques intéressante pour l’ensemble du cycle de développement et celà s’est révélé plus difficile que pour les autres. Nous en avons réussi à en identifier une qui englobe au final plusieurs citées auparavant :
- Temps moyen entre l’acceptation d’une feature et son déploiement
Cette métrique est intéressante par elle concerne à la fois la collboration entre le product owner et les développeurs et la collaboration entre les développeurs et les administrateurs système. Et vous avez-vous des idées de métriques que vous avez mis en place ou que vous pensez pertinentes ?
EN’oubliez pas que vous pouvez suivre les actualités de parisdevops sur le channel irc #parisdevops de freenode, sur le compte twitter @parisdevops et sur notre site web: parisdevops.fr
Merci à tous!