DevOps REX 2019

Publié le
par Valentin Liegrois, Aurélien Joga
dans DevOps
⭠ Retour à la liste des articles
thumbernail DevOps

DevOps REX 2019

Pour la deuxième fois depuis la création de la DevOps REX en 2016, l'équipe alter way s'est rendue à la cité des sciences afin d'enrichir ses connaissances sur les pratiques DevOps et partager les retours d'expériences avec les différents acteurs présents.

L'occasion pour nous de vous faire un retour sur les différents sujets présentés par des acteurs majeurs de la mouvance DevOps.

Plus d'informations sur le site officiel.

Introduction

Durant ce déplacement à cette conférence, nous avons été agréablement surpris par son organisation : tant sur la qualité des sujets traités, que sur la diversité des partenaires présents. Les différentes sessions de talk se sont déroulées dans deux salles dédiées, et nous avons notamment pu profiter du confort du magnifique amphithéâtre Gaston Berger. Un espace d'échanges a également été mis en place pour permettre aux participants d'échanger sur leurs expériences en la matière.

De la même façon que la vélocité avec laquelle les applications conçues dans les entreprises ont besoin d'être mises en production, la sécurité est également devenue un sujet de premier plan. La DevOps REX de cette année s'est intéressée de plus près à un nouveau sujet émergeant : le DevSecOps.

Nous avons eu l'occasion d'assister à diverses conférences présentées sous la forme d'un retour d'expérience des pratiques appliquées du modèle DevOps au sein d'entreprises de secteurs différents, dont nous vous faisons la synthèse.

DevOps à l'échelle : Quelles pratiques pour bien grandir ?

Le premier talk de la journée, animé par Matthieu FRONTON, Head of DevOps Strategy pour La Poste Digitale, nous a permis de mieux appréhender la manière dont s'est opérée cette transformation au sein de son groupe (à travers une présentation iconographique au format un slide = une icône, originale et efficace) et de découvrir deux outils qui ont posés les bases de sa réflexion : le livre "A seat at the table" de Mark Schwartz, qui porte sur le leadership et l'agilité au sein de l'IT, et le rapport "State of DevOps" produit par DORA -- DevOps Research and Assessment, une entité de Google.

L'objectif premier de sa démarche a été de désiloter la partie digitale du groupe. Pour ce faire, Matthieu a adopté une approche DevOps fondée sur plusieurs grands principes, comme l'harmonisation entre les équipes et la mise en place de la transparence sur la communication.

Il a également été confronté à des problématiques techniques sur différents sujets tels que IaaS, le PaaS ou la protection des données, qui ont nécessités un changement d'environnement, ce qui a par conséquent généré un changement de comportement des équipes. Cette transformation s'est opérée à travers la mise en place de règles simples apportant une certaine flexibilité, afin de faire disparaître le "Shadow IT" pour laisser place à une orchestration opérationnelle plus efficace. Par exemple en implantant une gestion des accès sécurisés mieux maîtrisés.

Cependant, cette opération qui s'est opérée dans la durée ne s'est pas faite sans mal. Certaines pratiques déjà bien ancrées (comme celles du référentiel ITIL) ont en effet occasionné une résistance au changement. La mise en place de nouvelles pratiques AGILE a permis d'opérer un certain nombre de constats pour adapter les méthodes et les outils.

Retrouvez l'intégralité de cette présentation en vidéo

Comment être un Ops dans une équipe de Dev sans finir sous l'eau ?

Sebastian CACERES, Senior DevOps Engineer chez Ultra, nous a fait part de ses expériences en tant qu'Ops rejoignant une équipe de Devs. Selon lui, le partage des connaissances est essentiel pour permettre la réflexion collective. La mise en place d'un wiki partagé entre les équipes Dev et Ops en est un bon exemple.

La vulgarisation des sujets complexes et la démystification de certains aspects, notamment sur la partie Ops auprès du public de devs, a permis de faciliter la prise de décisions en amenant l'entièreté de l'équipe à être force de proposition et d'instaurer une remise en question continue, en favorisant les interactions humaines et les débats avec un principe simple : doux avec les gens, dur avec le code.

