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

Devops chez Voyages-Sncf.com

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

Consultez-les par la suite

1 sur 44 Publicité

Devops chez Voyages-Sncf.com

Télécharger pour lire hors ligne

1h d’indisponibilité = 1 M€ de perte
Découvrez comment Voyages-sncf.com s’est appuyé sur la démarche DevOps pour innover et garantir un Time To Market concurrentiel tout en conservant un SLA irréprochable

1h d’indisponibilité = 1 M€ de perte
Découvrez comment Voyages-sncf.com s’est appuyé sur la démarche DevOps pour innover et garantir un Time To Market concurrentiel tout en conservant un SLA irréprochable

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Devops chez Voyages-Sncf.com (20)

Publicité

Plus récents (20)

Devops chez Voyages-Sncf.com

  1. 1. @aguilloteau
  2. 2. @aguilloteau Antony GUILLOTEAU Scrum master @Voyages-sncf.com Votre speaker
  3. 3. @aguilloteau L’agilité pour rapprocher le Dev et le métier
  4. 4. @aguilloteau L’Ops : le grand oublié de l’agilité
  5. 5. @aguilloteau Dev & Ops : des objectifs orthogonaux
  6. 6. @aguilloteau Quelques symptômes En cas de crise, combien de temps faut-il pour lever une alerte, récupérer les logs, les analyser puis identifier la défaillance ? Combien de temps pour livrer un correctif en production ? Quelle sont la fréquence et la simplicité des mises en production ? Existe-t-il des échanges informels entre Dev et Ops ?
  7. 7. @aguilloteau Les objectifs du DevOps Un même objectif : délivrer le meilleur logiciel aux clients de l’entreprise Améliorer la coopération entre les Dev et les Ops Fluidifier l’élaboration du produit Améliorer la livraison du produit
  8. 8. @aguilloteau Voyages-sncf en quelques chiffres 4,32 milliards d’euros de volume d’affaires en 2015 3,1% de croissance 1000 collaborateurs 2/3 Dédiés à l’international 52% de femmes et 48% d’hommes
  9. 9. @aguilloteau Voyages-sncf en quelques chiffres NUMERO 1 DU E-TOURISME 1er site de voyages en ligne français 12 millions de visiteurs uniques par mois 80 millions de voyages vendus en 2015 FLEURON TECHNOLOGIQUE 250 ingénieurs 2 data-centers 3500 serveurs 60 téraoctets de données traitées chaque mois 28 ventes par seconde
  10. 10. @aguilloteau Voyages-sncf en quelques chiffres Taux de disponibilité de 99,997% soit 15 minutes d’indisponibilité par an 1 heure d’indisponibilité = 1 millions d’euro de VA de perte sur le WEB France
  11. 11. @aguilloteau Améliorer la coopération Dev & Ops
  12. 12. @aguilloteau Améliorer la coopération Dev & Ops Manque de communication & incompréhension
  13. 13. @aguilloteau Améliorer la coopération Dev & Ops Intégration des Ops dans la vie du sprint de Dev (présence aux démonstrations fonctionnelles, démonstrations dédiées, participation aux cadrages, …) Point hebdomadaire entre Dev & Ops pour échanger sur la vie de la production Accompagnement des Dev lors des bascules de production Communautés de pratique transverses
  14. 14. @aguilloteau Fluidifier l’élaboration du produit
  15. 15. @aguilloteau Fluidifier l’élaboration du produit
  16. 16. @aguilloteau Fluidifier l’élaboration du produit Développer avec la cible (environnement de production)
  17. 17. @aguilloteau Développer avec la cible Environnement similaire du développement à la production Infrastructure “as a Service” interne Les configurations de production sont répliquées jusqu’aux environnements de développement
  18. 18. @aguilloteau Fluidifier l’élaboration du produit Adapter le SI aux besoins des développeurs
  19. 19. @aguilloteau Adapter le SI aux besoins des développeurs Les Dev proposent les technologies les plus adaptées au développement du produit Les Ops challengent les technologies proposées en amont Les Devs et les Ops sont impliqués dans leurs mises en oeuvre
  20. 20. @aguilloteau Fluidifier l’élaboration du produit Alerter des modifications de comportement
  21. 21. @aguilloteau Alerter des modifications de comportement Démarche Behavior Driven Development pour identifier les éventuelles régressions fonctionnelles Tests de performance automatisés pour ne pas détériorer les performances avec les nouvelles fonctionnalités Tests de charges pour s’assurer du bon fonctionnement du produit en production Sous la responsabilité de l’équipe de développement
  22. 22. @aguilloteau Fluidifier l’élaboration du produit Monitorer pour prévenir
  23. 23. @aguilloteau Monitorer pour prévenir Définition des indicateurs avec les Dev, les Ops et le métier Des logs centralisées pour analyser les incidents (ELK) Le Big data nous permet de stocker ce volume d’informations Les dashboards de supervision techniques et métiers sont réalisés par l'équipe (Grafana)
  24. 24. @aguilloteau Améliorer la livraison du produit
  25. 25. @aguilloteau Améliorer la livraison du produit Les Dev développent et livrent Les Ops installent et exploitent
  26. 26. @aguilloteau Améliorer la livraison du produit Une usine logicielle performante pour livrer rapidement
  27. 27. @aguilloteau Une usine logicielle performante Dépôt de code versionné (GIT, SVN) Pipeline de livraison pour déployer automatiquement le produit en construction Serveur d’intégration continue pour construire automatiquement le produit (Jenkins) Outil de release pour packager le produit automatiquement Outil commun avec la production pour le déploiement sur les environnements d’assemblage, d’intégration et de recette
  28. 28. @aguilloteau Améliorer la livraison du produit Fiabiliser les livraisons
  29. 29. @aguilloteau Fiabiliser les livraisons Validation des installations avec l’exécution des tests fonctionnels (Behavior Driven Development) sur les différents environnements Environnement ISO-PROD pour valider l’installation Tests de performance automatisés et tests de charge
  30. 30. @aguilloteau Améliorer la livraison du produit Un produit stable
  31. 31. @aguilloteau Un produit stable Utiliser les Feature toggle pour déployer souvent en désactivant les fonctionnalités non abouties Mettre en oeuvre des circuit breaker pour améliorer la résilience de son application Utiliser le dark launch (production cachée) pour valider au plus tôt les nouvelles fonctionnalités sans impacter tous les utilisateurs
  32. 32. @aguilloteau DevOps, une transformation à tous les étages
  33. 33. @aguilloteau Devops, une transformation à tous les étages
  34. 34. @aguilloteau Devops, une transformation à tous les étages Industrialiser l’usine logicielle, la livraison, les tests, le déploiement, le monitoring Evolution des rôles et missions de chacun : former les Dev et Ops Privilégier le management matriciel au management opérationnel
  35. 35. @aguilloteau Mais des résultats probants Site VSC : 4 mises en production par an ⇒ 1 mise en production par mois Certains projets avec une mise en production à chaque sprint Des fonctionnalités beta en 3 mois plutôt qu’un cycle de 9 mois Open source interne pour autonomie des équipes
  36. 36. @aguilloteau L’évolution DevOps en synthèse
  37. 37. @aguilloteau L’évolution DevOps en synthèse
  38. 38. @aguilloteau L’évolution DevOps en synthèse
  39. 39. @aguilloteau L’évolution DevOps en synthèse
  40. 40. @aguilloteau L’évolution DevOps en synthèse
  41. 41. @aguilloteau L’évolution DevOps en synthèse
  42. 42. @aguilloteau L’évolution DevOps en synthèse
  43. 43. @aguilloteau L’évolution DevOps en synthèse
  44. 44. @aguilloteau

