Qu’est-ce que la SRE ? D’où vient cette nouvelle discipline ? Comment sont composées les équipes SRE ? Toutes les réponses à vos questions sur l’ingénierie de la fiabilité des sites sont dans notre article.

Définition SRE

Site Reliability Engineering (SRE) ou l’ingénierie de la fiabilité des sites, en français, est une discipline qui envisage que les activités historiquement réalisées manuellement par les équipes d’exploitation soient gérées par des ingénieurs informatiques ou des professionnels, capables de développer des logiciels, d’utiliser l’automatisation pour gérer les systèmes de production et de résoudre les incidents.

Comment est née la méthode SRE

Le concept de Site Reliability Engineering a été introduit en 2003 par Ben Treynor Sloss, un professionnel qui dirigeait à l’époque l’équipe d’ingénierie informatique de Google et qui occupe actuellement le poste de VP Engineering chez Google. Le Site Reliability Engineering a depuis évolué, devenant aujourd’hui un vaste recueil de connaissances que Sloss définit comme « ce que vous obtenez lorsque vous traitez les opérations comme un problème logiciel et que vous engagez des ingénieurs logiciels pour travailler dessus». Il peut sembler contre-intuitif de prétendre que vous devez « traiter un logiciel comme s’il s’agissait d’un logiciel », mais l’opportunité s’est présentée à mesure que l’infrastructure évoluait et que les besoins de production augmentaient, des quelques serveurs gérés manuellement il y a quelques décennies, aux énormes ressources de calcul mises à disposition par les centres de données du soit-disant « Cloud ».

L’introduction de cette méthode a permis à l’équipe de Sloss de s’assurer que les fonctionnalités publiées étaient toujours fiables.

Dans une interview pour Google, Sloss parle de l’ingénierie de la fiabilité des sites en ces termes :

La SRE effectue un travail qui a toujours été effectué par les équipes d’infrastructure et d’exploitation, mais en utilisant des aspects de l’ingénierie logicielle et des ingénieurs expérimentés et intrinsèquement prédisposés, qui ont la capacité de remplacer l’automatisation par le travail humain. En règle générale, une équipe SRE est responsable de la disponibilité, de la latence, des performances, de l’efficacité, de la gestion des changements, de la surveillance, des interventions d’urgence et de la planification des capacités.

L’équipe SRE

Une équipe SRE est généralement constituée d’ingénieurs ayant une expertise dans deux domaines :

• L’ingénierie, développement logiciel dans le cadre de systèmes complexes et/ou distribués;
• Les domaines disciplinaires généralement réservés aux opérations informatiques, par exemple le triage des incidents et leur résolution, fonctionnent dans des situations de grande pression, parfois en cas d’urgence.

Dans le cycle de vie du logiciel, c’est-à-dire la chaîne de procédures qui mène de l’idée d’une fonctionnalité à sa mise en œuvre, il y a deux activités fondamentales réalisées par l’équipe :

• Le développement de logiciel (dev); dans lequel la création, le codage et les tests du logiciel ont lieu dans des environnements dits de non-production, où il n’y a pas de vrais utilisateurs – par exemple l’ordinateur portable du développeur, les ressources informatiques réservées à une équipe interne, le contrôle qualité, …
• Les opérations (ops) ; où le logiciel produit par le développeur est envoyé en production. A partir de ce moment, les utilisateurs peuvent le toucher physiquement, et ce logiciel peut produire des données et avoir un impact dans le monde réel. Les “ops” durent aussi longtemps que l’organisation a intérêt à maintenir ce service logiciel en vie.

Les membres de l’équipe ayant des compétences en ingénierie et développement logiciel ont pour objectif principal de se concentrer sur la conception et la construction de systèmes logiciels, mais ils doivent également atteindre un niveau de compétence adéquat concernant l’ensemble du cycle de vie des objets logiciels, qui est essentiellement le domaine exclusif de Opérations informatiques.

Standardisation et automatisation

La standardisation et l’automatisation sont deux composants essentiels du modèle SRE : les ingénieurs informatiques et les équipes opérationnelles travaillent à automatiser les processus, en particulier lorsqu’il s’agit de travaux manuels et répétitifs pouvant entraîner des erreurs humaines.

En appliquant la standardisation et l’automatisation, les équipes SRE sont en mesure d’optimiser la fiabilité d’un système en l’améliorant. La culture Site Reliability Engineering (SRE) peut aider les équipes à passer des approches traditionnelles aux approches natives du cloud.

Fiabilité du système

Le mot “Reliability” correspond à la fiabilité du site dans la langue française. En effet, un des objectifs d’une équipe SRE est aussi de trouver des pistes pour améliorer la conception et la gestion des systèmes d’information afin de les rendre plus « fiables ».

La définition donnée par Microsoft du Site Reliability Engineering est plutôt la suivante :

“La SRE est une discipline d’ingénierie informatique dédiée à aider les organisations à obtenir les niveaux de fiabilité appropriés de manière durable pour les systèmes, services et produits.”

Créer une application est d’abord un coût pour une organisation car elle emploie plusieurs professionnels et demande du temps et du travail. Si cela ne fonctionne pas pour l’organisation, c’est un gaspillage à la fois d’argent et de crédibilité.

Il faut également tenir compte du fait que peu de systèmes ont réellement besoin d’offrir une fiabilité proche de 100 % et il y a aussi peu de situations dans lesquelles il est vraiment possible et utile d’obtenir une disponibilité proche de cet objectif. On parle donc de fiabilité « appropriée » : les ressources et le travail mis en œuvre pour développer une application augmentent au fur et à mesure que le degré de fiabilité souhaité augmente. La recherche d’une fiabilité inutile peut entraîner une énorme perte de temps et d’argent, il est donc essentiel d’identifier le niveau de fiabilité approprié qui doit être recherché pour une application.

SRE, DevOps et ITIL 4

Nous avons déjà exploré la comparaison entre les trois frameworks dans notre article SRE, ITIL et DevOps : différences et similitudes, mais il faut souligner que ces trois méthodes représentent des manières différentes de résoudre le même problème et SRE ne représente pas une « étape évolutive » par rapport à DevOps ou ITIL, mais seulement une méthode différente pour relever les défis. Google lui-même définit la « culture » SRE comme une spécialité particulière de DevOps.