Est-il difficile de saisir l’essentiel lorsqu’on parle de DevOps ? Nous avons rassemblé pour vous des analogies frappantes, des formulations frappantes et des conseils d'experts qui aideront même les non-spécialistes à aller droit au but. En fin de compte, le bonus est le DevOps des employés de Red Hat.
Le terme DevOps est né il y a 10 ans et est passé d'un hashtag Twitter à un puissant mouvement culturel dans le monde informatique, une véritable philosophie qui encourage les développeurs à faire avancer les choses plus rapidement, à expérimenter et à aller de l'avant. DevOps est devenu inextricablement lié au concept de transformation numérique. Mais comme cela arrive souvent avec la terminologie informatique, au cours des dix dernières années, DevOps a acquis de nombreuses définitions, interprétations et idées fausses sur lui-même.
Par conséquent, vous pouvez souvent entendre des questions sur DevOps comme : est-ce la même chose qu’agile ? Ou s'agit-il d'une méthodologie spéciale ? Ou s’agit-il simplement d’un autre synonyme du mot « collaboration » ?
DevOps inclut de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), donc distiller ce qui est important peut être un défi, surtout lorsque vous êtes passionné par le sujet. Cependant, cette compétence est très utile, que vous essayiez de transmettre vos idées à vos supérieurs ou simplement de parler de votre travail à quelqu'un de votre famille ou de vos amis. Par conséquent, laissons de côté les nuances terminologiques du DevOps pour l’instant et concentrons-nous sur la situation dans son ensemble.
Qu'est-ce que DevOps : 6 définitions et analogies
Nous avons demandé à des experts d'expliquer l'essence du DevOps aussi simplement et brièvement que possible afin que sa valeur devienne claire pour les lecteurs, quel que soit leur niveau de connaissances techniques. Sur la base des résultats de ces conversations, nous avons sélectionné les analogies et les formulations les plus frappantes qui vous aideront à construire votre histoire sur DevOps.
1. DevOps est un mouvement culturel
« Le DevOps est un mouvement culturel dans lequel les deux parties (développeurs de logiciels et spécialistes de l'exploitation des systèmes informatiques) reconnaissent que les logiciels n'apportent de réels avantages que lorsque quelqu'un commence à les utiliser : clients, clients, employés, ce n'est pas la question », explique Eveline Oehrlich, chercheuse senior. analyste au DevOps Institute. « Par conséquent, ces deux parties garantissent conjointement une livraison rapide et de haute qualité des logiciels. »
2. DevOps consiste à responsabiliser les développeurs.
« DevOps permet aux développeurs de posséder des applications, de les exécuter et de gérer leur livraison du début à la fin. »
« Généralement, DevOps est présenté comme un moyen d'accélérer la livraison d'applications en production en créant et en mettant en œuvre des processus automatisés », explique Jai Schniepp, directeur des plateformes DevOps chez la compagnie d'assurance Liberty Mutual. "Mais pour moi, c'est une chose bien plus fondamentale." DevOps permet aux développeurs de posséder des applications ou des logiciels spécifiques, de les exécuter et de gérer leur livraison du début à la fin. DevOps élimine la confusion en matière de responsabilité et guide toutes les personnes impliquées dans la création d'une infrastructure automatisée et pilotée par les développeurs.
3. DevOps concerne la collaboration dans la création et la fourniture d'applications.
« En termes simples, DevOps est une approche de la production et de la livraison de logiciels dans laquelle tout le monde travaille ensemble », explique Gur Staf, président et responsable de l'automatisation des activités numériques chez BMC.
4. DevOps est un pipeline
"L'assemblage du convoyeur n'est possible que si toutes les pièces s'emboîtent."
«Je comparerais DevOps à une chaîne d'assemblage de voitures», poursuit Gur Staff. – L’idée est de concevoir et réaliser toutes les pièces à l’avance pour pouvoir ensuite les assembler sans réglage individuel. L'assemblage du convoyeur n'est possible que si toutes les pièces s'emboîtent. Ceux qui conçoivent et construisent un moteur doivent réfléchir à la manière de le monter sur la carrosserie ou le châssis. Ceux qui fabriquent les freins doivent penser aux roues, etc. La même chose devrait être vraie avec les logiciels.
Un développeur créant une logique métier ou une interface utilisateur doit réfléchir à la base de données qui stocke les informations client, aux mesures de sécurité pour protéger les données utilisateur et à la manière dont tout cela fonctionnera lorsque le service commencera à servir un public d'utilisateurs large, peut-être même de plusieurs millions de dollars. ".
« Amener les gens à collaborer et à réfléchir aux aspects du travail que d'autres effectuent, plutôt que de se concentrer uniquement sur leurs propres tâches, est le plus grand obstacle à surmonter. Si vous y parvenez, vous avez d’excellentes chances de réaliser une transformation numérique », ajoute Gur Staff.
5. DevOps est la bonne combinaison de personnes, de processus et d'automatisation
Jayne Groll, directrice exécutive du DevOps Institute, a proposé une excellente analogie pour expliquer DevOps. Selon elle, « le DevOps est comme une recette composée de trois grandes catégories d'ingrédients : les personnes, les processus et l'automatisation. La plupart de ces ingrédients peuvent provenir d’autres domaines et sources : Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, outils. Le secret du DevOps, comme toute bonne recette, est de savoir comment obtenir les bonnes proportions et le bon mélange de ces ingrédients pour augmenter la vitesse et l'efficacité de la création et de la publication d'applications.
6. DevOps, c'est quand les programmeurs travaillent comme une équipe de Formule 1
"La course n'est pas planifiée du début à la fin, mais au contraire, de l'arrivée au départ."
« Lorsque je parle de ce à quoi s'attendre d'une initiative DevOps, je pense à une équipe de course NASCAR ou de Formule 1 comme exemple », déclare Chris Short, directeur principal du marketing de plateforme cloud chez Red Hat et éditeur de la newsletter DevOps'ish. – Le leader d’une telle équipe n’a qu’un objectif : prendre la plus haute place possible à l’issue de la course, compte tenu des ressources dont dispose l’équipe et des défis qui lui sont arrivés. Dans ce cas, la course n'est pas planifiée du début à la fin, mais au contraire de l'arrivée au départ. Tout d’abord, un objectif ambitieux est fixé, puis les moyens de l’atteindre sont déterminés. Ensuite, elles sont décomposées en sous-tâches et déléguées aux membres de l’équipe.
« L’équipe passe toute la semaine avant la course à perfectionner les arrêts aux stands. Il fait de la musculation et du cardio pour rester en forme pour une journée de course épuisante. Entraînements travaillant ensemble pour résoudre les problèmes pouvant survenir pendant la course. De même, l’équipe de développement doit apprendre à publier fréquemment de nouvelles versions. Si vous disposez de telles compétences et d'un système de sécurité qui fonctionne bien, le lancement de nouvelles versions en production se produit également plus souvent. Dans cette vision du monde, une vitesse accrue signifie une sécurité accrue », déclare Short.
« Il ne s’agit pas de faire la « bonne chose » », ajoute Short, « il s’agit d’éliminer autant de choses que possible qui font obstacle à l’obtention du résultat souhaité. Collaborez et adaptez-vous en fonction des commentaires que vous recevez en temps réel. Soyez prêt aux anomalies et travaillez à améliorer la qualité afin de minimiser leur impact sur la progression vers votre objectif. C’est ce qui nous attend dans le monde du DevOps.
Comment faire évoluer DevOps : 10 conseils d'experts
C’est juste que DevOps et DevOps de masse sont des choses complètement différentes. Nous vous expliquerons comment surmonter les obstacles sur le chemin du premier au second.
Pour de nombreuses organisations, le voyage vers DevOps commence facilement et agréablement. De petites équipes passionnées se créent, les anciens processus sont remplacés par de nouveaux et les premiers succès ne tardent pas à arriver.
Hélas, ce n'est qu'un faux faste, une illusion de progrès, déclare Ben Grinnell, directeur général et responsable du numérique chez le cabinet de conseil North Highland. Les premiers succès sont certes encourageants, mais ils ne contribuent pas à atteindre l’objectif ultime d’une adoption généralisée du DevOps dans l’ensemble de l’organisation.
Il est facile de voir que le résultat est une culture de division entre « nous » et « eux ».
« Souvent, les organisations lancent ces projets pionniers en pensant qu'ils ouvriront la voie au DevOps grand public, sans se demander si d'autres pourront ou voudront suivre cette voie », explique Ben Grinnell. – Les équipes chargées de mettre en œuvre de tels projets sont généralement recrutées parmi des « Varègues » sûrs d'eux qui ont déjà fait quelque chose de similaire dans d'autres endroits, mais qui sont nouveaux dans votre organisation. Dans le même temps, ils sont encouragés à enfreindre et à détruire les règles qui restent contraignantes pour tous. Il est facile de voir que le résultat est une culture du « nous » et du « eux » 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 à faire évoluer. Les équipes DevOps sont confrontées à des défis techniques croissants, typiques des entreprises à croissance rapide axées sur l'informatique », a déclaré Steve Newman, fondateur et président de Scalyr.
« Dans le monde moderne, les services évoluent dès que le besoin s’en fait sentir. C'est formidable d'implémenter et d'implémenter constamment de nouvelles fonctionnalités, mais coordonner ce processus et éliminer les problèmes qui surviennent est un véritable casse-tête, ajoute Steve Newman. – Dans les organisations à croissance très rapide, les ingénieurs des équipes interfonctionnelles ont du mal à conserver une visibilité sur le changement et les effets en cascade au niveau des dépendances qu’il crée. De plus, les ingénieurs ne sont pas contents lorsqu’ils sont privés de cette opportunité et, par conséquent, il leur devient plus difficile de comprendre l’essence des problèmes qui se posent.»
Comment surmonter ces défis décrits ci-dessus et passer à l’adoption massive du DevOps dans une grande organisation ? Les experts recommandent d'être patients, même si votre objectif ultime est d'accélérer votre cycle de développement logiciel et vos processus métier.
1. N'oubliez pas que le changement de culture prend du temps.
Jayne Groll, directrice exécutive, DevOps Institute : « À mon avis, l’expansion du DevOps devrait être aussi progressive et itérative que le développement agile (et toucher également à la culture). Agile et DevOps mettent l'accent sur les petites équipes. Mais à mesure que ces équipes grandissent et s’intègrent, de plus en plus de personnes adoptent de nouvelles méthodes de travail, ce qui entraîne une transformation culturelle massive.
2. Passez suffisamment de temps à planifier et à choisir une plateforme
Eran Kinsbruner, évangéliste technique principal chez Perfecto : « Pour que la mise à l'échelle fonctionne, les équipes DevOps doivent d'abord apprendre à combiner les processus, outils et compétences traditionnels, puis nourrir et stabiliser lentement chaque phase individuelle du DevOps. Tout commence par une planification minutieuse des user stories et des flux de valeur, suivie par l'écriture de logiciels et le contrôle des versions à l'aide d'un développement basé sur des troncs ou d'autres approches les mieux adaptées au branchement et à la fusion de code.
« Vient ensuite l’étape d’intégration et de test, où une plate-forme d’automatisation évolutive est déjà requise. C’est là qu’il est important pour les équipes DevOps de choisir la plateforme adaptée à leur niveau de compétence et aux objectifs finaux du projet.
La phase suivante est le déploiement en production et celui-ci doit être entièrement automatisé à l'aide d'outils d'orchestration et de conteneurs. Il est important de disposer d'environnements virtualisés à toutes les étapes du DevOps (simulateur de production, environnement d'assurance qualité et environnement de production réel) et de toujours utiliser uniquement les données les plus récentes pour les tests afin d'obtenir des conclusions pertinentes. Les analyses doivent être intelligentes et capables de traiter le Big Data avec des retours rapides et exploitables.
3. Retirez la culpabilité de toute responsabilité.
Gordon Haff, évangéliste RedHat : « Créer un système et une atmosphère qui permettent et encouragent l'expérimentation permet ce que l'on appelle des échecs réussis dans le développement de logiciels agiles. Cela ne veut pas dire que personne d’autre n’est responsable des échecs. En fait, identifier qui est responsable devient encore plus facile, puisque « être responsable » ne signifie plus « causer un accident ». Autrement dit, l’essence de la responsabilité change qualitativement. Quatre facteurs deviennent critiques : l’ampleur des perturbations, les approches, les processus de production et les incitations. » (Vous pouvez en savoir plus sur ces facteurs dans l'article de Gordon Huff « Leçons DevOps : 4 aspects des expériences saines. »)
4. Ouvrir la voie à suivre
Ben Grinnell, directeur général et responsable du numérique du cabinet de conseil North Highland : « Pour atteindre une grande échelle, je recommande de lancer un programme de « dégagement de chemin » conjointement avec des projets pionniers. L’objectif de ce programme est de nettoyer les déchets laissés derrière eux par les pionniers du DevOps, comme les règles obsolètes et ce genre de choses, afin que la voie à suivre reste claire.
« Donner aux gens un soutien et un élan organisationnels grâce à une communication qui va bien au-delà du groupe pionnier en célébrant largement les succès des nouvelles méthodes de travail. Coachez les personnes impliquées dans la prochaine vague de projets DevOps et qui sont nerveuses à l'idée d'utiliser DevOps pour la première fois. Et rappelez-vous que ces gens sont très différents des pionniers.
5. Démocratiser les outils
Steve Newman, fondateur et président 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é d'interroger les logs est limitée à trois personnes « certifiées » pour utiliser un outil, vous disposerez toujours d'un maximum de trois personnes disponibles pour gérer le problème, même si vous disposez d'un environnement informatique très volumineux. En d’autres termes, il existe ici un goulot d’étranglement qui peut entraîner de graves conséquences (commerciales).»
6. Créer des conditions idéales pour le travail d'équipe
Tom Clark, responsable de la plateforme commune chez ITV : « On peut tout faire, mais pas tout à la fois. Alors fixez-vous de grands objectifs, commencez petit et avancez par itérations rapides. Au fil du temps, vous développerez une réputation de faire avancer les choses, de sorte que d’autres voudront également utiliser vos méthodes. Et ne vous inquiétez pas de constituer une équipe très efficace. Au lieu de cela, offrez aux gens des conditions de travail idéales et l’efficacité suivra.
7. N'oubliez pas la loi de Conway et les tableaux Kanban
Logan Daigle, directeur de la livraison logicielle et de la stratégie DevOps chez CollabNetVersionOne : « Il est important de comprendre les conséquences de la loi de Conway. Dans ma paraphrase libre, cette loi stipule que les produits que nous créons et les processus que nous utilisons pour le faire, y compris DevOps, s'avèrent être structurés de la même manière que notre organisation.
« S'il existe de nombreux silos dans une organisation et que le contrôle change de mains à plusieurs reprises lors de la planification, de la création et de la publication de logiciels, l'effet de la mise à l'échelle sera nul ou de courte durée. Si une organisation constitue des équipes interfonctionnelles autour de produits financés en fonction du marché, les chances de succès augmentent considérablement.
« Un autre aspect important de la mise à l'échelle est d'afficher tous les travaux en cours (WIP, workinprogress) sur des tableaux Kanban. Lorsqu’une organisation dispose d’un endroit où les gens peuvent voir ces choses, cela encourage grandement la collaboration, ce qui a un impact positif sur l’évolution.
8. Recherchez les vieilles cicatrices
Manuel Pais, consultant DevOps et co-auteur de Team Topologies : « Prendre les pratiques DevOps au-delà du Dev and Ops lui-même et essayer de les appliquer à d'autres fonctions n'est pas une approche optimale. Cela aura certainement un certain impact (par exemple, en automatisant le contrôle manuel), mais nous pouvons faire bien plus si nous commençons par comprendre les processus de livraison et de retour d’information.
« S'il existe d'anciennes cicatrices dans le système informatique d'une organisation - des procédures et des mécanismes de gestion qui ont été mis en œuvre à la suite d'incidents passés, mais qui ont perdu de leur pertinence (en raison de changements dans les produits, les technologies ou les processus) - alors elles doivent certainement être supprimées. ou lissés, plutôt que d’automatiser des processus inefficaces ou inutiles.
9. Ne multipliez pas les options DevOps
Anthony Edwards, directeur des opérations chez Eggplant : « DevOps est un terme très vague, donc chaque équipe se retrouve avec sa propre version de DevOps. Et il n’y a rien de pire lorsqu’une organisation se retrouve soudainement confrontée à 20 variétés de DevOps qui ne s’entendent pas très bien. Il est impossible que chacune des trois équipes de développement ait sa propre interface particulière entre le développement et la gestion des produits. Les produits ne devraient pas non plus avoir leurs propres attentes en matière de gestion des commentaires lorsqu'ils sont transférés vers un simulateur de production. Sinon, vous ne pourrez jamais faire évoluer DevOps.
10. Prêchez la valeur commerciale du DevOps
Steve Newman, fondateur et président de Scalyr : « Travaillez pour reconnaître la valeur du DevOps. Apprenez et n'hésitez pas à parler des avantages de ce que vous faites. DevOps permet d'économiser du temps et de l'argent (pensez-y : moins de temps d'arrêt, un temps moyen de récupération plus court), et les équipes DevOps doivent sans relâche souligner (et prêcher) l'importance de ces initiatives pour la réussite de l'entreprise. De cette façon, vous pouvez élargir le cercle d’adhérents et accroître l’influence du DevOps dans l’organisation.
BONUS
Sur Notre propre DevOps arrivera le 13 septembre. Oui, Red Hat, en tant que fabricant de logiciels, dispose de ses propres équipes et pratiques DevOps.
Notre ingénieur Mark Birger, qui développe des services d'automatisation internes pour d'autres groupes de l'organisation, racontera sa propre histoire en russe pur : comment l'équipe Red Hat DevOps a migré les applications des environnements virtuels de virtualisation Hat gérés par Ansible vers un format de conteneur à part entière sur la plateforme OpenShift.
Mais ce n'est pas tout:
Une fois que les organisations ont déplacé leurs charges de travail vers des conteneurs, les méthodes traditionnelles de surveillance des applications risquent de ne plus fonctionner. Dans la deuxième présentation, nous expliquerons notre motivation pour changer notre façon de journaliser et montrerons la poursuite du chemin qui nous a conduit aux méthodes modernes de journalisation et de surveillance.
Source: habr.com