Difficile de saisir l'essentiel en parlant de DevOps ? Nous avons rassemblé pour vous des analogies frappantes, des formulations percutantes et des conseils d'experts qui vous aideront à aller à l'essentiel, même si vous n'êtes pas spécialiste. En bonus, une contribution de l'équipe DevOps de Red Hat.
Le terme DevOps est apparu il y a 10 ans et a évolué d'un hashtag sur Twitter à un puissant mouvement culturel dans le monde IT, une véritable philosophie qui encourage les développeurs à obtenir des résultats plus rapidement, à expérimenter et à avancer par itérations. DevOps est désormais indissociable de la notion de transformation numérique. Mais comme c'est souvent le cas avec la terminologie IT, en une décennie, DevOps a accumulé de nombreuses définitions, interprétations et idées fausses à son sujet.
C'est pourquoi il n'est pas rare d'entendre des questions sur DevOps comme : est-ce la même chose que l'agile ? Ou s'agit-il d'une méthode particulière ? Ou est-ce juste un synonyme du mot « collaboration » ?
DevOps englobe de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), il peut donc être difficile d'en extraire l'essentiel, surtout si vous êtes passionné par le sujet. Cependant, cette compétence est très utile, que vous essayiez de transmettre vos idées à votre direction ou que vous racontiez simplement votre travail à des proches. Donc, pour l'instant, mettons de côté les nuances terminologiques de DevOps et concentrons-nous sur l'image globale.
Qu'est-ce que DevOps : 6 définitions et analogies
Nous avons demandé à des spécialistes d'expliquer l'essence du DevOps de la manière la plus simple et la plus concise possible, afin que sa valeur soit claire pour les lecteurs de tous niveaux techniques. À l'issue de ces discussions, nous avons sélectionné les analogies les plus frappantes et les formulations percutantes qui vous aideront à construire votre récit sur DevOps.
1. DevOps est un mouvement culturel
« DevOps est un mouvement culturel, au sein duquel les deux parties (développeurs de logiciels et spécialistes des systèmes d'exploitation IT) reconnaissent que le logiciel n'apporte pas de réelle valeur tant qu'il n'est pas utilisé par quelqu'un : clients, utilisateurs, employés, peu importe, » déclare Eveline Oehrlich, analyste principale et chercheuse à l'Institute DevOps. « C'est pourquoi ces deux parties assurent ensemble une livraison rapide et de qualité des logiciels. »
2. DevOps est ce qui donne du pouvoir aux développeurs
«DevOps donne aux développeurs le pouvoir de posséder des applications, de les lancer et de gérer la livraison du début à la fin»
«On parle généralement de DevOps comme d'un moyen d'accélérer la livraison des applications en construisant et en appliquant des processus automatisés, déclare Jai Schniepp, directeur des plateformes DevOps chez l'assureur Liberty Mutual. – Mais pour moi, c'est quelque chose de beaucoup plus fondamental. DevOps donne aux développeurs le pouvoir de posséder des applications ou certaines parties de logiciels, de les lancer et de gérer la livraison du début à la fin. DevOps élimine la confusion quant aux responsabilités et pousse tous les participants au processus à créer une infrastructure automatisée et gérée par le développeur.»
3. DevOps – c'est la collaboration dans la création et la livraison d'applications
«En d'autres termes, DevOps est une approche de production et de livraison de logiciels où tous travaillent ensemble», souligne Gur Staff, président et directeur de l'automatisation des affaires numériques chez BMC.
4. DevOps – c'est une chaîne de production
«L'assemblage en chaîne n'est possible que si toutes les pièces s'assemblent correctement.»
«Je comparerais DevOps à une chaîne de montage automobile, poursuit Gur Staff. – L'idée est de concevoir et de fabriquer toutes les pièces à l'avance afin qu'elles puissent ensuite être assemblées sans ajustement individuel. L'assemblage en chaîne n'est possible que si toutes les pièces s'assemblent correctement. Ceux qui conçoivent et fabriquent le moteur doivent réfléchir à la façon de le fixer à la carrosserie ou au châssis. Ceux qui fabriquent les freins doivent penser aux roues, et ainsi de suite. Il en va de même pour les logiciels.»
Un développeur qui crée la logique métier ou l'interface utilisateur doit réfléchir à la base de données qui stocke les informations sur les clients, aux moyens de sécurité pour protéger les données des utilisateurs, ainsi qu'à la façon dont tout cela fonctionnera lorsque le service commencera à servir un large éventail d'utilisateurs, potentiellement même des millions.»
«Faire en sorte que les gens collaborent et réfléchissent aux parties du travail réalisées par les autres, plutôt que de se concentrer uniquement sur leurs propres tâches, est le plus grand obstacle à surmonter. Si cela réussit, vous aurez d'excellentes chances de réussir votre transformation numérique», ajoute Gur Steff.
5. DevOps est la bonne combinaison de personnes, de processus et d'automatisation
Jayne Groll, directrice générale de l'Institut DevOps, a proposé une excellente analogie pour expliquer DevOps. Selon elle, «DevOps est comme une recette de cuisine, avec trois catégories principales d'ingrédients : personnes, processus et automatisation. La plupart de ces ingrédients peuvent être tirés d'autres domaines et sources : Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, outils. Le secret de DevOps, comme pour toute bonne recette, réside dans la façon de bien doser et mélanger ces ingrédients pour améliorer la rapidité et l'efficacité lors de la création et du déploiement d'applications».
6. DevOps est lorsque les programmeurs travaillent comme une équipe de Formule 1
«La course se planifie non pas du départ à l'arrivée, mais plutôt de l'arrivée au départ».
«En parlant de ce qu'il faut attendre de l'initiative DevOps, je prends l'exemple d'une équipe de course NASCAR ou de Formule 1, dit Chris Short, responsable du marketing des plates-formes cloud Red Hat et éditeur de la newsletter DevOps'ish. – Le leader de cette équipe a un seul objectif : atteindre la meilleure place possible à l'issue de la course, en tenant compte des ressources dont dispose l'équipe et des défis qui se sont présentés. Ainsi, la course se planifie non pas du départ à l'arrivée, mais plutôt de l'arrivée au départ. Tout d'abord, un objectif ambitieux est fixé, puis les moyens d'y parvenir sont définis. Ensuite, ceux-ci sont divisés en sous-tâches et délégués aux membres de l'équipe.»
«Tout au long de la semaine précédant la course, l'équipe perfectionne ses arrêts au stand. Elle s'adonne à des entraînements de force et de cardio pour être en forme lors de cette journée éprouvante. Elle s'exerce à travailler ensemble pour résoudre tout problème pouvant surgir pendant la course. De même, l'équipe de développement doit s'entraîner à publier fréquemment de nouvelles versions. Avec de telles compétences et un système de sécurité bien rodé, les mises en production de nouvelles versions se font également plus régulièrement. Dans cette optique, une augmentation de la rapidité signifie une augmentation de la sécurité », déclare Short.
« Il ne s'agit pas de faire les « bonnes choses », ajoute Short, mais d'éliminer autant de choses que possible qui entravent l'atteinte du résultat souhaité. Collaborez et adaptez-vous en tenant compte du retour d'information que vous recevez en temps réel. Soyez prêt aux anomalies et travaillez à l'amélioration de la qualité pour minimiser leur impact sur l'atteinte de l'objectif. C'est exactement ce que nous attendons du monde DevOps ».
Comment évoluent DevOps : 10 conseils d'experts
Le simple DevOps et le DevOps à grande échelle sont deux choses entièrement différentes. Nous allons vous montrer comment surmonter les barrières qui séparent les deux.
Pour de nombreuses organisations, le chemin vers DevOps commence facilement et agréablement. De petites équipes passionnées se forment, les anciens processus sont remplacés par de nouveaux et les premiers succès ne se font pas attendre.
Malheureusement, c'est juste un faux éclat, une illusion de progrès, comme le dit Ben Grinnell, directeur général et responsable du secteur numérique de la société de conseil North Highland. Les premières victoires sont certes réjouissantes, mais elles ne contribuent pas à atteindre l'objectif final, à savoir l'adoption généralisée de DevOps au sein de l'organisation.
Il est facile de voir qu'une culture de division entre « nous » et « eux » se forme en conséquence.
«Souvent, les organisations lancent des projets pionniers, pensant qu'ils ouvriront la voie à un DevOps à grande échelle, sans réfléchir à la question de savoir si les autres voudront ou pourront suivre ce chemin, explique Ben Grinnell. – Les équipes chargées de mettre en œuvre ces projets sont généralement composées de 'vétérans' confiants, qui ont déjà fait quelque chose de similaire ailleurs, mais qui sont novices dans votre organisation. Parallèlement, ils sont encouragés à casser et à détruire les règles qui restent obligatoires pour tous les autres. Il est facile de voir qu'en conséquence, une culture de division entre 'nous' et 'eux' se forme, ce qui entrave le transfert de connaissances et de compétences.»
«Et ce problème culturel n'est qu'une des raisons pour lesquelles DevOps est difficile à mettre à l'échelle. Les équipes DevOps rencontrent une augmentation des complexités techniques, caractéristiques des entreprises en forte croissance qui parient sur les technologies informatiques», dit Steve Newman, fondateur et président de Scalyr.
«Dans le monde moderne, les services changent dès qu'il y a un besoin. Implémenter et déployer constamment de nouvelles fonctionnalités est certes formidable, mais coordonner ce processus et résoudre les problèmes qui surgissent est un véritable casse-tête, ajoute Steve Newman. – Dans les organisations à très forte croissance, les ingénieurs au sein d'équipes interfonctionnelles luttent pour conserver la possibilité de suivre les changements et les effets en cascade qu'ils provoquent au niveau des dépendances. De plus, les ingénieurs ne sont pas du tout ravis lorsque cette possibilité leur est retirée, rendant plus difficile la compréhension des problèmes qui surgissent.»
Comment surmonter les difficultés décrites ci-dessus et passer à une utilisation massive de DevOps dans une grande organisation ? Les experts exhortent à faire preuve de patience, même si votre objectif final est d'accélérer le cycle de développement logiciel et les processus métier.
1. Souvenez-vous que le changement culturel prend du temps
Jayne Groll, directrice générale de l'Institut DevOps : «À mon avis, l'expansion de DevOps doit être aussi progressive et itérative que le développement agile (et toucher tout autant la culture). Dans Agile et DevOps, l'accent est mis sur les petites équipes. Mais à mesure que le nombre et l'intégration de ces équipes augmentent, nous avons de plus en plus de personnes appliquant de nouvelles méthodes de travail, ce qui entraîne une transformation culturelle à grande échelle».
2. Accordez suffisamment de temps à la planification et au choix de la plateforme
Eran Kinsbruner, évangéliste technique principal de Perfecto : «Pour que l'évolutivité réussisse, les équipes DevOps doivent d'abord apprendre à combiner des processus, outils et compétences traditionnels, puis lentement développer chaque phase de DevOps et la stabiliser. Tout commence par une planification minutieuse des histoires utilisateur (user story) et des flux de création de valeur (value stream), suivie d'une phase de développement logiciel et de gestion de versions en utilisant le développement basé sur le trunk ou d'autres approches les plus adaptées pour le branched et la fusion de code».
«Ensuite, il y a la phase d'intégration et de test, où une plateforme évolutive pour l'automatisation est déjà nécessaire. Ici, il est important pour les équipes DevOps de choisir la bonne plateforme qui corresponde à leur niveau de compétences et à leurs objectifs finaux de projet.
La phase suivante est le déploiement en production, et cela doit être entièrement automatisé à l'aide d'outils d'orchestration et de conteneurs. Il est également important d'avoir des environnements virtualisés à chaque étape de DevOps (simulateur d'environnement de production, environnement de contrôle qualité et l'environnement de production proprement dit) et d'utiliser toujours les données les plus récentes pour les tests, afin d'obtenir des résultats pertinents. L'analytique doit être intelligente et capable de traiter de grandes quantités de données avec des retours rapides et efficaces».
3. Libérez la responsabilité du goût de la culpabilité
Gordon Haff, évangéliste RedHat : «La création d'un système et d'une atmosphère qui permettent et encouragent les expérimentations permet de réaliser ce qu'on appelle des échecs réussis dans le développement agile de logiciels. Cela ne signifie pas qu'il n'y a plus personne responsable des échecs. En réalité, il devient même plus facile d'établir un responsable, car « être responsable » ne signifie plus « devenir le coupable d'un incident ». Autrement dit, la notion de responsabilité change qualitativement. À cet égard, quatre facteurs deviennent extrêmement importants : l'ampleur de l'échec, les approches, les processus de production et les incitations ». (Vous pouvez en savoir plus sur ces facteurs dans l'article de Gordon Haff « DevOps lessons: 4 aspects of healthy experiments ».)
4. Dégagez la voie
Ben Grinnell, directeur général et responsable de la division des technologies numériques du cabinet de conseil North Highland : « Pour réussir la montée en échelle, je recommande de lancer un programme de 'dégagement de la voie' en même temps que les projets pionniers. L'objectif de ce programme est d'éliminer les débris laissés par les pionniers DevOps, comme les règles devenues obsolètes et d'autres choses similaires, afin que la voie à suivre reste libre ».
« Donnez aux gens un soutien organisationnel et impulsez à travers une communication qui dépasse de loin le groupe des pionniers, célébrant largement les succès des nouvelles méthodes de travail. Formez les personnes impliquées dans la prochaine vague de projets DevOps qui se sentent nerveuses à l'idée d'utiliser DevOps pour la première fois. Et rappelez-vous que ces personnes sont très différentes des pionniers ».
5. Rendez les outils plus démocratiques
Steve Newman, fondateur et président du conseil d'administration de Scalyr : « Les outils ne doivent pas être cachés aux gens et ils doivent être relativement faciles à apprendre pour quiconque est prêt à y consacrer du temps. Si la possibilité de demander des logs n'est accordée qu'à trois personnes, 'certifiées' pour travailler avec un certain outil, vous n'aurez toujours que trois personnes capables de résoudre le problème correspondant, même si vous disposez d'un très grand environnement de calcul. Autrement dit, cela crée un goulet d'étranglement qui peut entraîner des conséquences graves (pour les affaires) ».
6. Créez des conditions idéales pour le travail de l'équipe
Tom Clark, responsable de la division Common Platform chez ITV : «Vous pouvez faire n'importe quoi, mais pas tout en même temps. Fixez donc de grands objectifs, commencez petit et avancez par itérations rapides. Avec le temps, vous gagnerez la réputation d'une équipe qui réussit, ce qui incitera d'autres à adopter vos méthodes. Et ne vous précipitez pas pour former une équipe hautement performante. Au lieu de cela, offrez aux gens des conditions de travail idéales et l'efficacité viendra d'elle-même.»
7. N'oubliez pas la loi de Conway et les tableaux Kanban
Logan Daigle, directeur de la livraison logicielle et stratégie DevOps chez CollabNetVersionOne : «Il est important de prendre conscience des conséquences de la loi de Conway. Dans ma libre interprétation, cette loi stipule que les produits que nous créons et les processus que nous utilisons, y compris DevOps, sont organisés de la même manière que notre organisation.»
«Si une organisation est très éclatée, et que la gestion des logiciels passe plusieurs fois de main en main lors de la planification, de la création et de la mise en production, l'effet de l'échelle sera nul ou de courte durée. En revanche, si l'organisation forme des équipes interfonctionnelles autour de produits financés avec une orientation marché, les chances de succès augmentent considérablement.»
«Un autre aspect important de l'échelle est de montrer sur les tableaux Kanban tous les travaux en cours (WIP, work in progress). Lorsque les gens ont un endroit où ils peuvent voir ces choses, cela stimule fortement la collaboration, ce qui est bénéfique pour l'échelle.»
8. Cherchez les vieilles cicatrices
Manuel Pais, consultant DevOps et co-auteur du livre «Team Topologies» : «Transférer les pratiques DevOps au-delà de Dev et Ops et essayer de les appliquer à d'autres fonctions ne peut guère être considéré comme une approche optimale. Cela produira certainement un certain effet (par exemple, grâce à l'automatisation de la gestion manuelle), mais il est possible d'obtenir beaucoup plus en commençant par comprendre les processus de livraison et de feedback.»
«Si dans le système informatique de l'organisation, il y a de vieilles cicatrices – des procédures et des mécanismes de gestion qui ont été mis en œuvre suite à des incidents passés, mais qui ont perdu leur pertinence (en raison de la modification de produits, de technologies ou de processus) – il est indéniablement nécessaire de les supprimer ou de les aplanir, plutôt que d'automatiser des processus inefficaces ou inutiles.»
9. Ne créez pas de variantes de DevOps
Anthony Edwards, directeur de la production chez Eggplant : «DevOps est un terme très flou, c'est pourquoi chaque équipe finit par avoir sa propre version de DevOps. Et il n'y a rien de pire que d'avoir 20 variétés de DevOps au sein d'une organisation, qui ne s'harmonisent pas bien ensemble. Il ne devrait pas y avoir un interface particulier entre le développement et la gestion du produit pour chacune des trois équipes de développement. De même, les produits ne devraient pas avoir des attentes uniques concernant le traitement des retours lors du transfert dans un simulateur de l'environnement de production. Sinon, vous ne parviendrez jamais à étendre DevOps.»
10. Proclamez la valeur de DevOps pour les affaires
Steve Newman, fondateur et président du conseil d'administration de Scalyr : «Travaillez sur la reconnaissance de la valeur de DevOps. Apprenez et n'hésitez pas à parler des avantages de ce que vous faites. DevOps permet d'économiser énormément de temps et d'argent (pensez simplement : moins d'arrêts, temps de récupération moyen plus court), et les équipes DevOps doivent constamment souligner (et prêcher) l'importance de ces initiatives pour le succès des affaires. Ainsi, vous pourrez élargir le cercle des adeptes et renforcer l'impact de DevOps au sein de l'organisation.»
BONUS
Sur Le 13 septembre, notre propre DevOps arrivera – oui, chez Red Hat, en tant que fournisseur de logiciels, nous avons nos propres équipes et pratiques DevOps.
Notre ingénieur Mark Birger, qui développe des services d'automatisation interne pour d'autres groupes à travers l'organisation, racontera en un russe pur son histoire – comment l'équipe DevOps de Red Hat a migré des applications des environnements virtuels Hat Virtualization, gérés par Ansible, vers un format conteneur complet sur la plateforme OpenShift.
Mais ce n'est pas tout :
Après que les organisations ont transféré leurs charges de travail dans des conteneurs, les méthodes traditionnelles de surveillance des applications peuvent ne pas fonctionner. Dans ce deuxième rapport, nous expliquerons notre motivation à changer notre approche en matière de journalisation et montrerons la suite du chemin qui nous a conduits à des méthodes modernes de journalisation et de surveillance.
Source : habr.com
