Nième article sur le DevOps

2020-05-24 par Badre BSAILA

DevOps est un vrai buzz-word et se cache sous ce petit acronyme une littérature abondante sur comment les DSI peuvent s’organiser pour livrer des produits de grande valeur-ajoutée. Dans cet article, je vais me focaliser sur les aspects business, organisationnels et techniques du DevOps, ceci dit l’aspect technique est le plus facile à implémenter. Aussi je vais me baser un peu (trop) sur la littérature de Microsoft car le concept est vu différemment par les usagers.

C’est quoi le problème qu’on essaie de résoudre ?

En principe les équipes de développeurs (Dev) et les ingénieurs système (Ops) gagnent leur pain en effectuant des missions divergentes : les Dev créent des changements d’applicatifs et de flux pour répondre aux demandes des équipes métiers, tandis que les Ops sont chargés de maintenir la stabilité de ces applicatifs et de l’infrastructure sur lesquels ils tournent. Malheureusement, des conflits d’intérêt remontent à la surface car les 1er veulent livrer plus et rapidement alors que les 2ème temporisent pour ne pas mettre en péril la santé du SI. On peut même assister à une guerre froide entre les deux parties : les demandes des Ops traînent à être traité par les Dev et vice versa, la recherche du coupable sur les issues de production, des escalades vers la hiérarchie des 2 côtés… Le DevOps se veut d’être un changement culturel et de processus pour permettre un certain degré de collaboration et un alignement des objectifs entre les 2 parties.

Notions générales

DevOps peut être défini comme l’union des humains, processes et outils qui permettent la livraison continue de valeur aux usagers (Donovan Brown, Microsoft DevOps Product Manager). La question qui saute à la vue de cette définition est bien sûr : c’est ce qu’on fait d’habitude, qu’est ce que ça change ? et là j’expose quelques différenciateurs :

• Focus sur la génération de la plus-value que la conformité au plan projet : ce point est peut être le plus rebutant pour les PMO. Mais si on prend exemple d’un projet en mode forfait de 1 an qui respecte tous ses jalons jusqu’à la dernière minute, ça veut dire tout simplement que durant 1 an nous n’avons rien appris de plus sur nos clients, l’environnement dans lequel nous évoluons, les technologies et plateformes utilisées, et que les documents projet comme expression des besoins, spécifications fonctionnelles des besoins, dossiers d’architecture et conceptions techniques élaborés au début étaient auto-suffisants pour la réalisation. Le vrai danger étant là : le produit livré aura un décalage d’un an sur les besoins des clients et aussi sur l’état d’art de la technologie et par conséquent potentiellement inutilisable. Le DevOps se focalise sur l’apprentissage continue des clients et de la technologie et l’incorporation du savoir acquis au backlog produit pour qu’à la livraison votre produit ait du sens.

• Production-first : votre produit doit atterrir en production le plus tôt possible avec le minimum viable, pas question qu’il y soit pour la 1ère fois qu’à la fin du projet. Pas mal d’issues bloquantes ne sont constatées que lorsqu’on est en production, exemple: les défauts d’architecture ou la non utilisabilité du produit ne peuvent pas se manifester sur les environnements de dév et test. (there’s no place like production : Dorothy wizard of Oz)

• Responsabilité partagée sur les silos, applications, et infrastructures : une pratique courante est d’affecter la responsabilité sur ses assets à différentes équipes chacune selon son périmètre fonctionnelle, et en soit l’idée n’est pas mal. Cependant, on doit se mettre d’accord sur le fait que mon asset peut être modifié pour le besoin d’autres équipes et que ce n’est pas que moi qui a le droit d’y toucher (bien sûr moyennant un processus de validation + test).

• Itération rapide et incorporation des retours clients dans le backlog : ça peut sonner comme du Agile, mais à la différence de l’agile, le DevOps insiste sur l’agilité pour les Ops. Ainsi on apprend aussi du feedback de notre infrastructure.

• Automatiser la livraison du code et de l’infrastructure : automatiser le max possible pour livrer continuellement.

• Flexibiliser l’infrastructure et la traiter plus au moins comme le code.

• Définir des processus clairs pour traiter les demandes des Dev pour les Ops et vice versa, pour la relecture des codes, les tests de non régression, les livraisons en production, les Hotfix,… et les faire respecter bien sûr.