Pour Sebastian, le maître mot permettant d'harmoniser les équipes repose sur la bienveillance. Il est nécessaire que les équipes se sentent à l'aise dans leur environnement pour les amener à s'impliquer dans une démarche de remise en question et d'apprentissage permanent.

Sebastian explique que d'autres techniques moins connues peuvent être bénéfiques. Le Pair Programming consiste ainsi à établir des binômes composés d'un développeur, qui aura en charge de coder et d'implémenter, et une personne ayant une vision plus globale du problème. Le Mob Programming, se présente quant à lui comme la création d'un groupe de travail composé d'un développeur et de plusieurs personnes émettant des propositions issues de leur propre expérience.

Ces méthodes permettent un partage de connaissances et une montée en compétence générale des équipes. Elle permettent également une prise de décision collective sur des sujets qui ne sont pas forcément maîtrisés par l'ensemble de l'équipe, ce qui ouvre parfois la voie à des solutions alternatives.

Toutefois, la mise en place de ces pratiques nécessite de franchir certains obstacles comme la résistance au changement. Celle-ci peut en effet persister sur des sujets tels que le partage des informations sur des pans de métiers qui n'y sont pas habitués, ou le cloisonnement qui peut être parfois très ancré dans l'ADN de l'entreprise.

Retrouvez l'intégralité de cette présentation en vidéo

GROUPAMA réussit une transformation DevOps multi-sites malgré la distance

Dans le contexte Groupama, la mise en place des pratiques DevOps a nécessité d'être adaptée à un environnement multi-site : en effet, historiquement leurs équipes sont éparpillées entre la Bretagne, Paris, Lyon et Montpellier. La plupart des pratiques agiles sont prévues pour fonctionner de manière optimale en environnement mono-site.

Henri GIORDANO, Responsable du centre d'expertise et DevOps, a ainsi insisté sur l'importance des relations humaines physiques dans les pratiques DevOps. Il a en effet constaté qu'au bout de 7 semaines en moyenne, l'absence ou le manque de contact physique entre les équipes entraîne une perte de confiance et leur désintéressement aux projets. Anecdote amusante, le KPI clé sur les projets multi-sites a été mesuré en termes de nombre de bières échangées entre les équipes Dev & Ops. En l'interprétant un peu, il s'agit ici de quantifier les interactions humaines entre les gens, par opposition à des tickets déshumanisés et déshumanisants.

Pour que ces pratiques fonctionnent sur un modèle multi-sites, 3 principes doivent impérativement être intégrés pour fonctionner :

  • La communication ;
  • L'état d'esprit ;
  • Les process.

Ces principes ont été mis en place au sein de son groupe en 3 phases :

  • L'utilisation des méthodes traditionnelles DevOps ;
  • La collecte de Feedback commun, afin d'entretenir l'état d'esprit collaboratif et tirer des conclusions sur les améliorations possibles ;
  • L'apport d'automatisation en conservant une qualité de niveau de service grâce à l'excellente technique acquise.

Cette transformation a également été possible grâce à la mise en place de concepts tels que la formation à travers la DevOps School qui propose un cursus de sensibilisation des équipes du groupe aux pratiques DevOps. Ou encore sur le CI/CD et les containers, sur un format de diffusion massif et accessible à tous pour sensibiliser le plus grand nombre. Afin de sensibiliser l'intégralité des publics, et pour palier aux différentes contraintes (> 200 personnes, multi-sites, aux horaires de travail différents, avec certains profils "très occupés"), il a mis en place une réunion d'information répétée plusieurs fois par jours, sur deux jours. Ce qui lui a permis de toucher 80% de la population visée.

Comme Sebastian, Henri a rappelé l'importance de l'humain dans le DevOps en nous expliquant comment il a remplacé beaucoup d'échanges via tickets déshumanisés par un canal de discussion slack. Prenant l'exemple d'un canal qu'il nous a présenté, un format d'utilisation commun consiste à ouvrir un thread par sujet. Le public pouvant lire le fil de discussion est ainsi élargi pour permettre des échanges plus fructueux.

La communication des prises de décision n'a selon lui pas besoin de "bottom-up" ou "top-down"... Mais surtout de bouche à oreille : cela montre l'adhésion de chacun à la décision.

