Chapitre 1 : La démarche DevOps enfin expliquée

Patrick Debois raconte qu’il a inventé le terme DevOps, après une série de conférences, peu fréquentées d’ailleurs, tandis qu’il cherchait à qualifier simplement la notion de gestion agile de l’infrastructure. L’important n’est donc pas tant de savoir comment ni pourquoi Patrick Debois a utilisé pour la première fois ce terme, mais plutôt de comprendre ce qu’il cherchait à expliquer et que l’on pourrait résumer en : les infrastructures informatiques et les opérations peuvent être agiles. Plus encore, elles devront, elles auront l’obligation de l’être demain pour réussir.

Il faut remarquer aussi que l’usage du mot DevOps n’est pas anodin. Sa simple concaténation marque l’impérieuse obligation de collaborer étroitement entre les développements et les opérations. La collaboration est une nécessité, mais collaborer étroitement en partageant largement jusque dans la responsabilité de l’échec ou du succès est la philosophie DevOps. Un véritable choc culturel.

Comme nous l’avons dit, même si elle peut être facilitée par l’adoption de nouveaux outils et technologies, la démarche DevOps est avant tout une philosophie. Sa dimension culturelle est donc fondamentale.

Au cœur de cette culture, il y a la volonté de changer le mode d’interaction entre les équipes de développement et les opérations. L’objectif est non seulement de partager l’information, mais aussi les responsabilités, ce qui suppose une évolution des mentalités pour parvenir à établir la relation de confiance requise et l’implication de tous les acteurs. Au-delà de cette confiance, il faut que chacun puisse acquérir une compréhension globale du système, de sorte que nul ne puisse ignorer les besoins ou les contraintes de l’ensemble des acteurs du système d’information. Cela se traduit par une évolution de l’organisation, de ses processus, du rôle et des périmètres de responsabilités de chacun.

Pour parvenir à étendre la portée de l’ensemble des acteurs du système, la culture DevOps favorise le développement des compétences dans une recherche perpétuelle d’amélioration. Cette approche est similaire au processus industriel Kaizen, qui s’est développé au Japon, dans la reconstruction qui a fait suite à la seconde guerre mondiale. Le mot Kaizen est issu de la fusion des deux mots japonais kai et zen qui signifient respectivement changement et bon.

La pratique quotidienne de cette démarche d’amélioration continue est la condition sine qua non de la réussite de sa mise en œuvre. Elle permet une évolution progressive, sans à coups, et incite chaque acteur du système à proposer des optimisations simples et concrètes sur l’ensemble de la chaîne de production. Appliquée au cycle de production logicielle, cette réorientation culturelle impacte l’ensemble de l’organisation, qui devient ainsi plus prompte à s’adapter et à rechercher le changement plutôt que de le fuir.

Autre source d’inspiration pour la culture DevOps, la philosophie Lean Startup proposée en 2008 par un américain, Eric Ries, initialement à destination des start-up. Depuis, la cible de cette démarche s’est étendue à l’ensemble des entreprises qui souhaitent mettre à disposition un produit sur le marché. Reprenant certains des principes du Lean Management (là encore une méthode de rationalisation de la production qui nous vient de l’industrie japonaise, en l’occurrence Toyota), Lean Startup vise à réduire les gaspillages et augmenter la valeur en continue pendant la phase de développement du produit.

Cette approche se traduit par une volonté d’amélioration continue de la performance (en termes de productivité et de qualité), par une réduction des délais, des coûts et la définition d’un produit minimum viable que l’on peut soumettre à l’évaluation des consommateurs. Cela suppose la mise en place de systèmes de mesure et des processus de remontée d’information systématique et le développement d’une culture fondée sur l’apprentissage en continu.

Au-delà de construire, il y a les hypothèses et la décision de construire. Cette décision est prise en fonction de ce qui est appris du comportement et des attentes des utilisateurs. Cet apprentissage se fait à partir des données mesurées. Ces données sont mesurées par des instrumentations mises en place en fonction des hypothèses à valider. L’objectif est de permettre à l’entreprise de se doter des moyens permettant de contrôler en permanence l’adéquation entre la vision du produit, son implémentation et les attentes du marché.

