Adoption de la pratique SRE

L'ingénierie de la fiabilité des sites (SRE) n'est ni un nouveau terme ni une nouvelle pratique. L'application des compétences de l'IT aux tâches et problèmes opérationnels existait bien avant le poste « d'ingénieur SRE ». Toutefois, l'organisation d'une approche proactive au développement et à la maintenance des logiciels renforce la réussite à long terme en améliorant l'efficacité opérationnelle, la planification de la feuille de route datadriven et la disponibilité et la fiabilité globales. Tous ces avantages expliquent l'adoption généralisée des SRE. 

Dans cet article, nous allons explorer ce qui est nécessaire pour mettre en place et adopter l'ingénierie SRE dans votre propre organisation, et découvrir certains des principes et bonnes pratiques clés que vous devrez garder à l'esprit en avançant dans votre parcours vers la maturité SRE.

Qu'est-ce que l'ingénierie SRE ?

L'ingénierie de la fiabilité des sites, ou SRE, est la pratique d'application de l'expertise IT aux problèmes opérationnels et DevOps. Cela signifie souvent l'écriture de code et le développement d'applications ou de services internes de manière proactive afin de combattre les soucis de fiabilité et de performances. L'ingénierie SRE est une pratique de longue date, mais elle a été récemment popularisée par Google lors de la première publication en mars 2016 du manuel Site Reliability Engineering: How Google Runs Production Systems (Ingénierie de la fiabilité des sites : comment Google exécute les systèmes de production).

SRE est un acronyme anglais couramment utilisé en français qui fait à la fois référence à un emploi, ingénieur en fiabilité des sites et à une pratique générale adoptée par les équipes de développement et IT, les équipes d'ingénierie de la fiabilité des sites. 

Les équipes SRE sont souvent organisées différemment selon l'entreprise et les services qu'elles prennent en charge. Il arrive parfois que les ingénieurs SRE soient répandus entre les équipes de développement. Ainsi, ils peuvent exprimer leurs préoccupations au cours de la planification de la feuille de route et collaborer étroitement avec les équipes d'assurance qualité, des nouvelles fonctionnalités jusqu'à la simulation, en passant par la gestion des environnements production. 

Une autre approche consiste à organiser une équipe SRE en tant que groupe autonome. L'équipe SRE dans son ensemble se concentre sur les responsabilités qui incluent notamment le monitoring des applications et de l'infrastructure, l'établissement des métriques de fiabilité et le suivi des problèmes avec les nouvelles versions et la gestion des tâches d'astreinte. Quelle que soit la manière dont elles sont organisées, le point commun de ces SRE est la fiabilité et les performances.  

DevOps et SRE

Avec l'adoption rapide des pratiques DevOps, vous vous demandez peut-être si l'ingénierie SRE est vraiment différente des DevOps et en règle générale, les deux termes vont de concert. L'ingénierie SRE est une pratique qui n'a pas forcément besoin de faire partie de la culture et de l'adoption des DevOps, mais elle est souvent mise en place par des organisations qui sont plus avancées dans leur parcours DevOps. Plus vous progressez avec le modèle de maturité DevOps, plus vous êtes susceptibles d'avoir adhéré aux pratiques SRE.

Le point n'est pas de comparer les SRE aux DevOps. Le point est d'établir une équipe SRE proactive et d'exploiter un modèle qui aide à renforcer les pratiques DevOps. Que vous choisissiez un cadre SRE intégré aux équipes de développement et IT, ou que vous vouliez faire des SRE une unité opérationnelle autonome, vous devez comprendre les responsabilités globales qui y sont associées.

Les responsabilités de l'équipe SRE

Les ingénieurs de la fiabilité des sites (SRE) ont pour responsabilité de définir ce que sont réellement les performances et la fiabilité en termes d'applications, de services et d'infrastructure. Au quotidien, les tâches qui leur incombent peuvent aller de l'instrumentation de nouvelles solutions de monitoring au développement d'applications pour les équipes de l'assistance technique. Elles peuvent aussi inclure le passage en production de nouveau code pour le débogage et de nouvelles fonctionnalités, ou elles peuvent répondre aux incidents en temps réel et exiger une étroite collaboration avec les équipes de l'assistance technique pour assurer l'expérience positive des clients.