Le DevOps n’a pas vocation à annihiler les pratiques et les cultures d’entreprise pré-existantes et s’y substituer, vous livriez déjà des produits avant. C’est juste qu’il pousse à aligner ce qui existe pour le faire plus fréquemment, rapidement et fiablement. A mentionner que le DevOps n’est pas un produit que vous achetez, les outils sur le marché sont juste là pour supporter les humains et les processes.

Les bénéfices

Chaque année l’éditeur d’outils DevOps Puppet fait un sondage (dernier) au niveau mondial pour évaluer l’impact de l’adoption du DevOps sur les organisations, en prenant le rapport de 2015 où la pratique était encore fraîche :

• Les organisations IT top performantes expérimentent 60 X moins d’incidents et recouvrent 168 X rapidement lorsqu’il y en a. Ils déploient aussi 30 X plus fréquemment et avec un temps de livraison 200 X de moins.

• La performance est atteinte que vous travaillez sur du legacy ou avec des architectures modernes (µ-services).

• Le Lean Management et la livraison continue aident à créer de la valeur économique de façon rapide et soutenable.

• Les initiatives DevOps quand ils sont lancées depuis la hiérarchie inférieure ont moins de chance de réussir.

• Les cultures toxiques, les conflits, les blocages non justifiés dans les départements IT provoquent souvent des burnout du côté des équipes Dev qu’Ops : les pratiques DevOps donnent sens au travail quotidien et font émerger une culture d’entreprise saine, inclusive, supportrice et orienté résultat plutôt que chercher le coupable à chaque détour. Ce tableau expose la typologie des cultures organisationnelles (Dr. Ron Westrum 1994)

Pathologique	Bureaucratique	Générative
Orientée vers le pouvoir	Orientée vers les règles	Orientée vers la performance
Faible coopération	Coopération modeste	Grande coopération
Messagers “abattus”	Messagers négligés	Messagers formés
Responsabilités non assumées	Responsabilités limitées	Risques partagés
Liaison découragée	Liaison tolérée	Liaison encouragée
L’échec conduit à se rejeter la faute	L’échec conduit au tribunal	L’échec conduit à investiguer la root-cause
La nouveauté est écrasée	La nouveauté crée des problèmes	La nouveauté est mise en œuvre

Inventaire des pratiques DevOps

Le DevOps prêche l’adoption de certaines pratiques pour livrer les produits :

Intégration continue (CI: Continuous Integration)

En principe à chaque fois qu’un développeur essaie d’ajouter son code au source contrôle : vous devez déclencher une build avec un job automatique qui compile le code, lance les tests nécessaires pour éviter les régressions et si c’est OK le code est versionné, sinon il est rejeté.

• Archiver tout ce qu’on peut dans le source contrôle.

• Automatiser la build et la faire dans un environnement contrôlé (pas dans la machine du développeur, nous ne voulons surtout pas entendre : mais ça marchait dans mon pc).

• Inclure les tests et l’analyse de code.

• Réparer les builds en échec rapidement : si les gens ne s’inquiètent pas pour une petite build KO dans un silo isolé à cause d’un petit test ils se lâcheront pour le 2, 3 , 100 ème test jusqu’au jour où vous perdriez des millions à cause d’un bug en production qui aurait pu être évité si on avait pris la peine d’investiguer.

• Monitorer la qualité et la santé des builds

• Builder une seule fois le code et déployer le package résultant vers tous les environnements. Évitez de builder différemment pour chaque environnement car ça cache des fois des bugs qui ne seront découverts qu’en production.

Livraison continue (CD: Continuous Delivery)

Essayez de livrer votre code avec une grande cadence sur les environnements de dév/test et dans une moindre mesure aussi dans la production pour pouvoir tester vos livrables de façon continue et avoir le feedback permettant d’apprendre et de réajuster le tir :

• Archiver les scripts de livraison dans le source contrôle.

• Automatiser la livraison et l’exécution de ces scripts : ne jamais intervenir sur le package ou l’infrastructure manuellement.

• Les déploiements sur tous les environnements doivent être iso pour la même raison : nous voulons éviter de cacher les bugs à cause des différences sur les environnements de test et de production.

• Assurer la rapidité à une certaine mesure : la livraison ne doit pas consommer beaucoup de ressources sinon on ne pourra pas la faire fréquemment (si vous réservez une chambre de guerre et vous réveillez le monde à 02h du matin le Samedi pour la faire : Ooooh boy !!).