Ces mesures permettront de valider les hypothèses ayant conduit à la définition du cahier des charges du produit. Mais elles permettront aussi d’optimiser l’intégralité des chaînes de valeur métier dépendant de services informatiques, et de s’assurer de sa fiabilité en résolvant les problématiques au plus tôt afin de limiter leur impact.

Elles permettront de réagir au plus tôt pour procéder aux changements requis et permettront d’étalonner la performance commune, puisque dans la démarche DevOps, les résultats, comme la livraison d’un service en production, sont désormais partagés. Elles nécessiteront la mise en place de processus communs de déploiement, de supervision (détection et prévention d’incidents de performance, de sécurité, de disponibilité), de support et de remédiation.

Enfin, cette culture qui recherche le changement, va encourager l’expérimentation en proposant une vision positive de l’échec. Pour définir de nouveaux besoins, il faut accepter de prendre des risques et cela ne doit pas être un frein. L’échec, au même titre que le succès, devient une source d’apprentissage (Fail fast). Anticiper une situation où le système ne répond plus et y remédier dans les plus brefs délais suppose l’implication de l’ensemble des acteurs. La capacité du système à se remettre en service après un dysfonctionnement sera augmentée si les plans d’escalade et processus internes sont partagés entre les équipes

Une bonne pratique permettant de valider l’efficacité de ces processus collaboratifs consiste à volontairement introduire des erreurs dans le système (Fault Injection Testing) et à gérer la situation qui en résulte en maximisant la collaboration entre les équipes. Un exemple de cette approche est le service Chaos Monkey que Netflix a développé sur la plateforme Amazon Web Services. Nous reviendrons d’ailleurs plus en détail sur cette implémentation dans la suite de cet ouvrage.

Autre exemple, la démarche Resilience Modeling and Analysis (RMA), issue du standard de l’industrie Failure Mode and Effects Analysis (FMEA), qui consiste à identifier en amont les éléments risquant une panne au sein d’une solution et les modes de défaillance qui en résultent. L’objectif est de définir les stratégies de résilience et de disponibilité dès la phase de conception de l’application en bâtissant un modèle qui détaille les possibilités de dysfonctionnement et qui documente l’ensemble des actions destinées à en atténuer l’impact.

Les contre-mesures ainsi définies pour s’assurer que l’incident ne puisse pas se produire ou pour limiter ses effets concernent les équipes de développement ainsi que les opérations. C’est l’un des objectifs de la modélisation des menaces dont nous reparlerons dans le chapitre 5 DevOps vu par la qualité.

Comme on peut le constater, la culture DevOps s’inspire donc d’une pluralité de disciplines déjà mises à l’épreuve avec succès dans le monde de l’industrie. Elle est fondée sur le respect mutuel des équipes, la confiance réciproque et le partage des responsabilités. Elle s’appuie sur une organisation et un management adapté. Enfin, elle s’inscrit dans une démarche d’amélioration, d’expérimentation et d’apprentissage en continu.

La structure même du mot DevOps nous indique que la démarche s’appuie largement sur la collaboration entre le monde des développements et celui de l’infrastructure. La structure du mot est moins explicite sur le troisième acteur essentiel de cette collaboration : le métier.

En effet, la collaboration qu’insuffle cette démarche n’a qu’un seul objectif : réussir à impliquer les acteurs métiers de manière pertinente et continue. Cet objectif n’est pas nouveau en soi, mais les expériences précédentes n’ont pas toujours été concluantes, même avec des méthodes agiles.

Comment pouvons-nous espérer qu’un acteur métier s’implique durablement dans les projets informatiques si au moindre déploiement, il est le témoin privilégié des mésententes entre ces deux acteurs essentiels de l’IT ?

