Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Devops, un tour d'horizon - Eutelsat 2018

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 38 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Devops, un tour d'horizon - Eutelsat 2018 (20)

Publicité

Plus par Ludovic Piot (15)

Plus récents (20)

Publicité

Devops, un tour d'horizon - Eutelsat 2018

  1. 1. DevOps @ Eutelsat – 28-juin DEVOPS UN TOUR D’HORIZON
  2. 2. LE SPEAKER Ludovic Piot @lpiot
  3. 3. Agenda UNE TENTATIVE DE DÉFINITION ▪ Pourquoi un tel engouement ? ▪ Disclaimer ▪ Une proposition de définition LES ORIGINES ▪ le mur de la confusion ▪ le mouvement agile : exemple à suivre ▪ le mur de la confusion OPS, THE FINAL FRONTIER ▪ la software factory : terrain de réconciliation KNOWING THE PATH VS. WALKING THE PATH ▪ DevOps is... / is not… ▪ TRS ▪ Tools ▪ Pistes de mise en œuvre
  4. 4. DEVOPS Une tentative de définition
  5. 5. DEVOPS – pourquoi un tel engouement ? Source:StateofDevOpsreport2016-2017 (Puppet+DevopsResearch&Assessment)
  6. 6. DEVOPS – pourquoi un tel engouement ? Source:StateofDevOpsreport2016 (Puppet+DevopsResearch&Assessment)
  7. 7. DEVOPS – disclaimer “It’s not about the destination, it’s about the journey” – Gene Kim DevOps n’est pas une méthodologie. Il s’agit de créer une culture dans laquelle Dev et Ops collaborent étroitement et en confiance.
  8. 8. DEVOPS – une proposition de définition L’approche DEVOPS a un objectif unique : ▪ aligner l'ensemble des acteurs et des compétences du système d’information… ▪ … sur la seule qualité du produit fourni à l'utilisateur final Pour cela, la démarche DEVOPS passe par… ▪ l'engagement de l'ensemble des acteurs sur la chaîne de production de valeur, ▪ dans une collaboration libre et sans contrainte ▪ et le souci d’une amélioration continue ▪ par le partage d'informations et de responsabilité ▪ et des outils et méthodes communes ▪ en vue d'automatiser les actions ▪ et ainsi d’étendre au maximum l’autonomie des différents acteurs en dehors de leur périmètre propre La démarche DEVOPS L’approche DEVOPS the Beal-Hedemark golden square Coût Temps Qualité Satisfaction Culture Automation Lean Measure Sharing
  9. 9. DEVOPS les origines
  10. 10. DEVOPS – le mur de la confusion Depuis toujours, DEV et OPS s’opposent à cause d’objectifs antagonistes… Les DEV recherchent : ▪ la rapidité de mise à disposition des nouvelles fonctionnalités aux utilisateurs finaux ▪ culture du produit Les OPS recherchent : ▪ la stabilité, la robustesse ▪ la maîtrise, la performance ▪ la sécurité ▪ l’industrialisation ▪ l’efficience économique ▪ culture du service Mais il y a confusion : ces objectifs sont des objectifs intermédiaires et non exclusifs !
  11. 11. “We don’t need an accurate document, we need a shared understanding” – Jeff Patton
  12. 12. AGILE – au départ, des difficultés similaires… PRATIQUES ▪ des équipes en silo ▪ des échanges sous forme « contractuelle » client/fournisseur ▪ un « effet tunnel » systémique ▪ des hypothèses de travail amont qui contraignent la réalisation CONSTATS ▪ un projet mal maîtrisé (coûts, délais) ▪ des écarts de conformité du livrable avec le besoin ▪ l’apparition tardive des soucis rend les correctifs très coûteux et douloureux ▪ à chaque étape, la pression du planning conduit à accepter les approximations des étapes amont ▪ l’OPS, en bout de cycle, doit se faire le garant du livrable le plus « dénaturé »
  13. 13. AGILE – le pragmatisme et le business… PRATIQUES ▪ des cycles courts et itératifs ▪ des équipes resserrées incluant fonctionnels et techniques ▪ « Do, learn, adapt ! » ▪ « less documentation is more communication » ▪ la construction commune et quotidienne des fonctionnalités du produit ▪ des mises en production plus fréquentes CONSTATS ▪ un projet mieux maîtrisé (coûts, délais) ▪ des ajustements plus rapides et plus fréquents pour rester pertinent ▪ l’introduction de la notion de « fail fast » ▪ une responsabilité partagée entre fonctionnels et techniques ▪ … mais l’OPS n’est toujours pas systématiquement inclus dans la démarche
  14. 14. DEVOPS Ops, the final frontier
  15. 15. ▪ Les méthodes agiles accélèrent et fiabilisent les livraisons des DEV. ▪ Les OPS et le déploiement sont perçus comme l’ultime frein à accélérer le Time-to-Market (TTM). ▪ La nécessité de faire sauter ce dernier goulot d’ étranglement devient flagrante. SOFTWARE FACTORY – le time-to-market s’impose…
  16. 16. L’usine logicielle, utilisée par les DEV, nécessite le savoir-faire des OPS : ▪ forts besoins en optimisation d’infrastructure ▪ forts besoins en automatisation « système » SOFTWARE FACTORY – terrain de réconciliation ❤ Usine de Build Build Vérifier la qualité du code Compiler Récupérer les dépendances Déployer Documenter Exécuter les tests Packager Référentiel binaires Référentiel de tâches et anomalies Plateforme de tests Documentation & Indicateurs BuildGestionnaire de sources Build local Notifications Serveur d’intégration continue
  17. 17. Les besoins en environnements de test explosent : ▪ organisation des équipes par domaine fonctionnel (feature teams) ▪ automatisation des tests (fonctionnels, performances, robustesse, conformité graphique, multi-canal) SOFTWARE FACTORY – infrastructure everywhere!
  18. 18. Le déploiement continu en Production de chaque nouvelle fonctionnalité dès qu’elle est livrée démultiplie les besoins dans le savoir-faire des OPS : ▪ pression de la vélocité ▪ architecture technique complexe (micro-services) ▪ modèles de déploiement complexes (blue/green, canary testing) ▪ évolution perpétuelle de l’infrastructure technique ▪ environnements éphémères ▪ bacs à sable à la demande pour les équipes des systèmes connectés CONTINUOUS DELIVERY – warp speed factor 8! “How long would it take your organization to deploy a change that involves just one single line of code?” - Poppendiek L’OPS devient un acteur indispensable à la réussite du projet de développement
  19. 19. DEVOPS – blue/green deployment
  20. 20. DEVOPS is… / is not…
  21. 21. DEVOPS – is not… 5- “to be a devops, use the tool xxx…” ▪ DevOps n’est pas prioritairement une affaire d’outil. ▪ L’usage d’un outil fréquemment utilisé dans les organisations DevOps n’est ni nécessaire, ni encore moins suffisant pour faire du DevOps. 1- “One tool to rule them all” ▪ Le partage d’outils doit répondre à un besoin de coopération et d’autonomie. ▪ Et non pas à un besoin d’industrialisation ou de respect des standards. 2- “No-OPS” ▪ L’automatisation est un vecteur d’autonomisation des acteurs et d’amélioration des opérations. ▪ Pas un moyen de se décharger de sa responsabilité. 3- “Every DEV has the root password” ▪ DevOps est un mouvement favorisant la coopération, pas le remplacement des OPS par les DEV. ▪ Dans ce sens, certains DEV peuvent avoir besoin de root. ▪ Par nature, DevOps doit minimiser ce besoin. 4- “Every sysadmin should write code / every DEV should rack servers” ▪ La coopération étroite ne veut pas dire la polyvalence de tous. ▪ C’est, au contraire, reconnaître les forces et faiblesses de chacun et en tirer le meilleur, collectivement.
  22. 22. DEVOPS – is… 7- “Fail fast” L’erreur est une richesse d’expérience. Il faut l’accepter comme une composante du mode opératoire, et expérimenter au plus faible coût (et PDCA). 8- “Most valuable product” Toute réalisation doit être itérative, pour accélérer l’arrivée de la feedback loop. On doit chercher le plus petit élément de réalisation qui apporte le maximum de valeur. 9- “In God we trust. Everything else, we test” Toute réalisation n’est achevée que lorsque le test garantissant la conformité de son fonctionnement est associé. 10- “Less doc is more communication” La documentation n’existe pas per se. Elle rendue inutile par le partage des outils et méthodes, du même espace de travail et les rituels de partage de connaissance (stand-up meeting, peer-programming, demo) 11- “Everything fails all the time!” - Werner Vogels Pannes et erreurs humaines sont inévitables. Par design, on doit les circonscrire et mettre en place les contre-mesures qui rendent ces pannes indolores. 1- “User-centric product” La qualité et la pertinence du produit fourni à l’utilisateur final est la seule chose qui importe. 2- “You build it, you run it!” - Werner Vogels le DEV est (co-)responsable de ce qui arrive en Prod (y-compris dans les astreintes). 3- “OPS as enablers, not gatekeepers” - Lindsay Holmwood Dans les domaines dont il est garant, l’OPS doit être facilitateur par son savoir-faire et non-pas censeur. 4- “Measure everything” - Etsy L’obsession de la mesure et de la traçabilité. Ce qui ne se mesure pas n’est qu’affaire d’opinion. 5- “Plan, do, check, act (PDCA)” La démarche d’amélioration continue, basée sur l’expérimentation perpétuelle et la mesure du résultat qui en ressort. 6- « Souriez, vous êtes filmés » Par défaut, la modération n’existe pas. Elle n’intervient qu’à postériori d’une douleur rencontrée. Pas d’over-engineering.
  23. 23. DEVOPS knowing the path vs. walking the path
  24. 24. 6- Augmentez le feedback des Ops 7- Mesurez votre succès à travers des KPIs … synthétiques 8- Adaptez vos processus business à votre vélocité de développement 9- Participez à la communauté 1- Commencez petit … et faites de ce succès un hérault 2- Concentrez-vous sur la culture … et pas sur les outils 3- Investissez sur les outils qui créent de la visibilité en temps réel … et l’intégration poussée dans l’usage de ces outils 4- Déployez des technologies d’automatisation … et ouvrez-en l’usage aux populations du projet 5- Augmentez votre vitesse de déploiement … et faites-en un KPI du projet DEVOPS – 9 bonnes pratiques à mettre en œuvre…
  25. 25. TRS – le Taux de Rendement Synthétique Ponctualité des Mises en Production ▪ P1 - Respect des dates de MEP ▪ P2 - Cadence des MEP par rapport aux sprints ▪ P3 - Profondeur des décalages de date de livraison Taux de Charge TRG Taux de Disponibilité Taux de Performance Taux de Qualité TRS Disponibilité de la plateforme à chaque étape ▪ D1 - Rapidité de mise à dispo. des environnements ▪ D2 - Dispo. des environnements Exigences non fonctionnelles ▪ Q1 - Qualité du code ▪ Q2 - Préparation de la MEP Expérience utilisateur ▪ Q3 - performance applicative ressentie par l’utilisateur  ▪ Q4 - Incidents suite à MEP Taux de Disponibilité Taux de Performance Taux de Qualité Utilisation efficiente des ressources ▪ C1 - Taux d’utilisation des ressources / plateformes
  26. 26. LE TAUX DE RENDEMENT SYNTHÉTIQUE ▪ La mesure aide à fédérer et à faire adhérer ▪ Un moyen pratique d’établir un dialogue ▪ Le TRS permet d’aller vite à l’essentiel. ▪ Cultiver un état d’esprit collaboratif. ▪ L’essayer c’est l’adopter ! TRS – quels enseignements ?
  27. 27. 6- Augmentez le feedback des Ops 7- Mesurez votre succès à travers des KPIs … synthétiques 8- Adaptez vos processus business à votre vélocité de développement 9- Participez à la communauté 1- Commencez petit … et faites de ce succès un hérault 2- Concentrez-vous sur la culture … et pas sur les outils 3- Investissez sur les outils qui créent de la visibilité en temps réel … et l’intégration poussée dans l’usage de ces outils 4- Déployez des technologies d’automatisation … et ouvrez-en l’usage aux populations du projet 5- Augmentez votre vitesse de déploiement … et faites-en un KPI du projet DEVOPS – 9 bonnes pratiques à mettre en œuvre…
  28. 28. Les nouvelles formes de collaboration – Build / ship / run DEV OPS Ephemeral Envs
  29. 29. Tools – Periodic table of DevOps tools
  30. 30. Tools – Continuous Delivery maturity matrix
  31. 31. Roadmap partagée et adaptative Utiliser un outil de project mgmt unique (Jira) : ▪ workflow peu contraignant ▪ workflow facile à faire évoluer Documentation en maintenance collaborative ▪ Rendre la documentation accessible à tous. ▪ Centraliser la doc dans un unique référentiel (Confluence). ▪ Permettre une maintenance collaborative avec validation croisée (pull requests) ▪ Documentation comme vecteur de maîtrise vs. vecteur de références Specs as tests Décrire les fonctionnalités qui, une fois compilées, servent : ▪ de tests unitaires (Cucumber) ▪ ou de tests d’acceptance (FitNesse) Souriez, vous êtes filmés Mettre en place une métrologie accessible à tous sur l’ évolution des docs et des specs : ▪ vélocité d’évolution ▪ qualité des revues ▪ nombre d’allers-retours Plan – Quelques pistes de mise en œuvre DEV OPS
  32. 32. Poste de dev. disponible on-demand Utiliser un outil de déploiement automatisé pour configurer le poste de DEV (Ansible, Vagrant, Packer) : ▪ code disponible sur un dépôt partagé ▪ code adaptable à des contextes projets ▪ à l’échelle d’une équipe / d’un projet / de l’entreprise Peer-review Permettre une validation croisée (pull requests) entre DEV, mais aussi entre DEV et OPS. Dépôts de code communautaires Utiliser des dépôts centralisés : ▪ fonctionnalités de collaboration sociale (Github, Gitlab, BitBucket) ▪ gouvernance de type community management ▪ réemploi de code comme stratégie d’entreprise. Lazy-coupled services Permettre une évolution dissociée de différentes applications / composants. Test development kit cf. rubrique test Code – Quelques pistes de mise en œuvre DEV OPS
  33. 33. Envs éphémères on-demand Pouvoir paralléliser les builds et les tests : ▪ envs. on-demand (Infra as Code) ▪ architecture technique iso prod ▪ jeu de données de test as a service Orchestration as Code Décrire le workflow de build et de tests par programmation (Jenkins Job DSL, Gitlab CI) Performance des tests Optimiser au maximum le temps de passage end-to-end des tests. ▪ mise à dispo de l’env. de test ▪ passage des tests (tests automatisés) ▪ restitution consolidée des résultats Test development kit Fournir un jeu de tests (jeu de données compris) pour tout code communautaire : ▪ tests automatisés ▪ jeu de données de test ▪ code de provisionning d’env. de test ▪ code de provisionning de workflow de test Build / test – Quelques pistes de mise en œuvre DEV OPS
  34. 34. Test like an Ops Embarquer les tests liés au run : ▪ tests de fail-over / recovery / clustering ▪ tests de restauration de données ▪ tests de rollback ▪ tests de performance (nominal, aux limites, endurance) ▪ tests d’upscaling / outscaling ▪ tests d’accès / de sécurité ▪ tests de débordement Page d’autodiagnostic Inclure des tests de base au sein de l’applicatif ▪ test d’accès R/W aux données / aux logs (DB et FS) ▪ test de connexion aux composants techniques / applis tierces ▪ test de load-balancing ▪ identification des serveurs portant les composants testés ▪ affichage de la configuration embarquée Smoke tests Jouer un scénario fonctionnel minimal avant et après chaque opération en production Test – Quelques pistes de mise en œuvre DEV OPS
  35. 35. Release on demand Autonomiser les acteurs du projet sur les opérations techniques : ▪ configuration partagée et collaborative (CMDB on git) ▪ envs. on-demand (Infra as Code) ▪ déploiements automatisés In God we trust. Everything else, we test Tracer et tester l’état de la plateforme avant et après chaque release/deploiement. Full stack release management Versionner et tracer tous les éléments mis en œuvre dans une release : ▪ application ▪ données ▪ code de déploiement ▪ documentation et specs ▪ tests ▪ infrastructure (immutable infrastructure) Release / deploy – Quelques pistes de mise en œuvre DEV OPS
  36. 36. Self-service Autonomiser les acteurs du projet sur les opérations techniques : ▪ automatiser les tâches les plus courantes ▪ outil d’orchestration (Jenkins) Ops As a Service… on demand Packager et fournir les activités des administrateurs sur un projet comme des services clé-en-main. In God we trust. Everything else, we test Inclure le provisionning et la configuration de la métrologie avec chaque tâche de déploiement. Partager les retours d’expérience Rendre les post-mortem publics (fail con’). Exposer les bonnes pratiques / les succès locaux. Supervision collaborative Partager la maintenance et le suivi de la supervision : ▪ outil accessible par tous les acteurs du projet ▪ capacités techniques et applicatives, voire projet ▪ maintenance collaborative avec validation croisée ▪ déploiement et maintenance as code : tests Operate / monitor – Quelques pistes de mise en œuvre DEV OPS
  37. 37. What’s next?
  38. 38. Questions ?

×