À ses débuts, en 2003, Skyscanner était un moteur de recherche de vols aériens.
Aujourd'hui, tous les mois, des millions de voyageuses et voyageurs comptent sur son application et son site web pour réserver leurs voyages. Pour soutenir sa croissance continue, Skyscanner avait besoin de visibilité sur tous ses services et sur les interactions interservices et avec les services tiers. L'entreprise avait développé un système de monitoring personnalisé, mais sa gestion est vite devenue compliquée. En effet, de nombreuses ressources d'ingénierie assuraient la maintenance d'outils en silo et entretenaient des relations distinctes avec les fournisseurs. En outre, le monitoring des utilisateurs réels n'était pas corrélé avec le backend. Un projet pluriannuel de centralisation et de simplification des données, des fournisseurs et de l'infrastructure de Skyscanner a alors été lancé, sans qu'il y ait de dépendance vis‑à‑vis du fournisseur.
gagnées par demande de fusion sur les pipelines de développement mobile lors de l'identification et de la résolution des goulots d'étranglement
pour définir les SLO sur tout signal télémétrique
systèmes internes et externes éliminés
Avant New Relic, nous n'avions pas vraiment permis aux ingénieurs de produire des données bien structurées, significatives et rentables. Avec New Relic, nous avons mis en place un ensemble de métriques, alertes et dashboards par défaut qui permet à notre équipe d'avoir accès à l'observabilité dès le départ.
Adoption d'OpenTelemetry et des normes open source
Pour Skyscanner, entreprise considérablement basée sur les projets de la CNCF (Cloud Native Computing Foundation), investir dans les normes open source va de pair avec un investissement dans le développement des équipes d'ingénierie. Presque tous les workloads de Skycanner s'exécutent sur Kubernetes et Amazon Web Services (AWS). L'implémentation des normes open source aide Skyscanner à réduire la charge de travail des équipes, à comprendre les applications et les systèmes, et à détecter et déboguer les régressions.
Skyscanner a très longtemps pesé le pour et le contre entre acheter une solution ou en développer une pour monitorer son stack technologique open source. Avec la croissance de l'entreprise et du volume de données, Skyscanner avait besoin des capacités d'analyse et de corrélation d'une solution prête à l'emploi en plus des dashboards et des alertes, du stockage et des requêtes, et de l'exportation et du transport. Les heures et le budget de développement qui seraient gagnés à long terme ont convaincu Skyscanner de travailler avec un prestataire d'observabilité expérimenté pour concentrer ses ressources sur les objectifs commerciaux clés. Pour Skyscanner, cette solution devait s'aligner sur son engagement vis-à-vis de l'open source et d'OpenTelemetry (OTel), s'intégrer à la CNCF et être applicable à tout le stack technique.
Normes open source et observabilité
En mariant les normes open source et l'observabilité, Skyscanner obtient désormais une seule source de données corrélées. L'instrumentation est entièrement open source, il n'y a donc aucune dépendance concernant le fournisseur choisi. Ainsi, Skyscanner peut migrer graduellement vers New Relic grâce à OTel sans que cela gêne trop les ingénieurs. Lorsque les données sont envoyées à New Relic, des alertes et des dashboards peuvent être créés rapidement grâce aux conventions de balisage et de sémantique. En cas de problème, les dashboards affichent ce qu'il se passe en descendant jusqu'au code et l'équipe concernée est alertée immédiatement.
Les données sont réparties facilement entre les équipes via des processus et des définitions Terraform automatisés : l'infrastructure en tant que code de Terraform permet d'écrire les définitions rapidement dans tous les services selon les différents domaines.
« Nous n'aurions pas pu développer une solution aussi performante que Terraform en interne. C'est une solution très puissante qui peut être utilisée sur n'importe quelle plateforme, notamment pour envoyer les données à plusieurs endroits. Terraform a joué un rôle significatif lors de cette transition fluide vers New Relic. » - Michael Tweed, Ingénieur principal, Skyscanner
Pour l'instrumentation d'un concept ou d'une bibliothèque, Skyscanner n'a pas besoin de modifier le code en fonction de l'emplacement où sont envoyées les données. Les propriétaires de service peuvent passer d'un backend télémétrique à l'autre sans changer le code, ce qui permet de simplifier les bibliothèques télémétriques et les pipelines d'exportation.
« Les intégrations avec OTel et Terraform nous ont permis d'avancer très vite. New Relic est également venu compléter les zones où OTel n'était pas encore assez stable, comme le monitoring des navigateurs et des agents mobiles tout en s'intégrant toujours aux normes open source comme la propagation du contexte des traces depuis les appareils des utilisateurs jusqu'aux services de backend. » -Daniel Gomez Blanco, Ingénieur logiciel principal Skyscanner. Auteur de Practical OpenTelemetry: Adopting Open Observability Standards Across your Organization
Modèle de tarification simple
Skyscanner a depuis transformé sa manière de traiter les données pour les rapports, le suivi et le monitoring. Les dashboards (dont un développé sur mesure par New Relic pour le monitoring des coûts) encouragent l'utilisation des bons signaux télémétriques et aident à visualiser l'ingestion.
Selon Daniel Gomez Blanco, « Le modèle de facturation de paiement par gigaoctet nous permet de répartir ces coûts sur les équipes de notre entreprise. Ainsi, toutes les parties prenantes connaissent le coût des données télémétriques qu'elles produisent. Elles peuvent prendre des décisions éclairées sur le RSI et utiliser les signaux comme le tracing distribué pour déboguer leurs services plus rapidement et à coût réduit ».
Avec New Relic, Skyscanner peut afficher les coûts par équipe, par système et par type de données. Les équipes peuvent ainsi étudier leur ingestion parallèlement à l'état de leurs produits et aux coûts de service. « Une fois la qualité des données améliorée, vous obtenez des informations exploitables à prix réduit », confie Daniel Gomez Blanco.
Skyscanner a pu remplacer plus de 12 solutions ponctuelles ou de monitoring grâce à New Relic. Auparavant, 10 ingénieurs expérimentés travaillaient uniquement sur la maintenance de ces solutions de monitoring. Aujourd'hui, ils peuvent se concentrer sur l'accélération de l'adoption de la nouvelle solution plutôt que sur sa maintenance. Le temps et les coûts économisés grâce à la réduction des outils ont permis à la technologie de Skyscanner d'exceller.
Regardez la vidéo de Daniel Gomez Blanco, ingénieur logiciel principal, où il explique pourquoi Skyscanner a décidé de consolider ses outils avec New Relic.
Solutions mobiles à la tête du secteur
« Avant New Relic, nous faisions le suivi des erreurs et des pannes, mais nous l'abordions de façon très éparpillée. Nous avions 10 équipes travaillant sur les services mobiles, réparties dans différents fuseaux horaires et bureaux. Il nous manquait une façon cohérente de le faire. Nous ne pouvions pas répondre aux questions sur le comportement des fonctions les unes par rapport aux autres ou sur la disponibilité de différentes sections de l'application. » -Michael Tweed, Ingénieur principal, Skyscanner
Skyscanner utilisait un code personnalisé pour les requêtes mobiles qui demandait certaines connaissances. En effet, les spécialistes en données devaient aider à l'interrogation des données. L'ajout de petits points de métriques prenaient des jours, de la fusion des codes à la création des dashboards, car il s'appuyait sur d'autres pipelines internes. Ensuite, une seule équipe centrale devait gérer le dépannage.
En consolidant les données et les processus avec New Relic, le SDK mobile de New Relic a pris en charge les requêtes mobiles et l'intégration des erreurs de requêtes mobiles. Le code personnalisé est alors devenu redondant. New Relic Query Language (NRQL) aide les ingénieurs à interroger les grands volumes de données pour les comprendre. Il crée instantanément des dashboards pour détecter des schémas. New Relic a également aidé Skyscanner à appliquer des conventions et des schémas en utilisant des abstractions en interne. Maintenant, Skyscanner peut en toute confiance répartir les alertes et les responsabilités entre les différentes équipes et ce jusqu'au niveau de chaque membre. Si une fonction donnée dans une application engendre des pics, cette alerte est acheminée automatiquement à l'équipe concernée.
« Nous avons réalisé des études avant et après la migration vers New Relic. Tous les ingénieurs des services mobiles ont indiqué avoir plus confiance en nos capacités de monitoring et nos fonctions en cours de production », explique Michael Tweed.
New Relic a maintenant été adopté et couvre toutes les équipes des services mobiles de Skyscanner.
Application des principes SLO et SLI au mobile
Comme Skyscanner n'a plus besoin de bloquer des ressources d'ingénierie sur la maintenance du stack de monitoring et des outils, l'entreprise a désormais le temps d'appliquer les principes d'ingénierie de la fiabilité des sites (SRE) des objectifs de niveau de service (SLO) et des indicateurs de niveau de service (SLI) pour le mobile, ce qui constitue une innovation révolutionnaire dans ce secteur. « Nous sommes l'une des premières entreprises à le faire et notre approche intéresse beaucoup de gens », précise Michael Tweed.
Auparavant, le monitoring des SLO se faisait manuellement. Skyscanner avait une solution de gestion des niveaux de service interne qui permettait à n'importe qui de définir les SLO et de recevoir des alertes sur certaines métriques HTTP et gRPC. Ces métriques provenaient des services backend et aidaient à surveiller l'état de l'utilisation de l'API, mais ne se concentraient pas sur les métriques de succès des voyageurs et voyageuses ni sur l'expérience utilisateur. Pour compliquer encore plus les choses, cet ensemble de pipelines était maintenu avec du code personnalisé qui n'était pas intégré à différentes parties du système. Il était donc difficile d'identifier le SLO endommagé.
Avec New Relic, Skyscanner peut créer un SLO à partir de n'importe quels événements, métriques ou données télémétriques, bien au-delà des simples services HTTP ou gRPC pour créer une définition de SLO normalisée, que le SLO vienne du frontend ou du backend.
Les définitions de service peuvent être intégrées avec Terraform pour tout gérer comme du code. Lorsque les cibles SLO sont définies en tant que code, les équipes y font attention. « Lorsque les SLO sont ne sont pas respectés, les responsables produits se soucient de l'expérience utilisateur et réagissent. Cela les aide à trouver un équilibre entre la santé du produit et la distribution des fonctionnalités ». Avec la présentation des SLO de manière unifiée et uniformisée, les ingénieurs voient la faille et son rapport instantané avec les événements. « C'est un format standard qui permet aux ingénieurs de rechercher et de voir où cela se passe », précise Michael Tweed.
Auparavant, avec la solution interne, les ingénieurs ne pouvaient choisir que 10 ou 11 seuils pour les SLO. Avec New Relic et NRQL, Skyscanner a configuré des SLO pour la latence qui permettent des seuils de n'importe quelle valeur. « Le système est extrêmement flexible et c'est ce que nous recherchions depuis toujours, mais nous avons dû faire face à des défis techniques », explique Daniel Gomez Blanco.
Mes équipes ne sont pas déconnectées ni noyées sous la complexité de nos services, alertes, logs ou données. Notre plateforme d'intégration fournit une vue claire, ce qui permet l'identification et la résolution des problèmes avant qu'ils n'impactent notre clientèle. C'est ce qui est le plus important.
De la réactivité à la proactivité
« Dès que vous mettez des données sous les yeux des équipes, elles deviennent proactives », constate Daniel Gomez Blanco.
Les équipes Skyscanner utilisent New Relic pour visualiser ce qui se passe, ce que font les services et les performances des fonctionnalités dans un environnement distribué. Avec New Relic, Skyscanner peut définir comment faire le suivi des métriques de disponibilité et de performances, en plus des métriques qui intéressent l'entreprise, comme le temps que prend un utilisateur pour voir le premier et le dernier résultats d'une recherche.
Avec toutes ces données disponibles, Skyscanner a évité de nombreux incidents. « Nous sommes devenus proactifs au lieu d'être réactifs. Auparavant, nous apprenions qu'un problème était arrivé et nous devions le corriger, » confie Michael Tweed. En allant au-delà du simple monitoring et des pannes d'application, Skyscanner peut afficher les moments clés du parcours de l'utilisateur et examiner l'expérience client.
« D'après les appels d'incident et les analyses rétrospectives, nous avons pu constater que les équipes qui utilisent New Relic et la corrélation entre services via le tracing distribué peuvent trouver plus rapidement la cause profonde d'une régression. Parfois, l'ingénieur le plus expérimenté arrivera derrière un ingénieur débutant qui sait utiliser New Relic en termes de MTTR », indique Daniel Gomez Blanco.
New Relic évite l'enfermement propriétaire et combine toutes les données télémétriques (métriques, événements, logs et traces) dans un seul et même endroit. La plateforme offre également la possibilité de fonctionner avec d'autres organisations via des intégrations d'infrastructure et AWS, notamment Amazon CloudFront et Kinesis Data Firehose. En instrumentant New Relic, Skyscanner a rationalisé ses outils et ses données et a fait des économies au niveau des heures d'ingénierie et de la mise en service des outils.
Visitez la page de nos clients pour en savoir plus sur la manière dont nos clients utilisent New Relic.
