Au Royaume-Uni, Domino’s crée une fonction SRE et modernise ses opérations de fiabilité. Découvrez comment !

Domino’s est un réseau de franchises comptant plus de 1 200 points de vente au Royaume-Uni et en Irlande et vendant plus de 114 millions de pizzas par an. Du point de vue de la technologie, l'échelle de ce réseau de restaurants, clients et pizzas présente un défi complexe. Nos clients peuvent commander des pizzas sur trois canaux de livraisons différents : applications mobiles, web et les plateformes de livraison en ligne comme Just Eat. Les partenaires franchisés contrôlent plusieurs variables sur ces canaux, de la modification des prix à la réduction, si nécessaire, de la zone desservie lors des périodes de pointe.

Dans le cadre de notre programme d'amélioration continue Phoenix et conformément à nos principes d'ingénierie moderne, nous voulions disposer de la capacité d'ingénierie de fiabilité du site (SRE) sur tout le stack technologique. Nous avons suivi une approche unique pour le développement de cette capacité opérationnelle. En effet, nous avons adopté les théories académiques et nous les avons utilisées pour guider notre transformation.

Une architecture adaptable : les microservices

Les organisations classiques ont généralement une application monolithique standard avec un serveur SQL pour la soutenir. Les clients viennent avec leur navigateur web et effectuent des transactions sur le backend pour acheter une pizza. Cependant, notre architecture de microservices est telle que nous avons un frontend découplé qui interagit par le biais d'une architecture qui va du backend au frontend. Une API Facade interagit avec un monolithe et nous avons un ensemble de microservices qui sont dirigés par une passerelle d'API. 

Le passage du monolithe aux microservices a établi les bases pour tester les nouvelles fonctionnalités en mode miroir, en utilisant le trafic d'utilisateurs réels tout en réduisant drastiquement le risque d'erreurs et en permettant à de nouveaux standards de performances et de fiabilité d'être définis. Notre équipe peut tester de nouvelles fonctionnalités en mettant un point de terminaison en mode miroir et en l'observant pour vérifier qu'il fonctionne comme prévu. Nous avons aussi utilisé un modèle de tests du canari pour placer les nouvelles fonctionnalités en live, en commençant par un acheminement de 10 % du trafic sur le système mis à jour et en continuant jusqu'à 100 %.

Lorsque nous avons commencé à créer une capacité SRE moderne, nous savions que notre architecture de microservices et notre passerelle d'API pouvaient se prêter à être le point focal principal de nos ingénieurs SRE.

L'anatomie d'une capacité : notre approche du SRE

Lorsque nous avons lancé le programme d'améliorations continues Phoenix, nous voulions recréer nos capacités de base concernant la réponse aux incidents et les transformer en ingénierie de fiabilité. Au début de la planification de la mise en place d'une fonction SRE, j'ai passé du temps à lire les travaux de recherche et les théories des universitaires sur les capacités elles-mêmes : quelle est l'anatomie d'une capacité générique ? Qu'est-ce qui est important à mesure que vous essayez d'implémenter une nouvelle capacité dans votre organisation ?

J'ai commencé par le travail de Dorothy Leonard-Barton. Dans sa revue, Wellsprings of Knowledge, elle parle des quatre dimensions d'une capacité opérationnelle : les systèmes techniques, les compétences, les systèmes de gestion et un ensemble de valeurs qui opèrent sur l'ensemble de la capacité. J'ai également lu le travail de David Teece, dont l'article Dynamic Capabilities explore comment une capacité peut être renouvelée et réimaginée dans le temps. 

Sur la base de ces travaux, nous avons décidé d'approcher la SRE selon « l'anatomie des capacités organisationnelles ». Nous l'appelons la « capacité pizza » — une pizza divisée en 6 tranches égales :

1. Systèmes techniques : les domaines de service frontend et backend, la passerelle d'API, New Relic, etc. 
2. Compétences : architectures de fiabilité, analyse des problèmes, tracing distribué
3. Systèmes de gestion : gestion et innovation du système de SRE, gestion des incidents
4. Valeurs : conscients, audacieux, techniques, collaboratifs et empathiques, data-driven
5. Activités de routine : ingénierie de fiabilité, paramétrage du monitoring
6. Apprentissage : aptitude à transférer de nouvelles technologies et compétences et à optimiser le système SRE

