Le SRE, pierre angulaire de votre production

Le SRE (Site Reliability Engineering) est devenu une pratique essentielle pour garantir la fiabilité et la performance des systèmes logiciels complexes. Dans cet article, nous explorons les idées clés et les meilleures pratiques partagées lors d'une discussion sur la SRE, couvrant divers aspects de cette discipline critique.

‍

‍

En ce qui concerne la terminologie entourant le SRE, comme ce qu’on retrouve dans les discussions autour des termes Agile et DevOps, il existe diverses interprétations de ce qu'implique le SRE. Pour certains, les seules définitions valables sont celles proposées par Google, à l'origine de l'acronyme. D'autres considèrent le SRE comme un nouveau titre de poste à la mode pour les équipes d'exploitation qui gèrent les systèmes distribués. Dans cet article, lorsque nous parlons de pratiques SRE, nous englobons toutes les pratiques visant à améliorer la fiabilité, qui sont généralement classées dans les cinq dimensions suivantes :

• Business SLAs & Error Budget : permettre aux équipes Métiers de prendre des décisions concernant le système informatique sur la base des résultats des Métiers.
• Observabilité : donner la capacité d’anticiper les perturbations potentielles des processus Métiers et de l’expérience utilisateur.
• Amélioration Post-Incident : définir une méthode claire et prévisible pour la mise en œuvre rapide de correctifs en réponse aux incidents actuels ou potentiels de l'activité.
• Automatisation : se prémunir contre les actions à haut risque et consacrer plus de temps aux tâches à valeur ajoutée pour améliorer les outils et les processus existants.
• Déploiement rapide et robuste : reconnaître que la fiabilité signifie également la capacité de déployer en toute sécurité des correctifs en production à tout moment.

Cependant, il existe une sixième dimension, souvent négligée, qui joue un rôle essentiel dans la réussite d'entreprises telles que Google, Facebook et Amazon : la conception (ou Design). Les organisations qui maintiennent des services hautement fiables tout en delivrant fréquemment des nouvelles fonctionnalités veillent à ce que le SRE ait une influence directe sur la conception des services. Cette influence s'étend du code source à l'implication dans l'architecture logicielle et aux interactions quotidiennes avec les équipes de développement.

‍

‍

Un piège courant dans toute transformation est de pousser fortement ces dimensions et d'anticiper que cela améliorera intrinsèquement la fiabilité. L'approche recommandée est de commencer par la fiabilité, suivie de la conception, puis d'utiliser les autres dimensions comme leviers.

Voyons maintenant un peu plus concrètement la contribution d’un SRE à lors d’un incident majeur. A ce moment, un SRE doit analyser six moments critiques et agir en conséquence :

• Délai de détection et de notification : mettre en œuvre la détection automatique, l'alerting et la traçabilité complète en vue d'une analyse ultérieure.
• Le temps de l'affectation : veiller à ce qu'il y ait un responsable désigné clair et unique pour la gestion des incidents à tout moment
• Temps de diagnostic : réduire le temps nécessaire au diagnostic en établissant l'observabilité afin d'éviter les conjectures pendant les incidents. Veillez à ce que l'équipe qui investigue ne soit pas perturbée.
• Temps de rétablissement : accorder aux opérateurs les autorisations nécessaires pour agir rapidement, identifier toutes les actions à haut risque et se concentrer sur le rétablissement du service plutôt que sur l'identification des rootcauses.
• Le temps de la conception : déterminer les actions nécessaires pour éviter que les mêmes problèmes ne se reproduisent ou pour en minimiser l'impact. Il peut s'agir d'améliorer la surveillance, les processus, les procédures d'astreinte, ainsi que la conception fonctionnelle, technique ou logicielle.

En réalité, l'amélioration de la fiabilité est invariablement un compromis impliquant au moins trois parties prenantes : les équipes de développement, les équipes d'exploitation et le Métier. Les observations suivantes reflètent les réactions potentielles de chaque équipe après un incident :

• L’équipe de développement : propose d'améliorer la surveillance pour des réponses plus proactives, car tout automatiser peut prendre beaucoup de temps et n'est pas nécessaire pour les incidents les moins probables.
• L’équipe des opérations : demande à l'équipe de développement d'automatiser les procédures de failover. Cependant, une augmentation de la surveillance entraîne une charge de travail supplémentaire pour l'équipe d'exploitation, qui est déjà occupée.
• L’équipe DevOps (alias "You Build It, You Run It") : peut affirmer que de tels incidents sont rares et qu'il est difficile de les améliorer, et expriment leur réticence à modifier les sprints à venir.
• L’équipe Métier : exprime son mécontentement à l'égard des temps d'arrêt, en invoquant des pertes financières ou des pertes d’opportunités.

Les systèmes d'information complexes, pour lesquels la SRE est particulièrement utile, impliquent souvent plus de trois parties prenantes, dont les utilisateurs, les ingénieurs de production d'applications, les gestionnaires et les tours de contrôle. C'est pourquoi le SRE est vraiment la pierre angulaire, pour s'assurer que tous les acteurs se parlent, en même temps, autour du même service, afin de prendre ensemble les meilleures actions pour améliorer la fiabilité au bon coût, et ne pas tomber dans la facilité en ne faisant que ce qui est facile pour chaque équipe.

Un des plus grands défis consiste à savoir comment démarrer votre approche SRE. Il n'existe pas d'approche unique, mais sur la base de notre expérience en tant que consultants et professionnels SRE dans de grandes entreprises technologiques, voici les points critiques qui méritent d'être sérieusement pris en compte pour une transformation réussie :

• Définir les objectifs : avant de commencer, clarifiez vos objectifs. Pourquoi voulez-vous mettre en œuvre la SRE ? Qu'est-ce qui est important pour votre organisation et quelles sont vos attentes ?
• Définir le rôle du SRE : définissez clairement le rôle et les responsabilités du SRE. Pour les systèmes d'information complexes, cette étape est essentielle pour penser d'abord à la fiabilité, puis pour utiliser les Business SLA, l'observabilité, l'amélioration post-incident, l'automatisation, le déploiement rapide et robuste et la conception comme leviers.
• Identifier l'expertise SRE : Identifier ou recruter votre SRE initial avec de fortes compétences de communication, de l'observabilité et des compétences en matière de conception.
• Déterminer le modèle d'exploitation : le modèle d'exploitation le plus approprié est celui qui responsabilise vos SRE et leur donne le moyen de changer les choses. Ce choix dépend de votre legacy IT et de la culture d'entreprise de votre organisation. Il peut s’agit  centre d'excellence (NatWest), d'équipes de développement (Amazon, SG Markets) ou d'opérations (Google, BNP Paribas, Bank of America).

En conclusion, la mise en œuvre réussie du SRE est une mission à multiples facettes qui nécessite une approche réfléchie. Il est impératif de reconnaître que le SRE ne se limite pas à des mesures réactives face à des incidents, mais qu'il s'agit également de stratégies proactives qui couvrent de multiples dimensions.

La nature dynamique du SRE, influencée par l'évolution constante du paysage technologique, nécessite une collaboration et une communication permanentes entre les différentes parties prenantes. La capacité du SRE à rassembler ces parties autour d'un objectif commun - améliorer la fiabilité tout en gérant les coûts - est la pierre angulaire de son succès.

‍

‍