Ingénierie de la fiabilité du site (Le) n’est pas un nouveau terme ou une nouvelle pratique. La pratique consistant à appliquer des compétences et des principes en génie logiciel à des problèmes et des tâches opérationnelles s’est produite avant même que l’ingénieur en fiabilité de site ne soit un titre de poste défini. Mais l’organisation d’une approche proactive de la création et de la maintenance de logiciels contribue au succès à long terme de l’amélioration de l’efficacité opérationnelle, de la planification de la feuille de route basée sur les données et de la disponibilité et de la fiabilité générales. Tous ces avantages expliquent l’adoption généralisée du SRE.

Dans cet article, je vais plonger dans ce qu’il faut pour entrer dans l’ingénierie de la fiabilité du site, comment l’adopter au sein de votre propre organisation et certains des principes fondamentaux et des meilleures pratiques que vous devrez garder à l’esprit à mesure que vous avancez dans votre parcours de maturité SRE.

Qu’est-ce que SRE?

SRE, ou ingénierie de fiabilité de site, est la pratique consistant à appliquer l’expertise en génie logiciel aux problèmes DevOps et opérationnels. Souvent, cela signifie écrire du code de manière proactive et développer des applications ou des services internes pour lutter contre les problèmes de fiabilité et de performances. SRE est une pratique depuis de nombreuses années, mais a été plus récemment popularisé par Google lors de sa première publication. Ingénierie de fiabilité de site : comment Google gère les systèmes de production en mars 2016.

SRE est un acronyme compliqué car il se rapporte à la fois à un titre de poste, ingénieur en fiabilité de site,ainsi qu’une pratique générale adoptée par les équipes de développement et d’informatique, ingénierie de fiabilité de site. Les équipes SRE sont souvent organisées différemment selon l’organisation et les services qu’elles soutiennent. Parfois, les ingénieurs en fiabilité de site (SRE) sont répartis entre les équipes de développement. Cela signifie qu’ils peuvent exprimer leurs préoccupations lors de la planification de la feuille de route et travailler en étroite collaboration avec les équipes d’assurance qualité, en collaborant sur tout, des fonctionnalités d’expédition à la mise en scène en passant par la gestion des environnements de production.

Une autre approche organise une équipe SRE en tant que groupe autonome. L’équipe SRE dans son ensemble se concentre sur les responsabilités, y compris la surveillance des applications et de l’infrastructure, l’établissement de mesures de fiabilité, le suivi des problèmes liés aux nouvelles versions et la gestion des tâches sur appel. Quelle que soit la façon dont ils sont organisés, ce qui reste le même pour tous ces SRE, c’est leur initiative : fiabilité et performance.

DevOps contre SRE

L’adoption rapide des pratiques DevOps peut vous amener à vous demander : « En quoi SRE est-il différent de DevOps ? » Généralement, les deux termes vont de pair. SRE est une pratique qui ne doit pas nécessairement faire partie de la culture et de l’adoption DevOps, mais qui est souvent mise en œuvre par des organisations qui sont plus avancées dans leur parcours DevOps. Plus votre modèle de maturité DevOps avance, plus vous avez de chances d’avoir adhéré aux pratiques SRE.

La conversation n’est pas « SRE versus DevOps ; la conversation porte sur la mise en place d’une équipe SRE proactive et d’un modèle opérationnel pour vous aider à renforcer votre pratique DevOps. Que vous choisissiez un framework SRE intégré à vos équipes de développement et informatiques, ou que vous souhaitiez faire de SRE une unité commerciale autonome, vous devez comprendre leurs responsabilités générales.

Responsabilités de l’équipe SRE

Les ingénieurs en fiabilité du site sont responsables de définir ce que performant et fiable vraiment méchant quand vous parlez de vos applications, services et infrastructure. Les tâches quotidiennes peuvent aller de l’instrumentation de nouvelles solutions de surveillance à la création d’applications personnalisées pour les équipes de support technique. Ils peuvent expédier du nouveau code à la production pour corriger des bogues ou fournir de nouvelles fonctionnalités, ou ils peuvent répondre aux incidents en temps réel et travailler en étroite collaboration avec les équipes de support pour offrir des expériences client positives.