• La livraison doit être idempotente : si on livre la V1 de notre solution sur le serveur SRV1, nous devons s’assurer que la relivraison de la même version sur le même serveur aura le même résultat.

• Utilisation des scénarios de livraison blue/green pour avoir un down-time très réduit et 0 impact ressenti côté utilisateur, et par conséquence avoir cette confidence de le faire souvent :

  • Avant une livraison, votre application est déjà déployé sur une ferme de serveurs (blue) avec une version V1.

  • Le nouveau package avec la version V2 n’est pas déployé sur la même ferme mais sur une autre (green) qui ne reçoit encore pas de flux utilisateur.

  • Test en interne sur les serveurs green pour vérifier qu’on a rien cassé.

  • Si Ok, à l’aide d’un équilibreur de charge : vous commencez à diriger du flux des serveurs blue ayant la V1 vers les serveurs green ayant la V2 tout en monitorant.

  • Si à n’importe quel étape vous découvrez une régression, vous réutilisez le même équilibreur de charge pour rediriger le flux vers les serveurs blue ayant la version V1 stable.

Infrastructure comme code

• Traitez l’infrastructure comme étant flexible : Stocker son état sur le source contrôle et chaque modification doit y être archivé avant de l’exécuter. Pas question de donner les accès directes pour exécuter les scripts shell, et ce pour les mêmes raisons qu’on versionne notre code : nous devons avoir un lieu centralisé où on sait l’état de notre infrastructure à un instant T et qui a modifié quoi après. Exemple: il y a des sociétés où la sécurité est une top spécification (les métiers de la finance, banque, assurance, …) et qui s’arrangent pour qu’aucun humain ait les droits admin sur les serveurs de production, ainsi pour activer les logs sur le serveur SRV1, Mr Ops crée une PR avec la configuration activée et qui doit être validé par son confrère, mergé, et déclenche la livraison continue (cette dernière étant configuré avec un compte service ayant les droits admin), même chose si on veut allouer une nouvelle VM, répliquer l’application sur un autre serveur pour tenir la charge,… Plusieurs solutions sur le marché répondent à ce genre de besoin : Chef, Puppet, Azure Resource Manager Template (ARM),…

• Ne jamais modifier l’état interne de l’infrastructure manuellement.

• Paramétrez les scripts pour pouvoir utiliser les mêmes sur tous les environnements.

• Les scripts doivent aussi être idempotents.

Test continue

Les tests permettent d’assurer la qualité de vos livrables et boostent votre confiance pour les livrer fréquemment :

• Tests unitaires sur les builds d’intégration continue.

• Tests d’intégration/fonctionnels sur les environnements de développements : permettent de déceler les régressions de façon tôt.

• Tests de charge et de non régression + Les tests manuels et exploratoires (ne jamais les négliger car l’expérience utilisateur ne peut pas être ressentie par des machines) sur les environnements de test.

• Pour la production : Health check et Warmup.

• Injection du chaos : un concept issu de l’ingénierie du chaos et basé sur l’étude du comportement global des systèmes en simulant des composants KO comme une indisponibilité de la base de données, lenteurs réseau, lag dans les files de pooling, latence des web services,… Le but étant d’adopter des pratiques pour garder un Minimum Viable Product même en incident.

Coopération des équipes Dev et Ops

Cette collaboration est la plus dûre à implémenter dans le DevOps car ça nécessite de faire émerger un changement culturel et de mentalité pour y arriver. Comment peut-on s’y prendre :

• Tout ce qui est livrable Dev/Ops doit être sur le contrôle source.

• Responsabilité partagée sur les assets pour permettre : d’une part aux Dev de proposer d’améliorer les scripts Ops pour aider à livrer leurs codes rapidement et avec fiabilité, et d’autre part pour que les Ops puissent proposer des améliorations de performance, de configurations, ajout de log et métriques les aidant à maintenir la santé de l’infrastructure.

• De même pour les astreintes à minuit ou week-end, ils doivent être partagées entre les équipes de Dev/Ops car traditionnellement c’est toujours l’Ops qui s’occupe du sale boulot.