Il est enfin important, dans un environnement multi-site, de ne pas tuer les initiatives qui peuvent avoir tendance à se multiplier au sein des différentes caisses régionales. Il convient au contraire d’adopter une posture de collecte de Feedback commun et d’en tirer les meilleurs résultats.

Retrouvez l'intégralité de cette présentation en vidéo

DevOps au delà des Dev et de Ops

Dans cette présentation, animée par Patrick DEBOIS, CTO de Zender et inventeur du mot DevOps, celui-ci a partagé son expérience avec les fournisseurs de services, et plus particulièrement la multiplication des services managés. Cette pratique tend à se démocratiser avec l'apparition de concepts tels que le Serverless (en d'autres termes du Servicefull). Elle nécessite cependant d'adopter une approche différente, qui peut parfois engendrer certaines dérives. Les projets peuvent alors être amenés à s'adapter aux services managés (qui possèdent certaines restrictions en termes de capacités ou de faisabilité technique), et non l'inverse.

On constate ainsi que d'autres équipes peuvent être amenées à collaborer sur des sujets parfois éloignés de leur cœur de métier initial. Tel est par exemple le cas d’un service juridique (pour la partie RGPD) ou commercial (pour la partie objectifs commerciaux), qui doivent être intégrés de manière plus directe à certains workflows qui leur étaient jusqu'alors étrangers.

Ces pratiques ne sont donc pas sans risque et peuvent générer un stress supplémentaire, que certaines équipes ne sont pas habituées gérer à ce niveau. Il est donc important de bien prendre en compte l'ensemble des Business Unit qui prendront part aux projets, et de les sensibiliser aux pratiques DevOps.

Retrouvez l'intégralité de cette présentation en vidéo

Comment le Dev, l'Ops et la sécu peuvent monter dans le même bus

Concernant l'aspect sécurité, Joy-Alexandra DENIS, RSSI adjointe chez JCDecaux, a présenté sa vision du DevSecOps à travers son expérience personnelle en prenant exemple sur le modèle de "Pizza team" qui dispose d'une certaine expérience sur l'automatisation, l'infrastructure as code et l'optimisation de la gestion des incidents.

Joy-Alexandra a donc introduit des concepts tels que le "Security by design", les "Security Champions" ou encore les "11 Golden Rules" (un guide de bonnes pratiques qui pose les bases pour un bon développement dès le départ), afin d'aider l'ensemble des équipes (pas seulement Dev et Ops, mais aussi Sécurité et Juridique) à mettre en oeuvre les bonnes pratiques de sécurité et respecter les normes de conformité légale.

Cette démarche est également passée par une transformation des pratiques de base. La communication écrite a par exemple été systématisée à travers divers canaux (mails, channel slack...) pour assurer une transmission d'information globale et fluidifier les process.

L'importance du reporting a également été mise en avant. Des KPIs graphiques remontés par un workflow automatisé peuvent en effet en découler, ce qui peut servir à la prise de décision et orienter les équipes en opérant des réajustements techniques ou en formant les collaborateurs sur un sujet crucial.

Retrouvez l'intégralité de cette présentation en vidéo

DevSecOps en embarquant l'outillage, le process et les 'Security Champions' chez AXA France

Nous avons également eu l'occasion d'avoir un retour d'expérience plus avancé sur les questions de DevSecOps. Yann CRUMEYROLLE, Architect SI, et Arthur SZUMOWICZ, Chef de projet DevSecOps, nous ont ainsi expliqué comment ce changement de Mindset DevOps et les pratiques AGILE mises en place ont permis une transformation de bons nombres d'application legacy monolithique, vers des applications optimisées, sécurisées, avec un temps de release features sous 6 semaines et une livraison en 15 minutes.

Il n’apparaît cependant pas toujours possible d'intégrer certaines pratiques dans un modèle DevOps. Yann nous donne ainsi quelques exemples concrets de ce qui n’a pas fonctionné sur l'aspect sécurité dans les process qu’il a mis en place :

  • Le SAST, car les applications contenant 4 millions de lignes de code nécessitent un temps de traitement de 48h et ont été considérées comme trop longues pour être intégrées au modèle DevOps ;
  • Le SCA, car les 20.000 composants utilisés, dont certains obsolètes, pouvaient poser des problèmes de sécurité ;
  • Le IAST, qui leur a posé problème sur des serveurs mutualisés, ne permettait pas d'obtenir de recette complète et pouvait contenir des vulnérabilités potentiellement cachées.

