Fort de 1200 personnes, réparties sur Nantes, Lille et Paris, SNCF Connect & Tech, filiale de la compagnie nationale de chemins de fer, est à la fois un e-commerçant clef du web français, totalisant 1,3 milliard de visites et 209 millions de billets vendus en 2023, et une agence créatrice de solutions numériques d'abord pour la SNCF (écrans en gare, outils pour les conducteurs, etc.), mais aussi pour les autorités organisatrices des transports ou d'autres entreprises.

En 2021, la société a achevé sa migration sur le cloud AWS, une opération massive bouclée en 18 mois. Un choix radical qui a bouleversé les pratiques internes d'exploitation, comme le raconte Emmanuel Thys, le directeur de la production de SNCF Connect & Tech depuis la mi-2022, à la tête d'une équipe d'une quinzaine de personnes dédiée à la qualité et aux processus d'exploitation.

Vous avez achevé votre migration sur AWS en 2021. Cette politique mono-cloud pourrait-elle être remise en cause, par exemple pour avoir un levier de négociation supplémentaire avec votre fournisseur ?

Emmanuel Thys : Nous avons un seul opérateur de cloud sur notre application de production, AWS, même si, de façon plus anecdotique, nous avons quelques applications internes hébergées sur Azure. Ce choix du mono-cloud n'est pas remis en cause. Vu l'importance de volumes que nous représentons, brandir une présence chez un autre prestataire ne serait de toute façon pas forcément un bon levier de négociation. Même si cela pourrait offrir une solution de repli en cas de rupture avec AWS. Ce choix du mono-cloud, qui n'a pas été facile, résulte d'un parti pris affirmé, qui va jusqu'à se baser sur les spécificités des architectures de ce fournisseur.

Comment gérez-vous les liens avec les systèmes externes, comme la gestion des réservations de la SNCF ?

Depuis sa refonte en SNCF Connect, notre site de e-commerce enregistre davantage de visites pour de la recherche d'itinéraires point à point et de l'agrégation d'informations voyageurs, qui peuvent provenir de sources très variées, que pour la distribution des billets à proprement parler. Pour produire SNCF Connect, mais aussi tous les autres services digitaux, un grand nombre d'interactions avec des systèmes tiers et/ou hébergés par une autre entité sont donc indispensables.

Dans notre contexte marqué par de très grands volumes, nous traitons la question des temps de réponse des tiers principalement avec des coupe-circuits. Par exemple, sur un check-out, en complément d'un billet de train, le site peut proposer un service de location de voiture, via un appel à des tiers. Mais, si le temps de réponse n'est pas satisfaisant, cet appel sera automatiquement coupé pour ne pas dégrader notre propre service. Quand un service externe se trouve directement sur le parcours d'achat d'un titre de transport ou sur le parcours de consultation d'une information voyageur - ce qui passe par la sollicitation de partenaires internes au groupe le plus souvent -, les coupe-circuits peuvent ne plus être automatiques, en fonction des scénarios. Car, dans certains cas, une coupure peut alors avoir un impact sur les propositions commerciales au coeur de notre activité. Par exemple si le ralentissement affecte un des systèmes de réservation de la SNCF - Inoui, Ouigo, Ouigo Espagne, TER -, la coupure serait activée uniquement sur décision, en cas d'incident grave.

Sans ces coupe-circuits, du fait des volumes que nous encaissons, toute dégradation des temps de réponse va se traduire par une accumulation des requêtes sur l'application. Il faut donc trouver un équilibre. Couper le circuit permet de vider la baignoire.

Comment calculez-vous ce point d'équilibre et vous assurez-vous de sa pertinence ?

