So macht Skyscanner seine Engineers mit Game Days fit für Observability

Als Metasuchmaschine für die Suche nach Linienflügen, Hotels und Mietwagen sammelt Skyscanner Daten von unterschiedlichen Anbietern und Services, auf die das Unternehmen keinen Einfluss hat. Anfangs nutzte Skyscanner Runbooks zur Handhabung bestimmter Fehlermodi. Aufgrund der verteilten Infrastruktur war die Ursache bestimmter Fehler jedoch unbekannt – eine Situation, in der Runbooks weniger nützlich sind. Skyscanner brauchte mehr: einen konsolidierten Ansatz, um Fehlern dieser Art auf den Grund zu gehen, statt nur ein Muster für deren Handhabung. Durch die Einführung einer Observability-Plattform war es schnell möglich, Datasets auf verwertbare Einblicke zu analysieren und auf dieser Grundlage schnell zu ermitteln, worauf ein Fehler zurückzuführen war.

Skyscanner nutzt OpenTelemetry (OTel) und andere offene Standards im Rahmen der Open-Source-Architektur, auf die sich das Unternehmen stützt. Das OpenTelemetry Protocol (OTLP) ermöglicht es Skyscanner, den Standard-OTLP-Exporter im Collector auf New Relic zu verweisen, das OTLP nativ akzeptiert. Diese Struktur hat den Vorteil, dass ein einziger offener Standard für die Instrumentierung verwendet wird, was für zukunftssichere Betriebsabläufe sorgt, da auf anbieterspezifische Angebote verzichtet werden kann. Zusätzlich ermöglicht dies ein erweitertes Data-Sampling, was die Datenerfassung insgesamt reduzieren sowie die Zeit verkürzen kann, die nötig ist, um Incidents bzw. Fehlern auf den Grund zu gehen.

„Observability Games“ bei Skyscanner

Zur Schulung seiner Entwickler:innen setzt Skyscanner auf eine neuartige Methode: „Observability Games“, ganze Tage, an denen realistische Incidents simuliert werden. Dafür setzt das Unternehmen die offizielle OTel-Demo und New Relic als Observability-Plattform ein. An diesen Tagen können Entwickler:innen das eigenständige Bearbeiten aufkommender Incidents einüben, statt nach einem Schema vorgehen zu müssen, das vielleicht nicht passend für die jeweilige Situation ist.

Bei diesen Simulationstagen drehen Teams ein „Unglücksrad“, um im Zufallsverfahren ein Incident auszuwählen. Damit ist sicher, dass alle auf Trab bleiben: Denn echte Incidents sind ebenso unerwartet wie chaotisch. Außerdem dient dies als witziger Eisbrecher zu Beginn des Schulungstags. Der „Game Master“ (GM), der die Schulung bei Skyscanner leitet, teilt die Teilnehmer:innen in Teams ein und gibt ihnen den Auftrag, das Problem so schnell wie möglich zu identifizieren und zu beheben. 

Solche Simulationen zeigen schnell auf, welche Teams zusätzliche Schulung in der Verwendung von New Relic benötigen, denn es kann immer sein, dass manche Teams Incidents weniger optimal oder effizient lösen, da sie mit der Plattform weniger vertraut sind. So haben GMs die Möglichkeit aufzuzeigen, wie New Relic und entsprechende Tools und Ansichten am besten verwendet werden können, um das Problem schneller zu identifizieren und zu beheben. Nach jeder Runde dreht ein anderer Teilnehmer bzw. eine andere Teilnehmerin das Rad, und der Vorgang wird für den nächsten Incident wiederholt.

Idealerweise sollte es sich bei GMs um unternehmensinterne Observability-Expert:innen handeln. Sie müssen die Tools und Features vorführen können, mit denen Entwickler:innen die Variablen schneller erfassen, die sich auf spezifische Incidents auswirken. Ein Leitfaden mit „Happy Paths“ bzw. Ansätzen zur Behebung einzelner Incidents im Game Day-Handbuch hilft GMs, Teams zu den relevanten Features zu leiten, sodass sie Observability-Herausforderungen schneller und präziser beheben können. 

Während diese „Happy Paths“ einen bevorzugten Pfad darstellen, haben Teammitglieder dennoch die Möglichkeit, andere Ansätze zu entwickeln, die ebenso gut funktionieren. In den Feedback-Sitzungen kann dieses Wissen dann geteilt und allen Teams zur Verfügung gestellt werden. Das Schöne an diesem Game-Day-Ansatz ist, dass Teams im Rahmen ihrer Zusammenarbeit gelegentlich sogar bessere „Happy Paths“ aufdecken als die Observability-Experten. Es kommt sogar vor, dass dabei organisatorische Mängel im Hinblick auf die Nutzung der New Relic Features zutage treten.

Game Days zeigen neue Möglichkeiten für Fehlerbehebungstools

