Cet article fait partie de la série mensuelle "DevOps War Stories". Chaque mois, nous entendons ce que DevOps apporte à une organisation différente, nous apprenons ce qui a et n'a pas fonctionné, nous regardons les difficultés rencontrées lors de l'adoption.

1. Présentation

J'aimerais raconter une histoire sur DevOps. Je m'appuierai sur quelques-unes des expériences et des leçons apprises dans un petit coin de Nokia, l'organisation Divertissement basée à Bristol, en Angleterre. Nous sommes des créateurs de produits de musique et pendant les deux dernières années, notre équipe a appris à fournir des logiciels côté serveur; rapide. Afin d'apprendre, nous avons dû faire des erreurs, je vise ici à partager nos réussites et les échecs, ce n'est pas une recette pour DevOps, mais vous pourriez trouver quelques ingrédients utiles.

Il existe de nombreuses définitions de DevOps et presque chaque variation que j'ai lu détient quelque chose de nouveau et intéressant. Pour cet article, je suggère DevOps comme une façon de travailler où :

"Les développeurs et les opérationnels travaillent ensemble pour s'assurer que les produits sont construits, les systèmes sont créés, passent à l'échelle et restent stable. Ils comprennent les responsabilités de chacun et apprennent régulièrement sur l'expertise de chacun".

Cela peut être comparé à la situation où les deux équipes sont séparées, organisationnellement ou culturellement, et ne fonctionnent pas efficacement ensemble.

DevOps est à la fois une culture souhaitable et une solution à un problème spécifique. Il n'est pas nécessaire partout. Je me suis promené lors de la conférence Future of Web Apps, et j'ai parlé à quelques-unes des personnes membres de start-up sur DevOps, la plupart d'entre eux ne voient pas la nécessité. Quand il y a seulement quelques personnes qui partagent la responsabilité dans l'entreprise, il n'y a pas de place pour ce genre de spécialité et le protectionnisme qui peut s'avérer tellement contraignant quand les organisations grandissent.

Cet article mentionne également la livraison continue - beaucoup. C'est parce que vouloir avoir la vision de livraison continue, avec des releases plus rapides, des changements plus fréquents, nous ont amenés à reconnaître la nécessité de DevOps.

2. Pourquoi les choses devaient changer...

Il y a quelques années encore, créer un logiciel était difficile. Tellement difficile que cela pourrait rendre fier un méchant dans James Bond. Bien que les équipes se développaient en utilisant des méthodes agiles, des changements ont été mis en attente et appliqués aux systèmes de production en une fois, ou plutôt soigneusement construits dans un fragile château de cartes et soigneusement appliqués ensuite en production. Cela a conduit à un certain nombre de problèmes communs, avec tous les symptômes trop familiers.

Qualité - La ruée pour les dates de mise en production pouvait facilement compromettre la qualité à la fois des décisions et des logiciels. La connaissance que l'abondon d'un élément dans cette release signifierait attendre encore quelques mois avec des décisions difficiles, et certaines veillées tard le soir, pour finalement mettre en production cette dernière feature.

Risque - Les mises en production n'étaient pas de routine, il n'y en avait pas deux pareilles, et elles impliquaient souvent des dépendances. Cela signifiait qu'ils risquaient des temps d'arrêt, des problèmes de performance... Certains de ces points étaient atténués avec les tests, les répétitions et les plans de rollback, mais le grand nombre de changements signifiait toujours un risque de problèmes.

Motivation - Malgré de généreuses quantités de pizza tard le soir, il y avait un effet secondaire sur les personnes. La fierté et la satisfaction d'une mise en production ont été mis à mal par la bureaucratie et la difficulté du processus de mise en production. La pression était forte pendant les mises en production. Une erreur et tout s'écroulait, avec aussi les chances de rentrer à la maison en plein jour. Les gens impliqués dans ces activités ne faisaient souvent pas le genre de rôles pour lequel ils sont allés à l'université ou ont étudié pour, une distraction malvenue dans les zones qui ont vraiment une valeur ajoutée à l'entreprise.

Coût - Il y avait à la fois des opportunités et des coûts financiers. Les efforts investis dans la construction d'une release ne le sont pas dans l'innovation ou l'ajout de valeur aux produits existants. Des releases rares ajoutaient un sentiment de délais longs, et un sentiment de non-réponse vis-à-vis du besoin. Un environnement où les possibilités de changement sont rares ajoute le problème que les créneaux de release sont précieux et peuvent facilement conduire à un coût élevé et la participation de la direction.