Réussir à reconstruire la confiance et à la conserver dans le temps est donc le premier objectif de toute démarche DevOps. Pour reconstruire cette confiance, il faut avoir conscience des clés de confiance de chacune des parties et travailler prioritairement sur ces sujets. En général, la confiance n’est jamais très loin. Il manque souvent juste un peu de volonté… et de méthode !

Pour réussir à construire la confiance entre deux mondes qui cohabitent, il faut identifier les leviers sur lesquels elle peut se construire. Chaque rôle dans cette collaboration n’espère pas bâtir cette confiance pour les mêmes raisons. Leurs objectifs premiers sont différents mais complémentaires.

Les équipes opérations tiennent avant tout à maintenir la production fonctionnelle et disponible. Certes, pour y parvenir sans recourir au paradigme de la stabilité à tout prix et gagner en fiabilité, ils doivent maîtriser les impacts de tous les changements, mais pas seulement. En réalité, l’une de leurs principales attentes vis-à-vis des équipes de développement est la qualité du produit qui leur est livré. De leur point de vue, si le produit est de qualité suffisante, il n’aura pas d’impact néfaste sur la production.

Et un produit de qualité du point de vue de des équipes de production n’est pas un concept particulièrement complexe : c’est un produit sans bug majeur sur un environnement iso-production.

En théorie, pour y parvenir, il suffit de tester. Mais la théorie n’est pas si simple à appliquer pour de multiples raisons, parmi lesquelles certaines sont très courantes :

• La stratégie de recette et de tests est rarement partagée. Puisque ce sont les développements qui assument la responsabilité de la grande majorité des tests, la typologie de tests à réaliser comme les résultats de ces derniers ne sont pas partagés.
• La stratégie de recette et de tests n’est pas toujours définie et/ou rigoureusement respectée. Lorsqu’une typologie et un planning de tests existent, ils ne sont pas toujours respectés rigoureusement : cela finit toujours par se savoir et par éroder la crédibilité de tout le plan qualité.
• La stratégie de recette et de tests n’est pas appliquée par les bonnes personnes. Il arrive trop souvent que le code soit implémenté, les tests écrits et le sign-off réalisé par la même personne. Il est évident que cela nuit à la crédibilité du résultat.

Pour que les équipes en charge des opérations souhaitent rechercher de nouvelles formes de collaboration, tous ces obstacles doivent être levés en définissant ensemble une stratégie de tests et de recette, garantissant un niveau de qualité satisfaisant pour tous et appliquée avec rigueur.

Vous l’avez compris la stratégie de tests et de recette est l’une des clés de confiance des équipes opérations pour réussir une démarche DevOps.

Démontrer la qualité du produit développé n’est pas suffisant en soi. Il ne faut pas croire d’ailleurs que les développeurs rechignent à réaliser des produits sans bugs et sans dysfonctionnements. Au contraire, la véritable difficulté qui constitue leur clé de confiance est leur capacité à disposer des bons éléments pour réaliser les tests qui les rassurent sur la qualité de leur produit.

Dit autrement, il s’agit pour les équipes de développement de disposer d’environnements iso-production à la demande dans des temps raisonnables et d’outils permettant de réaliser un maximum de tests avec le moins d’effort supplémentaire possible.

Il ne faut pas négliger non plus l’importance du cadre défini et généralement accepté qui détermine ce qu’est un produit de qualité du point de vue de l’organisation.

Lorsque se pose la question du niveau de test attendu pour s’assurer d’une qualité produit suffisante, il y a assez rarement une réponse. Et lorsque cette réponse est celle de l’un des développeurs, elle est souvent différente de celle d’un autre membre de la même équipe. Il est pourtant fondamental de connaître les tests minimums requis et les résultats attendus de ces tests.

Il faut néanmoins relativiser : la grande majorité des équipes de développement partagent des stratégies de tests relativement respectées et tous les développeurs ont conscience de la nécessité de faire des tests. La grande souffrance de ces équipes est de ne pas avoir les moyens de réaliser correctement ces tests.

