Tout comme de nombreuses autres startups, DAZN compte plusieurs équipes d'ingénieurs et divers produits, fonctionnalités et objectifs. Le défi pour le directeur des SRE, Craig Mclean, est de consolider et normaliser le stack technologique. Le « modèle en pyramide inversée » de l'entreprise, dans lequel chaque équipe peut choisir son produit et ses outils de monitoring, vient ajouter une couche supplémentaire à toute cette complexité.
Lors d'un récent panel sur l'observabilité, désormais disponible à la demande, Craig Mclean a partagé quelques conseils sur les tests, la rétrospection et les plus de 5 000 diffusions en direct par jour.
DAZN est une plateforme d'abonnement sur les sports avec, en plus de la programmation d'origine, des diffusions en direct et à la demande. Lancé en 2016, DAZN est aujourd'hui une entreprise de plusieurs milliards de dollars comptant des millions de clients dans le monde.
« Nous prenons tout ce qui échoue et nous l'analysons. »
Quiconque code, exploite et déploie des logiciels sait qu'à un moment ou à un autre quelque chose va planter. Mais si l'on intègre cet échec dans le processus et que l'on en tire les leçons, on a alors la clé de l'innovation.
« Si vous enchaînez les échecs, vous ne les dépassez pas. Par contre, si vous subissez un échec et que vous en tirez les leçons, alors vous devenez agile. Vous reconnaissez simplement qu'il y a une meilleure façon de faire. Et les rétrospections sont une clé permettant d'y arriver. » -Craig Mclead
DAZN dispose d'un flux de documentation standard qui capture objectivement les événements et les faits afin d'identifier ceux qui se sont bien passés et ceux qui auraient pu mieux se dérouler. Selon Craig Mclean : « Il est important de renforcer les bons comportements, car c'est ainsi que l'on éloigne les mauvais comportements et les pires. »
« Nous créons un ticket pour tout ce qui doit être réparé et nous apprenons beaucoup. C'est essentiellement de la même façon que nous gérons scrum, où à la fin de chaque sprint, nous faisons une rétrospection. C'est une amélioration quotidienne et c'est comme ça que nous sommes arrivés jusqu'ici. Nous n'avons pas débuté en tant qu'experts. Nous avons débuté en tant qu'ingénieurs raisonnablement bons… mais nous nous sommes améliorés à chaque fois. » -Craig Mclean
Le parcours suivi pour arriver jusqu'à 5 000 diffusions en direct par jour
« 10, 100, 1000, c'est toujours le même problème. Je ne suis pas arrivé à DAZN avec ma baguette magique et « abracadabra ! » tout s'est mis en place. Il a fallu des années. »
« Comme avec tout gros problème, il faut savoir le diviser en morceaux gérables. C'est ici que les microservices aident. » -Craig Mclean
Le conseil de Craig Mclean pour vaincre la peur des diffusions en direct est de choisir un petit service dont l'impact est réduit, mais dont la visibilité touche toute l'activité. « Ce n'est pas grave si vous le cassez parce que vous avez un environnement de test — enfin je l'espère, ou au moins un environnement de simulation — où vous pouvez le tester et le casser et le faire avancer sur tout le cycle de vie jusqu'à la production. Et ensuite, vous êtes plus à l'aise quand il faut le publier. »
DAZN mesure les métriques sur tout son stack technologique — en intégrant l'observabilité pour afficher les problèmes de performance, de la conceptualisation jusqu'aux heures d'envoi des tickets —mais la société n'a pas commencé comme ça.
« Un périple de plusieurs millions de kilomètres commence par le premier pas. Et c'est à vous de faire ce premier pas. Il faut s'y habituer. Vous devez développer des politiques, des pratiques et des idées, et développer la mentalité chez les développeurs que "ce n'est qu'une petite étape, je peux sortir un communiqué de presse pour ça et il sera automatiquement publié dès que je le tague." »
« Si vous voulez le développer, il vous suffit d'essayer de le faire. Et si vous allez l'observer, ne vous inquiétez pas de l'outillage énorme qui rend l'observabilité possible, inquiétez-vous plutôt de vos signaux dorés. Inquiétez-vous aussi de la saturation, du taux d'erreur, du taux de latence, de tout ce genre de choses. Mesurez tout cela. Parce que c'est là que vous commencez. Il faut bien que vous commenciez quelque part. »
« Nous créons un ticket pour tout ce qui doit être réparé et nous apprenons beaucoup. C'est essentiellement de la même façon que nous gérons scrum, où à la fin de chaque sprint, nous faisons une rétrospection. »
Tester pour exister
Selon Craig Mclean, il est également important de générer des situations de contrainte pour savoir comment réagira votre service. « Si le système n'est pas testé, il ne vaut rien »
« Que se passe-t-il si j'envoie des données au hasard à l'écran de connexion ? Et si je mets des caractères spéciaux dans les infos de connexion ? Ou dans les mots de passe ? J'ai vu les mots de passe échouer plus d'une fois à cause des caractères spéciaux qu'ils contenaient : certains systèmes backend éliminent ces caractères ce qui fait que le mot de passe stocké dans la base de données ne correspond pas à celui qui a été saisi. »
« D'autres fois, c'est tout simplement le volume considérable de trafic. Savez-vous ce qui va se passer si vous avez 10 millions d'utilisateurs en même temps sur votre site ? »
DAZN a réalisé des tests de charge sur ses composants pour être sûr que le site peut accepter des millions d'utilisateurs en même temps et qu'il sait aussi ce qu'il faut faire pour passer au million suivant.
« Quand on combine les tests de contrainte quels qu'ils soient avec l'observabilité, on arrive non seulement à faire planter le système, mais on voit aussi exactement où le plantage a eu lieu et on peut y aller directement et résoudre le problème. »
- Regardez Craig Mclean dans le panel sur l'observabilité et pourquoi elle est essentielle à la mission des équipes DevOps et SRE extrêmement performantes (en anglais).
-
La seule constante est le changement. Combien faut-il d'ingénieurs SRE pour définir l'observabilité ? Tous. Et ils n'arriveront quand même pas à se mettre d'accord. Manifeste de l’observabilité 2021.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
