OUI.sncf : « le Site Reliability Engineering rationalise et sécurise l’exploitation des systèmes d’information »

Dans les services techniques, on oppose souvent les intérêts des développeurs et ceux des exploitants. L’évolution du système d’information est la priorité des développeurs. Cette modification des sites et des applications va à l’encontre de l’objectif des exploitants, qui est d’assurer la stabilité des systèmes. Des démarches comme DevOps ont émergé afin de concilier au mieux les intérêts de chacun. D’autres entreprises vont plus loin : c’est notamment le cas de OUI.sncf, qui intègre une équipe dédiée au Site Reliability Engineering. Pour en savoir plus sur le SRE et sa mise en place chez le premier site marchand français, nous avons rencontré Guillaume Arnaud, site reliability engineer.

Outiller l’exploitation pour limiter les interventions

Pour les entreprises qui intègrent un système d’information restreint et stable, le nombre d’exploitants nécessaire est acceptable. Mais celles qui sont en phase de développement rapide cherchent à rationaliser leurs besoins. “L’enjeu est de se munir d’outils, côté exploitation, pour gérer un parc d’applications plus grand avec un effectif constant. Pour ce faire, on automatise certains process, on travaille sur la résilience du système. On met tout en œuvre pour que l’intervention humaine soit rare, même en cas d’incident, pour qu’un nombre limité d’exploitants puissent gérer plus de services”.

Par nature, cette démarche ne s’applique pas directement à toutes les entreprises. “Il y a un facteur d’échelle : plus le système d’information grandit, plus l’exploitation doit s’outiller pour être capable de gérer cette scalabilité.”

Une démarche popularisée par Google

Google fut l’une des premières firmes à s’intéresser à ces problématiques. “L’entreprise, en pleine croissance, avait besoin que ses spécialistes de l’exploitation soient en mesure de gérer de plus en plus de serveurs. Ils ont réalisé des projections et compris que s’ils ne réinventaient pas leur manière de fonctionner, ils seraient dans l’obligation de recruter un très grand nombre d’exploitants. En introduisant ce qu’on appelle aujourd’hui le Site Reliability Engineering, Google a souhaité réduire les risques qui pesaient sur l’expansion de son SI et sur la stabilité de ses systèmes”.

Les ingénieurs de Mountain View ont d’ailleurs publié le livre Site Reliability Engineering: How Google runs production systems pour présenter leur méthode.

Le SRE chez OUI.sncf

Certains estiment que la démarche SRE est une manière d’implémenter plus concrètement les principes du DevOps. Ces deux notions répondent en tout cas aux mêmes enjeux. “D’un côté, on demande aux développeurs d’améliorer leur time-to-market ; de l’autre, les exploitants sécurisent la production (performance, scalabilité…). Notre objectif est de concevoir les outils pour permettre à l’exploitation de travailler plus sereinement. On automatise au maximum. Les exploitants ne sont plus submergés par le travail lorsque les serveurs se multiplient. Ils sont ainsi plus productifs, dans un environnement sécurisé”.

OUI.sncf est une entreprise mature sur les initiatives DevOps. La mise en place du Site Reliability Engineering est une démarche plus récente. Dans les faits, les ingénieurs sont là pour faciliter le déploiement de nouvelles briques techniques.

“Notre première mission est de travailler sur l’industrialisation de diverses solutions. Quand une équipe souhaite implémenter une nouvelle technologie, nous l’étudions, nous la validons, puis nous prenons en charge son industrialisation complète pour que les opérationnels puissent l’exploiter facilement. Les facteurs de résilience et de performance sont bien évidemment contrôlés avant que ces nouvelles briques soient mises en production.

Notre deuxième mission, c’est l’audit. Nous pouvons être amenés à remettre en question certains choix, en étudiant l’existant, et proposer d’autres solutions plus efficaces.

Notre troisième mission est d’identifier les besoins techniques. Nous développons nous-mêmes des outils, des composants pour mieux lier les applications (des middlewares). Quand un besoin est identifié et qu’aucune solution convenable n’existe sur le marché, nous développons les outils nécessaires.”

Le profil du Site Reliability Engineer

Guillaume précise que le système d’information s’appuie de plus en plus sur des systèmes distribués (du messaging avec Apache Kafka, du cache distribué avec Cassandra ou Redis…) et que les exploitants ne peuvent devenir des experts de toutes ces technologies. “Cependant, ils doivent être en mesure d’exploiter ces technologies, et les développeurs de l’équipe SRE sont là pour les y aider”.

Cet objectif de l’équipe SRE dessine le profil des ingénieurs et les compétences nécessaires pour exercer ce nouveau métier. “Les compétences de développement sont essentielles. Les Site Reliability Engineers sont le plus souvent des développeurs qui ont une appétence pour l’industrialisation, l’exploitation, la résilience, la performance des systèmes. Pour les entreprises, la difficulté réside dans la capacité à trouver des profils compétents sur le développement avec un intérêt prononcé pour les problématiques des exploitants.

Chez OUI.sncf, nous avons la volonté de développer des technologies liées à la containerisation et au cloud. Ce sont de nouveaux paradigmes, en rupture, qui justifient à eux seuls le développement d’une équipe SRE structurée et l’intérêt de notre travail au quotidien. Notre rôle est d’accompagner les équipes de développement et d’exploitation pour qu’ils appréhendent au mieux ces nouveaux sujets.”