Devops et le facteur humain

L’objectif de ce billet est, à travers des exemples concrets, de vous (re) démontrer à quel point DevOps n’est pas un problème d’outils mais un problème humain.

Repartons de l’objectif : DevOps vise à nous amener à réduire le Time-To-Market, donc à pouvoir faire des déploiements rapide et fiables. Si on décline cet objectif, il faut

• Savoir ce qu’on déploie (sic) => avoir un système de release management
• Savoir déployer vite => automatisation du déploiement
• Savoir déployer de manière fiable => tests automatisés et plateforme d’homologation

Dit comme cela, nous avons l’impression qu’il va nous falloir un outil de release management, un outil d’automatisation, et un outil de test. Exact. Mais en fait, la difficulté n’est pas là.

Le release management

Prenons tout d’abord le release management. Dans une organisation classique, on utilise un gestionnaire de demandes pour gérer les bogues et les nouvelles fonctionnalités. Après une itération, on embarque tout ce qui a été fait, on valide et on déploie. Le gestionnaire de demande devrait donc donner le contenu d’une version. Il y a en fin d’itération, un comité qui valide la version et décide de l’envoyer en production.

On voit facilement que ce système ne peut convenir pour plusieurs déploiements par jour. Comment faire dans ce cas ? Il faut avoir un système qui permet de créer une version et la mettre en production sans décision humaine (sauf l’initiale). Cela implique donc, que, quand un développeur corrige un bug, il doit pouvoir mettre en production. Plus de Comité d’Approbation du Changement, plus de réunion de GO / NOGO de mise en production ou autre. L’équipe (au sens large orientée produit) a défini ses standards de qualité, et si ceux-ci sont remplis, la mise en production peut être décidée par n’importe qui. Un exemple de standard de qualité est : revue de code faite par un pair et tests automatisés en pré-production au vert. Ce standard est largement automatisable.

Ce changement est fondamental, car il remet en cause pas mal d’organisationnel :

• Quel est le rôle de l’équipe de recette ?
• Comment l’équipe support sait-t-elle ce qui est déployé ?
• Quel est le rôle du chef de projet / release manager ?

Si l’organisation concernée freine à répondre à ces questions, le changement aura du mal à se faire. Dans ce contexte, le rôle du manager est de rassurer tout le monde et de donner le cap. Un accompagnement est nécessaire la plupart du temps.

L’automatisation et la fiabilité

Lors de mon dernier projet, un Ops m’a dit “J’ai l’impression d’être remplacé par un script”. C’est en partie vrai. Comme toutes les tâches doivent être rendues plus fiables et plus rapides, la meilleure solution est souvent de les automatiser. Pour pouvoir faire plusieurs dizaines de déploiements par jour, il faut non seulement automatiser, mais il faut aussi avoir confiance dans les déploiements. Cela passe par la mise en place des tests. Or, si les Ops sont déjà souvent automatisés, rares sont ceux qui sont équipés de tests. Il vont donc devoir apprendre à en faire, et devront probablement être accompagnés pour cela. Et c'est une bonne occasion de travailler avec les Devs, qui sont en général plus matures sur ce sujet.

Un autre point important est que l’on n’automatise pas seulement la production. La pré-production sera naturellement déployée avec les mêmes outils que la production, mais pour réduire les différences entre les environnements et donc fiabiliser le processus, nous allons chercher à utiliser les mêmes outils pour tous les environnements, recette, intégration et même développement. L’objectif est double : éviter le fameux «chez moi, ça marche», et donner en développement les mêmes outils qu’en production (par exemple le monitoring, les clusters de base de données, les systèmes de gestion de logs…). C’est aujourd’hui relativement facile grâce à la virtualisation et à la maturité des outils comme Chef, Puppet, Vagrant… A titre d’exemple, lors de notre dernier projet, le même système de déploiement déployait 10 environnements de développements, 10 de recette et d’intégration, une pré-production et une production, pour un total de plus de 800 machines virtuelles.

Le système de déploiement sera donc un artefact commun aux équipes Dev et Ops. Il est indispensable qu’il soit construit par les 2 équipes en concertation, chacune amenant ses besoins et ses solutions. Construire ce système d’un seul coté ne traite que partiellement le problème, c’est une approche à éviter.

Les Devs ont besoin des Ops, et les Ops ont besoin des Devs

Voici 2 exemples concrets pour expliquer cela :

Comment mettre à jour une application sur un cluster de 10 machines, associée à une migration de schéma de base de données ? Le tout sans interruption de service ? La solution est souvent la suivante : concevoir une application qui fonctionne avec les 2 versions du schéma de base données (avant et après) (impact coté Dev), et déployer l’application serveur par serveur, en sortant le serveur du cluster (impact coté Ops).

Un autre exemple : comment mettre en haute disponibilité Solr (un moteur d’indexation) ? Après de longues discussions, la solution retenue est de ne pas le mettre en haute disponibilité, mais de migrer la fonctionnalité sur Elastic Search (impact coté Dev).

Que retenir de ces exemples ? Que c’est la discussion entre les 2 équipes qui a permis de définir ces deux solutions. Et que chacune des 2 équipes n’auraient pu arriver seule à cette solution.

On constate la même chose dans les outils : les Devs vont devoir s’intéresser à ce que se passe en production, voir même aller déboguer sur la production. Ils vont donc devoir utiliser des outils Ops pour s'y connecter et y travailler: par exemple SSH, tcpdump, cat, tail, find... Hélas, j'ai vu assez peu de développeurs maitriser ces outils. Et les Ops vont devoir comprendre comment fonctionne l’application pour pouvoir la gérer, et donc utiliser des outils Dev, par exemple VisualVM (pour monitorer une JVM) ou Sidekiq (un moteur de jobs asynchrones). Autre exemple : rares sont les Devs qui savent ce qu’est un load balancer, rares sont les Ops qui savent faire marcher un ORM. Or les 2 sont souvent nécessaire pour la bonne marche du système.

Comme pour tout changement, il y aura résistance. C’est cette résistance qui va être la principale difficulté de votre projet DevOps. C’est la dessus que vous aurez probablement besoin d’accompagnement.

Ne commencez pas votre projet DevOps par choisir un outil. Au lieu de cela, demandez au Devs ce qu’ils sont prêts à confier aux Ops, et aux Ops ce qu’ils sont prêts à confier aux Devs.