Nous éprouvons ces mécanismes avec des tirs de charge, permettant de simuler des conditions de température et de pression extrêmes, et en introduisant des perturbations selon les principes du Chaos Engineering. Cette approche est très ancrée dans nos pratiques de production, car les parcours - calcul d'itinéraires, mise au panier, paiement, etc. - mis en oeuvre dans notre application sollicitent énormément de briques applicatives, que l'on parle des couches de sécurité, des composants front-office ou back-office. Chaque équipe Devops en charge d'un composant est responsable d'effectuer ses propres tirs de charge pour respecter ses niveaux de service. Et, bien-sûr, nous effectuons en complément des tests de bout en bout, pour valider que l'ensemble de la chaîne se comporte bien.

Comment évoluent les usages du Chaos Engineering en interne ?

Depuis deux ans, nous travaillons beaucoup sur des scénarios de pannes et de perturbations, souvent inspirés de faits réels. Nous nous en servons pour éprouver la résilience des systèmes et des équipes, pour mesurer comment elles réagissent à ces scénarios. Par ailleurs, même si nous ne l'avions pas forcément anticipé, ces scénarios servent aussi beaucoup en formation pour les ops et les équipes de support.

Pour l'instant, les tirs de charge sont effectués tant sur la production que sur des environnements de pré-production - même si c'est de façon un peu plus légère sur la première -, tandis que les scénarios de Chaos Engineering ne sont joués que hors production. Mais nous avons pour objectif de les étendre à la production également !

Sur une architecture 100% cloud, quelles sont les principales problématiques de l'équipe en charge de la production ?

Être 100% cloud nous permet d'aller plus loin dans la recherche de la qualité de service. Car nous mettons derrière nous les problématiques de pannes physiques - casses de disques, engorgements du réseau, etc. - via des environnements extrêmement résilients par construction. Nous héritons aussi de beaucoup de mécanismes de résilience, via un hébergement sur trois zones AWS, et de mises à l'échelle automatiques, via l'usage de Kubernetes essentiellement. Nous pouvons donc nous consacrer à nos processus de production, comme la gestion des changements. Nous assurer de leur robustesse, pour la gestion d'un incident ou d'une crise. Travailler sur nos retours d'expérience suite à un événement ou une campagne de tirs de charge. Mettre en place les bons mécanismes de retour arrière ou la bonne définition des standards d'hypervision. Le quotidien de mon équipe consiste à se focaliser sur la qualité.

Avez-vous déployé des mécanismes d'auto-réparation de votre infrastructure (self-healing) ?

Ces scénarios sont assez faciles à déployer sur des pannes simples, comme évincer et reconstruire une entité qui ne répond de façon incorrecte au sein d'un pool de ressources. Comme nous sommes 100% sur des architectures d'infrastructure as code depuis la migration cloud - même si nous sommes passés d'une technologie maison à Terraform -, il suffit de sortir cette entité du flux et d'en reconstruire une autre.

Mais, très souvent, les incidents qui ont un réel impact sur la production résultent de plusieurs facteurs ou sont la combinaison de plusieurs événements. L'analyse d'un ou plusieurs experts est alors souvent nécessaire. D'où l'intérêt de réfléchir à ces scénarios et de les simuler. Surtout que ceux-ci sont souvent écrits par les personnes les plus aguerries de l'organisation et mis en oeuvre par le reste de l'équipe, permettant une transmission des connaissances.

Comment gérez-vous les pics de charge, que ceux-ci soient prévus, du fait de l'ouverture à la vente des billets de train sur une période, ou résultent d'événements imprévus, comme les incendies qui ont touché les lignes TGV en amont de la cérémonie d'ouverture des J.O. ?

Nous avons défini trois gabarits standards, documentés et activables : un gabarit normal, un gabarit d'ouverture de vente et un dernier orienté SAV et informations voyageurs. Quand le 31 juillet, par exemple, des lignes ont été coupées en raison d'événements météo, ce gabarit a été activé pour assurer les échanges et remboursements et délivrer l'information voyageurs. Ces gabarits s'activent relativement vite, en moins d'une heure. Donc, même quand on est surpris par un événement, nous sommes en mesure de réagir relativement vite. Par ailleurs, nous avons une certaine marge sur notre gabarit standard, couplé à des mécanismes de protection comme des salles d'attente.

