Comprendre le DevOps

Que vous mainteniez l’infrastructure de l’entreprise opérationnelle, gériez les problèmes informatiques des clients, développiez des logiciels ou protégiez vos équipes contre les menaces de sécurité, vous connaissez probablement le DevOps.

Après tout, le terme existe depuis près de 15 ans et son adoption ne se dément pas. Toutefois, cela n’implique pas une définition, un positionnement et une application universels. Il a mené à plusieurs déviations sémantiques : BizDevOps, DevSecOps, AIOps, NoOps, FinOps, etc. Tout cela nourrit la confusion sur la nature du DevOps et sa pertinence pour quiconque dans l’écosystème numérique. Prenons donc le temps de dévoiler les bases, les principes et les vérités cachées du DevOps.

Origine

Commençons par une définition commune de ce qu’est le DevOps. Cette simple et seule question peut entraîner de longues heures de débats, des différends, voire des conflits. Tout incite à revenir à la source pour une réponse claire et fiable. Cela nous conduit à Patrick Debois, qui a inventé le terme en 2009 en organisant les premiers DevOps Days à Gand, en Belgique. Sa frustration d’administrateur système, déplorant un défaut de collaboration dans la chaîne de valeur technologique, fut un déclencheur du mouvement DevOps mondial. Elle découlait avant tout du manque d’empathie, d’échange et de collaboration effective, surtout visible entre les équipes développement et exploitation.

Voici l’une de ses meilleures citations pour définir le DevOps : Le DevOps désigne tout ce que l’on entreprend pour atténuer la friction entre des silos. Tout le reste relève de l’ingénierie.

Cette acception assez vague illustre l’approche globale et l’applicabilité du DevOps et son concept de base. Bien que le terme semble en soi limiter la portée au développement (Dev) et l’exploitation (Ops), le principal moteur du mouvement consiste à améliorer la collaboration et le flux entre tous les silos concernés, comme l’opérationnel, la sécurité, la qualité ou le support. Il semble donc bien plus pertinent de comprendre pourquoi ce but a abouti à terme dans l’adoption du DevOps comme catalyseur clé d’une évolution organisationnelle, culturelle et technologique que de rechercher un terme plus adapté et complet.

Le DevOps N’EST PAS la fin

Maintenant que nous savons comment aborder le DevOps, il faut comprendre que le DevOps n’est pas une fin en soi. Que nous le considérions comme une série de pratiques, de principes, voire un concept sociotechnique, il n’incarne qu’un moyen d’atteindre des objectifs premiers. La communauté BVSSH (Better Value Sooner Safer Happier) active nous fournit une série logique d’objectifs premiers. En d'autres termes, les pratiques et principes DevOps contribuent à une création de valeur optimale, une meilleure qualité, une exécution plus fiable, un retour accéléré et des clients/employés plus satisfaits. On se trompe si on pense réaliser un projet DevOps sans aboutir à l’un de ces objectifs premiers.

Au cours des 10 dernières années, de nombreux projets DevOps ont échoué à créer une valeur ajoutée. Le terrain a montré que l’une des causes premières de l’échec des transformations DevOps réside dans le fait d’y voir une transformation DevOps. La propension à classer les nouvelles approches a relégué au second plan les objectifs (métier) premiers, comme la satisfaction client ou la qualité d’exécution.

Trois voies du DevOps

Lancé par le livre The Phoenix Project début 2013, le concept DevOps repose sur trois voies : flux, rétroaction et apprentissage continu et expérimentation.

1. Première voie : flux

La première voie met l’accent sur l’optimisation du flux de tâches de la création à la production, du développement à l’exploitation. Cela implique d’éliminer les silos entre les équipes, créant une culture de collaboration, et d’automatiser les processus pour éviter les engorgements. L’objectif est de veiller à exécuter les tâches aussi rapidement et facilement que possible. Voici des stratégies pour optimiser le flux de bout en bout :