Malgré une image apparemment sombre, nous livrions encore des fonctionnalités, mais savions que nous pouvions faire mieux. Les gens étaient très conscients des symptômes, mais peut-être pas de leurs origines. Des tentatives ont été faites pour améliorer la situation, à la fois pour affiner le processus existant et en s'intéressant à d'autres approches, y compris la livraison continue et DevOps. Toutefois, le véritable assassin a été l'introduction de changement, ou la création d'un plan, tout en respectant nos autres engagements.

3. Comment nous y sommes arrivés...

Bilan

Au lieu de plonger dans la prochaine release, nous nous sommes arrêtés. Même cela a été dur, et a nécessité de la discipline. La tentation est de toujours pousser vers l'avant, comme l'homme infâme qui n'arrête pas d'aiguiser sa scie, qui se sent bien en dépensant de l'énergie, même si c'est finalement inutile. Nous nous sommes arrêtés juste assez longtemps pour consolider notre vision et planifier les prochaines étapes. Après toute l'évangélisation faite, l'entreprise a commencé à écouter. Des discussions particulièrement notables ont eu lieu au niveau du leadership entre les opérateurs, l'ingénierie, les produits et les architectes. De ceci est sorti une volonté d'essayer quelque chose de nouveau, tant au niveau organisationnel que technique.

Ce quelque chose de nouveau était la livraison continue et avec elle la promesse de réduction du temps de production et des coûts, et la fin de tout ce processus frustrant de release. La mise en œuvre de la livraison continue exigerait des équipes d'ingénierie agiles à considérer la mise en production comme le point où leur travail a été fait, et pas seulement comme avant, remis à l'équipe qualité, aux intégrateurs ou opérationnels. En outre, les déploiements fréquents seraient nécessaires, quelque chose pour lequel ni l'outillage, ni les gens n'ont été préparés. Il était clair qu'une plus grande collaboration serait nécessaire pour atteindre cet objectif, et qu'il y avait beaucoup à apprendre du mouvement des DevOps en pleine croissance. Je pense qu'il est juste de dire que sur le moment, nous n'avons pas apprécié tous les nombreux avantages que cette façon de travailler apporte.

Engagement

Une équipe a été créée pour aider à construire des outils et encourager les progrès vers la livraison continue et un style DevOps. Cela repose sur le travail d'individus enthousiastes qui avaient été dispersés à travers les équipes, leur permettant de concentrer leurs initiatives, à la fois techniques et autres. C'est peut-être une évidence, mais pas facile à vendre, cela nécessite, de la part de tout le monde, de reconnaître que les équipes ont besoin de s'améliorer, et aussi accepter le fait que la livraison pourrait ralentir pendant que les nouveaux modes de travail sont établis. En plus de l'investissement en temps, une équipe dédiée, ou un projet, c'est un signal fort - c'est l'approche pour l'avenir, et nous nous engageons dans celle-ci.

Inspecter, adapter, apprendre

Dans un environnement agile, le point de départ naturel est la rétrospective. C'est le processus de recherche de ce qui fonctionne et ce qui ne fonctionne pas, afin de trouver des idées pour améliorer les facteurs positifs et supprimer les négatifs. Dans les équipes ingénierie, les rétrospectives étaient monnaie courante, mais la livraison continue imposait de prendre en compte les perspectives de beaucoup d'autres domaines, y compris les architectes, les produits, l'assurance qualité et les testeurs. Les rétrospectives inter-équipes sont celles qui ont généré certaines des idées les plus utiles; ils ont encouragé la conversation, un sentiment de but commun, et de la communauté. En y réfléchissant, je pense que celles-ci auraient dû être plus fréquentes. Quand un changement radical se déroule, le rythme du changement peut être surprenant, mais ce n'est pas toujours un changement positif, et donc pas toujours bien accueilli, surtout si le bénéfice à long terme est masqué par les inconvénients à court terme.

Focus sur la valeur

Un autre concept utile était de penser, de façon parfois obsédante, sur les processus de valeur, les rôles et ce que les outils apportent au processus de release. Ceci nous a conduits à contester les interfaces entre dev et ops, et aussi la façon dont nous évaluons et gérons les risques. Il est facile avec le temps de considérer le mauvais et l'indifférence comme acceptée et incontestée. Une technique simple contre cela est de toujours challenger les process et de se demander "Quel avantage cela m'apporte?". Nous avons également utilisé une technique plus rigoureuse nommée Value Stream Mapping. C'est une façon de visualiser et de comprendre l'ensemble du processus de développement du produit.

