Qu’est-ce que le SRE ? Quel est le lien avec DevOps ?

SRE signifie Site Reliability Engineering. Il s’appuie sur les principes de DevOps pour apporter une approche axée sur l’ingénierie aux opérations informatiques. SRE utilise un logiciel pour automatiser le fonctionnement du système, identifier les problèmes et mettre en œuvre des résolutions.

Le concept de SRE développé chez Google. Il est basé sur l’idée que le code et le logiciel sont le moyen le plus efficace de gérer des systèmes à grande échelle. Les procédures manuelles initiées par une équipe distincte comportent un risque d’oubli et d’incohérence.

Dans cet article, vous apprendrez ce qu’est SRE et comment il aide à rationaliser les opérations cloud. Nous expliquerons également où SRE chevauche DevOps, ainsi que les façons dont il diffère.

Où SRE s’intègre-t-il dans la livraison de logiciels ?

La SRE concerne la gestion des opérations. Il entre dans le processus de livraison du logiciel une fois que le code a été développé, révisé et déployé. Les ingénieurs en fiabilité du site observent, entretiennent et optimisent généralement ces services déployés, en prenant en charge les responsabilités des administrateurs.

La particularité du SRE par rapport aux opérations traditionnelles est l’accent mis sur l’automatisation. Les contrôles de l’infrastructure, la gestion des modifications, les audits et la réponse aux incidents doivent tous être automatisés dans le modèle. Le praticien SRE se concentre sur le provisionnement et l’exécution d’outils logiciels qui accomplissent ces tâches, au lieu d’interagir directement avec le système lui-même.

SRE unifie les aspects disparates de l’expérience de gestion des opérations. L’utilisation d’un processus piloté par des outils signifie qu’il y a moins d’endroits où les problèmes peuvent survenir. Cela permet d’augmenter la stabilité à mesure que les systèmes se développent, même si la taille de l’équipe SRE reste statique.

Que font réellement les ingénieurs SRE ?

Les ingénieurs SRE sont généralement des développeurs de logiciels qui ont également de l’expérience dans l’exploitation de services de production. Cela leur donne une connaissance globale du processus de livraison, de la validation du code à la résolution des incidents. Ils utiliseront ces connaissances pour concevoir et mettre en œuvre des mécanismes de déploiement et de surveillance des environnements en direct.

Comme la « fiabilité » est littéralement dans le nom, les équipes SRE sont également chargées de mesurer le temps de disponibilité et de trouver des moyens de l’améliorer. Les ingénieurs SRE définissent les objectifs de niveau de service (SLO) qui fournissent des cibles de fiabilité pour l’organisation. Ils établiront et observeront les indicateurs de niveau de service (SLI) qui indiquent si les objectifs sont atteints, tels que le taux d’erreur, le débit des demandes et le nombre de tickets. Les SRE seront impliqués dans la rédaction des accords de niveau de service (SLA) qui sont également partagés avec les clients.

Les ingénieurs SRE sont les gardiens efficaces des nouveaux déploiements. Leur souci de préserver la stabilité signifie qu’ils provoquent parfois des gels de déploiement si un SLO ou un SLA est sur le point d’être violé. L’équipe SRE peut demander aux développeurs de se concentrer sur la résolution de la cause des incidents, au lieu de continuer à déployer de nouveaux travaux.

Aucun service ne peut s’attendre à fonctionner avec une fiabilité à 100 %. SRE le reconnaît en accordant aux développeurs un « budget d’erreur » qu’ils sont autorisés à « dépenser ». Une fois que ce budget a été dépassé par de nouveaux bogues, tickets ou pannes, la résolution des problèmes devient la priorité de chacun jusqu’à ce que le budget d’erreur et les SLO soient restaurés.

Il peut s’agir d’un ingénieur SRE qui complète ce travail de correction en écrivant un nouveau code. Parce que l’équipe SRE a une formation en génie logiciel, elle est équipée pour traiter les problèmes de sa propre initiative. Lorsque le service fonctionne bien, les personnes occupant des rôles SRE redeviennent des développeurs réguliers. Les ingénieurs SRE de Google devraient consacrer au moins la moitié de leur temps à des travaux de développement.

Cet équilibre unique entre le développement et les opérations permet de préserver la capacité de l’ingénieur SRE à superviser le processus de livraison. Leur niveau de visibilité est inestimable lorsqu’il s’agit de repérer les risques qui pourraient provoquer un incident. Il encourage également les ingénieurs à minimiser le temps consacré aux tâches opérationnelles en mettant en œuvre de nouveaux outils et des procédures automatisées. Cela peut créer un cycle autonome : un degré d’automatisation plus élevé rend généralement le service plus fiable, réduisant ainsi la charge de travail de l’équipe SRE. À leur tour, les ingénieurs sont libérés pour reprendre le développement, augmentant ainsi le débit.

Comment SRE s’aligne-t-il sur DevOps ?

DevOps est un terme au sens large qui décrit l’utilisation de technologies et de méthodologies modernes pour fournir plus rapidement des logiciels de meilleure qualité. Ceci est réalisé en réduisant l’écart entre les équipes de développement et d’exploitation, puis en superposant l’automatisation au processus de livraison de logiciels.