En fin de compte, les ingénieurs en fiabilité de site sont la clé pour comprendre exactement comment les clients vivent votre produit et comment suivre les performances et la fiabilité du système à travers les yeux de vos clients. Les équipes SRE doivent déterminer exactement où se trouvent les limites de service entre ce que les équipes de développement expédient et ce que les clients expérimentent. À partir de là, ils doivent trouver des moyens de surveiller les problèmes de fiabilité et de performance d’une manière qui aide vos équipes internes à identifier de manière proactive les risques et à fournir de meilleurs logiciels.

Les équipes SRE diffusent les connaissances entre les équipes de produits et de développement afin de définir de manière cohérente la fiabilité dans l’ensemble de l’organisation. Avec tout le monde sur la même longueur d’onde, les équipes d’ingénierie peuvent prendre des décisions basées sur les données lorsqu’il s’agit de publier de nouvelles fonctionnalités ou d’améliorer les expériences actuelles en production.

Principes et pratiques d’ingénierie de la fiabilité du site

À un niveau très élevé, Google définit le cœur des principes et des pratiques SRE comme une capacité à « embrasser le risque ». Les ingénieurs en fiabilité des sites équilibrent le besoin organisationnel d’innovation constante et de livraison de nouveaux logiciels avec la fiabilité et les performances des environnements de production.

La pratique du SRE se développe à mesure que l’adoption de DevOps se développe, car ils aident tous deux à équilibrer les besoins parfois opposés des équipes de développement et d’exploitation. Les ingénieurs en fiabilité du site injectent des processus dans les flux de travail CI/CD et de livraison de logiciels pour améliorer les performances et la fiabilité, mais ils sauront quand sacrifier la stabilité pour la vitesse. En travaillant en étroite collaboration avec les équipes DevOps pour comprendre les composants critiques de leurs applications et de leur infrastructure, les SRE peuvent également apprendre les composants non critiques.

La transparence entre toutes les équipes sur la santé de leurs applications et systèmes peut aider les ingénieurs en fiabilité du site à déterminer le niveau de risque avec lequel ils peuvent se sentir à l’aise. Le niveau de disponibilité du service souhaité et les problèmes de performances acceptables que vous pouvez raisonnablement autoriser dépendront également du type de service que vous prenez en charge. Les principes et les pratiques du SRE englobent l’expérimentation et exigent un dévouement à comprendre de manière proactive la santé des services qu’ils soutiennent.

Un modèle d’exploitation et de maturité SRE

Vous pouvez assumer une grande partie des responsabilités demandées à un ingénieur en fiabilité de site tout en ayant un titre de poste d’ingénieur logiciel. Alors, comment savez-vous à quel point votre pratique d’ingénierie de la fiabilité de site est mature? Heureusement pour vous, nous vous présenterons un moyen rapide de créer un modèle d’exploitation SRE efficace et de suivre votre maturité par rapport à celui-ci. Un modèle d’exploitation SRE comprend généralement trois éléments, que vous pouvez réaliser par phases :

1. Une équipe (ou au moins une personne) dédiée à la pratique du SRE.
2. Intégration et influence approfondies au sein des équipes de produits, de développement et d’exploitation.
3. Autonomie pour automatiser les flux de travail et écrire du code pour presque n’importe quelle partie de votre application ou système.

La maturité de votre SRE dépend de l’endroit où votre organisation se situe le long de ces trois éléments d’un modèle opérationnel SRE. Si vous avez pris les mesures nécessaires pour constituer une équipe SRE ou embaucher votre premier ingénieur en fiabilité de site, vous êtes au début de votre parcours. Si vous avez une équipe et qu’elle est une partie précieuse des discussions sur la feuille de route, de l’assurance qualité, des flux de travail de déploiement, des processus de gestion des incidents, alors vous avez une pratique SRE quelque peu mature.

Une organisation n’atteint la maturité SRE complète que lorsque l’unité commerciale SRE a l’autonomie nécessaire pour automatiser les flux de travail, créer des applications, posséder ses propres solutions de surveillance et d’alerte, ou s’immiscer dans presque toutes les conversations. Exprimer les problèmes de performance et de fiabilité dès le départ et avoir une discussion proactive sur ces préoccupations est toujours mieux que de simplement les ignorer jusqu’à ce qu’il soit trop tard.

