La SRE est-elle la cerise sur le gâteau du DevOps?

C’est Google qui, en 2003, a introduit le terme  » Site Reliability Engineering  » (SRE) se traduisant par Ingénierie de la fiabilité de site. Aujourd’hui, l’entreprise emploie plus de 1500 ingénieurs de la fiabilité de site qui exploitent des systèmes à grande échelle dans un cycle continu de développement et de lancement de fonctionnalités. L’ingénierie de la fiabilité de site cherche à améliorer le modèle DevOps traditionnel en transférant les responsabilités opérationnelles vers les développeurs de logiciels.

DevOps

Le DevOps est une philosophie ayant pour but d’unir les rôles de développement (Dev) et des opérations (Ops). Préconisant une infrastructure partagée et hautement automatisée, le DevOps demande un pipeline de logiciel fluide avec une collaboration active entre le développement et les opérations, intégrée dans toutes les étapes du cycle de vie de la livraison. La méthodologie de travail qui en découle est légère, agile et son rythme de lancement des fonctionnalités se trouve grandement accéléré.

Le DevOps aborde le conflit d’intérêts existant entre le développement et les opérations et qui mène vers une absence de responsabilité de la part des deux équipes face aux problèmes qui pourraient survenir. Tandis que les développeurs veulent lancer des fonctionnalités de façon continue, les opérateurs doivent s’assurer d’un fonctionnement optimal. Plus le lancement des fonctionnalités est rapide, plus les risques sont grands ; l’exploitation d’une application à long terme peut alors devenir problématique. Les opérateurs et les développeurs n’ont aucun pouvoir sur le domaine de l’autre, il se crée alors une boucle de délégation de responsabilité menant éventuellement à la stagnation.

En intégrant les deux disciplines et en faisant la promotion d’une collaboration croisée, le DevOps aspire à résoudre ce conflit d’intérêts. Les développeurs sont alors plus enclins à prévenir les problèmes opérationnels futurs, car ils canalisent leur passion pour l’automatisation afin de résoudre les problèmes à l’échelle. Bien que ces pratiques aient un potentiel de mise à l’échelle illimité, le modèle peut éventuellement s’effondrer sous le poids de sa propre agilité et de sa complexité, au fur et à mesure qu’il accumule des dettes techniques.

SRE : Ingénierie de la fiabilité de site

Une SRE est en quelque sorte, une police d’assurance contre ce rythme de changement accéléré, limitant les dettes techniques engendrées par les pratiques DevOps. Un ingénieur de la fiabilité de site est responsable de la gestion de ce rythme de changement, il est également responsable de maintenir la stabilité de la performance de l’utilisateur final ainsi que la qualité et la fiabilité des éléments livrés. C’est l’ingénieur qui détient les accords de niveaux de services (ANS) d’une application et qui fournit les paramètres d’introduction des changements. La SRE délègue les responsabilités lorsque surviennent les problèmes, prévenant le lancement de nouvelles fonctionnalités avant que les problèmes opérationnels ne soient résolus. La délégation de responsabilités renforce la collaboration entre les développeurs et les opérateurs, ce qui améliore les capacités de surveillance, de gestion et de mise à l’échelle d’une application.

Essentiellement, l’ingénierie de la fiabilité de site gouverne la collaboration entre le Dev et les Ops au cœur d’une application Web, celle-ci étant découplée du pipeline DevOps, ce qui met en relief les protocoles de surveillance comme moyen de simplifier la collaboration. Ainsi, la SRE prolonge le modèle DevOps en y surimposant une couche de responsabilité englobant le modèle en entier, réduisant ainsi la dépendance sur la robustesse du pipeline et rendant l’équipe du Dev plus disponible aux Ops.

Une SRE est responsable de la fiabilité de l’application Web qui est essentielle au modèle commercial d’une organisation, mais qui est généralement là où se manifestent les problèmes techniques. Par conséquent, l’expérience de l’utilisateur final est vue comme le paramètre principal de la conformité aux ANS. Cela place la SRE dans une position idéale pour déléguer les responsabilités et atténuer les problèmes affectant les ANS et ainsi restaurer le comportement prévu de l’application Web. De cette façon, le rôle de la SRE facilite la résolution rapide des problèmes tout en préservant les objectifs de l’entreprise.

Ben Treynor est l’auteur du terme « SRE » (Ingénierie de la fiabilité de site) chez Google, il a compilé un guide d’implantation de rôles SRE. Il cite cinq piliers des fondements d’une structure DevOps, expliquant comment une SRE peut aider les organisations à mettre ces piliers en œuvre.

Décloisonner les services – la SRE élimine les barrières entre le Dev et les Ops grâce à une couche superposée et aide à combler l’écart entre l’équipe de développement qui souhaite livrer le plus rapidement possible et l’équipe des opérations qui veut éviter le désastre à l’étape de production. Ben Treynor décrit le rôle d’une SRE comme « ce qui arrive lorsque l’on demande à un ingénieur de logiciel de concevoir la fonction opérationnelle ».

Il s’agit de consacrer une équipe d’opérateurs à la supervision de la fiabilité du produit et de donner aux développeurs de logiciels la responsabilité des opérations quotidiennes de leurs applications en production.

Tirer profit de l’outillage et de l’automatisation – l’automatisation fait déjà partie intégrante des pratiques DevOps, mais elle est préconisée davantage par une SRE. Elle utilise l’expérience d’un développeur dans l’automatisation de problèmes à l’échelle ; une tâche habituellement réservée aux opérations. Ainsi, l’automatisation est accrue au-delà des paramètres habituels des développeurs et se répand à travers toute l’application.

Tout mesurer – une SRE se concentre sur la capacité de surveillance d’une application comme moyen de cibler les problèmes dans le pipeline afin de déléguer les responsabilités. Tandis qu’un modèle DevOps traditionnel implique l’écriture de code, une SRE instrumente le code, le poussant au sein de l’application Web et l’exposant à la visibilité.

Accepter les échecs – le rôle d’une SRE est d’atténuer les dettes techniques qui surviennent à cause de l’agilité accrue d’un modèle DevOps. L’échec fait donc partie du quotidien, car on ne peut prévenir tous les problèmes, et puis les améliorations sont mises en œuvre de façon itérative.

Implémentation graduelle des changements – une SRE a pour but de réduire le coût de l’échec ; elle doit donc mettre en place les changements de façon graduelle afin qu’ils puissent être surveillés. Elle doit s’adapter elle-même, ainsi que son équipe, aux besoins uniques de l’organisation en question et créer, au fur et à mesure, sa description d’emploi. Ainsi, une SRE peut véritablement avoir son propre système de surveillance du pipeline DevOps et atténuer les risques au cours du processus.

Le DevOps a transformé la façon dont nous déployons les applications. Son accent sur la collaboration a accéléré, au sein de nombreuses entreprises, le lancement de fonctionnalités et la propagation de l’automatisation. Une SRE peut être une bonne solution pour pallier l’ambiguïté de la responsabilité face aux problèmes qui surviennent dans l’application Web. C’est un prolongement des pratiques DevOps, amenant les fonctions opérationnelles entre les mains des développeurs et responsabilisant les opérations grâce à l’atténuation du risque. Steve Strutt a qualifié une SRE « d’approche infonuagique pour les opérations ».

Pour en apprendre plus sur la façon d’intégrer les pratiques exemplaires DevOps au sein de votre organisation, demandez une évaluation de plateforme applicative.