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
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. @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. @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. @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. @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
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
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
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
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
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)
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
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
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
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. @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
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