Le DevSecOps a été introduit chez AXA par THALES avec une approche qui privilégie la qualité à la quantité. Le principe de Security Champions y a encore été instauré et les équipes ont été formées grâce à des programmes dédiés portant par exemple sur l'OWASP, en organisant des DOJO donnés par un Security Champions sur des sujets spécifiques comme une faille de sécurité critique.

On constate également que ce changement d'état d'esprit apporte une meilleure perception de la sécurité aux collaborateurs, ce qui permet de propager les bonnes pratiques de sécurité aux équipes qui auraient pu ne pas se sentir concernées au premier abord.

Retrouvez l'intégralité de cette présentation en vidéo

Tales of container security - Ou l'importance d'une démarche sécurité globale dans un projet cloud

Rachid ZAROUALI, fondateur de SevenSphere, a également partagé son expérience personnelle à travers trois Story Telling de ce qu'il a pu observer dans certaines entreprises et les solutions potentielles qui peuvent être apportées :

Le premier cas concerne la migration d'une application java sur docker qui a fini par aboutir mais qui a rencontré des problèmes de sources. Elle a en effet explosé en vol lors du déploiement lors du passage en production puisque l'analyse a révélé des failles de sécurité.

Dans ce contexte, il aurait pu être judicieux:

Dans le deuxième cas une personne pousse une application en production pour une release de fonctionnalités, le déploiement a été effectué en mode de développement, ce qui interpelle l'équipe qualité qui investigue le problème. Elle se rend compte qu'aucun versionning n'est appliqué sur l'application, qu'il n'y a pas de tag d'image unique, que le compte Administrateur admin/admin est actif et qu'une faille CVE critique est présente.

Rachid nous explique d'abord qu'il y a eu une méconnaissance des bonnes pratiques et que, pour palier à ces problème, il est indispensable :

  • de former les équipes à la fois sur les méthodes de développement, mais également de sécurité ;
  • de mettre en place des process clairs et simples avec les nouvelles compétences acquises et y coupler une communication accrue.

Dans ce dernier cas une société avec une approche In Cloud We Trust utilise un service managé pour son cluster Kubernetes exposé sur un cloud public sans y apporter de configuration supplémentaire et se retrouve victime de tentatives d'attaques.

  • Il nous explique qu'on a tendance à croire que la conteneurisation et les technologies qui lui sont liées sont "secure native" , alors qu'en réalité une mauvaise configuration ou une configuration incomplète peut rendre la solution vulnérable. Heureusement certaines solutions existent telles que kube-bench, kube-hunter ou encore Docker bench, qui sont des outils qui permettent de vérifier la conformité d'une infrastructure managée par un cloud provider.

Ce qu'il faut retenir de ces exemples, c'est d'essayer de proposer des choses simples en posant des bases solides, plutôt que d'utiliser des solutions complexes clé en main, et de mettre l'accent sur la sécurité sur des points qui peuvent paraître anodins tel que :

  • La mise en oeuvre du versioning ;
  • La mise en oeuvre des tests techniques fonctionnels ;
  • L'établissement de points de contrôles à tous les niveaux aussi bien en dev qu'en prod avec des outils open source (par exemple : Clair, Trivy, Dagda...).

Retrouvez l'intégralité de cette présentation en vidéo

Conclusion

La DevOps REX a été pour nous une véritable mine d'informations concernant de nombreux aspects, à la fois sur les expériences partagées, les bonnes pratiques mises en oeuvre dans des contextes concrets et les résultats extrêmement positifs que les acteurs qui ont adoptés cette approche ont pu constater.

Si vous souhaitez aller plus loin, l'intégralité des talks sont disponibles sur la chaîne Youtube DevOps Rex.

C'est donc avec un enthousiasme certain que nous espérons pouvoir retrouver cet événement l'année prochaine pour enrichir notre propre expérience et la partager avec tous les acteurs du paysage DevOps !

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way