Pour caricaturer, un développeur réalise un code de grande qualité, définit des algorithmes complexes, mais son code, particulièrement optimisé ne fonctionne pas en production parce qu’il n’a jamais pu le tester dans des conditions similaires à cet environnement de production.

En règle générale, la plus grande difficulté des développements est d’obtenir des environnements et des machines de tests dans des délais raisonnables. Au-delà de la difficulté à parfois obtenir un environnement dont les caractéristiques sont le plus proches possible de l’environnement final, ce sont les délais de mise à disposition de ces environnements qui sont problématiques.

Il n’est pas rare de devoir compter les délais en semaines et de devoir faire intervenir sa hiérarchie pour obtenir les outils nécessaires pour faire son travail. Pourtant, la plus grande partie des développeurs se soumettra volontiers à un choix plus restreint d’outils et d’environnements pour peu qu’on leur garantisse l’efficacité des tests et des délais d’approvisionnement raisonnables.

La qualité des environnements provisionnés et les délais de provisioning font donc partie des clés de confiance des développements.

La confiance des métiers est le moteur de leur implication dans le monde de l’IT. A contrario leur défiance tire son origine des décalages permanents de perception entre les deux mondes des équipes informatiques. Il n’est pas rare d’observer des entités métiers préférant travailler avec des sociétés extérieures plutôt qu’avec le service informatique interne.

Pourtant, les métiers sont demandeurs d’un service informatique à la hauteur des meilleurs concurrents du marché. Après tout, qui mieux que les informaticiens de leur société peuvent comprendre les contraintes de leur métier ? Aujourd’hui l’informatique est partout, ils ont donc toute latitude pour voir leur métier dans sa transversalité.

Dès lors que les équipes informatiques font valoir leur expertise, leur réactivité et la qualité de leur collaboration, au moyen d’une démarche DevOps par exemple, les équipes métiers s’impliqueront naturellement. Il est certain que personne ne souhaite s’impliquer dans une coopération avec des services en conflit.

La qualité de la collaboration et l’expertise des équipes informatiques sont donc les clés de confiance des métiers.

Pour retrouver de la confiance dans une collaboration parfois difficile, il est important de commencer par travailler ensemble sur les clés de confiance identifiées pour chacune des parties prenantes. En trouvant ensemble un mode de fonctionnement qui vous convient collégialement, vous bâtirez les fondations d’une nouvelle culture de collaboration.

Une bonne solution pour démontrer que cette collaboration retrouvée est efficace et pérenne est d’introduire de l’automatisation. Une collaboration qui fonctionne et qui est automatisée (au moins en partie dans un premier temps) démontre une volonté et un investissement qui rassurent les métiers.

En effet, une collaboration qui fonctionne ne doit pas être mise en péril si l’équipe s’agrandit ou les personnes sont remplacées. Pourtant, et c’est normal, toute collaboration repose avant tout sur des femmes et des hommes qui s’entendent sur une manière de fonctionner.

La structuration du processus autour de l’automatisation permet donc de créer un cadre dans lequel de nouveaux collaborateurs entrent naturellement. La pérennité de ce cadre de collaboration n’empêche pas de le faire évoluer.

En effet, le temps aidant et la maturité grandissant, il est plus que probable que le cadre de collaboration soit dans l’obligation de s’adapter au changement de son environnement technique comme humain. Le processus doit intégrer un dispositif d’amélioration continue et la chaîne d’automatisation doit le prendre en compte. Le changement doit se faire de manière pragmatique et structurée avec une rigueur de tous les instants.

Pour que la confiance reste à la fois dans les hommes et dans le cadre procédural automatisé, il est important d’éviter l’instabilité et l’incertitude. Ces notions ne sont pas contradictoires avec la prise en compte de l’amélioration continue, si ces principes sont respectés rigoureusement et évitent ainsi le changement à tout va.

C’est à ce prix que la confiance peut naître, s’accroître et se consolider entre toutes les parties prenantes d’une démarche DevOps.

Néanmoins, la consolidation de la confiance n’est pas le seul avantage à introduire une démarche automatisée, elle permet également de gagner du temps et de la qualité.

