Skyscanner verknüpft offene Standards mit Observability

Skyscanner erblickte 2003 das Licht der Welt als Suchmaschine für Linienflüge.

Heute nutzen Monat für Monat Millionen von Menschen die App und Website des Unternehmens zur Planung ihrer Reisen. Um dem anhaltenden Wachstum gerecht zu werden, benötigte man bei Skyscanner einen umfassenden Einblick in alle Services – ihre Funktion, Wechselwirkungen und Kompatibilität mit Drittanbieterservices. Das vom Unternehmen entwickelte proprietäre Monitoring-System wurde im Laufe der Zeit immer aufwendiger zu verwalten: Zahlreiche Engineers waren ständig damit beschäftigt, separate Tools und Anbieterbeziehungen zu pflegen, und eine Korrelation zwischen dem Real-User Monitoring und dem Backend fand nicht statt. Das läutete schließlich den Beginn eines mehrjährigen Projekts ein, in dem die Daten, Anbieter und Infrastruktur von Skyscanner zentralisiert und vereinfacht werden sollten, ohne dass das Unternehmen an einen bestimmten Anbieter gebunden würde. 

Die Entscheidung für OpenTelemetry und offene Standards

Investitionen in offene Standards und berufliche Förderung der Engineers gehen bei Skyscanner Hand in Hand, da das Unternehmen vorwiegend Projekte der Cloud Native Computing Foundation (CNCF) nutzt. Nahezu alle Workloads bei Skyscanner laufen auf Kubernetes und Amazon Web Services (AWS). Durch die Implementierung offener Standards kann Skyscanner seinen Teams den Arbeitsalltag erleichtern, Einblicke in Anwendungen und Systeme erhalten und Regressionsfehler debuggen.

Bei Skyscanner wägte man wiederholt die Vor- und Nachteile einer selbst entwickelten Lösung für das Monitoring des Open-Source-Tech-Stacks mit denen einer fertig gekauften ab. Mit zunehmenden Anwenderzahlen und Datenmengen wurde klar, dass zusätzlich zu Dashboards, Alerts, Speicher und Abfragen eine Out-of-the-Box-Lösung her musste, die die notwendigen Funktionen für Analyse und Korrelation lieferte. Die zu erwartenden Einsparungen hinsichtlich Entwicklerstunden und Budget überzeugten Skyscanner schließlich, sich mit einem erfahrenen Observability-Anbieter zusammenzutun und damit wieder mehr Zeit für die eigenen Hauptgeschäftsziele zu haben. Diese Lösung sollte gemäß den Ansprüchen von Skyscanner offene Standards und OpenTelemetry (OTel) unterstützen sowie mit CNCF kompatibel sein. Und sie musste den gesamten Tech-Stack abdecken.

Offene Standards und Observability

Durch die Verknüpfung von offenen Standards und Observability erhält Skyscanner einen einzelnen korrelierten Datenstrom. Die Instrumentierung ist voll und ganz Open Source und daher anbieteragnostisch. Das bedeutete, das Skyscanner die Migration zu New Relic mit OTel nach und nach und mit minimalen Störungen für die Engineers durchführen konnte. Wenn Daten an New Relic gesendet werden, können Alerts und Dashboards dank der einheitlichen Konventionen für Tagging und Semantik rasch erstellt werden. Und wenn etwas schiefläuft, zeigen die Dashboards bis hin zur Code-Ebene, was los ist, und das relevante Team erhält sofort einen Alert. 

Die teamübergreifende Datenweiterleitung erfolgt problemlos über automatisierte Abläufe und Terraform-Definitionen – mit Terraform lässt sich Infrastruktur als Code entwickeln, sodass Definitionen schnell mit unterschiedlichen Feldern für alle Services geschrieben werden können.

„Intern könnten wir so etwas wie Terraform nicht entwickeln“, erklärt Michael Tweed, Principal Engineer bei Skyscanner. „Terraform ist so leistungsstark und mit allen Plattformen kompatibel – einschließlich des Datenversands an mehrere Ziele. Dass der Übergang zu New Relic so glatt lief, haben wir zu einem großen Teil auch Terraform zu verdanken.“

Bei der Instrumentierung eines Konzepts oder einer Bibliothek muss Skyscanner keine Codeänderungen je nach Datenziel mehr durchführen. Serviceinhaber können ohne Codeänderung zwischen Telemetrie-Backends wechseln. Das wiederum bedeutet, dass Telemetriebibliotheken und Export-Pipelines vereinfacht werden können.

„Dank der Integrationen für OTel und Terraform kamen wir rasch voran. Mit New Relic konnten wir auch Bereiche abdecken, in denen OTel noch nicht stabil genug war, wie Browser-Monitoring und Mobile Agents, und trotzdem weiter mit offenen Standards arbeiten wie der Trace-Kontext-Propagierung von diesen Benutzergeräten an Backend-Services“, fügt Daniel Gomez Blanco hinzu, Principal Software Engineer bei Skyscanner und Autor von „Practical OpenTelemetry: Adopting Open Observability Standards Across your Organization“. 