Au final, les ingénieurs SRE sont essentiels pour bien comprendre l'expérience des clients avec votre produit et à la meilleure façon d'en faire le suivi en termes de performances et de fiabilité système. Les équipes SRE doivent savoir où se trouvent la limite entre ce que publient les équipes de développement et ce que le ressenti des clients. Une fois cette limite établie, ils doivent trouver différentes méthodes de monitoring des problèmes de fiabilité et de performances afin d'aider les équipes internes à activement identifier les risques et proposer de meilleurs logiciels. 

Les équipes SRE partagent leurs observations avec les équipes produit et développement afin de déterminer en continu la fiabilité dans toute l'organisation. Une fois que tout le monde est sur la même longueur d'onde, les équipes d'ingénierie peuvent prendre des décisions qui sont datadriven pour la sortie de nouvelles fonctionnalités ou l'amélioration de l'expérience client en phase de production. 

Les principes et pratiques SRE

À un très haut niveau, Google met au cœur des principes et pratiques SRE la capacité à « embrasser les risques ». En effet, les ingénieurs SRE contrebalancent les besoins organisationnels d'innovation constante et de nouveaux logiciels avec la fiabilité et les performances des environnements de production. Par exemple, une partie non essentielle de votre service ne requiert peut‑être pas d'être disponible à 99,999 % si elle n'a pas d'effet sur les clients. Si le travail de fiabilité cause d'importants retards au niveau de la sortie des logiciels, sans créer une amélioration nette du service côté client, c'est alors une perte de temps. 

La pratique des SRE augmente parallèlement à la croissance d'adoption des DevOps, car les deux équilibrent les besoins parfois opposés de l'équipe de développement et de celle de l'équipe des opérations. Les SRE injectent des processus dans le CI/CD et dans les workflows de sortie de logiciels afin d'améliorer les performances et la fiabilité, mais ils savent aussi quand il est nécessaire de sacrifier la stabilité pour la rapidité. En collaborant étroitement avec les équipes DevOps pour comprendre les composants critiques de leurs applications et infrastructure, les ingénieurs SRE peuvent également savoir quels sont les composants non essentiels.

Ils peuvent aussi déterminer le niveau de risques acceptable, en rendant l'intégrité des applications et systèmes complètement transparente pour toutes les équipes. En outre, le niveau de disponibilité du service voulu et les problèmes acceptables de performance que vous pouvez raisonnablement tolérer dépendront aussi du service que vous prenez en charge. Les principes et pratiques SRE embrassent l'expérimentation et exigent que l'on soit déterminé à comprendre l'intégrité des services pris en charge.

Le modèle d'exploitation et de maturité SRE

Il est fréquent qu'un ingénieur IT assume bon nombre des responsabilités normalement associées au poste d'ingénieur SRE et c'est peut-être votre cas. Comment savez-vous alors si votre pratique SRE est suffisamment mature ? Nous allons vous montrer comment développer rapidement un modèle d'exploitation SRE efficace et suivre comparativement l'évolution de votre maturité.

Un modèle d'exploitation SRE comprend généralement trois éléments atteignables en trois phases :

1. Une équipe (ou au moins une personne) spécialisée à la pratique des SRE.
2. Une intégration et influence en profondeur des équipes produit, développement et opérations.
3. La liberté d'automatiser les workflows et d'écrire du code pour quasiment toutes les différentes parties de l'application ou du système.

Votre niveau de maturité SRE dépend de la phase du modèle d'exploitation SRE où en est votre organisation. Si vous avez pris des mesures pour créer une équipe SRE ou embaucher votre premier ingénieur SRE, vous êtes tout au début de votre parcours. Si vous disposez d'une équipe et qu'elle participe activement aux discussions sur la feuille de route, l'assurance qualité, les workflows de déploiement, les processus de gestion des incidents, vous avez alors une pratique SRE relativement mature. 

Une organisation arrive à la maturité SRE seulement lorsque l'unité organisationnelle SRE jouit de l'autonomie suffisante pour automatiser les workflows, développer les applications, posséder des solutions de monitoring et d'alertes, ou intervenir dans quasiment toutes les discussions. Le fait de pouvoir nommer les préoccupations de performances et de fiabilité en aval et d'avoir une discussion proactive sur ces préoccupations vaut toujours mieux que de simplement les ignorer jusqu'à ce que ce soit trop tard.

