Le SRE (Site Reliability Engineering) ou ingénierie de la fiabilité consiste à exploiter l'ingénierie logicielle pour automatiser les tâches d'exploitation IT et pour accélérer la livraison logicielle en minimisant les risques. Découvrez tout ce que vous devez savoir sur cette approche et ses meilleures pratiques.
En 2003, l'ingénieur Benjamin Treynor Sloss de Google se voit confier la responsabilité d'une équipe de sept ingénieurs. Leur mission ? Accroître la fiabilité des sites et services de la célèbre firme américaine.
Afin d'y parvenir, cet expert en codage décide d'appliquer les meilleures pratiques de développement et d'ingénierie logicielle à l'infrastructure et l'exploitation des services. C'est ainsi qu'est né le SRE, ou Site Reliability Engineering.
Qu'est-ce que le SRE (Site Reliability Engineering) ?
Le SRE (Site Reliability Engineering) ou ingénierie de la fiabilité des sites consiste à appliquer l'approche d'ingénierie logicielle aux opérations IT. Comme l'a écrit Ben Treynor Sloss lui-même : « le SRE est ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation ».
Les équipes SRE utilisent le logiciel en tant qu'outil pour gérer les systèmes, résoudre les problèmes, et pour automatiser les tâches d'exploitation. Les tâches traditionnellement accomplies manuellement par les équipes d'exploitation sont effectuées à l'aide de logiciels et d'outils d'automatisation. Tout l'intérêt du SRE est de créer des systèmes logiciels fiables et extensibles.
Il s'agit notamment d'automatiser la gestion des systèmes en production, la gestion des changements, la réponse aux incidents, et même la réponse d'urgence qui serait traditionnellement effectuée manuellement par les administrateurs système.
Cette méthode aide à gérer de larges systèmes par le biais du code, permettant aux administrateurs système de gérer des centaines de milliers de machines. Les équipes peuvent ainsi trouver l'équilibre entre la relaxe de nouvelles fonctionnalités et l'assurance d'une fiabilité pour les utilisateurs.
La standardisation et l'automatisation sont les deux principaux composants du modèle SRE. Les ingénieurs de fiabilité des sites cherchent à améliorer et automatiser les tâches d'exploitation. Le SRE est idéal pour les équipes cherchant à passer d'une approche traditionnelle de l'exploitation IT à une approche cloud-native.
En outre, le SRE supprime la friction naturelle entre les équipes de développement désirant relaxer continuellement du logiciel, et les équipes d'exploitation souhaitant éviter les pannes et autres problèmes d'exploitation. C'est pourquoi le SRE s'aligne étroitement avec les principes DevOps et peut jouer un rôle clé dans l'implémentation de cette méthodologie.
Les grands principes du SRE sont l'apprentissage à partir des échecs, la priorisation de la satisfaction client, l'automatisation, et la collaboration pour résoudre les problèmes de systèmes ayant mené à des erreurs.
Les pratiques du SRE
Le SRE repose avant tout sur un ensemble de pratiques. Il convient tout d'abord de surveiller les données pour détecter les incidents. Les outils de monitoring permettent d'agréger des informations sur les performances du système, et de recevoir des alertes en cas d'anomalie.
Des outils tels que les runbooks permettent de réagir aux incidents de manière efficace et planifiée, et de partager les informations disponibles entre tous les membres d'une équipe. Une autre pratique SRE consiste à créer des rétrospectives sur les incidents pour en tirer des leçons. À chaque échec, le processus doit être documenté.
Les SLI et SLO permettent de mesurer le véritable impact des incidents en se basant sur leur utilisation du service. Ceci permet de classer les réactions de la meilleure manière possible.
Enfin, le SRE implique de développer en se basant sur le budget d'erreur disponible. La vitesse de progression doit être modérée en fonction du risque d'enfreindre le SLO. Le budget d'erreur permet de prendre les meilleures décisions pour les clients.
Qu'est-ce qu'un budget d'erreur ?
Le budget d'erreur est un outil utilisé par l'équipe SRE pour réconcilier automatiquement la fiabilité de service d'une entreprise avec son rythme de développement logiciel. Il définit la marge de manœuvre de l'équipe de développement, par rapport aux contraintes d'exploitation.
Prenons l'exemple d'une entreprise dont le SLA garantit un temps de disponibilité de 99,99% par an. Cela signifie que le budget d'erreur mensuel est d'environ 4 minutes et 23 secondes. Il s'agit du temps total d'indisponibilité autorisé par mois sans conséquences contractuelles.
Si l'équipe de développement veut déployer de nouvelles fonctionnalités ou améliorations, elle doit s'assurer que le budget d'erreur restant est suffisant. Dans le cas contraire, il faut patienter jusqu'à ce que l'équipe d'exploitation réduise le nombre d'erreurs ou de pannes à un niveau acceptable.
Ainsi, le budget d'erreur aide les équipes de développement et d'exploitation à améliorer la stabilité et la performance des services, à prendre des décisions data-driven sur le déploiement de nouvelles fonctionnalités ou applications, et à maximiser l'innovation en prenant des risques dans les limites acceptables.
Quels sont les avantages du SRE ?
Le SRE apporte de nombreux avantages au sein d'une organisation. Il offre tout d'abord une vision plus claire des besoins de la clientèle, permettant ainsi d'accroître la fiabilité du service. Afin de comprendre le niveau de fiabilité attendu par les clients, on peut utiliser les SLI et SLO.
Les SLI ou indicateurs de niveau de service mesurent la performance de métriques clés comme la latence, la disponibilité, et autres points essentiels du parcours utilisateur. Les SLO ou objectifs de niveaux de service définissent la fiabilité à atteindre.
Les SLO doivent être plus stricts que les SLA ou accords de niveau de service, à savoir les garanties légales de fiabilité du service. En quelque sorte, les SLO servent de garde-fou pour les SLA. De leur côté, les budgets d'erreur indiquent jusqu'où il est possible d'atténuer la fiabilité sans enfreindre les SLO.
Autre avantage : le SRE aide à accroître la vélocité du développement. Avec un budget d'erreur suffisant, les ingénieurs peuvent prendre des risques et déployer des ressources pour le développement de nouvelles fonctionnalités.
Les équipes peuvent aussi travailler plus rapidement grâce aux boucles de feedback. Un principe clé du SRE est de mener une enquête rétrospective après chaque incident, en rédigeant des documents résumant les leçons tirées et les mesures à prendre pour le futur. Ceci permet de stimuler les développements futurs.
Par ailleurs, le SRE permet de réagir plus rapidement aux incidents et de récupérer plus rapidement. De nombreux outils et procédures permettent une réponse prompte aux incidents comme les outils de monitoring pour la détection, les systèmes d'alerte, les Runbooks pour guider la réponse et les solutions de collaboration.
Le SRE apporte aussi l'automatisation au sein d'une organisation. Ceci permet aux équipes de libérer du temps pour se concentrer sur les tâches essentielles plutôt que sur le travail répétitif. Un autre avantage est la standardisation par la création de documentations, de processus et de Runbooks pour les tâches les plus communes.
Pour l'onboarding de nouveaux employés, le SRE peut aussi s'avérer utile en rendant les informations accessibles à tous les membres de l'organisation. Les rétrospectives d'incidents et les Runbooks aident les nouveaux arrivants à s'adapter rapidement.
Enfin, le SRE instaure une culture d'apprentissage et de croissance au sein de l'organisation. Les pratiques encouragent un environnement psychologiquement sain où l'échec est célébré, et où les équipiers sont invités à mettre en lumière les problèmes. Les incidents sont traités sans accusations, et tout le monde coopère pour trouver la cause systémique.
SRE vs DevOps
On compare souvent le SRE et le DevOps, car l'objectif final est le même. Dans les deux cas, il s'agit d'aligner le développement et l'exploitation avec la satisfaction des clients.
Toutefois, les méthodes employées pour atteindre ce but diffèrent. Alors que le DevOps se focalise sur l'unification du développement et de l'exploitation pour créer de la valeur en entreprise, le SRE se concentre sur le processus par lequel ces buts sont atteints. Ainsi, ces deux méthodologies sont complémentaires.
Le SRE peut permettre d'atteindre les buts du DevOps. Il aide à réduire les silos d'informations par la création d'une documentation accessible, et permet d'accepter l'échec en priorisant les besoins de fiabilité du client.
Le concept d'implémentation progressive des changements est au cœur du DevOps et du SRE, au même titre que l'automatisation. En outre, le SRE encourage à se concentrer sur les métriques les plus profondes et pertinentes.
SRE et cloud
À cause de la migration depuis un environnement IT traditionnel et les data centers sur site vers un environnement cloud hybride, l'entreprise moyenne génère deux à trois fois plus de données d'exploitation chaque année.
Par conséquent, le SRE est perçu comme essentiel pour l'utilisation de ces données à des fins d'automatisation de l'administration système, de l'exploitation et de la réponse aux incidents. Cette approche est aussi incontournable pour accroître la fiabilité de l'entreprise bien que son environnement IL devienne plus complexe.
Une approche de développement cloud-native consiste à construire les applications en tant que microservices et à les déployer dans des conteneurs. Elle peut simplifier le développement, le déploiement et l'extension des applications.
Toutefois, cette méthodologie crée aussi un environnement distribué compliquant l'administration, l'exploitation et la gestion. Une équipe SRE peut soutenir ce rythme rapide d'innovation tout en assurant la fiabilité du système, sans pour autant ajouter de pression sur les équipes DevOps.
Quel est le rôle d'un Site Reliability Engineer ou ingénieur de fiabilité des sites ?
L'ingénieur de fiabilité des sites ou Site Reliability Engineer est un rôle nécessitant un bagage en administration système, en développement logiciel et en exploitation IT. Les équipes de SRE sont responsables de la manière dont le code est déployé, configuré et surveillé, mais aussi de la disponibilité, de la latence, de la gestion des changements, de la réponse aux incidents et de la gestion de capacité des services en production.
En se basant sur les accords de niveau de service, les équipes d'ingénieurs SRE définissent la fiabilité requise pour les systèmes selon les SLI et les SLO. Ils déterminent ainsi le lancement de nouvelles fonctionnalités.
L'équipe de développement peut ensuite dépenser le budget d'erreur pour déployer de nouvelles fonctionnalités. L'équipe SRE détermine si un produit ou service peut être lancé en fonction du SLO et du budget d'erreur disponible.
Si un service entre dans le cadre du budget d'erreur, l'équipe de développement peut le lancer n'importe quand. Toutefois, si le système rencontre trop d'erreurs ou est trop souvent indisponible, le budget d'erreur ne permet pas de nouveau lancement.
Les ingénieurs de la fiabilité des sites divisent leur temps entre les tâches d'exploitation et les travaux de développement comme la création de nouvelles fonctionnalités, l'extension du système ou l'implémentation d'automatisation.
Comment suivre une formation SRE ?
Afin de devenir ingénieur de fiabilités des sites, vous pouvez choisir les formations DevUniversity. Nos cursus à distance vous permettent d'apprendre les meilleures pratiques de SRE et DevOps, afin de devenir un véritable expert.
Toutes nos formations s'effectuent à distance via le web, en BootCamp ou en Formation Continue. Reconnu par l'État, notre organisme est éligible au Compte Personnel de Formation pour le financement. Découvrez DevUniversity dès maintenant !
Vous savez tout sur le Site Reliability Engineering ou SRE. Pour plus d'informations sur le même sujet, consultez notre dossier complet sur les certifications DevOps et notre dossier sur les meilleurs outils DevOps.
.jpg)
