SRE et DevOps : définitions, différences et avantages

‍Le Site Reliability Engineering (SRE) a vu le jour dans les bureaux de Google quelques années avant le DevOps, à l’aube du nouveau millénaire. Ces deux concepts ont pour dénominateur commun le lancement optimal de nouveaux produits au sein d’une infrastructure fiable. Alors qu’est-ce que le SRE ? Est-ce la même chose que le DevOps ? 

Qu’est-ce que cela apporte à une entreprise ? Quel est le quotidien d’un.e ingénieur.e de la fiabilité du site ? 

SRE et DevOps parlent-ils la même langue ?

Oui et non ! On va dire que si le SRE et le DevOps étaient des personnes, le SRE serait québécois et le DevOps, français : une langue commune avec toutefois des expressions qui diffèrent. 

Dans les faits, les ingénieur.es SRE travaillent à la fois pour les équipes de développement et des opérations, mais pas uniquement dans le cadre du DevOps, d’où cette comparaison avec les langues. Mais pas de panique, on vous dit tout !

SRE (Site Reliability Engineering ou ingénierie de la fiabilité du site) : définition et objectifs

L’ingénierie de la fiabilité des sites va s’inspirer des grands principes du génie logiciel (c’est-à-dire les meilleures méthodes de développement logiciel) pour les appliquer aux problèmes d’infrastructure et d’exploitation d’un système informatique. Et par système informatique (SI), on entend l’ensemble des éléments matériels, virtuels et…humains inhérents à l’informatique et à ses composantes.

L’objectif du SRE consiste à créer des logiciels ultra-évolutifs et fiables pour justement remédier aux problèmes rencontrés par les infrastructures et les équipes. Par exemple, pour les utilisateurs d’une application, cela signifie une expérience fluide et agréable, avec le moins de bugs possible.

La mission des ingénieurs SRE consiste ainsi à aider les équipes de développeurs, la DSI et les équipes opérationnelles à mieux collaborer. L’objectif étant qu’ils puissent assurer ensemble, disponibilité, fiabilité et robustesse des SI et des services en ligne avec deux armes de prédilection : l'amélioration continue et l’automatisation.‍‍

Et le DevOps dans tout ça ?

Au fil du temps et des nouvelles prouesses technologiques, les applications d’entreprise se sont complexifiées. Les tâches de développement (build) et celles en charge de l’exécution de l’application (run) ont été progressivement attribuées à différents services IT. Développeurs (Dev) et administrateurs système (Ops) travaillaient alors chacun de leur côté et la communication s’est raréfiée. 

Le mouvement DevOps est né de la volonté de rétablir la communication entre les services en misant sur l'optimisation des moyens (humains et techniques) afin d’améliorer constamment le cycle de vie des applications. 

Pour résumer, SRE et DevOps ont un objectif commun : garantir le lancement des produits avec tout ce que cela comporte de fiabilité, disponibilité et de performance, tout en veillant à ce que l'opérationnel et les développeurs aient une même visibilité des choses.

En revanche, ces deux disciplines ne vont pas tout à fait se poser les mêmes questions. Alors que les équipes DevOps vont se demander quels sont les objectifs à atteindre, les ingénieur.es SRE vont tâcher de comprendre comment atteindre lesdits objectifs. 

Une certaine complémentarité caractérise ainsi SRE et DevOps et à bien des égards, ils ont en commun certaines missions et responsabilités.

Quelles sont les missions d’une équipe SRE ?

Casser les silos

Les conséquences des silos organisationnels sont nombreuses : manque de communication, innovations technologiques qui peinent à s’insérer, désaccords, etc. La première mission de l'ingénieur.e SRE va être d’inviter les équipes de développement, d’administration et les DSI à engager une discussion commune autour de leurs process et de leurs outils.

Tirer avantage des erreurs, bugs et autres interruptions

Des  infrastructures 100% fiables n'existent pas dans le monde informatique. C’est d’ailleurs pour cette raison qu’un budget alloué à l’erreur est systématiquement prévu dans les contrats de niveau de service (SLO, SLI). Les ingénieur.es SRE définissent et mesurent ainsi un niveau de service attendu d’un système. Par exemple, on peut prévoir qu’une application soit disponible à 98% et les 2% restant serviront à corriger les erreurs et surtout, à en tirer les leçons.

Mettre l’automatisation au service des équipes IT

Le SRE va être en mesure de développer des outils qui vont faciliter le quotidien des équipes de développement et celles en charge des opérations. L’objectif étant d’éliminer un maximum de tâches manuelles et chronophages.

Surveiller, alerter, corriger

Voilà qui ferait un beau mantra pour les équipes SRE. En effet, ils/elles vont déployer pléthore de technologies de surveillance et de gestion des incidents pour détecter et résoudre rapidement les problèmes d’une infrastructure. 

Avoir un.e ingénieur.e SRE dans une équipe IT comporte de nombreux avantages…

• Il/elle maîtrise plusieurs disciplines 

Il/elle a le profil opérationnel d’un.e administrateur.trice système tout en ayant de solides connaissances en développement, car oui, il/elle code ses propres outils ! Il peut donc comprendre le langage des devs et des ops et les aider à communiquer.

• Il/elle améliore la qualité de service

Une utilisation fluide des services et des applications, une réduction des temps d'arrêt : sans aucun doute, l’ingénieur.e SRE contribue à l'amélioration de l’expérience utilisateur.

• Il/elle rééquilibre la charge de travail et la productivité des équipes

S’il/elle est trop accaparé.e par l’opérationnel, c’est que les performances d’une application ou d’un service sont insuffisantes. Il/elle confie alors aux équipes de développement le soin de corriger le tir.

• Il/elle est l’instigateur du changement

Dans une démarche constante d’amélioration continue, il/elle insuffle de nouvelles méthodes de travail et sait s’adapter à l’évolution rapide du monde de l’IT.