La difficulté de la mise en place du DevOps dans une entreprise

"DevOps", ce mot, on ne peut plus voir une offre d'emploi dans l'IT à des postes d'infrastructure ou développement sans qu'il soit évoqué. De nombreuses entreprises prennent le virage du DevOps, les idées et les notions se mélangent, la cible est souvent floue, alors que les objectifs sont limpides, conduire cette transformation est donc loin d'être une tâche aisée.

Cet article est écrit en collaboration avec Pierre Galdon, ami ingénieur SysOps avec qui j'ai travaillé durant plusieurs années.

Il n'y a aucun doute quant au fait, qu'avant d'arriver sur ce billet vous avez lu des définitions, des articles, peut-être participé ou exposé à des conférences, bref vous avez votre idée sur le sujet. Nous ne présumons pas vous faire changer d'avis, ce n'est pas le but. Nous résumons ici ce que nous avons pu apprendre de nos expériences en tant que spectateur et acteur de ce changement majeur de l'IT ces dernières années.

Pourquoi le DevOps, et d'abord qu'est-ce c'est ?

On aura entendu "Le DevOps ce sont des méthodes, comme l'agile", ou encore "Non, le DevOps c'est la collection d'outils, qui nous permet d'automatiser", je (Pierre) crois que le DevOps c'est tout cela et plus encore. Nous retiendrons surtout la définition de son objectif.

Le rôle du DevOps est d'améliorer la collaboration entre les équipes de développement, et les ingénieurs de production. Le principe étant d'augmenter les interactions entre les deux parties. De ces interactions, les fruits sont nombreux: réduire le time to market, augmenter l'agilité des équipes,... Cela permet aussi de monter en compétence ensemble, en augmentant le nombre de sujets de partages, axés autour de problématiques affrontées ensemble.

Le but est donc de casser les barrières entre les deux équipes / camps / clans, afin de produire des applications (applicatif + infrastructure) de qualité supérieure, en unifiant les pratiques de développement et de production.

Le développement et la production : Deux mondes que tout oppose ?

C'est sans doute le premier souci, dans un monde idyllique, le DevOps n'a que des avantages. Malheureusement, souvent les attentes des Dev et des Ops ne sont pas les mêmes. La où un développeur va livrer un applicatif, qui doit répondre à des contraintes métiers, à des contraintes de stabilités, et éventuellement à de la sécurité (Le security by design n'étant pas encore assez répandu), un Ops doit de son côté s'occuper de l'observabilité, de la sécurité, et de la fiabilité de l'infrastructure et des middlewares qui servent à héberger la solution. Sur le papier, aucune incompatibilité à prévoir. Pourtant très souvent, des tensions se créent, réduisant la qualité du travail, car les objectifs donnés aux deux faces de l'équipe sont trop éloignés l'un de l'autre.

Imaginons la conversation suivante autour d'une application quelconque:

"On m'a demandé de livrer la feature Trop_bien_2"
"On a pas anticipé la charge engendrée par la feature Trop_bien_1, on a besoin de stabiliser l'application"

Elle résume parfaitement ce qui est décrit ci-dessus : deux points de vue qui semblent opposés, dont les buts respectifs contribuent à l'amélioration de l'application. C'est ici que tout se joue, réussir à réconcilier les acteurs en leur offrant un discours rationnel, clair, et cohérent.

Motiver les équipes à travailler ensemble plutôt que les y forcer

De part mes expériences professionnelles, le modèle que j'ai vu fonctionner pour une collaboration en mode DevOps est celui de sensibiliser les équipes, leur expliquer pourquoi l'entreprise à choisi d'aller vers ce modèle et les avantages qu'elle compte en tirer. Forcer les gens à travailler ensemble parce qu'on l'a décidé créé toujours de la résistance et réduit l'adoption de méthodologies DevOps.

Il est important de sensibiliser ses équipes car il faut comprendre que des collaborateurs ont sans doutes connu d'autres méthodologies "miracles" avant, et n'en ont pas forcément gardé de bons souvenirs.

Il ne faut pas négliger non plus l'importance du leadership et de l'exemplarité, des managers motivés, qui arrivent à mettre leurs ambitions de côté pour une collaboration saine et productive, seront certainement votre meilleur argument pour convaincre les équipes.

Améliorer les relations entre Dev et Ops

Ce point est pour moi un prérequis pour mettre en place plus facilement du DevOps au sein d'une entreprise. Il faut créer des échanges concrets entre Dev et Ops. Cela peut passer par de multiples méthodes, comme par exemple de manière non exhaustive :

• Le mode "one team", ne plus parler de Dev ou d'Ops mais de feature team sans forcément faire le distinguo entre les deux, cela permet de créer une unité au sein de l'équipe.
• Fixer des objectifs aux deux parties qui ne peuvent être atteint qu'en collaborant
• Organiser des workshops, que ce soit par un prestataire externe ou par des collaborateurs internes, autour de sujet pouvant intéresser les deux côtés.
• Organiser des chaos day (j'en parlais il y a quelques mois)
• Si les équipes ne sont pas localisées proches l'une de l'autre, il peut aussi être utile d'organiser des "safaris", faire travailler un Dev dans l'open space des Ops par exemple, cela permet de comprendre certaines problématiques auxquelles peuvent être confrontées les personnes.

Un peu de team building ne fait pas de mal, organiser des déjeuners, sorties, afterworks, fluidifieront les relations entre collègues, et faciliteront les prises de contact par la suite.

Ne pas faire de cadrage de projet, parce qu'on est "agile"

Je ne m'étalerais pas sur cet amalgame souvent fait entre DevOps et Agile, mais j'ai souvent entendu, lorsque j'étais Ops et que je me plaignais que les specs changeaient tous les deux jours : "on est agile, il faut t'adapter". NON, être agile ne signifie pas faire n'importe quoi n'importe comment n'importe quand. NON, être agile ne signifie pas avoir des specs qui sortent du chapeau tous les deux jours. Ce genre de points peut au contraire créer de la frustration au sein des équipes et réduire l'adhérence qui peut se créer entre Dev et Ops.

L'ensemble des aspects doit être pris en compte dans le cadrage du projet, ce, quelques soient les méthodes appliquées, et même au-delà du cadrage, durant toute la vie de vos applications.

En conclusion

Le modèle DevOps peut améliorer la productivité au sein des entreprises, le souci est pour moi que beaucoup d'entreprises l'ont vu mis en place avec succès chez de gros acteurs, et notamment les GAFAM, et ont voulu l'imposer tel quel, sans forcément emmener leur équipes avec eux. Le modèle DevOps n'impose pas de règles strictes identiques d'une entreprise à une autre, mais des modèles de collaborations. Il est nécessaire d'adapter ces modèles au fonctionnement et à l'historique de sa DSI, et de les diffuser le plus clairement et concrètement possible, sans quoi, la désorganisation et la résistance au changement s'installent.