Par Gologic en collaboration avec Alexandre Couëdelo.
Site Reliability Engineer (SRE) est un poste qui gagne beaucoup de traction sur le marché, pourtant, le concept soulève toujours de nombreuses questions. Quelle est la responsabilité d’un SRE ? Votre organisation doit-elle adopter le modèle SRE ? Quel est le lien entre SRE et DevOps ?
Cet article a pour objectif d’éclaircir ce concept, pas si nouveau, et vous permettra de comprendre à quel point il est important pour réussir à livrer des logiciels fiables fréquemment et d’assurer la meilleure expérience utilisateur possible sans épuiser vos équipes.
Définition SRE
Le modèle SRE a été créé chez Google en 2003, lorsque Ben Treynor Sloss a rejoint la société de la Silicon Valley et a mis en place la première équipe SRE. Mais qu’est-ce qu’un SRE exactement ? Le SRE est une approche d’ingénierie logicielle qui utilise des logiciels pour gérer des systèmes, résoudre des problèmes et automatiser des tâches liées aux opérations. Le SRE est une méthode efficace pour développer des systèmes logiciels évolutifs et hautement fiables.
Quel est le rôle d’un ingénieur en fiabilité de
site dans une entreprise ou une équipe ?
La seule et unique responsabilité « officielle » d’un SRE est de s’assurer de la fiabilité des systèmes, c’est-à-dire que l’entreprise atteint ses objectifs ; objectifs traduits en SLA (Service Level Agreement). Les SLA sont des objectifs contractuels établis entre le client et le fournisseur permettant de formaliser des SLO comme objectifs d’affaires et qui entraînent des pénalités s’ils ne sont pas respectés.
Les SLO (Service Level Objectif) sont une mesure interne de la performance des systèmes. Un exemple de SLO serait « 95 % des utilisateurs peuvent se connecter en moins de 100 ms » ou « 99,9 % des requêtes HTTP aboutissent sans erreurs ». Et, pour savoir si les SLO sont atteints, les SLI sont mis en place pour se mesurer. Un exemple de SLI serait « Le temps de réponse de la fonctionnalité en ms ».
Les SLO sont un outil extrêmement efficace qui évite l’épuisement lié aux alertes et permettent aux équipes de se concentrer sur ce qui compte pour apporter de la valeur à l’utilisateur final. Créer des SLO, c’est adopter une approche basée sur le « budget d’erreur », ce qui signifie que tant que vous n’avez pas consommé votre budget, vous ne devez pas vous laisser interrompre par une dégradation des métriques.
Tant que les SLO sont respectés (pas d’alerte en cours), un SRE se concentrera sur la mise en œuvre concrète du DevOps, cela signifie s’assurer que tous les bons outils sont en place pour créer un cycle de livraison DevOps. Cela inclut également de collaborer avec les équipes d’opérations pour s’assurer que l’infrastructure et la sécurité sont en place. Les équipes SRE seront spécialisées dans un premier temps sur les outillages et les bonnes pratiques CI/CD. Le grand défi pour les nouveaux SRE sera la jungle d’outils du marché et de sélectionner ceux dont l’entreprise a « vraiment » besoin.
Quel est le quotidien d’un SRE ?
En conséquence, un SRE consacrera généralement 50 % de son temps au support de l’outillage et ainsi améliorera les processus en codant des pipelines et/ou des scripts d’automatisation. Il donnera également du coaching et rédigera de la documentation pour aider les développeurs à atteindre le niveau de qualité requis pour déployer en production.
Regardez la vidéo de Kevork Sayad, SRE chez Gologic, pour en apprendre davantage sur les bonnes pratiques SRE à mettre en place.
La surveillance et l’exploitation du système en production représenteront l’autre 50 % de sont emploi du temps. Le SRE est le gardien de la production, par conséquent il a la responsabilité de définir les exigences de déploiement. Il doit évaluer le risque d’un déploiement et peut s’opposer à tout déploiement s’il juge le risque trop important. Regarder
Pour que la collaboration avec les équipes de développement se déroule sans accroc, il est essentiel que le SRE participe aux premières étapes du développement du produit afin d’identifier les dangers potentiels dès le début. Il s’agit essentiellement de prendre le temps d’expliquer aux gens d’affaires, les règles du jeu en les incluant dans la définition du SLO et la mise en place de la surveillance du logiciel une fois en production.
SRE vs DevOps : quelle est la différence ?
Où se trouve le SRE dans l’organisation ? La meilleure illustration se trouve dans le livre DevOps Topology de Matthew Skelton et Manuel Pais. Si vous ne possédez pas encore le livre, ne vous inquiétez pas, leur site web contient un résumé de toutes les topologies DevOps. Oui ! Il existe plusieurs manières de travailler en mode DevOps et SRE est l’une d’elles.
Dans le modèle SRE, les développeurs (Dev) et les opérations (Ops) sont séparés, cependant, le développeur balance plus de logiciels aux Ops. En fait, ni les Dev ni les Ops ne sont responsables de l’exécution du logiciel en production.
Dans ce modèle, vous disposez d’une ou plusieurs équipes SRE dédiées, facilitant ainsi la collaboration entre les équipes Dev et Ops. L’objectif principal des SRE est la fiabilité (reliability en anglais). Par conséquent, ils définissent les règles et l’automatisation nécessaire pour déployer et opérer des logiciels en production.
L’équipe SRE rassemble généralement des personnes d’horizons différents telles que des administrateurs système, des administrateurs DevOps et des développeurs. Les Ops se concentrent sur le fait d’automatiser et de maintenir l’infrastructure qui répondra aux besoins de l’organisation. La contribution des Ops, dans la plupart des cas, se résume à la création et la maintenance d’un PaaS (Platform as a Service) que les développeurs utiliseront pour la livraison logiciel. L’idée centrale dans cette philosophie est que l’infrastructure doit être considérée comme un service.
SRE & DevOps, des modèles récents ?
Tel que mentionné précédémment, le modèle SRE a été inventé chez Google, lorsque Ben Treynor Sloss a rejoint l’organisation en 2003, où il a fondé la première équipe SRE. Comme référence, le terme DevOps a été officiellement inventé en 2008, ce qui a conduit à la première conférence DevOpsDays en Belgique en 2009. Comme vous pouvez le voir, le modèle SRE a été inventé et mis en place 5 ans avant même que nous commencions à parler de DevOps. Ainsi, DevOps et SRE diffèrent à bien des égards, Par exemple, le SRE ne préconise pas le fameux « You build it, You run it ». Cependant, le SRE implémente une partie de la philosophie DevOps et résout même des problèmes importants dans le modèle DevOps de base, comme nous le verrons dans la prochaine partie.
« If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes, and is somewhat closer to a concrete definition of a job or role than, say, “DevOps engineer.” So, in a way, class SRE implements interface DevOps. »
The Site Reliability Workbook: Practical Ways to Implement SRE
Pourquoi avez-vous besoin d’ingénieurs
SRE ?
Quel(s) problème(s) SRE résout-il dans les modèles DevOp ? Les modèles les plus simples — Type 1 et Type 2 — ont leurs limites lorsqu’il s’agit de grandes entreprises. Une véritable collaboration Dev/Ops est difficile quand de plus en plus de produits sont en production et requièrent une infrastructure complexe pour les supporter.
Nous avons vu le même problème surgir avec Agile/SCRUM, où la méthode fonctionne très bien avec quelques équipes, mais une fois que vous avez une douzaine d’équipes SCRUM avec malgré elles des interdépendances, garder tous les backlogs alignés avec les besoins de l’organisation devient un enfer. L’une des solutions pour les grandes entreprises a été d’adopter SAFe (Scaled Agile Framework).
Le SRE résout un problème de croissance pour le modèle DevOps. Lorsque vous avez de nombreuses équipes travaillant en mode Agile/DevOps appliquant « You build it, You run it », les produits sont de plus en plus interconnectés. Imaginez le produit de l’équipe A est consommé par les microservices de l’équipe B basés sur les APIs d’autres équipes C et D. Vous obtenez des couches complexes de microservices fournissant une application à vos clients.
Mais qu’est-ce qui empêche le château de cartes de s’effondrer ? Comment assurer la fiabilité de votre système malgré sa complexité ? Comment s’assurer que toutes les équipes et tous les microservices servent au mieux les intérêts de l’utilisateur final ? Toutes les équipes suivent-elles le même standard de qualité ? Une équipe avec un niveau de qualité élevé pourrait-elle être affectée par une équipe aux attentes plus faibles ?
Vous devriez voir où nous essayons d’en venir. Pour que l’approche DevOps évolue et garantisse le meilleur niveau de service pour l’utilisateur final, vous avez besoin de personnes pour coordonner toute cette complexité et assurer que la qualité du processus de livraison logiciel est uniforme. C’est le rôle du SRE.
Conclusion
SRE est un modèle de gestion de parc applicatif (software management — SM) qui a été créé par Google quelques années avant la création du DevOps. SRE a rapidement gagné de la popularité dans les moyennes et grandes entreprises, car il met en œuvre certains des principes du DevOps et résout un problème de croissance dans les modèles DevOps les plus simplistes.
La principale responsabilité d’un SRE est de s’assurer que le système fournit toujours la même qualité de service à l’utilisateur final. Les meilleures armes de SRE sont appelées SLO (Service Level Objectives), qui sont des indicateurs statistiques mis en place pour mesurer la fiabilité du logiciel et indiquer quand intervenir pour résoudre les problèmes.
Le SRE prend également part aux affaires en informant les différentes parties impliquées sur la performance de leur produit. C’est ici que réside la principale différence avec un administrateur système. Le SRE joue un rôle plus à l’avant-scène, traduisant directement les données techniques en données affaires !
Pour conclure, les SRE sont responsables de l’environnement de production. Ils doivent définir les exigences de qualité pour les équipes de développement afin d’éviter les déploiements à risque. Cela se traduit concrètement par la création de pipelines automatisés et de la maintenance des nombreux outils qui composent la chaîne de livraison logicielle.
Est-ce que le rôle de SRE t’intéresse ? Go, rejoins-nous ! Nous avons un rôle sur mesure pour toi.
Par Gologic en collaboration avec Alexandre Couëdelo.