Unkompliziertes Preismodell

Die Art und Weise, wie bei Skyscanner Daten zum Reporting, Tracking und Monitoring gehandhabt werden, hat sich seither grundlegend gewandelt. Jedes Team ist für die erfassten Telemetriedaten selbst verantwortlich. Dashboards (darunter ein speziell von New Relic erstelltes Dashboard zur Nachverfolgung der Kosten) sorgen für die Bevorzugung hilfreicher Telemetriesignale und stellen die Datenerfassung grafisch dar. 

„Da die Abrechnung pro Gigabyte erfolgt, können wir die Kosten auf die Teams im Unternehmen umlegen. So wissen alle Beteiligten, wie teuer die von ihnen produzierten Telemetriedaten sind, und können fundierte Entscheidungen hinsichtlich der Rendite treffen und beispielsweise mit Signalen wie dem Distributed Tracing die eigenen Services schneller – und kostengünstiger – debuggen“, so Gomez Blanco.

New Relic zeigt Skyscanner die Kosten nach Teams, Systemen und Daten an. So können sich die Teams jederzeit über ihre Datenerfassung sowie die Produkt-Health und Servicekosten informieren. „Mit qualitativ hochwertigeren Daten erhalten Sie Einblicke zu einem günstigeren Preis“, freut sich Gomez Blanco.

Mehr als 12 separate Monitoring- und Einzellösungen konnten bei Skyscanner durch New Relic ersetzt werden. Zuvor waren 10 erfahrene Engineers allein mit der Pflege dieser Monitoring-Lösungen beschäftigt. Jetzt können sie sich auf die Förderung einer Nutzungszunahme konzentrieren anstatt nur auf die Beibehaltung des Status Quo. Die aus der Verringerung der Toolanzahl resultierenden Zeit- und Kosteneinsparungen haben die Technologie von Skyscanner enorm vorangebracht.

Branchenweit ganz vorn beim Mobile Monitoring

Tweed erzählt: „Vor New Relic haben wir Fehler und Abstürze natürlich auch nachverfolgt, aber das fand in 10 verschiedenen Teams statt, die sich über diverse Zeitzonen und Büros verteilt um das Mobile Monitoring kümmerten. Eine einheitliche Herangehensweise war so nicht möglich. Wir konnten zum Beispiel keine Performance-Vergleiche von verschiedenen Features durchführen oder Fragen zur Verfügbarkeit unterschiedlicher App-Bereiche beantworten.“ 

Skyscanner nutzte für Mobile-Abfragen benutzerdefinierten Code, der spezielles Fachwissen erforderte, sodass Data Scientists bei den Datenabfragen helfen mussten. Selbst das Hinzufügen kleinster Metrik-Datenpunkte dauerte vom Zusammenführen von Codes bis zur Erstellung von Dashboards mehrere Tage, da es von anderen internen Pipelines abhing. Und das Troubleshooting hing dann schließlich an einem zentralen Team. 

Durch die Konsolidierung von Daten und Prozessen mithilfe von New Relic konnte das New Relic Mobile SDK die Integration der Mobile-Abfragen sowie der Abfragefehler übernehmen, sodass speziell geschriebener Code überflüssig wurde. Mit der New Relic Query Language (NRQL) können Engineers große Datenmengen abfragen und interpretieren sowie sofort Dashboards erstellen, um nach Mustern zu suchen. New Relic half Skyscanner zudem bei der Durchsetzung von Konventionen und Mustern durch internen Einsatz von Abstraktionen. Alerts und Verantwortlichkeiten bei Skyscanner werden jetzt auf die verschiedenen Teams und Mitarbeiter:innen verteilt. Verursacht ein bestimmtes Feature in einer Anwendung Spikes, wird der entsprechende Alert automatisch an das relevante Team weitergeleitet.

„Wir haben vor und nach der Migration zu New Relic Umfragen durchgeführt, und all unsere Mobile-Engineers waren sich einig, dass sie unseren Monitoring-Toolsets und Features in der Produktion jetzt mehr vertrauen“, erläutert Tweed.

Alle Mobile-Teams verlassen sich inzwischen vollständig auf New Relic.

SLOs und SLIs auch für das mobile Nutzungserlebnis

Da die Engineers bei Skyscanner jetzt nicht mehr vorwiegend mit der Pflege der Monitoring-Tools beschäftigt sind, können sie die Site-Reliability-Engineering(SRE)-Prinzipien der Service-Level Objectives (SLOs) und Service-Level Indicators (SLIs) auf das mobile Nutzungserlebnis anwenden – ein in der Branche bisher fast einzigartiger Ansatz. „Wir sind damit eines der ersten Unternehmen, das dies tut, und wir sehen großes Interesse in der Branche“, so Tweed. 

