La SRE, assurer la fiabilité, la vélocité, l’efficacité et la performance
C’est Google en 2016 qui a popularisé la SRE dans l’article Site Reliability Engineering : How Google Runs Production Systems. Les pratiques SRE s’intéressent à la définition, la mesure et la maîtrise des risques sur l'ensemble de l'architecture ‘Full Stack’, permettant ainsi de relever les défis actuels et à toute échelle des architectures logicielles modernes. En conciliant l’impératif de disponibilité, de fiabilité et de performance des environnements de production, cette pratique favorise l’accélération des cycles d'innovation et la fréquence des déploiements logiciels. Mais quel est le rôle exact de l'ingénieur SRE ?Détermination des niveaux de service (SLI) et autres indicateurs de performance
Google définit comme base essentielle des missions SRE les 4 ‘Golden Signals’ applicatifs : la latence, le trafic, le taux d’erreurs et la saturation. Ces signaux clés sont mesurés pour tous les services critiques et portés par les équipes en charge. Mais la palette des indicateurs va en général bien au-delà, englobant l’infrastructure et le middleware, mais aussi des dimensions essentielles comme l’expérience client ou la performance business, les coûts et la productivité, ou encore les processus de développement ou de gestion des incidents. En collaborant avec les équipes et le management, l’ingénieur SRE apporte une cohérence transverse dans le choix des indicateurs critiques. Il offre ainsi à toute les équipes une vue holistique de la charge et de la performance de l’ensemble du système, en laissant à ces dernières la liberté de gérer les indicateurs détaillés qui leur sont spécifiques.Un rôle d’animation sur les SLO et SLI
Sur la base de ces indicateurs et de leur valeur nominale en charge (‘baseline’), les ingénieurs SRE vont animer la définition des objectifs de niveau de service (Service Level Objectives ou SLOs‘) qui caractérisent le niveau de performance cible sur un indicateur spécifique et déterminant, par exemple : « le service de commande doit répondre en moins de 500ms pour 95% des transactions mesuré sur 1 journée » ou « la disponibilité de ce microservice doit être supérieur à 99.99% mesurée sur 1 semaine ». La définition de ces SLOs sur chaque composant critique va découler de la contribution de ce composant à la performance et la fiabilité globales du service, telles que définies par les attentes des clients et du leadership.Un impact technique et business considérable
Grâce aux SLI & SLO, l’ingénieur SRE peut animer l’amélioration continue, avec une vision claire de la situation réelle et des attentes de l’organisation. Les équipes peuvent gérer leur dette technique et définir les améliorations nécessaires ; elles connaissent leur budget résiduel d'erreur afin de rester conforme à leurs SLO ; elles peuvent définir les priorités et focaliser les ressources, sans générer de surcoût là où les SLO de performance et de fiabilité sont déjà atteints. Ces indicateurs sont par ailleurs précieux pour les leaders techniques et business qui peuvent à tout instant accéder aux tableaux de bord de la performance de leurs applications, systèmes et services, ce qui leur permet de diriger les équipes avec une vision globale et cohérente de la santé de leur système.Une appétence pour les incidents, le chaos et la charge
L’ingénieur SRE, avec sa compréhension ‘Full-Stack’ de l’architecture, est généralement activement impliqué dans la gestion et la résolution des incidents. Sur cette base, il s’assure que tout incident fait l’objet d’une rétrospective, lors de laquelle les équipes analysent factuellement les événements et les causes. Elles définissent ensuite un plan d’amélioration afin d’éviter la ré-occurrence des incidents ou d’en minimiser l’impact et les temps de détection et de remédiation. L’ingénieur SRE peut par ailleurs y contribuer en automatisant certaines tâches et/ou en fournissant de nouveaux moyens de détection, d’analyse et de remédiation. Il met par ailleurs en œuvre des action a préventives telles que des tests de charge en amont des pics réels pour comprendre les points de saturation et les seuils d’effondrement. Il anime l’ingénierie du chaos et les ‘Game Days’, lors desquels on confronte les systèmes et les équipes à des pannes volontaires afin valider les architectures et la préparation des équipes à répondre à ces pannes.Assurer la réussite d’une pratique SRE
Quatre éléments clés contribuent fortement au succès et à la montée en charge rapide de la SRE. Le premier consiste en la mise en place de ressources réellement dédiées à la pratique SRE , que ce soient des ingénieurs SRE directement intégrés aux équipes DeVOps (‘embedded’), regroupés dans une équipe centrale (‘Platform Engineering’) ou dans un modèle hybride. Le deuxième impératif est celui d’une intégration complète au sein des équipes et de leur processus de travail, le meilleur moyen d’influencer les décisions produits, de développement et d'exploitation. En termes d’outils et d’automatisation, pour accomplir son rôle, la SRE doit être équipée avec des plateformes modernes de CI/CD, d’infrastructure immuable et d’Observabilité. Enfin, le leadership : pour mener sa mission d’amélioration continue, l’ingénieur SRE doit être soutenu par le management, être dans une relation de transparence et de confiance avec celui-ci, et aligné en continu sur les priorités de l’entreprise.Les enjeux Business et Clients liés à la disponibilité, la fiabilité et la performance sont considérables. L’adoption d’une pratique SRE permet d’établir une visibilité unifiée et transparente ‘Full Stack’ sur les applications et les architectures. Elle fournit ainsi une mesure et une compréhension commune du comportement et des risques inhérents à chaque composant et à leurs interactions dans l’architecture lorsqu’elle est en charge ou soumise à un stress. Favorisant l’excellence et la performance, elle devient ainsi un véritable levier de croissance business et d’innovation.
Par Grégory Ouillon, CTO chez New Relic
