DevOps BuzzWord, les dérives du système

Comme tout buzzword qui se respecte, le DevOps est largement galvaudé et perd son sens original. À force de l’entendre utilisé à toutes les sauces, nous sommes proches de l’indigestion.
Aussi ai-je décidé de me fendre d’un article pour tenter de combattre les idées reçues. Prenons en quelques unes, pour leur tordre le cou une bonne fois pour toute.

Cherche profil DevOps

Faites une recherche, vous pourrez constater que les offres d’embauches pour des profils DevOps pleuvent sur LinkedIn et autres job boards du marché. Qu’est-ce qu’un tel profil signifie ? Il s’agit souvent de profils maîtrisant les moteurs d’intégration continue, éventuellement développeur mais toujours adepte de l’automatisation. On vous expliquera que ce profil est à la croisée des chemins car il cumule les compétences d’un développeur et celles d’un admin. Stop ! S’il existe vraiment des personnes reconverties du développement à l’exploitation et vice-versa, le métier de chacun reste bien développeur ou exploitant et non les deux. D’une façon générale et sauf exception, car il y en a toujours, un développeur sait réaliser des applications, là où un Ops maîtrise le système sur lequel elles s’exécutent.
DevOps n’est pas un profil, mais une culture d’entreprise. Résumer cela à un profil est un raccourci facile et dangereux. On ne cherche pas des profils, mais on cherche à nourrir une culture.

Automatisation égale DevOps

Régulièrement, je me rends compte que pour mes interlocuteurs, faire du DevOps signifie automatiser. Après tout, si l’on automatise la chaîne de déploiement, il semble que l’on règle tous les problèmes. Bien souvent, la proposition consiste à prendre les processus existants pour les automatiser, sans plus de réflexion. À notre tour, prenons un peu de recul. J’ai rencontré par exemple des équipes capables d’automatiser la création de tickets pour réserver des créneaux de mise en production. Si la prouesse technique est respectable, l’automatisation dans ce cas n’améliore en rien le processus global. L’automatisation n’a de valeur que si elle est le fruit d’une collaboration entre les équipes. Elle doit en outre permettre de gérer des tâches répétitives n’ayant que peu de valeur ajoutée. Le but d’une automatisation est précisément de libérer du temps pour revenir à l’essentiel : créer de la valeur. Notre but avec DevOps est de nous inscrire dans une amélioration continue pour pouvoir livrer de manière fluide de la valeur stable et maîtrisée aux utilisateurs finaux. Pensez-vous réellement qu’automatiser des processus désuets fasse partie de la solution ?

La stack DevOps

Dans la même veine que l’automatisation, j’entends régulièrement parler de la stack ou du framework DevOps. Les éditeurs s’en donnent à coeur joie, pour vous vendre des solutions tout-en-un. Pour enrichir les outils d’automatisation, on associe le graphe, le monitoring, la centralisation des logs, un petit serveur d’intégration continue et un orchestrateur pour lier le tout. Ne nous méprenons pas, ces outils ont leur juste place dans vos plateformes. Gardez en tête que mettre en place une stack DevOps ne revient pas à adopter la culture DevOps. Ne tentez pas d’apporter une réponse technique à un problème qui ne relève pas de la technique mais plutôt des relations humaines. Avoir les meilleurs outils du monde ne sert à rien s’ils ne sont pas adaptés à votre contexte. Certes, les grandes sociétés du web partagent leurs outils, mais ils sont le fruit d’une longue histoire intimement liée au contexte de l’entreprise. Ne cherchez donc pas à tout prix à construire une stack DevOps, cherchez plutôt à répondre à vos problèmes concrets en repensant votre organisation et vos processus.

Équipe DevOps