Das Monitoring von SLOs war früher ein manueller Prozess. Skyscanner hatte eine interne Lösung für das Service-Level-Management, die beliebigen Mitarbeiter:innen die Festlegung von SLOs und Einrichtung von Alerts anhand bestimmter HTTP- und gRPC-Metriken erlaubte. Diese Metriken stammten von Backend-Services und trugen zum Health-Monitoring der API-Nutzung bei, aber sie berücksichtigten keine Erfolgskennzahlen für Reisende oder das Benutzererlebnis. Zusätzlich erschwert wurde das Ganze durch die Tatsache, dass diese Pipelines auf speziellen Code angewiesen waren, der nicht mit anderen Teile des Systems kompatibel war, sodass die Nichterfüllung von SLOs schwer zu ermitteln war.

Mit New Relic kann Skyscanner aus beliebigen Metriken, Events oder Telemetriedaten ein SLO erstellen, und zwar über einfache HTTP- oder gRPC-Services hinaus, um eine standardisierte SLO-Definition unabhängig davon zu erstellen, ob sie vom Frontend oder Backend stammt.

Servicedefinitionen können in Terraform integriert werden, sodass alles als Code gehandhabt wird. Und sobald SLO-Ziele als Code definiert sind, erhalten sie eine größere Bedeutung für Teams. „Wenn SLOs jetzt nicht erreicht werden, sorgen sich unsere Produktmanager:innen um das Benutzererlebnis und werden aktiv. Sie finden jetzt eher das Gleichgewicht zwischen Produkt-Health und Feature-Bereitstellung“, so Gomez Blanco. Da die SLOs jetzt auf eine einheitliche Weise dargestellt werden, können die Engineers rasch sehen, wenn sie nicht erfüllt werden und auf welches Event dies zurückgeht. „Wir haben jetzt ein einheitliches Format, das den Engineers die Lokalisierung der Problemursache erleichtert“, erklärt Tweed. 

Früher konnten Engineers in der internen Lösung nur 10 oder 11 Schwellenwerte für Reaktionszeit-SLOs wählen. Mit New Relic und NRQL konnte Skyscanner Latenz-SLOs für beliebige Schwellenwerte einrichten. Gomez Blanco sagt dazu: „Es ist so flexibel und wir wollten schon lange so etwas implementieren, aber bisher hatten wir immer technische Schwierigkeiten.“ 

Proaktiv statt reaktiv 

Gomez Blanco ist überzeugt: „Sobald Sie einem Team Daten vorsetzen, fängt es an, proaktiv zu handeln.“

Die Skyscanner-Teams nutzen New Relic zur Visualisierung der Vorgänge, um zu sehen, was in den Services vor sich geht und wie die Features in einer verteilten Umgebung funktionieren. Mit New Relic kann Skyscanner selbst festlegen, wie Performance- und Verfügbarkeitsmetriken verfolgt werden sollen – zusätzlich zu anderen Metriken, die ebenfalls für das Unternehmen von Interesse sind, wie die Zeitspanne zwischen dem ersten und dem letzten Suchergebnis, das Benutzer:innen angezeigt wird. 

Dank dieser Datenfülle konnte Skyscanner schon einige Beinahe-Zwischenfälle verhindern. Tweed dazu: „Wir handeln jetzt proaktiv, anstatt nur zu reagieren. Früher haben wir erst von Problemen erfahren, wenn sie sich schon bemerkbar gemacht hatten, und konnten sie dann erst beheben.“ Da Skyscanner jetzt nicht mehr auf einfaches Monitoring beschränkt ist, können die Mitarbeiter:innen alle wichtigen Momente der User Journey sehen und sich ein Bild des Benutzererlebnisses machen.

„In Incident-Reviews und Nachbesprechungen wird deutlich, dass diejenigen Teams, die New Relic und das Distributed Tracing zur Korrelation zwischen Services nutzen, die Ursache eines Regressionsfehlers viel schneller finden. Das heißt auch, dass ab und zu die erfahrenen Engineers gegenüber Neulingen, die sich aber mit New Relic auskennen, das Nachsehen haben, wenn es um die MTTR geht“, fügt Tweed hinzu.

New Relic ist anbieteragnostisch und führt alle Telemetriedaten (Metriken, Events, Logs, Traces) an einem zentralen Ort zusammen. Über Infrastruktur- und AWS-Integrationen, z. B. Amazon CloudFront und Kinesis Data Firehose, besteht die Möglichkeit zur Partnerschaft mit anderen Unternehmen. Durch die Instrumentierung mit New Relic konnte Skyscanner Tools und Daten standardisieren. Das führte sowohl hinsichtlich Engineering-Stunden als auch Toolbereitstellung zu Kosteneinsparungen.