DAZN macht auch sein Release-Deployment zum absoluten Highlight

In punkto Tech-Stack agieren in Start-ups häufig mehrere Engineering-Teams mit unterschiedlichen Technologien und Features und teils separat ausgerichteten Zielvorgaben. So waren auch bei DAZN die entsprechende Konsolidierung und Standardisierung eine der Herausforderungen schlechthin für Craig Mclean, Head of SRE der globalen Streaming-Plattform. Erschwerend kam dabei zudem hinzu, dass nach dem Unternehmenscredo alle Teams jeweils eigene Product- und Monitoring-Tools nach ihrem Gusto implementieren konnten. Entstanden war in der Folge also gewissermaßen das Modell einer „umgedrehten Pyramide“, bei der sich die Komplexität des Tech-Stacks durch alle Stufen von unten nach oben fortlaufend intensiviert.

Wie diese Problematik adressiert werden konnte – noch dazu mit fantastischen Ergebnissen – verriet Mclean jüngst in unserer Observability-Expertenrunde (Video on demand verfügbar). Maßgeblich dafür: konsequentes Testing und präzise retrospektive Analysen. Das Resultat: nicht weniger als 5.000 Live-Releases täglich.

„Hinfallen. Zurückschauen. Nochmal machen.“

Auch über Entwicklerkreise hinaus kein Geheimnis: Überall dort, wo Software geschrieben, betrieben und ausgerollt wird, ist auch der Fehler quasi vorprogrammiert. Die Kunst ist es vielmehr, genau diesen Umstand vorausschauend mit einzukalkulieren, daraus zu lernen und ihn schließlich in Innovation umzumünzen.

„Bleibt man passiv, obwohl etwas nicht rund lief, gerät man das nächste Mal wieder in genau dieselbe Situation“, fasst Mclean hier treffend zusammen. „Setzt man aber an der Frage an, warum es nicht rund lief, ist man beim agilen Prinzip: Der nächste Versuch ist immer besser als der vorherige. Und dafür ganz zentral sind Retrospektiven.“

Hierzu dokumentieren Mclean und sein Team über ein standardisiertes System sämtliche Ereignisse und Fakten, um klar zuordnen zu können, was gut funktioniert hat und wo es hakte. Ohne Schuldzuweisungen, versteht sich: „Positive Punkte zu bestärken ist für uns ebenso wichtig wie eine schonungslose Analyse negativer Aspekte, damit diese nicht zu noch größeren Problemen auswachsen“, erklärt Mclean.

„Ausnahmslos alles, für das ein Fix vonnöten ist, halten wir in einem Ticket fest und lernen daraus. Ganz so wie bei Scrum, bei dem auf jeden Sprint eine Retrospektive folgt. Mit dieser festen Integration in unsere Abläufe verbessert sich alles mit jedem Tag ein klein wenig mehr. Erst das hat uns dorthin gebracht, wo wir heute stehen. Denn damit angefangen haben auch wir quasi bei null. Das zwar als gute Entwickler, keine Frage. Aber eben noch nicht so gut, wie wir es dadurch geworden sind.“

Der Weg zu 5.000 Live-Releases am Tag

„Wichtig zu verstehen ist, dass hinter 10 Releases letztlich die gleiche Problematik steht wie hinter 100 oder 1.000“, so Mclean. „Und dass sie sich nicht von heute auf morgen löst. Auch bei uns nicht. Gebraucht hat es dafür konsequente Kleinarbeit über mehrere Jahre.“ 

„Angegangen sind wir das ganz klassisch: Hat man ein großes Problem, sieht man am besten zu, wie man es in leichter überschaubare Teilaspekte herunterbrechen kann. Hierfür ideal sind Microservices.“

Mit ihrer Hilfe lassen sich auch Vorbehalte adressieren, die Live-Releases mit sich bringen könnten. Dazu rät Mclean, für den Einstieg einen Service zu wählen, bei dem die Auswirkungen eines Ausfalls zwar ein geringes Ausmaß haben, aber durchaus wahrgenommen werden können: „So kann man relativ bedenkenlos Verschiedenes austesten. Zudem sollte sich ja zunächst alles in der Test- oder Staging-Umgebung abspielen. Und selbst wenn nicht, gibt es noch immer die Dev-Umgebung. Getreu dem Prinzip Trial and Error tastet man sich dann immer weiter bis zur Produktion voran und gewinnt so auch Vertrauen in das Release-Konzept.“

Einen wichtigen Puzzlestein bilden dabei Metrics, die das Team gestützt auf Observability-Technologie über seinen gesamten Tech-Stack hinweg erfasst und auswertet. Denn erst damit kann es Performance-Probleme vom Konzept bis zur Ticket-Auslieferung in sämtlichen Phasen punktgenau isolieren.

„Auch Reisen über tausende Kilometer starten mit dem ersten Schritt. Der ist einfach immer der entscheidende, man muss einfach anfangen. Und auf ihm aufbauend kann man dann peu à peu Policies und Best Practices definieren. Auch neue Ideen entstehen dann quasi unterwegs. Zudem wird die Mentalität der Entwickler gestärkt. Sie sind in der Lage, bei einem kleinen Problem einfach einen zugehörigen Bericht aufzusetzen und dann mit Tagging einen Auto-Release auszulösen.“

„Wer entwickelt, gewinnt. Man muss es einfach nur angehen. Observability liefert dann die passenden goldenen Signale: Sättigung, Fehler- und Latenzraten und so einige mehr. Dass sie gemessen werden, ist wichtig. Aber bevor das geht, muss erstmal der Anfang gemacht werden.“ 

Probieren geht über Sinnieren

„Wie sich ein Service unter Druck verhält, weiß man natürlich auch erst, wenn so eine Drucksituation entsteht“, so Mclean weiter. „Ohne Stresstest also keine Stressinfo.“

„Dafür muss ich meinen Login-Bildschirm eben auch mit Kundendaten in allen möglichen Variationen beharken, zum Beispiel auch mit Sonderzeichen und mit Passwörtern. Genau das ist eine Kombination, bei der leicht Probleme auftreten können: Irgendwo finden sich in einem Passwort Sonderzeichen, die aber von einem Backend-System entfernt werden. Und schon stimmt das in der Datenbank gespeicherte Passwort gar nicht mehr mit dem überein, das wir eigentlich festgelegt hatten.“

„Manchmal verursacht auch allein die Traffic-Menge gewaltige Probleme. Was passiert, wenn 10 Millionen Besucher gleichzeitig regelrecht auf eine Website einprasseln? Das sollte man lieber vorab wissen, statt einfach auf ein Live-Szenario zu warten und zu hoffen.“

Um sich zu vergewissern, dass auch Millionen gleichzeitige Nutzer:innen kein Problem sind, hat DAZN Load-Tests für seine Komponenten durchgeführt. Auch für die Frage, wie für weitere Millionen skaliert werden kann, hat man sich vorbereitet.

„Wenn man seine Stresstests mit Observability kombiniert, wird nicht nur klar ersichtlich, wann das System Probleme bekommt, sondern auch genau, wo. So kann man sich der Fehlerursache ganz gezielt annehmen.“