Ursprünglich waren Teams an Game Days weniger geneigt, die Errors Inbox und die Möglichkeit zur Korrelation von Distributed Tracing und Logs zu nutzen, die in New Relic zur Verfügung steht. Durch den Verlass auf Distributed Tracing kam es vor, dass Teams das Debugging nicht so durchführten, dass sie der Ursache auf den Grund gehen konnten.

Bei einem der Incidents im Unglücksrad am Game Day mussten alle Services gescannt werden, um festzustellen, wo Fehler vorlagen. Anschließend mussten die einzelnen Probleme eingehend geprüft werden, um ihre Ursache aufzudecken. Dieser Incident war auf Daten aus einem Produktkatalog-Servicefehler gestützt, der in der Vergangenheit aufgetreten war.

Zunächst mussten Teams alle Entities öffnen und den Service mit der höchsten Fehlerquote auswählen:

Beim Klicken auf den Service wurde die Errors Inbox angezeigt:

Dies war ein neuer Ansatz für manche Teammitglieder, die es nicht gewohnt waren, die Errors Inbox als ersten Schritt zur Fehlerdiagnose und -behebung zu verwenden. Durch eine grundlegende Analyse bis hin zur Fehlergruppe konnten Teams die Ergebnisse so filtern, dass nur solche angezeigt wurden, bei denen ein Distributed-Tracing-Fehler vorlag:

Von hier aus konnten Teams nun alle Fehler mit Distributed Traces prüfen und dann den HTTP-POST-Flow für den jeweiligen Fehler genauer ansehen:

Anhand dieser Entity Map stellten Teams fest, dass der Fehler im Frontend lag und bei GetProduct auftrat, was wiederum die betroffene Produkt-ID aufzeigte.

Zu diesem Zeitpunkt war den Teams klar, wo der Fehler ursprünglich aufgetreten war, welche Transaktion/Anfrage betroffen war (GetProduct im Produktkatalog-Service) und welche spezifische Produkt-ID zu diesem Fehler geführt hatte. Nicht klar war jedoch, ob es sich um ein generelles Problem mit dem Service handelte oder es mit dem spezifischen Produkt zu tun hatte.

Im nächsten Schritt klickten die Teams auf den Link zum Produktkatalog-Service, um die Service-Telemetriedaten einzusehen:

Abermals konnten sie hier mithilfe der Errors Inbox die betroffene Produkt-ID sehen und klickten dann auf das Fehlerprofil:

Schließlich stellten sie fest, dass der Fehler ausschließlich auf diese spezifische Produkt-ID zurückzuführen war:

Das war's!

Game Days in Ihrem Unternehmen

Observability Game Days erfordern ein gewisses Maß an Vorausplanung. Es ist wichtig, Beispiel-Incidents vorzubereiten und simulierte Dashboards mit den Daten einzurichten. Bei der Verwendung von OTLP-Standards lassen sich Daten relativ leicht aus vorherigen Incidents in ein simuliertes Dataset ziehen, um diese Beispiele zu erstellen, besonders wenn Feature-Flagging genutzt wurde. In solchen Fällen können Sie die Daten aus historischen Incidents verwenden, um die Beispiele für das Unglücksrad zu erstellen. Auf diese Weise lassen sich auch vollständige Tracing-Daten importieren, sodass Teams Probleme mithilfe einer Regressionsanalyse beheben können. Es empfiehlt sich, Incidents zu bearbeiten, die sowohl Backend- als auch Fronend-Anwendungsfälle betreffen, sodass alle Engineering-Teams vom Gelernten profitieren können.

Dazu ist es nicht nötig, ein Glücksrad zu kaufen: Jedes interaktive System zur Generierung zufälliger Zahlen belebt die Veranstaltung und hilft Ihnen, die Game-Day-Kultur zu etablieren, die für Spaß und lebhafte Mitarbeit sorgt. Es ist eine gute Idee, diesen Prozess als Eisbrecher einzusetzen, um die Einstellung der Teilnehmenden („schon wieder eine Schulung!“) zu verändern und Lust auf das aktive Einbringen zu machen.

Die Teilnehmenden bei Skyscanner fanden den spielerischen Lernansatz durchweg spannend und gaben an, dass sie anschließend besser in der Lage waren, Fehler in ihren Produktionssystemen zu beheben. Über 90 % der Befragten wünschten sich weitere Gelegenheiten, Game Days als Lernmöglichkeit für Observability zu nutzen. Das unterhaltsame und interaktive Format, der Timer-Countdown, der zur Lösung von Problemen im Team verwendet wurde, und die Gelegenheit, im Team mit anderen an einem vorgegebenen Problem zu arbeiten, half allen, besser zu werden, unabhängig davon, welche Kompetenzen sie mitbrachten.

New Relic nutzt das Feedback von Skyscanner seinerseits, um seine Produkte weiter zu verbessern. Dazu stehen die Engineers von Skyscanner im direkten Kontakt mit den Entwickler:innen bei New Relic.