• Taille de lot : lots de travail plus petits traités par le système. Des idées comme de vastes lancements nuisent à un flux optimal.
• En cours : limitation du nombre de tâches auxquelles une équipe se consacre en même temps.
• Files d’attente : réduction de leur nombre et de leurs délais de traitement.
• Priorisation : prise de décision orientée valeur ou économique avec l’accent mis sur la pertinence intégrée au flux.

2. Deuxième voie : rétroaction

La deuxième voie met l’accent sur la création d’une boucle de rétroaction rapide et fiable au sein, entre et autour du développement et de l’exploitation. Cela implique d’établir des mécanismes continus de test, d’analyse et de retour client ou utilisateur. Cela implique aussi de faciliter le partage du savoir et l’apprentissage mutuel. Cela permet aux équipes de vérifier assez tôt la validité de leurs hypothèses de valeur. Il s’agit enfin de collecter des données d’expérience auprès des clients, des utilisateurs, des développeurs, des fournisseurs ou d’autres acteurs de l’écosystème. Après tout, on ne peut valider les hypothèses quant à la valeur possible des produits ou services offerts qu’en mesurant l’expérience finale. L’alimentation du système en données qualitatives et opérationnelles promeut l’amélioration et l’apprentissage continus.

3. Troisième voie : apprentissage continu et expérimentation

La troisième voie met l’accent sur l’importance de l’apprentissage continu et l’expérimentation. Cela implique de favoriser une culture d’expérimentation, acceptant l’échec comme une occasion d’apprendre, d’améliorer la résilience des processus, des technologies et des équipes et utilisant les données et les métriques pour promouvoir l’amélioration continue. L’apprentissage continu et l’expérimentation aident les équipes à améliorer leurs processus et résultats au fil du temps.

En comprenant et appliquant les trois voies, l’organisation améliore la collaboration, la rétroaction et l’amélioration continue, d’où de meilleurs résultats et des processus plus efficaces. En d’autres termes, elle contribue à mieux responsabiliser les équipes. Ou, comme le disait Werner Vogels, Directeur de la technologie d’Amazon, on utilise ce que l’on crée. Moins une équipe subit de dépendances pour créer de la valeur, meilleurs sont les résultats concrets.

Adoption de CALMS et des pratiques DevOps

CALMS est un acronyme largement utilisé en DevOps signifiant Culture, Automation, Lean, Measurement et Sharing. Lorsqu’on les applique avec le bon équilibre, les piliers CALMS offrent un solide cadre qui aide les organisations à adopter les trois voies et intégrer les pratiques DevOps associées à leur écosystème :

• Culture consiste à créer une culture de collaboration, d’empathie, de confiance et d’apprentissage continu dans l’organisation.
• Automation (automatisation) consiste à automatiser sans cesse les processus et workflows pour gagner en efficacité et réduire le risque d’erreur humaine.
• Lean désigne la base méthodologique des modes de travail Lean (et Agile), comme l’élimination du gaspillage et l’accent mis sur la valeur client et le flux.
• Measurement (mesure) consiste à utiliser les données (preuve) et les métriques pour mesurer l’efficience des produits, services, processus et pratiques et identifier les domaines à améliorer.
• Sharing (partage) consiste à promouvoir le partage du savoir et la collaboration des équipes et des individus dans l’organisation.

Culture : favoriser l’empathie, la collaboration et la coresponsabilité

C’est la raison pour laquelle le cadre CALMS s’ouvre sur la culture. La culture incarne la base même de la philosophie DevOps, avec une réorientation vers la collaboration, la coresponsabilité et la fin des silos organisationnels. Cette transformation culturelle ne se limite pas aux équipes de développement et d’exploitation, mais concerne les opérationnels, les utilisateurs, les experts en sécurité et les fournisseurs. Elle englobe une logique qui privilégie la communication, l’empathie et un engagement collectif pour créer de la valeur utilisateur.