Automatiser, c’est effectivement gagner du temps : d’abord pour les tâches les plus répétitives à faible valeur ajoutée, mais aussi pour les tâches plus complexes techniquement. Ces mêmes tâches sont également celles qui sont les plus susceptibles d’introduire des erreurs d’inattention mettant à mal la collaboration. Automatiser, c’est donc également assurer un niveau de qualité constant et optimal.

Cette notion peut paraître évidente, mais dans les faits, tout n’est pas si simple. Il n’est pas toujours facile d’identifier les tâches à faible valeur ajoutée, sans oublier que personne n’aime voir son travail dévalorisé. La notion même de valeur ajoutée peut faire l’objet d’un débat.

En réalité, les processus qui devraient naturellement porter la collaboration sont rarement définis d’un commun accord, chacun gardant plutôt jalousement son bout de processus dans son coin pour le faire évoluer à sa guise. Rester dans cet état d’esprit avant d’automatiser ne fera pas gagner en qualité. En réalité, il n’y aurait même aucun bénéfice à automatiser.

Pour gagner en qualité il faut donc partager le processus qui porte la collaboration et établir un consensus sur les tâches les plus critiques candidates à l’automatisation. Le consensus ainsi établi évite le débat sur la valeur de ces tâches, on se concentre sur la valeur apportée par l’automatisation.

En général ce sont les tâches les plus pénibles pour les équipes, soit parce qu’elles sont particulièrement chronophages sans intérêt intellectuel particulier, soit parce qu’elles sont particulièrement complexes et éprouvantes. Dans les deux cas, ce sont les tâches les plus susceptibles de générer des erreurs, et du fait de ces erreurs de générer de la tension entre les partenaires.

Lorsque ces tâches sont identifiées, les automatiser apporte un gain évident et souvent immédiat. L’automatisation peut d’ailleurs se faire à moindre coût si on ne cherche pas à optimiser en même temps que l’on automatise, car, automatiser et optimiser sont deux activités bien distinctes.

Automatiser consiste à rendre systématique à l’aide d’outils technologiques un enchaînement d’activités spécifiques qui n’est pas forcément optimisé ou industrialisé.

Il est pourtant vrai que l’inconscient collectif associe facilement l’automatisation et les automates à l’industrie et donc à une certaine forme d’optimisation. Une démarche DevOps évite ce type de préjugés. Lorsque nous automatisons une collaboration, nous ne nous embarrassons pas de savoir si elle est optimale et industrialisable, nous nous contentons de nous assurer qu’elle fonctionne.

Il est possible et même recommandé pour accélérer et tendre vers du continuous delivery de chercher ensuite à supprimer les étapes inutiles et à optimiser la chaîne d’activités.

Lorsqu’une collaboration fonctionne et qu’elle est au moins en partie automatisée et ainsi pérennisée, il faut entrer dans une phase d’amélioration continue avec pour objectif l’accélération continue des cycles de livraison.

Le continuous delivery consiste en une automatisation complète de la chaîne de mise en production autant au niveau de la plateforme technologique que du processus de collaboration associé. Sa mise en oeuvre implique donc de ne plus avoir aucune interaction humaine entre la réalisation du service ou du produit et sa mise à disposition finale. Il s’agit d’un objectif ambitieux qui peut volontairement n’être que partiellement atteint. On préfère alors parler d’accélération du delivery plutôt que de continuous delivery.

Pour y parvenir, la recherche de gaspillages et d’une industrialisation des processus est le premier axe de travail important qui est au cœur de la culture DevOps.

L’autre axe de travail fondamental concerne alors l’extension du périmètre d’automatisation. Le degré de confiance dans les processus automatisés augmentant avec le temps et la maturité des équipes sur le sujet, il devient nécessaire d’envisager en permanence d’automatiser un peu plus ce qui fonctionne déjà afin de tendre vers le continuous delivery.

Pour y parvenir de manière agile, ou autrement dit de manière itérative et incrémentale, il faut avoir conscience des différents processus et des différentes problématiques que soulève une démarche DevOps.

