En juin, nous avons eu le plaisir d'organiser notre tout premier PagerDuty Summit virtuel EMEA ! Llywelyn Griffith-Swain, responsable SRE, et David Jambor, responsable de l'ingénierie des systèmes chez Vodafone, figuraient parmi nos intervenants. Ils ont décrit l'approche de Vodafone pour parvenir à une télémétrie immuable.

David a ouvert la séance en définissant les objectifs stratégiques de Vodafone. « Notre vision est de créer une culture axée sur l'ingénierie », a-t-il expliqué. « Nous voulons donner aux équipes de développement les moyens d'être autonomes. C'est pourquoi nous les mettons au centre de tout ce que nous faisons, mais nous voulons les mettre au défi : leur code doit atteindre la production en quatre heures. »

Pour ce faire, Vodafone met en place des fonctionnalités en libre-service, permettant aux équipes de développement de définir les outils et les fonctionnalités dont elles ont besoin et la manière dont elles souhaitent les utiliser. L’objectif final est de disposer de capacités d’observation et d’alerte qui indiquent aux équipes de développement ce qui arrive au code et comment il se comporte lorsqu’il passe en production.

« Nous développons de nombreux outils autour de cela », a expliqué David. « Nous développons un véritable CI/CD continu, en mettant l'accent sur le déploiement continu qui nous permet de déplacer le code d'un sandbox vers l'environnement de production. Mais cela ne peut pas être réalisé sans une infrastructure immuable, qui nous permettra de fournir une observabilité et des alertes immuables aux équipes de développement. »

Pourquoi la télémétrie immuable est-elle importante ?

Pour expliquer comment l’observabilité immuable peut être définie, David nous a donné une excellente analogie en utilisant la Formule 1.

Imaginez que vous êtes en tête de la course et que votre pneu est crevé, ce qui vous oblige à vous arrêter au stand. Que voulez-vous que vos ingénieurs fassent : réparer ou remplacer le pneu ? Vous voulez bien sûr qu'ils le remplacent, car vous voulez reprendre la course le plus vite possible. L'immuabilité consiste à jeter ce qui est cassé et à le remplacer rapidement, au lieu de perdre du temps à essayer de le réparer.

« L'immuabilité des infrastructures informatiques signifie en réalité qu'il ne faut pas modifier les éléments qui ne fonctionnent plus. Il est beaucoup plus rapide de les remplacer par quelque chose de nouveau », explique David. « L'observabilité immuable s'appuie sur cette approche pour fournir une capacité à la demande et prête à l'emploi permettant de surveiller et d'alerter tout, de bout en bout, de manière immuable. »

Comment Vodafone permet la télémétrie immuable

L'approche immuable de la télémétrie permettrait aux équipes d'ingénierie de fiabilité du site (SRE) de développer de nouvelles approches de surveillance à la demande. Llewelyn nous a donné un exemple où trois équipes de développement utilisent toutes un moniteur de taux d'erreur de seuil.

Mais que se passe-t-il si une équipe décide de se doter d'un moniteur de taux d'erreurs de détection d'anomalies ? Au lieu de remplacer le moniteur existant et de contrarier les autres équipes, l'équipe SRE développerait le nouveau moniteur. Une fois prêt, l'équipe de développement qui l'a demandé utiliserait le nouveau moniteur, tandis que les autres continueraient à utiliser le moniteur existant.

Llewelyn a également évoqué les défis auxquels Vodafone a été confrontée dans la mise en œuvre de la télémétrie immuable. « Nous avons plus de 150 développeurs et suivons l'approche DevOps, où les développeurs doivent posséder le code, qu'il soit en production ou dans des environnements inférieurs, y compris la surveillance et les alertes ultérieures », a-t-il expliqué. « Nous devons également donner une vue immédiate de notre statut de production à toutes les parties prenantes pour permettre une visibilité sur l'ensemble du numérique. »

Il a également expliqué que la solution qu'ils construiront devra être conforme aux principes SRE de réduction des efforts. Mais comme la solution sera également destinée aux développeurs, cela signifie qu'ils devront rendre tous les modules et moniteurs disponibles sous forme de code et implémentés via un pipeline CI, ce qui permettra aux développeurs de les ajouter rapidement selon les besoins et permettra également à Vodafone de récupérer en cas d'incident.

L'équipe SRE rêvait qu'un développeur n'ait jamais à quitter le pipeline de versions pour mettre en place la surveillance et les alertes ; au lieu de cela, ils peuvent simplement appeler des modules qui ont été construits par l'équipe elle-même. Dans la pratique chez Vodafone, l'équipe SRE développe des configurations pour les moniteurs Datadog et les légendes PagerDuty , qui peuvent être appelées dans Terraform pour configurer la surveillance et les alertes. À l'avenir, si les développeurs souhaitent de nouveaux moniteurs, ceux-ci seront demandés à l'équipe SRE, qui les développera et les rendra disponibles, et les développeurs pourront ensuite les appeler via Terraform.

David a conclu la session en expliquant comment PagerDuty s'intègre dans la stratégie de SRE. « L'objectif de SRE est d'éliminer le travail pénible pour permettre de consacrer du temps à des tâches plus précieuses, comme des solutions d'ingénierie qui rendent demain un endroit meilleur. L'automatisation des tâches est vitale ici, et PagerDuty est le meilleur outil pour ce travail car il rapproche les équipes de développement de leur code et renforce la propriété.

Vous souhaitez regarder la session complète ? Inscrivez-vous dès aujourd'hui pour consultez-le à la demande (gratuitement !), ainsi que d'autres sessions clients, y compris la gestion des incidents chez Form3 et comment améliorer l'efficacité opérationnelle avec Auto Trader UK et Gousto.