• Les bonus des équipes projet de Dev peuvent être conditionnés par l’acceptabilité des livrables par les équipes Ops pour pousser les gens à s’asseoir sur table et s’arranger pour le bien de tout le monde.

Développement orienté hypothèses

Une présentation des équipes de Bing a montré que parmi les nouvelles fonctionnalités développées dans le moteur de recherche : 1/3 avaient un impact positif sur les résultats de recherche, 1/3 avaient 0 impact, et 1/3 avaient dégradé carrément le moteur. Pour dire qu’une nouvelle fonctionnalité que vous jugez opportune et que vous ajoutez dans votre backlog ne veut pas nécessairement dire que vos clients s’en réjouiront à la livraison. C’est pourquoi il est intéressant d’utiliser 2 techniques :

• Monitoring (APM : Application Performance Monitoring) : permet de mesurer l’état de santé de vos applicatifs + infrastructures et d’avoir des dashboards pour surveiller votre produit. Un souci doit pouvoir être découvert avant que le client final le sent et ce genre d’outil est l’idéal pour ça. A noter que vous pouvez aussi inclure des mesures de business : chiffre d’affaires, nombre de commandes, nombre de visites,…

• Test A/B : consiste à livrer son application avec des drapeaux chacun associé à une version du produit, la version A est celle standard tandis que la version B a une nouvelle fonctionnalité fraîchement développée : on active le drapeau de la version B pour un pourcentage minime du flux (par exemple: 10%) ou pour des testeurs bêtas (exemple: Windows Insider Program, Microsoft Teams Developer Preview, Microsoft Edge Insiders Program, ….) et on voie si elle a un impact positif ou non. Par exemple : je veux ajouter un nouveau parcours client dans mon site web : je le développe, je l’active sur 10% du flux et je monitore avec les outils APM pour savoir si j’ai plus de commandes avec la clientèle ayant la version B (en respectant les proportions bien sûr) ou j’ai un désengagement par rapport à la clientèle ayant la version A. Si oui j’active le nouveau parcours à 100% de la clientèle et je supprime l’ancien, sinon je ferme le flux vers la version B du parcours client et soit je jette ses développements à la poubelle soit je les raffine pour lancer un autre test.

Ainsi pour chaque proposition de nouvelle fonctionnalité par le Product Owner ou les équipes métiers, on peut :

• Formuler des hypothèses claires sur l’impact attendu en nombre de commandes, nombres de visites, …

• Déployer la fonctionnalité le plus tôt possible avec le Minimum Viable Product.

• Créer les métriques + dashboards permettant de valider les hypothèses ou non.

• Utiliser les techniques de Test A/B pour ouvrir la nouvelle fonctionnalité qu’à une partie des utilisateurs et monitorer l’impact.

• Apprendre de la production pour affiner le backlog produit ou arrêter carrément d’y investir si ça ne vaut pas la peine : c’est la vie, le comportement des consommateurs n’est jamais prévisible et c’est toujours mieux d’échouer vite que d’investir 1 an avec 0 bénéfices à la fin.

Quel processus de développement pour DevOps ?

• Tout processus de développement itératif avec des cycles de livraison courts : Kanban, Lean, Scrum, XP, …

• La culture est le composant le plus critique. Si votre organisation a déjà investi sur une méthode agile, ça facilitera l’adoption du DevOps car l’agilité encourage aussi des pratiques comme : tolérer l’échec, l’expérimentation, développement itératif, time to market réduit, chercher rapidement un feedback du client …

• L’important étant de se concentrer sur la livraison de valeur continue.

Wrap-Up

Pour conclure, l’adoption du DevOps n’est pas un projet limité dans le temps : c’est un processus d’apprentissage continue pour les DSI. Il n’y a pas de critères objectifs/une fonction de scoring qui va déterminer si vous faîtes du DevOps à un instant T ou non. Il faudra s’y prendre de façon itérative et à chaque fois implémentez une ou 2 pratiques (qui vous parlent) et infusez le changement de façon progressive, douce et continue dans votre organisation. Et n’oubliez pas le DevOps n’est pas une solution logicielle qui s’achète avec sa carte bancaire, c’est avant tout un changement culturel et de processes, les outils n’existent que pour le supporter.

Références

• Channel 9 (David Tesar et Thiago Almeida)

• Microsoft Learning (Steven Borg)

Badre BSAILA, Ingénieur d'étude et développement .NET sénior