La SRE ou Ingénierie de Fiabilité de Sites : comment réussir sa mise en place?
L'ingénieur SRE doit avoir une culture "Full Stack" pour comprendre le comportement et les interactions de tous les composants de l'environnement et dialoguer avec toutes les équipes impliquées.
L’adoption de la SRE (ou Ingénierie de Fiabilité de Sites) et le rôle qui l’incarne, l’ingénieur SRE, connaissent une forte accélération. Une évolution logique pour une pratique qui permet une gestion proactive et une amélioration continue de la performance des architectures et des équipes logicielles. Mais quelles sont les clés pour implémenter une pratique SRE avec succès au sein de son organisation ?
La SRE, un rôle central entre fiabilité, vélocité, efficacité et performance
Popularisée par Google en 2016 dans l’article Site Reliability Engineering : How Google Runs Production Systems, les pratiques SRE permettent d’adresser plusieurs défis des architectures logicielles modernes à toute échelle. La SRE prend en charge la définition, la mesure et la maîtrise des risques sur l'ensemble de l'architecture ‘Full Stack’, en faisant systématiquement appel à l’automatisation, à l’instrumentation et la mesure, ainsi qu’à la simulation et l’analyse d’incidents. Elle permet l’accélération des cycles d'innovation et de la fréquence des déploiements logiciels en répondant aux impératifs de disponibilité, de fiabilité et de performance des environnements de production.
Si la SRE n’implique pas le DevOps, elle est dans les faits souvent mise en œuvre par des organisations qui ont atteint un niveau avancé de maturité de leur pratiques DevOps, généralement associé à une architecture modularisée et/ou en micro-services, une infrastructure dynamique de type Cloud, et une adoption des outils d’automatisation CI/CD et de déploiement d’infrastructure Immuable.
"Full Stack" et "Everything as Code"
Pour pouvoir animer et guider toutes les décisions qui impactent la fiabilité et la performance, et quelle que soit son expérience initiale, l’ingénieur SRE doit développer une culture ‘Full-stack’ des architectures, qui lui permet de comprendre le comportement et les interactions de tous les composants des environnements, et de dialoguer aussi bien avec les développeurs du code ‘Back-end’ ou ‘Front-end’, que les équipes ‘middlleware’ et infrastructure, ou encore les équipes outils et CI/CD. L’ingénieur SRE pense en termes d’automatisation et gère le cycle de vie de l’architecture avec une approche ‘Everything as Code’. Il a les compétences pour développer les standards, les modèles, les scripts, les workflows, les configurations et les applications internes qui permettent d’automatiser toute activité qui doit être effectuée de façon répétitive, qu’elle concerne le cycle de vie du code, de l’infrastructure ou des outils et de l’instrumentation.
L’automatisation est essentielle et permet d’assurer la cohérence, la répétabilité et la prédictibilité des changements, en éliminant les erreurs et oublis humains ou les disparités entre équipes. Pour être réellement effective et maintenable, l’automatisation requiert une approche ‘Everything as Code’ rigoureuse où tous les composants d’automatisation sont considérés comme du code, gérés au travers d’outils logiciels de type git ou de déploiement immuable, gérant les versions, la documentation et les déploiements.
SRE et pilotage par les données, instrumentation et observabilité
Les enjeux Business et Clients liés à la disponibilité, la fiabilité et la performance sont considérables. Il est donc vital d’établir une visibilité unifiée et transparente ‘Full Stack’ sur les applications et les architectures. Cette approche permet une mesure et une compréhension commune du comportement et des risques inhérents à chaque composant et à leurs interactions dans l’architecture, lorsque celle-ci est en charge ou soumise à un stress. Encore trop souvent, les lacunes d’instrumentation et la fragmentation des outils ne permettent pas de détecter et de résoudre rapidement les dégradations et les incidents. Cette situation crée des tensions et des conflits entre les équipes, celles-ci ne parvenant pas à s’accorder sur la nature et les causes des incidents ou des problèmes de performance lorsqu’ils surviennent. Des incompréhensions qui augmentent fortement les risques ainsi que les temps de détection et de résolution des incidents.
Visualisation, mesure et analyse automatiques, en temps réel
Un des rôles clé de l’ingénieur SRE est donc de s’assurer : que l’architecture est systématiquement instrumentée sur l’ensemble de ses composants ; que la télémétrie collectée en temps réel est exploitée pour la visualisation, la mesure et l’analyse du comportement du système ; que les outils d’analyse et de détection sont en place pour une résolution proactive et rapide des anomalies et des dégradations susceptibles de conduire à un incident ; que les équipes peuvent ainsi réduire le taux d’incident, leur MTTD et leur MTTR.
L’ingénieur SRE s’assure en particulier du fait que les développeurs sont formés et disposent des outils nécessaires pour instrumenter leur code et leurs environnements automatiquement, dès la phase de développement et de déploiement (Instrumentation as Code), assurant ainsi la disponibilité de la télémétrie. Il fournit aussi aux équipes les moyens d’automatiser le déploiement des ‘alertes’, les ‘dashboards’ ou des ‘Service Level Objectives’ (Observability as Code), par exemple au moyen d’ un outil comme Terraform. Ceci afin de garantir que tout nouveau déploiement préserve l’observabilité de l’architecture et la couverture de mesure, d’analyse et de détection.
La SRE apporte ainsi à toutes les équipes une vue unifiée de bout-en-bout qui permet une collaboration plus fluide et une prise de décision rapide fondées sur des données objectives en temps réel, et non plus sur des opinions individuelles.