Au fil du temps, ces gabarits comportent eux-mêmes de moins en moins de ressources du fait de l'adaptation de nos architectures pour embrasser les technologies cloud. Par exemple, en passant de la VM à des environnements Kubernetes, par essence prêts pour les mises à l'échelle automatiques. De notre côté, nous avons donc de moins en moins d'actions à faire dans la mise en oeuvre de ces gabarits.

Ces architectures ont-elles aussi été adaptées aux spécificités de votre fournisseur de cloud ? Et quel est l'impact de ce travail en termes de coûts ?

On peut schématiser cette adaptation des architectures avec trois générations de workloads : la VM dans le cloud, les clusters d'orchestrateurs de conteneurs et le Function-as-a-service, comme les services Lambda chez AWS. De nombreux passages de VM vers les clusters Kubernetes ont eu lieu dès la migration vers le cloud. En complément, depuis trois ans, certains projets tournant sur des VM basculent vers la seconde ou la troisième génération. Et tout nouveau projet se développe sur ces deux dernières générations. [Actuellement, l'infrastructure de SNCF Connect & Tech tourne sur environ 35% de VM, 50% de clusters Kubernetes et 15% de serverless, NDLR].

Ces refactorings permettent effectivement une utilisation au plus juste des ressources, donc une diminution des coûts, associée à des mécanismes de mises à l'échelle automatiques. Le passage des VM à Kubernetes est promu auprès des équipes applicatives via les économies substantielles qu'il engendre, économies variables en fonction des projets. Mais, bien souvent, on parle d'une division par deux de la facture. Or, ce sont les équipes applicatives qui portent leur budget cloud.

Deux grands leviers de FinOps sont en réalité associés. Le premier mise sur l'utilisation des mécaniques contractuelles de notre fournisseur, qui propose divers plans d'optimisation. Et le second consiste à ajuster la consommation au plus juste, un exercice à rendement décroissant au fil du temps. Aller chercher les gains dépassant les premières évidences nécessite de l'ingénierie.

On assiste souvent à des frictions entre la production et les équipes applicatives sur ce sujet, le réflexe de la première étant de maximiser les performances pour assurer la disponibilité ?

C'est un des éléments qui m'ont frappé en arrivant dans le groupe : nous sommes suffisamment résilients pour bien nous entendre avec les FinOps. Depuis mon arrivée, je n'ai pas assisté à une panne significative. En 2023, nous affichons une durée d'incident moyenne de 50 minutes. Ces incidents sont donc clos ou contournés très rapidement, même si la problématique peut donner lieu à un projet d'amélioration déployé plus tard. Plus de 90% des incidents dits majeurs - ce qui chez nous est caractérisé à des seuils très bas, comme plus 10% de taux d'échec sur la réponse d'un service - proviennent de perturbations venant de partenaires.

Par ailleurs, comme la culture de la production est largement diffusée dans les équipes DevOps, y compris parmi les profils de développeurs, les discussions sont assez naturelles. Si les recommandations FinOps ont taillé trop juste, nous avons la capacité à revenir en arrière en encaissant momentanément la charge via nos mécanismes de résilience en place.

Sur quels projets d'innovation travaillez-vous en ce moment ?

Nous travaillons beaucoup sur l'hypervision, soit la supervision des chaînes de service à la transaction plutôt que sur des indicateurs globaux et des seuils d'alerte. Et ce, de bout en bout. L'objectif est d'avoir une vision à un seul endroit du parcours client, avec les métriques des composants sollicités, mais aussi de leurs interfaces. Ce passage à l'hypervision doit aider à accélérer le diagnostic des perturbations, via une vision orientée services. Le projet, réalisé pour l'instant sur la technologie Datadog, est en développement. L'hypervision des premières chaînes de service devrait être mise en oeuvre au cours du quatrième trimestre, au plus tard.