Attention, il y a un piège dans cette dénomination. Créer une équipe DevOps peut avoir du sens. En effet, il semble bon de réunir les bonnes pratiques de collaboration, d’automatisation et d’amélioration continue au sein d’une équipe ayant pour mission de diffuser la culture. Toutefois, ne nous trompons pas de but. Il doit s’agir de transformer le mode de fonctionnement des projets. Cette équipe, au-delà des outils et technologies utilisés, doit obtenir l’adhésion de l’ensemble des collaborateurs qu’ils soient devs, ops, décideurs ou métier. La langue française est riche et les mots ont un sens.
Une équipe ainsi nommée se sentira plus responsable de mettre en place des outils, que de changer la culture de l’entreprise. C’est aussi le message qui risque d’être reçu par le staff.
Si votre but est bien d’adopter un esprit commun DevOps à travers cette équipe, nommez-la dans ce sens : “Équipe de transformation DevOps” par exemple. Si équipe il y a, n’oubliez pas que vous commencez par ajouter une nouvelle interaction dans un système déjà complexe. Le risque est d’aboutir à de nouveaux processus toujours plus complexes qui, au lieu de fluidifier l’organisation, vont la freiner un peu plus.

Continuous Delivery

Pour finir, parlons un peu de déploiement continu ou de livraison continue. Quel est selon vous le but de DevOps ? Beaucoup diront, sur la base de la fameuse présentation de John Allspaw et Paul Hammond, qu’il s’agit de faire du déploiement continu comme Flickr. Dans cet exemple, je considère qu’il s’agit plus exactement d’un effet de bord de l’adoption d’une culture DevOps. Bien sûr, être capable de livrer en continu des applications sur la production est une belle promesse. Toutefois, livrer des versions en production n’est pas une fin en soi. Vous risquez de vous contenter d’empiler des releases, qui généreront du bruit sans améliorer réellement l’expérience de vos utilisateurs finaux. Tout le monde, n’a pas les mêmes problèmes que Facebook, Twitter, Flickr ou Netflix. Alors posez vous la question, y a-t-il un réel goulot d’étranglement sur votre production ? Avez-vous besoin de livrer des dizaines de versions par jour en production ? L’avantage avec DevOps, c’est qu’il n’y a pas de méthode toute tracée. DevOps est une culture de la collaboration à adopter et cultiver, pas une nouvelle méthodologie. Enfonçons une porte ouverte : chaque entreprise a une culture et une histoire qui lui est propre, c’est pourquoi l’adoption d’une culture DevOps doit prendre une forme adaptée au contexte pour réussir.

Pour conclure

À l’origine, DevOps propose de rapprocher les devs et les ops dans le but de collaborer et d’inscrire ces équipes dans un objectif commun : produire de la valeur pour l’entreprise. L’idée vient du constat que ces équipes avaient des objectifs antagonistes, source d’incompréhension, de friction et de lenteur. Il faut donc un changement culturel pour aligner les équipes, c’est ce que l’on appelle la culture ou l’idéologie DevOps. Nous nous concentrons sur les devs et les ops, pourtant ils ne sont pas les seuls impliqués dans la production de valeur informatique. Introduire la sécurité dans l’équation est essentiel, ajoutons donc un peu de Sec à DevOps pour obtenir DevSecOps. Allons-nous devoir ajouter encore des acronymes pour comprendre que c’est l’ensemble de la chaîne de production qui doit être alignée ? Personnellement, je me contenterai du terme DevOps pour inclure le processus dans son ensemble. Il existe tout de même quelques guides à appliquer pour réussir une transformation DevOps :

• Instaurez la collaboration, par des échanges réguliers
• Mesurez la valeur apportée à l’entreprise
• Adoptez les cycles courts et l’amélioration continue des méthodes agiles
• Ouvrez la porte à l’innovation, pour trouver des solutions nouvelles
• Maintenez cet effort dans la durée, n’ayez pas peur d’y investir du temps et des hommes
• N'hésitez pas à impliquer le management

DevOps n’est ni une technologie, ni une méthode, ni une personne ! Ne perdez jamais de vue qu’il s’agit d’abord de collaboration et d’amélioration continue.