Savoir traiter et mettre en oeuvre chacune de ces problématiques séparément pour en démontrer la valeur rapidement est primordial. Il faut avoir constamment conscience que tous ces processus sont liés entre eux. Il s’agit donc de savoir construire sa feuille de route agile autour des sujets DevOps en fonction du contexte pour créer un cercle vertueux d’amélioration continue.

Même si DevOps est avant tout une transformation de la culture des acteurs et des processus du système d’information, sa dimension technologique n’est pas neutre.

Le succès de sa mise en application ne repose pas sur un seul outil ou sur une seule technologie : le principe est de s’appuyer sur ce que chaque outil fait de mieux. Mais c’est aussi du niveau d’intégration de ces outils que dépend l’optimisation des processus, la coordination de la gestion des livraisons, l’efficacité de la collaboration, la durée des cycles de déploiement ou la capacité à gérer de multiples environnements. En effet, ces outils se fondent sur la manipulation d’objets communs, idéalement, tous issus de la même source, et partagés entre les équipes de développement et d’infrastructure. Ainsi, il ne peut y avoir de divergence de vue vis-à-vis de ces objets entre les développeurs et les opérations.

Cette démarche est facilitée par la virtualisation des systèmes et par la prise en charge par de multiples outils d’automatisation de provisioning et de configuration. Aujourd’hui, il est possible de réserver et configurer les ressources processeur, réseau et stockage d’une plate-forme complète à partir d’un environnement bare-metal ou d’un hyperviseur disposant d’un référentiel d’images virtuelles.

Ce provisioning est réalisé sur la base de modèles d’infrastructure qui vont pouvoir être partagés et répliqués sur les différentes plates-formes (développement, intégration, recette, pré-production, production) qui pourront varier en termes de dimensionnement mais seront identiques en termes de configuration. Ainsi le comportement observé sur la plateforme d’intégration sera le même que celui constaté sur la production.

L’environnement de déploiement d’une application est donc devenu un livrable du projet.

À ce titre, il doit être archivé et lui aussi géré en versions, en tirant parti des pratiques issues du monde du développement (tels que l’utilisation de référentiels partagés avec contrôle de version, l’automatisation des tests…).

Cette nouvelle approche suppose la capacité à gérer directement par des lignes de code le provisioning et la configuration de l’infrastructure dans un langage permettant de les créer et les faire évoluer. Les services d’infrastructure, qu’ils s’exécutent à demeure ou dans le cloud, doivent donc être dynamiquement modifiables via des interfaces de programmation. Cette composante infrastructure as code est un élément clé de la dimension technologique de DevOps.

Enfin, comme nous l’avons vu précédemment, l’instrumentation d’une solution est essentielle. Il faut pouvoir, en continu, observer le comportement du système sur le plan technique. Ainsi développeurs et équipes de gestion des opérations pourront, au plus tôt, identifier les limites en termes de performance et corriger les dysfonctionnements.

Il faut également, sur le plan fonctionnel, obtenir des informations permettant de répondre aux besoins fluctuants des utilisateurs et valider les hypothèses ayant conduit à définir le cahier des charges du produit.

En résumé

Pour résumer, nous pourrions dire que DevOps va au-delà de ce que laisse supposer son nom, car c’est une démarche de collaboration agile entre le monde des études et du développement (Dev), le monde des opérations, de la production et des infrastructures (Ops) et les représentants des métiers, des utilisateurs et des clients (Business) pour l’ensemble du cycle de vie du service, de sa conception initiale jusqu’à son support en production.

La mise en oeuvre s’appuie donc sur trois piliers, à commencer par la collaboration pour construire une relation de confiance, puis sur l’automatisation pour pérenniser la confiance et enfin l’industrialisation pour accélérer et tendre vers le continuous delivery.

Enfin, et surtout, DevOps est une transformation culturelle. La dimension technologique n’est là que pour faciliter l’évolution qu’elle sous-tend.