Jusqu’à présent, cela ressemble à SRE. Cependant, SRE a un seul objectif en tête – la fiabilité – tandis que DevOps prend également en compte des préoccupations tangentielles, telles que l’efficacité des développeurs et la rapidité de livraison. Il convient de noter que DevOps est souvent abordé comme un pont entre le développement et les opérations, tandis que SRE les fusionne. Dans SRE, les tâches de développement et d’exploitation sont effectuées par les mêmes personnes, le développement attirant l’attention.

Pour ces raisons, SRE peut être considéré comme une implémentation spécifique de DevOps. Bien que les objectifs globaux soient similaires et fortement alignés, SRE décrit une méthode pour les atteindre : utiliser les budgets d’erreur, les SLO et les SLI pour protéger les services contre les erreurs, puis mettre en œuvre des protections qui permettent au biais de travail de revenir vers le développement.

Benjamin Treynor Sloss, l’ingénieur de Google qui a inventé le terme SRE, déclare que SRE peut être considéré comme « une implémentation spécifique de DevOps avec quelques extensions idiosyncratiques ». Alternativement, vous pouvez inverser le modèle et approcher DevOps « comme une généralisation de plusieurs principes SRE fondamentaux à un plus large éventail d’organisations, de structures de gestion et de personnel ».

L’une des principales différences entre SRE et DevOps est sa dépendance aux données. DevOps est souvent considéré comme un ensemble de principes permettant de déplacer efficacement le code des postes de travail des développeurs vers les environnements de production. Cela signifie travailler en termes de commits, de demandes de fusion, de pipelines et de conteneurs. SRE est une stratégie de déploiement de modifications avec une fiabilité maximale et un risque de régression réduit. Une SRE efficace nécessite une observation et une analyse continues pour déterminer où les erreurs se sont produites et comment elles pourraient se répéter à l’avenir. C’est plus investigatif et conscient de soi qu’une implémentation DevOps typique.

Le SRE est-il un bon choix de carrière ?

SRE n’a que récemment commencé à attirer l’attention du grand public. Il peut être difficile de trouver un rôle SRE car de nombreuses organisations n’ont pas encore reconnu les avantages du modèle. Dans certains cas, une forme de SRE peut être présente au sein d’une organisation, mais cela peut ne pas se refléter dans les rôles annoncés.

Malgré sa nature spécialisée, SRE est généralement un bon choix de carrière. Cela exige une intersection de compétences, allant du développement de logiciels à l’exploitation des services et à la réponse aux incidents, avec un bon degré de profondeur dans chacun. Il y a peu de candidats qui peuvent offrir cela, ce qui signifie que les rôles SRE ont tendance à être des postes lucratifs.

Une analyse de GitLab en avril 2022 n’a trouvé que 21 000 ouvertures SRE alors qu’il y avait 104 000 postes DevOps. Les données de Glassdoor indiquaient cependant une fourchette de salaires allant jusqu’à 300 000 $ pour le travail SRE, contre 234 000 $ pour DevOps.

Entrer dans un rôle SRE pourrait être une opportunité enrichissante pour les personnes qui souhaitent rester dans le domaine du développement tout en acquérant une expérience pratique de l’exploitation des services. Il est particulièrement adapté aux personnes qui trouvent les rôles d’administrateur traditionnels trop répétitifs et pratiques. En tant que SRE, vous devrez automatiser les opérations, rechercher des opportunités pour améliorer la qualité du service et contribuer aux efforts de développement réguliers une fois que le téléavertisseur d’incident est devenu silencieux.

Conclusion

L’ingénierie de la fiabilité du site utilise des méthodes couramment associées au développement de logiciels pour automatiser les opérations de service. Les ingénieurs SRE sont des développeurs expérimentés qui connaissent également les défis de l’exécution et de la mise à l’échelle des services en production. Ils établissent une chaîne d’outils de mesure et d’optimisation de la fiabilité, prenant en charge les tâches autrefois gérées par des administrateurs système dédiés.

SRE peut être considéré comme une mise en œuvre des principes DevOps. La nomination d’ingénieurs SRE devrait se traduire par un service plus résilient et capable d’accepter des changements rapides. Cela permet d’atteindre l’objectif DevOps d’accélérer le déploiement de logiciels sans affecter la qualité. SRE définit une stratégie spécifique qui va dans ce sens en mettant l’accent sur la mesure des données, ainsi que sur l’unification des talents de développement et d’exploitation.

Alors que DevOps est désormais largement compris dans la communauté, SRE reste un domaine d’intérêt émergent pour de nombreuses organisations. Les ouvertures peuvent être plus difficiles à trouver, mais elles ont tendance à être plus lucratives lorsqu’elles apparaissent. Cela reflète l’ensemble varié de compétences que les ingénieurs SRE doivent posséder. La demande est susceptible de croître rapidement au cours des deux prochaines années, il est donc temps pour les candidats et les organisations de commencer à prêter attention à la transition vers la SRE.