Notes de l'éditeur

  • Aller plus loin ensemble
  • Scrum master Voyages-sncf
    agilité à l’échelle de l’entreprise depuis 2012 (Chaîne Youtube VSC)
    Travaille actuellement sur un projet organisé en 3 équipes Scrum / mise en place démarche DevOps
    Mon leitmotiv : que tout le monde travaille ensemble en partageant un objectif commun
  • Rappel valeur :
    logiciel opérationnel plutôt que documentation exhaustive
    Interaction plutôt que processus
    Adaptation au changement plutôt que suivi d’un plan
    Moindre mesure : La collaboration avec les clients plus que la négociation contractuelle
  • Dev (développement) : évolution des systèmes
    Ops (exploitation) : garants stabilité et disponibilité des systèmes
  • Fréquence et simplicité de MEP :
    Les Ops sont rarement impliqués au démarrage des projets.
    Il s’ensuit des délais allongés entre la livraison des applications et celle des machines qui serviront de socle
    Existe-t-il des échanges informels entre Dev et Ops ?
    Souvent uniquement par mail ou par ticket (type JIRA)
  • Coopération :
    Construire et MCO en commun
    Fluidifier
    Développer avec la cible (environnement de production) et adapter le SI aux besoins des développeurs.
    Alerter et monitoring (prévenir)
    Livraison
    Rapidité du TTM en garantissant la fiabilité et la stabilité du produit
  • Peu d’échanges (dév ➔ ops pour aider l’installation et l’exploitation, ops ➔ dév pour améliorer le monitoring techniques ET métier)
    Coopération : Construire et MCO en commun
  • Développer avec la cible (environnement de production) et adapter le SI aux besoins des développeurs.
    Monitoring
  • Environnements similaires
    version logicielle, architecture (apache)
    Infrastructure as a service :
    Les dév ne sont plus ralentis par la mise à disposition d’environnement
    Les dev ne ralentissent plus les Ops avec des demandes d’actions sans valeur ajoutée
  • Pour être informé des modifications de comportement
  • Impacts opérationnels et managériaux
  • Evolution des rôles :
    Le Dev fait de l’Ops : sensibilisation
    L’Ops fait du Dev (équipe pluri disciplinaire) : former et accompagner le changement
    Management matriciel :
    Les équipes sont éphémères (la durée d’un projet)
  • Waterfall (cycle en V)
    Mise en production espacées avec un contenu important (1 à 2 releases par an)
    Souvent dans la douleur ➔ phase de validation en fin de version
  • Agile
    Cycle itératif avec un produit « testable » à la fin de chaque itération ➔ à des fins de validation et non d’installation
    Notion de release qui regroupe plusieurs itérations
  • Lean :
    se base sur l’agile,
    industrialisation des processus,
    partage de connaissance dans l’équipe,
    pluri-disciplinarité des membres de l’organisation
    Toyota et le kaisen
  • Continous integration :
    Capacité de tester et déployer automatiquement
    et de manière industrialiser le soft
  • Continous delivery
    L’équipe produit un software sur des cycles courts,
    pouvant être releasé n’importe quand
  • Continous deployment :
    Chaque changement (i.e. commit) est déployé en production
  • Continous operations ou « Canary Release »
    Déploiement blue / green
    0 downtime
    Facilité de rollback
    Minimise les risques d’échec (First Attempt In Learning)
    Démarche nécessaire pour l’AB testing

×