Outre la capacité pizza, nous utilisons également un modèle de systèmes reconfigurables pour montrer la capacité en action. Nos développeurs utilisent un workflow GitOps et différents environnements pour faire avancer le produit jusqu'en production. Les ingénieurs SRE doivent lire un document de conception de bas niveau, analyser les schémas de fiabilité et décider de la meilleure façon de rendre les points de terminaison les plus fiables possible.

Monitoring et amélioration du système de manière proactive

La SRE est un exercice data-driven avec des engagements précis qui doivent être monitorés tout le temps. Nos ingénieurs établissent les signaux dorés pour la latence, le trafic, les erreurs et la saturation. Pour chaque signal doré, nous établissons les objectifs de niveau de service (SLO) et les bilans d'erreurs. Le taux de disponibilité est un bon exemple de cette approche : si vous décidez que votre serveur doit être disponible à 95 %, votre bilan d'erreurs est alors de 5 %. Si vous avez 12 heures de requêtes, 95 % d'entre elles doivent avoir été servies correctement ; si 3 % d'entre elles échouent, la disponibilité est de 97 % et reste dans le bilan d'erreurs.

Grâce à New Relic, nous pouvons également utiliser le monitoring synthétique pour tester nos signaux dorés et le parcours de nos clients sur le site. La mise en œuvre de notre processus de connexion modernisé est un bon exemple du parcours de l'utilisateur : nous observons la disponibilité des données synthétiques et le temps qu'il faut pour qu'un client suive tout le processus. Si un point de terminaison va dans le mauvais sens, nous pouvons orchestrer une réponse qui remettra le système sur les rails. Lorsque les performances du système sont suffisantes dans l'instance synthétique, nous pouvons commencer le test du canari en le faisant passer à la phase de production.

New Relic joue un rôle essentiel qui permet à nos ingénieurs SRE de surveiller et d'améliorer le système. Nous instrumentons les applications sur tout le stack d'architecture en utilisant le monitoring des performances des applications (APM), tandis que le tracing distribué nous apporte une image claire du fonctionnement de nos composants. Le tracing distribué suit et observe les demandes de service au fur et à mesure qu'elles passent dans les systèmes distribués. Il joue un rôle essentiel qui permet aux ingénieurs SRE de comprendre l'écosystème.

Notre approche du SRE et du monitoring axée sur les capacités permet à nos ingénieurs d'approcher la réponse aux incidents de manière proactive. Nous avons également adopté les activités de préparation à l'assistance en amont de certaines nouvelles versions. Le développeur en chef examine le code avec l'ingénieur SRE, qui peut ensuite former le chef du centre d'assistance.

Les signaux dorés et les bilans d'erreurs nous permettent de drastiquement réduire les risques avec nos nouvelles versions en production et de moderniser notre processus de gestion des changements. Lorsque nous introduisons une nouvelle fonctionnalité, nous commençons avec un miroir, puis nous utilisons le test du canari pour l'introduire dans un environnement live. Nous utilisons les bilans d'erreurs pour savoir si les nouvelles fonctionnalités peuvent utiliser un processus de gestion des changements préapprouvé afin d'accélérer la livraison de l'équipe d'ingénierie. Si elles n'ont pas dépassé leur bilan d'erreurs, les équipes peuvent effectuer autant de changements standard qu'elles le souhaitent.

New Relic nous permet de faire le suivi des performances et de nous assurer que le bilan d'erreurs n'est pas dépassé. S'il est dépassé, la fonctionnalité passe alors à un processus de gestion plus lent et plus classique. Nos responsables SRE se retrouvent alors dans des réunions d'ingénierie hebdomadaires et examinent les points de terminaison live en utilisant les SLI et les SLO. Si l'un d'entre eux va dans le mauvais sens, nous pouvons agir et les remettre sur les rails.