SRE

_{Home >> Cloud Computing >> SRE}

Né à l’origine chez Google, le SRE (Site Reliability Engineering) est un modèle d’organisation DevOps ayant pour but de garantir la stabilité de produits critiques pour le business d’une entreprise.

SRE is what happens when you ask a software engineer to design an operation function.
Ben Treynor

La team SRE, une équipe d’ingénieurs

La team SRE est une équipe ingénieurs, qui a de solides compétences systèmes couplées à des compétences de développement. Sa mission est de maintenir la disponibilité et la performance des produits et de s’assurer de la qualité et la fiabilité des éléments livrés. L’équipe SRE opère et supervise la fiabilité de produits stratégiques. C’est elle qui détient les accords de niveaux de services. C’est elle également qui évalue si les livraisons effectuées par les équipes de développement ont un niveau de qualité suffisant pour être déployés en production.

SRE, une mise en application des 5 piliers DevOps

Le modèle SRE est une évolution de l’organisation DevOps, mis en place au sein d’une entreprise, pour garantir la performance de ses produits “business critique”. Voici des solutions concrètes proposées par le modèle SRE pour répondre concrètement aux piliers du DevOps.

• Réduire les silos dans les organisations : Toil Budget, PRR
• Accepter l’échec comme normal : Blameless postmortem
• Implémenter les changements par itérations : Canary release
• Tirez parti des outils et de l’automatisation : self-healing
• Mesurer au maximum : SLI-SLO, Error budget

Détaillons ces notions.

Les KPI du modèle SRE

Dans le modèle SRE, 4 indicateurs sont monitorés en continu. Ils permettent de s’assurer que l’équipe SRE offre aux clients le niveau de service attendu et qu’elle dispose de suffisamment de temps pour que cela continue à l’avenir.

• SLI : Service Level Indicator. Niveau de service mesuré
• SLO : Service Level Objective. Objectif de niveau de service que l’on se fixe
• Error Budget : différence entre SLI et SLO. Budget que l’on peut s’accorder pour innover, tester…
• Toil Budget : pourcentage de tâches opérationnelles, manuelles, à faible valeur ajoutée, sur l’ensemble des tâches de l’équipe SRE. Ce toil ne doit jamais excéder 50%

Toil budget, l’équilibre entre Dev et Ops

Le toil c’est l’ensemble des tâches opérationnelles qui sont répétitives, manuelles et à faible valeur ajoutée.

• l’équipe SRE ne doit pas passer plus de 50% de son temps à faire du toil
• doit passer à minima 50% de son temps à développer des outils, notamment d’automatisation qui contribuent à la réduction du futur toil
• Si le toil dépasse 50% les demandes repartent vers l’équipe de développement
• Mise en place d’un outil simple pour mesurer le toil jour après jour

Production Readiness Review

La Production Readiness Review (PRR) est une revue mise en place par l’équipe SRE pour évaluer si un livrable répond aux exigences qu’elle a défini pour être déployé en production.

La PRR, peut prendre la forme d’une checklist dont les points sont validés un à un par l’équipe SRE ou d’un pipeline qui permet de tester automatiquement un ensemble d’éléments tels que

• la qualité du code
• la compatibilité avec l’environnement
• le niveau d’automatisation

Si la PRR n’est pas validée, le code est renvoyé à l’équipe de développement pour modification

Canary release

La canary release est un pattern qui permet de faire tester les dernières modifications réalisées (appelée version N+1) à une tranche de population restreinte avant de réaliser un déploiement progressif de cette version.

• D’abord effectué sur une toute petite partie des utilisateurs contrairement au blue-green
• Permet de s’assurer de la qualité des livraisons
• Permet de n’impacter qu’une partie restreinte de la population adressée en cas de problème
• Permet de préserver le niveau de disponibilité
• Permet de tester la montée en charge

Blameless Post-mortem

Un Blameless Post-mortem (post-mortem sans reproche) est organisé à la suite de tout incident significatif.

L’équipe SRE, accompagné d’autres parties prenantes si nécessaire, fait un compte-rendu de l’incident, définit la chronologie des évènements qui y ont menés, extrait les leçons qu’elle en a tiré et développe des recommandations pour que les choses marchent mieux à l’avenir.

• Permet la prise d’initiative et l’innovation
• Permet de détecter les problèmes et d’en identifier la cause plus rapidement en libérant la parole
• Se concentre sur le “comment” plutôt que sur le “qui”
• Référence l’ensemble des corrections à apporter pour que l’incident ne se reproduise pas
• Transforme l’erreur en apprentissage
• Permet d’améliorer la qualité des produits et services
• Permet d’anticiper les problèmes et d’apporter des corrections en amont