La promotion d’une culture DevOps consiste à favoriser la transparence et des canaux de communication ouverts entre chaque équipe et service. Les unités opérationnelles s’intègrent au processus de développement, assurant l’ajustement des projets informatiques et des objectifs organisationnels. L’essence d’une culture DevOps consiste à améliorer la rapidité, la qualité et la fiabilité de l’offre de produits et de services en éliminant les silos entre les équipes et créant un sens de coresponsabilité.

L’accent mis sur ces aspects culturels accélère la création de valeur, améliore la qualité et la fiabilité, accroît l’agilité à réagir à l’évolution des besoins métier et renforce la collaboration et le travail d'équipe. En outre, la culture DevOps peut aider l’organisation à réduire les coûts et gagner en efficacité en automatisant les tâches répétitives et simplifiant les processus.

Automatisation : minimiser les tâches manuelles et simplifier les workflows à des fins d’efficacité

L’automatisation est le moteur qui propulse la machine DevOps, aidant l’organisation à simplifier les workflows, réduire les erreurs manuelles et accélérer l’exécution. Du développement de code au déploiement et l’analyse, les outils d’automatisation jouent un rôle clé pour assurer une recherche, une intégration, une exécution et un déploiement continus.

Le test automatisé veille à une analyse détaillée des modifications de code, réduisant le risque de création de défauts dans l’environnement de production. Des pipelines d’intégration continue automatisent le développement et l’intégration, offrant un socle cohérent et fiable aux déploiements. Les outils de déploiement d’applications automatisé facilitent un processus fluide et répétable, minimisant les interruptions et améliorant l’efficacité globale.

De plus, de nombreuses autres solutions technologiques couvrent des tâches comme le contrôle de version, la gestion des versions, l’orchestration de conteneur, l’affectation d’infrastructure, la gestion du savoir, la mesure d’expérience, l’analyse et l’observabilité.

Lean : priorité à la valeur, l’élimination du gaspillage et l’optimisation du flux

Lean et Agile forment le cœur de la méthodologie DevOps. L’entreprise numérique repose grandement sur les principes et pratiques Agile et Lean pour gérer son environnement volatile, imprévisible. Que les équipes utilisent des outils Scrum, Kanban ou autres pour gérer les workflows, les impératifs DevOps clés exigent de s’attacher à la valeur, le flux et la résilience.

Supposons une équipe Scrum chargée de développer un nouveau produit pour l’organisation et ayant du mal à obtenir un retour sur les éléments déjà mis en production. Dans ce cas, elle peut envisager le travail en binôme, l’observabilité ou la mesure d’expérience pour recueillir le retour voulu. Dans ce cas, les pratiques Lean comme le management visuel, la cartographie des chaînes de valeur et le Kaizen aident à améliorer l’efficacité en levant les obstacles ou réduisant les tâches manuelles pour recueillir le retour voulu. De même, imaginons un agent de service client gérant les demandes courantes. Il se réjouirait sûrement d’une collaboration efficace et d’un workflow entre les groupes de résolution des incidents complexes ou de boucles de rétroaction continue mesurant l’expérience pour améliorer la satisfaction client et utilisateur.

L’idée et la compréhension des différences de contexte jouent un rôle clé pour appliquer des pratiques Lean ou Agile. Si l’équipe opère dans un contexte plutôt prévisible avec des procédures de travail standards, le besoin d’appliquer des méthodes agiles diffère assez de celui d’une équipe de développement produits faisant face à de hauts niveaux d’incertitude et de volatilité. Cette dernière bénéficiera donc davantage des principes et cadres agiles comme le développement incrémental, la gestion par blocs de temps ou Scrum. De même, les équipes dans un contexte prévisible et stable bénéficieront plus d’améliorations Lean pour étayer la normalisation et l’automatisation de leurs tâches répétitives et workflows.

L’approche Lean invite aussi à utiliser des métriques (preuves) pour identifier les domaines à améliorer. En analysant des indicateurs comme la satisfaction client, le délai et le temps de résolution, l’organisation repère les inefficacités et priorise les améliorations de processus.

Mesure : prise de décision factuelle et amélioration continue