4. Ce que nous avons fait - ce qui a fonctionné et ce qui n'a pas

Juste assez d'outils

Une des premières initiatives visait à améliorer le processus de livraison en réduisant les erreurs et en accélérant la gestion des informations de configuration. Une passation était nécessaire, car les différents environnements avant la production étaient détenus par des équipes différentes. Les outils sont rapidement devenus complexes, en essayant de servir à la fois les fournisseurs et les consommateurs de données. Une sorte de course aux armements a commencé, avec des exigences étant ajoutées pour chaque défaillance spécifique. Plus ils grandissaient, plus ces outils devenaient compliqués, certains se révélant plus un obstacle qu'une aide. Ces outils ont pour objectif de gérer l'interface entre les équipes, mais ils viennent en fait renforcer la différence entre ces équipes, et, pire encore, découragent la communication et la collaboration.

Pour aider avec ces nouveaux outils, des processus ont été introduits. Nous voulions que tout le monde soit responsable pour le déploiement d'applications, alors qu'auparavant seuls l'étaient les opérateurs. En intégrant les exigences de l'ops et des devs, nous avons développé un outil de déploiement qui a standardisé le processus de release, la gestion de la configuration, l'orchestration et la vérification des déploiements sur différents environnements. Il l'a fait juste assez, et nous nous sommes fondés sur une saine collaboration pour faire le reste.

L'approche de la gestion dépendance est un bon exemple. L'architecture orientée service contenait des dépendances complexes, mais le logiciel semblait un moyen coûteux de traiter le problème, nous avons économisé nos efforts avec quelques règles simples. Comme d'habitude les ingénieurs ont pris en charge les tests automatisés et la maintenance de la compatibilité de leurs services avec leurs consommateurs. Puis nous avons ajouté la notion de «transaction de déploiement», un verrou exclusif sur l'intégration et les environnements en cours d'exécution. Cela signifie qu'un seul service pourrait être testé et déployé à la fois, ce qui réduit le risque d'avoir des problèmes d'ordre lors du déploiement. Un effet secondaire utile, c'est que l'approche a favorisé la conversation entre les équipes en attente pour l'opération, la promotion de la compréhension des différentes parties du système

Organisation et direction

Dans un environnement classique, l'ingénierie et les opérations sont des organisations distinctes, il y avait une différence d'impédance entre les deux organisations - leurs propres équipes, les méthodes de travail, le leadership et les styles. Les objectifs et incitations étaient différents, pour résumer, les ops étaient incités à la stabilité et les devs étaient rémunérés pour apporter du changement. Il était évident que nous avions besoin de créer une structure qui encourage une plus grande collaboration et la promotion des objectifs communs.

Bien que nous aimerions penser que la plupart des problèmes peuvent être résolus au niveau technique, dans une grande organisation, le taux de changement est souvent accéléré par les évangélistes, un leadership fort et un ensemble critique de personnes donnant le bon exemple. Un gestionnaire de réflexion s'est imposé afin de mener les deux équipes de développement et d'exploitation, à cheval sur le fossé. Cela a contribué à changer les comportements, et crucialement lui a permis de voir et de comprendre les points de vue, une source inestimable d'informations.

Culture

La culture dans l'équipe de développement reposait sur l'agilité, en utilisant un mélange de Scrum, Kanban et des concepts Lean. Cela signifiait que nous avions déjà un pied, d'une certaine façon, dans la culture DevOps que nous voulions créer. Il y avait déjà une certaine collaboration, et des connaissances qui se chevauchaient, mais il y avait des domaines spécifiques à améliorer, et se méfier. Détendre certaines des règles et laisser les gens travailler en dehors de leurs zones normales d'expertise pourrait conduire à des échecs, et conduire à une culture du blâme démoralisante et énergivore. Nos principes culturels clés comprenaient confiance, accepter que les choses soient cassées de temps en temps, apprentissage partagé, et la responsabilité au bon endroit.

