DevOps, pourquoi n’y avons-nous pas pensé plus tôt ?

Assez curieusement, la première fois que je vis le mot « devops » écrit, ce n’étais pas dans un article de blog ni dans un ouvrage technique ni même sur Wikipedia. Non, je le lus dans le CV qu’un ami m’avait envoyé afin que je lui donne mon avis.

Mon ami et moi eûmes peu de temps après un entretien au téléphone et je lui posai la question suivante : « Pourquoi as-tu écrit devops dans la description de ton profil ? » Il tenta de m’expliquer ce que recouvrais ce terme et cessa quelques instants après qu’il s’est aperçu que je n’y comprenais rien. Il réfléchit un court moment et me dit : « il s’agit de tout ce que l’on n’aurait pas du faire lorsque nous avons travaillé ensemble entre 2004 et 2006 ». Et je compris aussitôt ce qu’était devops ou, du moins, ce que devops essayait de résoudre.

A l’époque évoquée par mon ami, je travaillais comme consultant Oracle pour un célèbre opérateur de téléphonie. Mon domaine d’activités au sein de l’équipe projet ne tarda pas à s’étendre à l’intégration de la solution logicielle dans le SI de l’opérateur avec tout ce que cela comprend comme gestion de l’ordonnancement des jobs, de la supervision générale, de la reprise d’activité des composants de la plateforme et, accessoirement, de l’amélioration des performances des accès à Oracle. Soit dit en passant, je n’ai pas écrit une ligne du logiciel que nous étions censé concevoir. A la place, j’ai réalisé tout un tas d’outils périphériques pour gérer les services de la plateforme, lire des journaux de log, importer et exporter des données et créer des planifications de tâches.

L’équipe a reçu du renfort en 2004 avec l’arrivée de mon ami en tant que concepteur Java. Inutile de dire qu’il n’a pas écrit beaucoup plus de lignes de Java que je n’avais conçu de schéma de bases de données puisqu’il a été happé par les mêmes tâches que moi. Nous avions migré du domaine du développement au domaine des opérations et notre travail consistait à assurer la liaison entre les développeurs et les administrateurs système car ces deux communautés, appartenant à des services différents composés de personnels ayant des statuts différents ne communiquaient pas.

Ces problèmes de communication qui existent entre une communauté de développeurs et une équipe en charge de la maintenance d’un système d’information ont pour conséquence, par le principe de Conway [1], que des logiciels de qualité, adaptés au besoin fonctionnel et conçus par des développeurs talentueux dans un cadre méthodologique maîtrisé se révèlent être des cauchemars à installer et à configurer, affichant des performances désastreuses et présentant un comportement en exploitation totalement erratique et impénétrable.

C’est exactement ce qui se produisit dans le projet pour lequel mon ami et moi travaillions.

Pour tenter de comprendre cette situation, examinons ce que Melvin Conway a dit un jour. « Les organisations qui conçoivent des systèmes sont limités à concevoir des systèmes dont l’architecture n’est qu’une copie des structures de communication de ces organisations » [2].

En des termes plus triviaux, cette sentence indique que si, pour une foule de raisons, développeurs et exploitants s’ignorent, ne se font pas confiance et, en un mot, ne communiquent pas, il y a fort à parier que la solution logicielle conçue par les premiers sera considérée par les seconds comme l’équivalent numérique d’une machine infernale.

Par le même principe, nous étions, mon ami, moi et deux autres collègues, un élément de cette organisation et nous avons conçu notre propre projet, un ensemble assez hétéroclite de scripts écrits Perl et en Python, de modèles de déploiement Ant, de programmes en PL/SQL incorporés dans Oracle et de documents de configuration de système d’exploitation. Nous avions notre propre zone dans le gestionnaire de configuration et dans la GED et nous étions autonomes quant aux choix technologiques que nous avions à faire. Grâce à nos efforts et de notre point de vue, la situation s’est largement améliorée pour les exploitants et pour les développeurs mais pas pour nous.

Nous étions blâmés pour chaque environnement livré en retard, pour les problèmes de performances de la base de données, pour les erreurs de compatibilité avec le système, pour les dépendances manquantes et, si je me souviens bien, pour avoir une consommation excessive de café et de tabac.

Nous étions devenus un point central du système vers lequel développeurs, testeurs et exploitants convergeaient tous espérant que nous apporterions la solution. En réalité, nous étions devenus le Single Point of Failure de l’organisation du projet. Nos opérations, toutes manuelles, étaient cependant testées mais n’étaient pas reproductibles. Nos tâches d’installation, de configuration et de supervision nous accaparaient un temps précieux que nous ne pouvions pas mettre à profit pour communiquer, expliquer et partager nos connaissances. Enfin, l’organisation du projet et la culture de l’entreprise excluaient toute approche basée sur un cycle d’amélioration continue et promouvaient même un certain conservatisme méthodologique.

Pourtant nous étions une équipe pluridisciplinaire, aussi à l’aise avec le développement, les tests ou la documentation qu’avec le déploiement ou le tuning. Nous connaissions bien nos produits et nous étions passionnés.

Que nous a-t-il manqué pour réussir ?

Une organisation décloisonnée. Des automates de configuration et de déploiement. Des interlocuteurs à notre image, ouverts et coopératifs et un moyen de démontrer que nous faisions des progrès effectif.

Ces quatre éléments sont ce que l’initiative devops considère comme étant ses principes fondateurs. Les organisations bâties en silos du type une équipe de développement, une équipe de test et une équipe d’infrastructure ne produisent pas de bons logiciels. Devops, comme Agile, cherche à décloisonner les structures des projets informatiques pour mettre en place les conditions d’émergence d’une équipe interdisciplinaire et soudée dont les membres s’estiment et se font confiance.

Si l’intégration continue est un principe maintenant bien connu après quelques années d’application des diverses méthodologies agiles, le déploiement continu reste peu et mal adopté. Son principe est similaire à celui de l’intégration continue : déployer souvent et plus vite pour que le déploiement devienne une activité routinière plutôt que de rester cet événement risqué sur lequel les projets mettent en jeu leur survie.
Et parvenir à ce degré de maturité nécessite d’automatiser les tâches de préparation et de configuration des infrastructures et des plateformes au moyen de scripts et de logiciels de virtualisation.

Le partage de connaissance et l’évangélisation sont des facteurs de réussite importants de la mise en place d’une organisation devops comme ils le sont pour Scrum par exemple. Il est essentiel d’avoir un soutien sans faille du product owner fonctionnel d’une part mais aussi du DSI qui devient aussi un product owner. Les exploitants cessent ainsi de subir les solutions logicielles pour en devenir des utilisateurs à part entière car ils utiliseront les fonctionnalités d’exploitation qu’ils auront eux-mêmes aidé à spécifier et à développer.

Le dernier élément à prendre en compte est la mesure effective du progrès. On réalise cet aspect en devops de la même manière qu’on le réalise dans le cadre de l’intégration continue : par la mise en place d’un système de déploiement automatisé qui récupère les éléments nécessaires d’infrastructures et de plateformes virtuelles depuis le gestionnaire de configuration, qui déploie ces éléments de façon automatique et qui notifie les parties prenantes du projet du succès ou de l’échec de cette opération.

Les cinq aspects que j’ai évoqué dans cet article (équipe pluridisciplinaire, organisation décloisonnée, automatisation, communication et mesure) supposent des pré-requis humains et technologiques. Je décrirai ces pré-requis dans un second article au sujet de devops.

[1] Principe de Conway
[2] Conway, Melvin E. « How do committees invent. » Datamation 14.4 (1968): 28-31.