Est-il difficile de comprendre le sujet lorsque l'on parle de DevOps? Nous avons rassemblé pour vous des analogies vives, des formulations de percussions et des conseils d'experts qui aideront même les non-spécialistes à aller droit au but. Au final, le bonus est le DevOps de Red Hat.
Le terme DevOps est né il y a 10 ans et est passé d'un hashtag sur Twitter à un puissant mouvement culturel dans le monde informatique, une véritable philosophie qui encourage les développeurs à obtenir des résultats plus rapidement, à expérimenter et à avancer en utilisant la méthode d'itération. DevOps est devenu inextricablement lié au concept de transformation numérique. Mais comme c'est souvent le cas avec la terminologie informatique, sur une décennie, DevOps a réussi à acquérir de nombreuses définitions, interprétations et idées fausses.
Par conséquent, à propos de DevOps, vous pouvez souvent entendre des questions comme: est-ce la même chose que Agile? Ou s'agit-il d'une sorte de méthodologie spéciale? Ou s'agit-il simplement d'un autre synonyme du mot «collaboration»?
DevOps comprend de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), il peut donc être difficile d'isoler l'essentiel, en particulier lorsque vous êtes partial envers le sujet. Cependant, cette compétence est très utile, peu importe si vous essayez de transmettre vos idées à vos supérieurs ou simplement de parler de votre travail à vos parents ou amis. Par conséquent, pour l'instant, mettez de côté les nuances terminologiques de DevOps et concentrez-vous sur la vue d'ensemble.
Qu'est-ce que DevOps: 6 définitions et analogies
Nous avons demandé aux experts d'expliquer l'essence de DevOps aussi simplement et brièvement que possible afin que sa valeur devienne claire pour le lecteur, quel que soit le niveau de formation technique. Sur la base des résultats de ces conversations, nous avons sélectionné les analogies et les formulations de percussions les plus frappantes qui vous aideront à construire votre histoire sur DevOps.
1. DevOps est un mouvement culturel
"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, pas le sujet, dit Eveline Oehrlich, analyste principale au DevOps Institute. «Par conséquent, ces deux parties fournissent ensemble une livraison de logiciels rapide et de haute qualité.»
2. DevOps est ce qui permet aux développeurs
«DevOps permet aux développeurs de posséder des applications, de gérer leur lancement et leur livraison du début à la fin»«DevOps est généralement considéré comme un moyen d'accélérer la livraison des applications à la production en créant et en mettant en œuvre des processus automatisés», a déclaré Jai Schniepp, directeur de la plate-forme DevOps chez Liberty Mutual. "Mais pour moi, c'est une chose beaucoup plus fondamentale." DevOps donne aux développeurs le pouvoir de posséder des applications ou certaines parties du logiciel, de les lancer et de gérer la livraison du début à la fin. DevOps élimine la confusion des responsabilités et conduit tous les participants au processus à créer une infrastructure automatisée et axée sur les développeurs. »
3. DevOps est une collaboration dans la création et la livraison d'applications
«En termes simples, DevOps est une telle approche de la production et de la livraison de logiciels lorsque tout le monde travaille ensemble», a déclaré Gur Staf, président et chef de la Digital Business Automation 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 de montage automobile», poursuit Gur Staf. - L'idée est de pré-concevoir et de faire tous les détails afin qu'ils puissent ensuite être assemblés sans ajustement individuel. L'assemblage du convoyeur n'est possible que si toutes les pièces s'emboîtent. Ceux qui conçoivent et fabriquent le moteur devraient réfléchir à la manière de le monter sur la carrosserie ou le châssis. Ceux qui font des freins devraient penser aux roues, etc. Il devrait en être de même avec les logiciels.
Un développeur qui crée une logique métier ou une interface utilisateur doit penser à une base de données qui stocke des informations sur les clients, aux mesures de sécurité pour protéger les données des utilisateurs et à la façon dont cela fonctionnera lorsque le service commencera à desservir un grand, voire plusieurs millions de personnes. public d'utilisateurs. "
«Faire en sorte que les gens coopèrent et réfléchissent aux parties du travail qui sont effectuées par d'autres, et ne se concentrent pas uniquement sur leurs propres tâches - c'est le plus grand obstacle qui doit être surmonté. S'il réussit, vous avez d'excellentes chances de transformation numérique », ajoute Gur Staf.
5. DevOps est la bonne combinaison de personnes, de processus et d'automatisation
Jayne Groll, directrice exécutive du DevOps Institute, a proposé une grande analogie pour expliquer DevOps. Selon elle, «DevOps est comme une recette culinaire dans laquelle il existe trois catégories principales 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 de DevOps, ainsi que toute bonne recette, est de savoir comment choisir les bonnes proportions et mélanger ces ingrédients pour augmenter la vitesse et l'efficacité du travail lors de la création et de la publication d'applications. »
6. DevOps - c'est lorsque les programmeurs travaillent en équipe de Formule 1
"La course n'est pas planifiée du début à la fin, mais plutôt de la fin au début.""En parlant de ce à quoi s'attendre de l'initiative DevOps, je citerai l'exemple de l'équipe de course NASCAR ou de Formule 1", explique Chris Short, directeur général du marketing de la plateforme cloud de Red Hat et éditeur de la liste de diffusion DevOps'ish. - Le chef d'une telle équipe a un seul objectif: prendre le maximum de place possible en fonction des résultats de la course, en tenant compte des moyens dont dispose l'équipe et des épreuves qui lui sont tombées. De plus, la course n'est pas prévue du début à la fin, mais plutôt de l'arrivée au départ. Un objectif ambitieux est d'abord fixé, puis les moyens de l'atteindre sont déterminés. Ils sont ensuite divisés en sous-tâches et délégués aux membres de l'équipe. »
«Toute la semaine avant la course, l'équipe peaufine l'arrêt au stand. Il est engagé dans la formation de puissance et de cardio pour être en forme lors d'une journée de course exténuante. Il élabore des actions conjointes pour résoudre tout problème pouvant survenir en course. De même, l'équipe de développement doit former les compétences nécessaires pour publier fréquemment de nouvelles versions. Avec de telles compétences et 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 augmentation de la vitesse signifie une augmentation de la sécurité », explique Short.
«Il ne s'agit pas de faire la« bonne chose », ajoute Short,« mais d'éliminer autant de choses que possible qui entravent le résultat souhaité. Collaborez et adaptez-vous en fonction des commentaires que vous recevez en temps réel. Soyez prêt pour les anomalies et travaillez sur l'amélioration de la qualité pour minimiser leur impact sur le mouvement vers l'objectif. C'est ce qui nous attend dans le monde de DevOps. »
Comment faire évoluer DevOps: 10 conseils d'experts
Juste DevOps et DevOps massifs sont deux choses complètement différentes. Nous vous expliquerons comment surmonter les obstacles du premier au deuxième.Pour de nombreuses organisations, le chemin vers DevOps commence facilement et joliment. 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 à venir.
Hélas, ce n'est qu'un faux éclat, une illusion de progrès, selon Ben Grinnell, directeur général et responsable de la technologie numérique du cabinet de conseil North Highland. Les premières victoires sont certes encourageantes, mais n'aident pas à atteindre l'objectif ultime, à savoir l'utilisation massive de DevOps dans l'organisation.
Il est facile de voir qu'en conséquence, une culture de séparation en «nous» et «ils» se forme.«Souvent, les organisations lancent de tels projets pionniers, estimant qu'elles ouvriront la voie à des DevOps de masse, sans hésitation, elles peuvent et voudront que d'autres le fassent», explique Ben Grinnel. - Les équipes pour la mise en œuvre de tels projets sont généralement recrutées auprès de «Vikings» sûrs d'eux qui ont déjà fait quelque chose de similaire dans d'autres endroits, mais qui sont nouveaux pour votre organisation. En même temps, ils sont encouragés à enfreindre et à détruire les règles qui restent contraignantes pour tous les autres. Il est facile de voir qu'en conséquence, une culture de séparation en «nous» et «ils» se forme, ce qui empêche 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 de DevOps sont confrontées à la croissance de difficultés purement techniques caractéristiques des entreprises à croissance rapide qui se sont appuyées sur la technologie informatique », a déclaré Steve Newman, fondateur et président du conseil d'administration de Scalyr.
«Dans le monde moderne, les services changent dès qu'un tel besoin se fait sentir. Continuer d'implémenter et d'implémenter de nouvelles fonctionnalités est bien sûr génial, mais coordonner ce processus et résoudre les problèmes est un vrai casse-tête », ajoute Steve Newman. - Dans les organisations à croissance très rapide, les ingénieurs faisant partie d'équipes interfonctionnelles peinent à conserver la capacité de suivre les changements et les effets en cascade qu'ils génèrent au niveau de la dépendance. De plus, les ingénieurs ne sont pas du tout satisfaits lorsqu'ils sont privés d'une telle opportunité et, en conséquence, il leur devient plus difficile de comprendre l'essence des problèmes qui se posent. »
Comment surmonter les difficultés décrites ci-dessus et passer à l'utilisation massive de DevOps dans une grande organisation? Les experts vous invitent à la patience, même si votre objectif ultime est d'accélérer le cycle de développement logiciel et les processus métier.1. N'oubliez pas que le changement culturel prend du temps
Jayne Groll, directrice exécutive du DevOps Institute: «À mon avis, l'extension DevOps devrait être aussi progressive et itérative que le développement agile (et affecter également la culture). Agile et DevOps se concentrent sur les petites équipes. Mais à mesure que le nombre et l'intégration de ces équipes augmentent, de plus en plus de personnes appliquent de nouvelles méthodes de travail et, par conséquent, une transformation culturelle à grande échelle se produit. »
2. Passez suffisamment de temps à planifier et à choisir une plateforme
Eran Kinsbruner, évangéliste technique principal, Perfecto: «Pour que la mise à l'échelle fonctionne, les équipes DevOps doivent d'abord apprendre à combiner les processus, outils et compétences traditionnels, puis développer lentement chaque phase DevOps individuelle et la stabiliser. Tout commence par une planification minutieuse des user stories et des flux de valeur (valuestream), suivie par l'étape de l'écriture du logiciel et du contrôle de version en utilisant le développement basé sur les troncs ou d'autres approches les plus appropriées pour la branche et la fusion de code. »
«Vient ensuite la phase d'intégration et de test, où une plate-forme d'automatisation évolutive est déjà requise. Et ici, il est important pour les équipes DevOps de choisir la bonne plateforme qui correspond à leur niveau de compétence et aux objectifs ultimes du projet.
La phase suivante est le déploiement dans un environnement de production, et il devrait être entièrement automatisé à l'aide d'outils et de conteneurs d'orchestration. Dans le même temps, il est important d'avoir des environnements virtualisés à toutes les étapes de DevOps (un simulateur d'environnement de production, un environnement de contrôle qualité et, en fait, un environnement de production) et de toujours utiliser uniquement les dernières données pour les tests afin d'obtenir des conclusions pertinentes. Les analyses doivent être intelligentes et capables de traiter les mégadonnées avec une rétroaction rapide et efficace. »
3. Débarrassez-vous du goût coupable
Gordon Haff, évangéliste RedHat: «La création d'un système et d'une atmosphère qui permet et encourage l'expérimentation permet la mise en œuvre de soi-disant échecs réussis dans le développement de logiciels agiles. Cela ne signifie pas que personne d'autre n'est responsable des échecs. En fait, il est encore plus facile d’établir une personne responsable, car «être responsable» ne signifie plus «devenir le coupable de l’accident». Autrement dit, l'essence de la responsabilité change qualitativement. Dans ce cas, quatre facteurs deviennent extrêmement importants: l'ampleur de l'échec, les approches, les processus de production et les incitations. » (Pour en savoir plus sur ces facteurs, voir les leçons DevOps de Gordon Huff: 4 aspects des expériences saines.)
4. Tracer la voie à suivre
Ben Grinnell, directeur général et chef de la technologie numérique, North Highland Consulting: «Pour évoluer, je recommande qu’avec les projets pionniers, nous lançions le programme Clearing Path. L'objectif de ce programme est de nettoyer les déchets qui restent avec les pionniers de DevOps, tels que les règles qui ont perdu leur pertinence et d'autres choses similaires, afin que la voie à suivre reste claire. »
«Donner aux gens un soutien organisationnel et donner un élan grâce à une communication qui va bien au-delà du groupe pionnier, célébrant largement le succès des nouvelles méthodes de travail. Former des 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. Rendre les outils plus démocratiques
Steve Newman, fondateur et président de Scalyr: «Les outils ne doivent pas être cachés aux gens, et ils devraient être relativement faciles à apprendre pour quiconque est disposé à y consacrer du temps. Si la possibilité de demander des journaux n'est fournie qu'à trois personnes qui sont «certifiées» pour travailler avec une sorte d'outil, vous aurez toujours un maximum de trois personnes qui peuvent traiter le problème correspondant, même si vous avez un très grand environnement informatique. En d'autres termes, un goulot d'étranglement survient ici qui peut entraîner de graves conséquences (pour les entreprises). »
6. Créer des conditions idéales pour le travail d'équipe
Tom Clark, responsable de Common Platform chez ITV: «Vous pouvez tout faire, mais pas tout à la fois. Par conséquent, fixez-vous de grands objectifs, commencez petit et allez de l'avant avec des itérations rapides. Au fil du temps, vous gagnerez la réputation d'une équipe qui réussit, alors d'autres voudront également utiliser vos méthodes. Et ne poursuivez pas la construction d'une équipe très efficace. Au lieu de cela, fournir aux gens des conditions de travail idéales et l'efficacité viendra d'elle-même. »
7. N'oubliez pas la loi Conway et les tableaux Kanban
Logan Daigle, directeur de la livraison et de la stratégie logicielle de CollabNetVersionOne DevOps: «Il est important de comprendre les conséquences de la loi de Conway. Dans ma paraphrase gratuite, cette loi stipule que les produits que nous créons et les processus que nous utilisons, y compris DevOps, se révèlent être les mêmes que notre organisation. »
«Si l'organisation est très fragmentée, et lors de la planification, de la création et de la publication de logiciels, la gestion passe de main en main plusieurs fois, l'effet de la mise à l'échelle sera nul ou de courte durée. 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 la mise à l'échelle est d'afficher sur les tableaux Kanban tout le travail en cours (WIP, workinprogress). Lorsqu'une organisation apparaît dans un endroit où les gens peuvent voir de telles choses, cela stimule considérablement la coopération, ce qui a un effet positif sur la mise à l'échelle. »
8. Cherchez de vieilles cicatrices
Manuel Pais, consultant DevOps et co-auteur de Team Topologies: «Prendre des pratiques DevOps au-delà de Devi Ops lui-même et essayer de les appliquer à d'autres fonctions peut difficilement être qualifié d'approche optimale. Cela donnera sans aucun doute un certain effet (par exemple, en raison de l'automatisation du contrôle manuel), mais beaucoup plus peut être réalisé si nous commençons par une compréhension des processus de livraison et des commentaires.
"S'il existe de vieilles cicatrices dans le système informatique de l'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 leur pertinence (en raison d'un changement de produits, de technologies ou de processus), alors ils doivent certainement être supprimés ou lissés, et ne pas automatiser des processus inefficaces ou inutiles. »
9. Ne pas générer d'options DevOps
Anthony Edwards, directeur de la production d'aubergine: «DevOps est un terme très vague, donc chaque équipe a sa propre version de DevOps. Et il n'y a rien de pire lorsque 20 variétés de DevOps apparaissent immédiatement dans l'organisation, qui ne s'entendent pas très bien. Chacune des trois équipes de développement ne peut pas avoir sa propre interface spéciale entre le développement et la gestion des produits. Comme il est impossible pour les produits d'avoir leurs propres attentes uniques concernant le traitement des commentaires lors du transfert de l'environnement de production vers le simulateur. Sinon, vous ne pourrez jamais faire évoluer DevOps. "
10. Prouvez la valeur de DevOps pour les entreprises
Steve Newman, fondateur et président de Scalyr: «Travaillez à reconnaître la valeur de DevOps. Apprenez et n'hésitez pas à parler des avantages de ce que vous faites. DevOps économise énormément de temps et d'argent (pensez simplement: moins de temps d'arrêt, temps de récupération moyen 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. Vous pouvez ainsi élargir le cercle des adhérents et renforcer l'influence de DevOps dans l'organisation. "
BONUS
Le 13 septembre, nos propres DevOps arriveront au Forum Red Hat Russie - oui, Red Hat, en tant que fabricant de logiciels, a 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, raconte sa propre histoire en russe pur - comment l'équipe Red Hat DevOps a migré des applications des environnements gérés Hat Virtualization par Ansible dans un format de conteneur complet sur la plate-forme OpenShift.
Mais ce n'est pas tout:Une fois que les organisations ont transféré les charges de travail dans des conteneurs, les méthodes traditionnelles de surveillance des applications peuvent ne pas fonctionner. Dans le deuxième rapport, nous expliquerons notre motivation à changer la méthode d'enregistrement et montrerons la poursuite du chemin qui nous a conduit aux méthodes modernes de journalisation et de suivi.