L'adoption de l'outil de déploiement a été l'une des premières choses pour tester cette culture. Les ops ont effectué tous les changements de production, ils avaient une connaissance intime des systèmes, pourquoi diable devraient-ils faire confiance aux ingénieurs pour faire des déploiements sans surveillance ? Pour en savoir plus, nous avons utilisé une expérience de Fail Safe, un «poste de travail de déploiement» a été mis en place dans le cœur de l'espace ops. C'était le seul endroit où les déploiements pourraient avoir lieu et ceux-ci ne pouvaient être réalisés que si à la fois un opérateur et un développeur étaient présents. Au fil du temps, l'expérience venant, les bugs ont été corrigés, l'outil affiné, la confiance acquise et l'outil est devenu omniprésent.

Pendant la période où les développeurs et opérationnels les échangeaient peu, il y avait une sorte de «collaboration réactive», une tendance à ne parler que lorsque les choses allaient mal. Cela signifiait une mauvaise planification à long terme, et a encouragé une attitude défensive des deux équipes. Nous avons cherché à encourager les premières conversations, que la collaboration soit toujours plus facile si vous partagez le même vocabulaire, nous avons mis en place des formations inter-équipes et des ateliers.

Il est intéressant de noter que la prochaine embauche est une opportunité vitale, non seulement pour accroître les compétences de l'équipe, mais pour orienter la culture dans une direction souhaitée. Donc, nous avons considéré quel type de compétences et quels principes favoriseraient une culture DevOps. Dans un entretien, il est instructif de demander à un "ops" ce qu'il ressent pour les développeurs de logiciels qui travaillent directement sur les systèmes de production, ou à un ingénieur, comment il se sentirait si son code entrait en service 30 minutes après l'avoir commité ? Du sang qui s'écoule du visage et des bras saisissant le fauteuil ne sont pas des signes prometteurs.

5. Où sommes-nous maintenant

La mentalité DevOps était un des fondements pour l'amélioration de notre capacité de release, mais les avantages de cette approche sont souvent cachés sous la bannière de livraison continue. Passons en revue les domaines qui ont été si problématiques lorsque les releases étaient rares :

Qualité - En général, la qualité des services a augmenté. Le rôle de DevOps en cela est plus visible quand il y a des incidents en productions tels que des bugs, des pannes ou une augmentation du temps de réponse. Cela montre à la fois comment les problèmes de production sont remarqués, et ce qui arrive quand ils le sont. Les systèmes de monitoring de production pourraient être grossièrement classés en deux domaines: l'infrastructure et les applications. Les outils de monitoring d'infrastructure (Nagios, Keynote) sont créés avec les besoins de l'OPS à l'esprit, les outils de monitoring d'applications (graphite) sont plus construits pour les besoins des devs. Le chevauchement ou redondance entre ces outils est souhaitable, deux points de vue sur les mêmes systèmes agissent comme un contrôle de parité. Lorsqu'un incident se produit, la collaboration se fait via Campfire, directement entre les personnes qui sont nécessaires et peuvent ajouter de la valeur. Si avez été la personne transpirant sur la console sur un serveur de production, avec un chef de projet sur une épaule, et votre patron sur l'autre, vous comprendrez comment c'est rafraîchissant.

Risque - Le risque, la probabilité de problèmes suite à une release, a diminué. Les petits changements progressifs réduisent le risque dû au changement, et de façon cruciale rende plus facile d'évaluer le risque. Dans une relation DevOps saine, les personnes ont suffisamment de connaissances pour faire une évaluation elles-mêmes, ou savent quand demander de l'expertise d'une autre équipe.

Motivation - je crois que la motivation des gens s'est améliorée, il y a encore beaucoup de frustrations, mais sachant que les délais de déploiement sont courts, cela fait une grosse différence de savoir que les ops et les ingénieurs se soutiendront mutuellement. Avec la responsabilité au bon endroit, les gens font le travail pour lequel ils ont signé et plus de temps est consacré à la création, plutôt que la livraison du produit. Pour les ops cela signifie moins de temps à lutter contre les incendies, et plus de temps à investir dans notre plate-forme, en particulier du côté de l'automatisation.

Coût - Le coût, en terme de temps, pour accoucher d'un changement est certainement là où les nouvelles méthodes de travail DevOps ont eu le plus d'impact. Un outillage de déploiement commun fait gagner du temps. La collaboration, la planification et le dépistage précoce font que les applications sont presque certaines de fonctionner sur les infrastructures de production, plutôt que d'avoir peur des surprises désagréables. Les coûts des enquêtes de gestion sont réduits en raison d'une plus grande compréhension et une confiance entre les deux zones.

Qui reçoit le bipper?