Automatisation organisationnelle, du monitoring et des CI/CD

Les ingénieurs SRE peuvent automatiser à peu près tout et n'importe quoi. Si un problème est facilement détectable, corrigible ou résoluble en aval, il faut l'automatiser. La visibilité sur tout — des pratiques d'intégration et de publication jusqu'au monitoring de l'environnement de production — doit être à la disposition des équipes SRE. S'il est possible d'identifier différentes façons de découvrir en aval les problèmes de performances et de fiabilité, il faut aussi avoir l'autorité de mettre en place ces changements.

Les capacités DevOps et IT de l'automatisation, du monitoring, de l'intelligence artificielle et de l'apprentissage machine d'aujourd'hui donnent aux équipes SRE un énorme avantage lors de l'identification des problèmes, mais aussi lors de la réponse à ces problèmes et du dépannage. Les organisations avec des pratiques DevOps et SRE matures peuvent détecter les problèmes lors de la simulation et peuvent également développer des workflows de gestion automatisée des incidents et des systèmes autocorrectifs. En déterminant les composants critiques de vos applications et infrastructure, les ingénieurs SRE peuvent limiter l'étendue de tout ce qui peut entraîner d'importants problèmes.

La pratique des niveaux de service (SLI, SLO et SLA)

Les niveaux de service sont importants pour aider les équipes SRE à communiquer l'intégrité des produits et services numériques à toutes les parties prenantes. Cela est possible en identifiant et mesurant les composants critiques qui sont essentiels pour assurer une expérience client positive. En particulier, il est nécessaire de savoir quand un ou plusieurs composants compromettent la fonctionnalité pour les clients externes. Nous appelons ces points d'intersection les limites du système. Ces limites correspondent à l'endroit où les ingénieurs SRE doivent appliquer les indicateurs et objectifs des niveaux de service à leurs métriques afin de révéler la véritable histoire des performances et de la fiabilité du système. 

• Les indicateurs de niveau de service (SLI) sont les mesures et métriques clés permettant de déterminer la disponibilité d'un système.
• Les objectifs de niveau de service (SLO) sont les objectifs définis pour le niveau de disponibilité que vous attendez d'un système.
• Les accords de niveau de service (SLA) sont les contrats légaux qui expliquent ce qui se passe si le système ne répond pas aux critères du SLO.

Si les SRE ne sont pas toujours chargés de la gestion des niveaux de service, ces derniers relèvent souvent de leur compétence. En faisant le suivi des SLI et en les reliant aux SLO, vous pouvez définir les objectifs de performance d'un système. Le manuel de Google sur les SRE définit les quatre signaux dorés des niveaux de service comme étant la latence, le trafic, les erreurs et la saturation. Par exemple, vous pourriez observer un appel d'API et faire le suivi du nombre de requêtes réussies ou pas (SLI) par rapport au pourcentage global de requêtes qui doivent être réussies pour que l'expérience des clients soit bonne (SLO).

Les équipes SRE définissent souvent des SLO stricts sur les composants critiques au sein de leurs applications et services afin de mieux comprendre à quel point un SLA peut-être strict avec les clients. À partir de là, l'équipe peut appliquer des budgets d'erreur afin de comprendre à quelle vitesse ils doivent résoudre les erreurs afin de continuer de respecter leurs SLO. Les niveaux de service permettent aux équipes de faire l'agrégat des métriques et de créer une vue transparente des temps de disponibilité, des performances et de la fiabilité dans toute l'organisation. Les cadres de l'entreprise peuvent utiliser les niveaux de service pour monitorer en un coup d'œil la conformité des équipes, applications, services, etc. et ainsi mieux comprendre l'intégrité du système dans sa globalité.

Vous êtes sur le point d'adopter les meilleures pratiques SRE

L'adoption des meilleurs principes et pratiques SRE n'arrive pas en une nuit. Elle nécessite du temps et des efforts pour monitorer de manière proactive les performances et la fiabilité de vos équipes et systèmes. Mais au bout du compte, vos équipes DevOps, et surtout vos clients, vous remercieront d'avoir décidé de tirer parti des SRE.