Trois éléments clés pour éviter l’échec de vos initiatives DevOps
Le DevOps est considéré aujourd’hui comme le modèle de « delivery » de référence. Pourtant sa mise en place et sa compréhension amènent à des régressions parfois décourageantes. Voici quelques solutions à mettre en œuvre pour faire de ces pratiques un succès.
par
Arnaud Wetzel, CTO de kbrw
Publié le: 06 sept. 2023
Alors qu’une large majorité des DSI considèrent l’application du DevOps comme clé pour la réussite de leur organisation, Gartner prédisait que 75 % des initiatives DevOps dans les entreprises allaient échouer en 2022. L’important pour comprendre cet écart (et le combler) est :
d’appréhender la nature et l’objectif du modèle,
puis de voir comment améliorer sa mise en œuvre organisationnelle,
et enfin de souligner la place fondamentale d’une approche plateforme.
Devops n’est pas une méthode ou un outil, mais l’agilité des opérations techniques.
« L’agilité est la capacité de la chaîne de décisions à intégrer le risque à l’exécution […] et ne pas le faire porter intégralement à son exécutant. »
Arnaud Wetzelkbrw
Qu’est-ce que le DevOps ? Pratiquer l’« infrastructure as code », l’intégration continue, l’automatisation des opérations, utiliser des outils spécifiques ? Souvent, les réponses se focalisent sur le « comment » sans aborder le « pourquoi », qui est pourtant essentiel pour établir et piloter les objectifs de l’implémentation du modèle.
Les projets logiciels sont complexes et les échecs nombreux. Empiriquement, on constate que la capacité à s’adapter au changement est essentielle dans un processus de livraison de valeur continue, et les opérations en font partie. Le DevOps serait donc une extension des méthodes agiles pour un modèle de développement itératif.
Mais cette définition ne suffit pas. De mon point de vue, l’agilité d’une organisation est la capacité de la chaîne de décisions à intégrer le risque à l’exécution, quand il est très important et ne pas le faire porter intégralement à son exécutant.
Le processus itératif n’est qu’un moyen pour aligner les contraintes des développeurs avec la décision des jalons métier.
Devops est l’agilité des opérations techniques. Son objectif est donc d’intégrer les risques de celles-ci dans les processus et la responsabilité des développeurs : sécurité, conformité, performance, continuité de service, délai de déploiement et de mise en place du support.
Planifier la transformation de votre organisation DevOps
Une fois cet objectif défini, on comprend les problèmes qui sont fréquemment rencontrés dans les stratégies de mise en œuvre du DevOps :
Les équipes dev deviennent des équipes « devops ». Ici on rencontre un problème de compétence et de charge de travail. Sécurité, performances, supervision, etc. sont des sujets de haut niveau de compétence. Le développeur – même assisté d’une plateforme et d’un haut niveau d’automatisation – ne pourra prendre réellement part à la responsabilité des risques d’exploitation. La sécurité est souvent la grande perdante de cette approche.
Les équipes sysadmin deviennent des équipes « devops ». En changeant les méthodes et les outils des opérateurs de l’exploitation, avec « l’infrastructure as code » par exemple, on fluidifie les relations de dépendances entre dev et ops. Mais on augmente la complexité de la stack. La spécialisation nécessaire pour maîtriser cette nouvelle gamme d’outils va avoir tendance à cloisonner les responsabilités et accentuer la relation client-fournisseur entre l’équipe « devops » et les développeurs.
Les devs sont autonomes sur leurs opérations sans compétence additionnelle : NoOps ou serverless. Ici on cumule potentiellement les problèmes des deux approches précédentes. Car la plateforme permettant ce type d’approche devient une boîte noire à qui l’on sous-traite tous ses risques d’exploitation, et où l’on pense que l’outil et la sous-traitance se suffisent à eux-mêmes.
Ces démarches sont pourtant toutes valides et doivent être appliquées conjointement : sous-traiter à des plateformes pour se concentrer sur le contrôle du risque au « bon » niveau ; acculturer les équipes d’ops pour les intégrer à une logique de développement et les éloigner du mode client-fournisseur ; faire monter en compétence et en responsabilité les développeurs sur les problématiques d’exploitation.
Ainsi, au-delà des outils et de l’organisation, la transformation doit être pilotée par ses objectifs :
Le niveau de performance des opérations en intégrant le développement : MTTR, fréquence de déploiement, etc. ;
À quel niveau hiérarchique les sujets opérationnels techniques sont-ils intégrés dans les décisions ? Jusqu’à quels niveaux se trouvent des comités d’exploitation ?
Quel est le niveau de convergence des connaissances des techniques, risques et problèmes opérationnels ? Ici, plus les technologies, les outils, les méthodes des opérations et des développeurs divergent, plus l’objectif de co-responsabilisation est inaccessible.
Mettre en place une plateforme adaptée : du cloud native au DevOps native
La prise de contrôle des développeurs sur une partie des opérations nécessite un haut niveau d’automatisation porté par l’essor des plateformes. Mais l’adoption massive de celle-ci et leur situation de monopole recrée souvent la ségrégation client-fournisseur entre les opérations et le développement.
L’excellence IT des plateformes cloud et la liberté d’action des développeurs sur celles-ci en ont fait des standards. Cela rend acceptable, voire incontournable, un niveau de sous-traitance et de perte de contrôle sur les risques des opérations IT qui peuvent être incompatibles avec les objectifs du DevOps.
Les systèmes conçus nativement autour de ces standards « best of breed » des opérations IT ont leur label : le « cloud native ».
Pour moi, la mise en place réussie du DevOps nécessite donc une approche plateforme construite conjointement autour du principe de Cloud Native et de DevOps, le « DevOps native » :
intégration des processus IT : gestion du changement, gestion des incidents, gestion des capacités transparentes et intégrées entre la plateforme et les systèmes qu’elle héberge,
intégration des compétences : convergence des langages et outils des développements et de la plateforme, pour permettre aux experts des opérations et du développement de participer conjointement à l’amélioration de la solution.
Il est possible d’avoir cette approche en utilisant les plateformes de Microsoft, de Google ou d’Amazon Web Services, mais aussi en créant sa propre plateforme. La solution dépend du cœur de métier de son entreprise et de son adhérence avec les risques des opérations IT.
L’important pour ne pas perdre son agilité est donc la capacité de définir son modèle opérationnel et ses objectifs indépendamment des schémas imposés par les géants du cloud.
L’auteur
Arnaud Wetzel est CTO et cofondateur de kbrw.
Kbrw est un éditeur SaaS de solutions d’Order Management Systems, de Warehouse Management Systems et dédiées au commerce B2B déployées dans plus de 100 pays. À ce titre, il possède une forte expertise dans les différents domaines du développement, de l’hébergement, et de la transformation digitale.