Surveillance, CI/CD et automatisation organisationnelle

Les ingénieurs en fiabilité de site peuvent et vont automatiser à peu près tout et n’importe quoi. S’il peut détecter, corriger ou résoudre un problème de manière proactive, il doit être automatisé. Des pratiques d’intégration continue et de livraison à la surveillance de l’environnement de production, les SRE doivent avoir une certaine visibilité sur l’ensemble de ces processus. S’ils peuvent identifier des moyens de découvrir de manière proactive les problèmes de performance et de fiabilité, ils doivent avoir le pouvoir de mettre en œuvre ces changements.

Les capacités DevOps et INFORMATIQUEs d’aujourd’hui en matière d’automatisation, de surveillance, d’intelligence artificielle et d’apprentissage automatique confèrent aux équipes SRE un énorme avantage pour identifier les problèmes, y répondre et les résoudre. Les organisations ayant des pratiques DevOps et SRE matures peuvent détecter les problèmes lors de la mise en scène et peuvent également créer des flux de travail automatisés de gestion des incidents et des systèmes d’auto-correction. En déterminant les composants critiques de vos applications et de votre infrastructure, les SRE peuvent réduire la portée des éléments susceptibles de causer des problèmes majeurs.

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

Les niveaux de service entrent en jeu pour aider les équipes SRE à communiquer la véritable santé des produits et services numériques à toutes les parties prenantes. Cela se fait en identifiant et en mesurant les composants critiques qui sont essentiels pour offrir des expériences client positives. En particulier, ils doivent savoir quand un ou plusieurs composants exposent des fonctionnalités à des clients externes. Nous appelons ces points d’intersection les limites du système. Les limites du système sont l’endroit où les ingénieurs en fiabilité du site doivent appliquer des indicateurs et des objectifs de niveau de service à leurs métriques afin de raconter la véritable histoire de la performance et de la fiabilité du système.

• Indicateurs de niveau de service (SLI) sont les key mesures pour déterminer la disponibilité d’un système.
• Objectifs de niveau de service (SLO) sont des objectifs que vous définissez pour la disponibilité que vous attendez d’un système.
• Contrats de niveau de service (SLA) sont les contrats légaux qui expliquent ce qui se passe si le système ne respecte pas son SLO.

Bien que les SRE ne soient pas toujours responsables de la gestion des niveaux de service, cela relève souvent de leur compétence. En suivant les SLI et en les liant aux SLO, vous pouvez définir des objectifs autour des performances d’un système. Le livre SRE de Google définit les quatre signaux d’or des niveaux de service comme la latence, le trafic, les erreurs et la saturation. Ainsi, par exemple, vous pouvez examiner un appel d’API et suivre son nombre de demandes réussies / échouées (le SLI) par rapport à un pourcentage général de demandes qui doivent réussir pour que les clients aient une bonne expérience (le SLO).

Les équipes SRE fixent souvent des SLO stricts sur les composants critiques de leurs applications et services afin de mieux comprendre la rigueur d’un SLA qu’elles peuvent accepter avec les clients. À partir de là, l’équipe peut appliquer des budgets d’erreur pour comprendre à quelle vitesse elle doit résoudre les problèmes afin de rester conforme à ses SLO. Les niveaux de service permettent aux équipes d’agréger les métriques et de créer une vue transparente de la disponibilité, des performances et de la fiabilité dans l’ensemble de l’organisation. En un coup d’œil, les chefs d’entreprise peuvent utiliser les niveaux de service pour surveiller la conformité de plusieurs équipes, applications, services, etc. afin d’acquérir une compréhension complète de l’état de leur système.

Adopter les meilleures pratiques SRE

L’adoption des meilleures pratiques et des principes du SRE ne se fera pas du jour au lendemain. Il faut du temps et des efforts pour surveiller de manière proactive vos équipes et vos systèmes pour des problèmes de performance et de fiabilité. Mais, en fin de compte, vos équipes DevOps et surtout vos clients vous remercieront d’avoir décidé de tirer parti de l’ingénierie de fiabilité du site.