Dans le cas où vous vous interrogez sur le classique "qui reçoit le bipper ?" - Ce sont les ops. Ils ont les compétences et l'expérience nécessaires pour traiter des questions en direct, sans parler de méthodes de travail axées sur les appels et des réactions rapides. Il y a quelque chose de différent si l'implication des ingénieurs R&D est beaucoup plus rapide, et que c'est une une méthode de travail acceptée.

6. Les défis auxquels nous sommes confrontés aujourd'hui...

Nous sommes maintenant confrontés à deux défis classiques qui suivent le changement - continuer d'avancer, et de mieux en mieux. Continuer d'avancer tout en maintenant une culture des DevOps naissante doit être réaliste, les ingénieurs et les ops arrivent à faire avancer les choses en travaillant et en apprenant ensemble, l'entreprise voit des avantages clairs et y est favorable. Compte tenu de l'article Range of DevOps de Mitchell Hashimoto, nous virons un peu vers la droite. Ainsi, alors que les développeurs sont enthousiastes à relever de nouveaux défis, nous devons prendre soin que la perspective des ops soit prise en compte.

John Wills met en avant le fait que DevOps est à propos de culture, d'automatisation, de mesure et de partage. L'automatisation et la mesure pourraient être notre prochain point à améliorer, les deux zones qui ont besoin de suivre le rythme de la technologie et qui ont besoin se développer en même temps, plutôt qu’a posteriori. Le côté technique de DevOps ne sera mis en place. Nous expérimentons souvent de nouveaux langages et de nouvelles approches en matière de provisionnement, comme Clojure en conjonction avec Palette.

Il y a aussi le défi de construire sur ce que nous avons appris en réunissant deux équipes très disparates. Des avantages énormes ont été acquis en mettant l'accent sur la collaboration et la compréhension d'autres responsabilités, perspectives et priorités. Les comportements qui ont mené à notre intérêt pour DevOps peuvent servir à d'autres personnes dans l'organisation, qui pourraient en tirer des avantages similaires.

7. En conclusion...

Il est assez difficile de résumer trois ans de greffe, d'apprentissage et de changement, surtout quand tant de gens brillants et variés ont été impliqués. Pour évaluer l'impact des DevOps, de livraison continue, de l'agilité ou toute autre chose que nous avons fait, et d'en tirer des informations utiles, est tout aussi délicat.

Il y avait quelques éléments clés. Appliquer les principes agiles nous a permis d'inspecter, de s'adapter et d'apprendre. Nous sentons que nous avons fait des progrès en vue de devenir une organisation qui apprend (Jez Humble a un post sur pourquoi cela est important plus que n'importe quoi d'autre) Ces habitudes et méthodes de travail (notre culture pourrait-on dire) étaient cruciale, de nombreuses idées en découlaient, tout comme l'élan nécessaire pour continuer à s'améliorer.

Suivre les pensées et les principes d'organisation comme Etsy, Flickr, Thoughtworks et le livre génial de Jez Humble, nous a permis d'apprendre rapidement. L'émergence de la communauté DevOps, sa convivialité et sa volonté de partager (caractérisée par DevOpsDays) nous a permis de réaliser l'importance et les avantages de la pratique.

Une première étape clé a été de reconnaître les échecs, arrêter de planifier notre prochaine étape, et commencer à changer. Les choses auraient pu aller plus rapidement, mais nous avons promu les concepts Agile et DevOps et persévéré, à un moment donné tout a été réuni et nous avons commencé à évoluer rapidement. Dans le même temps, nos produits se sont améliorés et l'enthousiasme a augmenté. Obtenir le temps et l'engagement étaient quelques-uns des plus grands défis. Reconnaissant que certaines choses ne peuvent pas changer, encore, et attendant patiemment le moment propice, était tout aussi important.

En résumé, je pense que ces expériences ont montré que les comportements DevOps peuvent être introduits et maintenus, dans une grande organisation, mais il faut les cinq P : Promotion, Planification, Persévérance, Patience, et bien sûr, Pizza.

À propos de l'auteur

John Clapham est un manager en développement logiciel dans la division Divertissement de Nokia basé à Bristol. Auparavant, en tant que Product Owner pour l'équipe livraison continue, il a contribué à transformer le processus de release de la plate-forme Divertissement à partir d'un processus couteux, une fois tous les trois mois, vers une routine de une fois toutes les 30 minutes. John est passionné agile, coaching, café et trouver de nouvelles façons de construire de bons produits. John peut être trouvé sur Twitter comme @johnC_bristol, et sur LinkedIn.