L’avantage du Site Reliability Engineering (SRE) dans l’exploitation informatique moderne

Selon une étude actuelle de LinkedIn, les Site Reliability Engineers font partie des rôles les plus recherchés sur le marché du travail suisse. Aux États-Unis, il s’agit même du poste bénéficiant de la plus haute rémunération dans le domaine de l’IT, selon une autre étude.

Parmi les postes vacants les plus courants en Suisse en 2023, on trouve sept professions dans le domaine informatique. Les Site Reliability Engineers occupent la 2^e place du classement. Source : LinkedIn Job Trends

Dans cet article de blog, vous découvrirez pourquoi les Site Reliability Engineers sont particulièrement demandés, quelles sont leurs tâches et quelles sont leurs compétences clés.

Mais avant tout : le Site Reliability Engineering, initialement introduit par Google, n’est pas un modèle de réussite unique qu’une entreprise doit absolument s’imposer, mais doit avant tout servir d’inspiration. Adopt and adapt !

Site Reliability Engineering (SRE) : qu’est-ce que c’est ?

Le Site Reliability Engineering applique une approche d’ingénierie logicielle à l’exploitation informatique. Ou comme Ben Treynor de Google l’a très bien formulé : « SRE is what happens when a software engineer is tasked with what used to be called operations ».

L’objectif du Site Reliability Engineering est de créer des systèmes très fiables et évolutifs. Ainsi, l’accent est mis davantage sur la conception et la construction de ces systèmes que sur des aspects réactifs tels que la maintenance et la gestion des incidents. Des méthodes de génie logiciel sont utilisées afin d’automatiser de manière cohérente des tâches qui étaient auparavant effectuées manuellement.

Le SRE aide également à atteindre un bon équilibre entre stabilité et flexibilité. Ici, les Service Level Objectives (exemple : 99,9% de disponibilité) et l’Error Budget qui en découle (exemple : 42 heures d’indisponibilité autorisées par mois) jouent un rôle essentiel. Si l’Error Budget est dépassé, alors l’Error Policy s’applique (exemple : « arrêt du développement des nouvelles fonctionnalités »). Le non-respect des Error Budget doit avoir des conséquences, et ce, également pour les équipes de produits.

Pourquoi le Site Reliability Engineering a-t-il actuellement le vent en poupe ?

L’importance croissante des services numériques et la nécessité de concevoir des systèmes fiables et évolutifs ont certainement contribué à cette popularité. Les entreprises qui dépendent d’une haute disponibilité de leurs services ont adopté des pratiques de SRE et Google a fait office de pionnier en la matière.

Bien entendu, la fiabilité a toujours été un thème central. Mais les approches opératives traditionnelles ne sont plus adaptées aux nouvelles contraintes techniques. On peut citer notamment :

• Les systèmes complexes distribués – p. ex. le passage des monolithes aux microservices – avec des utilisateurs imprévisibles (vs le mythe de la surveillance « tout est prévisible ») : les systèmes doivent pouvoir évoluer rapidement et automatiquement sans pour autant entraîner une évolution rapide des problèmes et des coûts ou que le TCO (Total Cost of Ownership) devienne incalculable.

Le DevOps nous a certes aidés à surmonter le fossé entre le développement et l’exploitation – entre autres grâce au partage de la responsabilité des résultats. Mais souvent, même dans un environnement DevOps, il manque un moyen pratique d’ancrer la fiabilité dans les systèmes. D’où la déclaration de Google : « SRE implements class DevOps ». Vu sous cet angle, le SRE a aussi quelque chose de très concret.

Que fait un SRE et quelles sont les compétences nécessaires ?

Les actions du SRE sont avant tout caractérisées par une mentalité très spécifique que l’on retrouve souvent parmi les développeuses et développeurs de logiciels. Dans le travail quotidien, cela s’exprime par un désir intrinsèque d’automatisation des activités répétitives et manuelles.

« Dès que je dois faire quelque chose manuellement deux fois, je l’automatise. Ou mieux encore, je l’automatise après l’avoir fait une seule fois. »

(Un développeur logiciel inconnu que le travail répétitif ennuie très vite)

Les Site Reliability Engineers sont ainsi plutôt uniques parce qu’ils ont besoin de compétences transversales. Leur background peut être celui d’administrateur système avec un intérêt ou des compétences en développement de logiciels ou au contraire celui de développeur logiciel avec un solide savoir-faire en opérations informatiques.

Beaucoup des activités quotidiennes du SRE tournent autour de l’automatisation :

• Mise en place de surveillance automatisée dans un environnement distribué afin de garder un œil sur des indicateurs clés comme la disponibilité ou la latence
• Mise en œuvre de scripts, p. ex. pour automatiser la réponse aux incidents
• Support des équipes travaillant sur une plateforme autour des thèmes de la fiabilité et de l’évolutivité
• Support des équipes de produits et des ingénieurs de versions afin de rendre les pipelines de développement plus robustes

Et toute personne qui a déjà travaillé dans l’exploitation informatique sait que cela implique également de résoudre des problèmes qui peuvent survenir à tout moment. C’est aussi le cas pour le SRE, mais ce qui est déterminant, c’est que ce type de travail n’est pas prédominant. Cela peut être mis en œuvre par des règles simples, comme c’est le cas chez Google, par exemple :

• Un plafond de 50% de « Ops Work » est appliqué (résoudre des problèmes, être sur appel, etc.)
• Un minimum de 50% doit être du travail d’ingénierie (p. ex. automatisation, développement de logiciels)

Finalement, une des missions principales est aussi de briser le cercle vicieux, de sortir du mode « urgence » et de mettre en place des systèmes dans lesquels les problèmes ne surviennent pas. D’un point de vue économique, nous ne pouvons plus nous permettre de nous entêter à appliquer un mode basé sur la réaction dans un environnement massivement évolutif et de tout faire manuellement. L’automatisation et la standardisation sont les clés et le Site Reliability Engineer y contribue de manière décisive.