La mesure est une clé de voûte du DevOps, apportant les données qu’exigent une prise de décision avisée et l’amélioration continue. Les métriques DevOps aident l’organisation à évaluer l’efficacité de ses produits, services et processus numériques, identifier les domaines à améliorer et suivre l’avancement. La collecte, interprétation et application continue de données et métriques pertinents renforce la collaboration tout au long du cycle de valeur, de la création à l’exploitation, de la direction aux équipes.

La plupart des organisations et des équipes performantes ont bien appliqué les métriques DORA types du DevOps : délai de modification, fréquence de déploiement, taux d’échec et temps de résolution. En outre, les organisations ont commencé à étudier des métriques de résultat ou de valeur, comme le taux de fidélisation client, la satisfaction utilisateur ou employé. En intégrant une mesure rigoureuse, l’expérience et l’impact, on se réoriente vers une vraie exécution, optimisation et collaboration globale au lieu de résultats partiels.

Conformément à la troisième voie du DevOps, la mesure constitue aussi un facteur clé d’une culture d’apprentissage continu pour favoriser l’évolution constante des écosystèmes. Il faut adopter la non-répétition comme un indicateur nouveau pour promouvoir un environnement propice à l’apprentissage (l’erreur est humaine) tout en soulignant l’importance d’apprendre des erreurs passées (ne pas reproduire l’erreur).

Partage : distribution de la charge cognitive et partage du savoir

Ce pilier du CALMS met l’accent sur l’importance de la communication, la collaboration et le partage du savoir dans et entre les équipes. Dans une culture DevOps, l’information circule aisément entre les équipes développement, exploitation et d’autres acteurs, favorisant une compréhension commune des objectifs et priorités.

Le partage concerne aussi la documentation et le transfert de connaissances. Le DevOps promeut la création d’une documentation nécessaire (suffisante) couvrant tout le cycle de vie du développement. Celle-ci s’avère utile pour intégrer de nouveaux membres à une équipe, résoudre des problèmes et assurer la continuité en cas de mouvements de personnel.

Suivant l’idée qu’on utilise ce que l’on crée, l’organisation œuvre pour renforcer la responsabilité des équipes réelles. Plus une équipe exécute ses tâches en autonomie, plus son flux est fiable, les boucles de rétroaction courtes et la valeur ajoutée élevée pour ses clients. Un piège courant consiste à vouloir qu’une équipe assume toutes les tâches dans le cycle de vie d’un produit ou la chaîne d’exécution. Le concept de charge cognitive nous apprend que les limites humaines font qu’une équipe de quelques ingénieurs ne peut pas réunir toutes les connaissances et compétences requises, simples ou complexes.

L’entreprise adopte donc une structure organisationnelle distinguant le produit de la plateforme, pour dissocier la livraison du produit de l’ingénierie technique et du support spécialisé. Cela permet aux équipes produit de s’attacher à analyser, créer et fournir des produits numériques au client tout en utilisant des services normalisés qu’offre les équipes plateforme, avec l’appui des experts en sécurité ou automatisation de test des équipes de support.

Mise en pratique du DevOps

Il importe en termes de déploiement de disposer d’un ingénieur DevOps. À la base, le DevOps est un mouvement, une méthodologie, une série de pratiques. Le fait de disposer d’un ingénieur DevOps dont le rôle englobe tout le processus équivaut à designer un seul collaborateur. Une approche plus pratique consiste à réunir des ingénieurs dans une organisation moderne pour effectuer des activités DevOps et adopter ses principes et pratiques types. Qu’ils appartiennent à une équipe produit ou plateforme ou jouent un rôle de support, on peut utiliser le terme générique ingénieur DevOps pour identifier les compétences et fonctions requises.

Le DevOps vise à éliminer la friction entre des silos en suivant les trois voies et équilibrant les piliers CALMS concernés. Si on le comprend vraiment, on peut exploiter son potentiel dans sa propre organisation. Cela aboutit à des écosystèmes affichant une empathie accrue, une meilleure collaboration, un flux optimisé et, finalement, une satisfaction client élevée.