même . C ’ est une initiative qui porte sur plusieurs années . Chez Vanguard , nous avons créé ce que nous appelons notre « anneau décodeur » du DevOps . En effet , même si vous avez lu tous les ouvrages et tous les articles , et trouvé un cadre d ’ activité qui vous plaît et que vous comprenez bien , [ cela ] ne signifie pas que les 4 000 autres professionnels de l ’ informatique qui travaillent chez Vanguard , ou les commerciaux , y comprendront eux aussi quelque chose . Nous avons rassemblé toutes ces connaissances dans un anneau décodeur du DevOps , qui se présente comme un simple tableau Excel ressemblant beaucoup à un modèle de maturité , dans lequel toutes les capacités ou caractéristiques de DevOps figurent sur des lignes , tandis que les niveaux de maturité se trouvent dans des colonnes . Cela permet donc de déterminer soi-même à quel stade on se trouve . L ’ idée est de créer une perspective sur le long terme , qui permette de continuer à adopter de nouveaux concepts de DevOps après avoir franchi les étapes fondamentales . On peut parler du DevOps comme d ’ un événement de mutation informatique majeur actuellement en cours au sein de Vanguard .
CTP� : Nous avons quelque chose de similaire chez CTP . Les colonnes sont représentées par les individus , les processus et les technologies . Souvent , nous arrivons en apportant une liste de recommandations , et la plupart du travail se porte sur les technologies . La partie représentée par les personnes et les processus est complexe et cloisonnée . Seule une petite portion de l ’ effort porte là-dessus . L ’ agilité se limite à cela . Nous avons coutume de dire que les technologies sont faciles à gérer , alors que les personnes et les processus sont difficiles . Comment pouvons-nous briser ces barrières , ces silos et ces différentes combinaisons de mesures incitatives pour obtenir un réel gain d ’ agilité ?
Jeff Dowds� : Je suis d ’ accord avec vous . Une nouvelle architecture , qui consiste dans notre cas à passer d ’ une approche monolithique de la création de logiciels à celle de micro-services , implique que le cloud computing adopte un modèle de consommation et non de provisionnement . Le pipeline de CI / CD se met en place pour accélérer le processus de compilation , de conditionnement et de déploiement du cycle de vie des logiciels . Les informaticiens peuvent se consacrer aux changements technologiques et faire des progrès pour que cela marche , mais les équipes organisées en piles complètes ( c ’ est-à-dire toutes les entités et directions opérationnelles ) doivent lâcher du lest sur leurs responsabilités et accepter de les transférer aux services d ’ exécution . Cela pose des difficultés . Dans tous les services informatiques se trouvent des spécialistes qui dirigent leurs sphères de responsabilité et ne sont pas toujours prêts à les abandonner . Ce type de changement organisationnel n ’ est pas toujours facile .
Les changements culturels . Même si vous mettez en place une équipe en pile complète et que vous leur confiez un pouvoir décisionnel après leur avoir donné des objectifs d ’ activité , il y a un autre changement culturel majeur qui se produit . Les développeurs euxmêmes , au lieu d ’ être seulement des experts de quelques domaines , doivent évidemment travailler dans une pile complète , ce qui n ’ est pas facile , car il faut assembler les collaborations .
Nous collaborons aujourd ’ hui sur Hangouts , mais nous avons besoin de plateformes collaboratives pour permettre à la pile complète de communiquer et ce , non seulement en interne , mais également avec les entités commerciales , ce qui est souvent compliqué . La « partie molle », c ’ est-à-dire les changements humains , organisationnels et culturels , est plus difficile à gérer que les aspects techniques . Mon seul conseil , c ’ est d ’ essayer de mettre l ’ accent sur un certain nombre de paramètres qui tendent à favoriser le changement comportemental que vous recherchez . Personnellement , je ne me suis concentré que sur un seul paramètre et sur sa fréquence de déploiement . Si vous fonctionnez avec une méthode DevOps , vous devriez voir votre fréquence de déploiement augmenter . Il n ’ y a aucun autre moyen d ’ accélérer votre fréquence de déploiement qu ’ en travaillant par fines tranches , en considérant les concepts comme des produits minimums viables , [ et ] en ayant une infrastructure auto-provisionnée . Là encore , l ’ enjeu consiste à adopter une architecture de microservices , à mettre en place des pipelines CI / CD robustes , à décaler les tests vers la gauche , à donner du pouvoir décisionnel à votre équipe , à décaler les fonctions de sécurité vers la gauche , à regrouper les équipes qui collaborent ensemble , et à prendre les décisions stratégiques qui produisent le résultat commercial recherché . Je suis convaincu que si l ’ équipe se concentre sur sa fréquence de déploiement et admet que chaque concept de DevOps auquel vous pensez aura un impact positif sur cette fréquence , vous finirez par adopter le comportement nécessaire sur le plan culturel .
CTP� : Parmi les choix de Vanguard , l ’ un de ceux que nous aimons citer en exemple est celui de l ’ équipe en pile complète , que vous évoquez souvent . Cela nous plaît , car nous considérons un ingénieur de pile complète comme une licorne . Il n ’ existe pas une seule personne qui sache tout sur tout . Vous êtes capables de rassembler des personnes issues de disciplines différentes sous un leadership distinct en les plaçant toutes au même endroit dans des cubes ouverts . C ’ est comme cela que vous avez composé votre équipe de construction du cloud et nous avons trouvé que c ’ était une très bonne approche . Comment êtes-vous parvenus à faire en sorte que l ’ organisation renonce à ces ressources ? Comment avez-vous réussi ce tour de force ?
Jeff Dowds� : Vous faites référence à notre équipe de construction du cloud , qui est souvent citée en exemple par de nombreux fournisseurs de cloud . Comment sommes-nous parvenus à ce que notre équipe d ’ ingénieurs du cloud finisse par adopter notre vision du DevOps ? Il nous a suffi de travailler pendant 8 , 10 ou 12 mois en faisant l ’ inverse , et de voir que cela était inefficace . Pour accomplir notre passage au cloud public , nous avons dû extraire des ressources critiques d ’ au moins trois organisations : la sécurité , nos
HIVER 2018 | THE DOPPLER | 41