So entwickelte Domino’s UK eine SRE-Funktion und eine neue Zuverlässigkeitsstrategie

Domino’s ist ein Franchise-Unternehmen mit mehr als 1.200 Geschäften im Vereinigten Königreich und in Irland und verkauft mehr als 114 Millionen Pizzen pro Jahr. Aus technologischer Sicht stellt diese Größenordnung von Restaurants, Kund:innen und Pizzen eine riesige Herausforderung dar. Unsere Kundschaft kann die Pizza über drei verschiedene Kanäle bestellen: über die mobile App, das Web und über Online-Lieferdienste wie Just Eat. Die Franchise-Partner übernehmen dabei für mehrere Variablen selbst die Verantwortung, beispielsweise Preisänderungen oder, falls zu Spitzenzeiten notwendig, eine Einschränkung des Einzugsgebiets.

Im Rahmen unseres Phoenix-Programms zur kontinuierlichen Verbesserung und im Einklang mit unseren modernen Engineering-Prinzipien wollten wir Site Reliability Engineering (SRE) als Business Capability für den gesamten Tech-Stack etablieren. Dabei sind wir kreativ vorgegangen und haben uns von akademischen Theorien leiten lassen.

Anpassbare Architektur: Microservices

Bisher nutzen Unternehmen in der Regel eine herkömmliche Monolith-Anwendung mit einem SQL-Server im Hintergrund. Um eine Pizza zu kaufen, rufen die Kund:innen einen Webbrowser auf, und die Transaktionen erfolgen mit dem Backend. Allerdings haben wir aufgrund unserer Microservice-Architektur ein entkoppeltes Frontend, dessen Schnittstelle über eine Backend-to-Frontend-Architektur bereitgestellt wird. Eine API-Fassade dient als Schnittstelle zu einem Monolithen und wir haben eine Reihe von Microservices, die über ein API-Gateway gesteuert werden. 

Unser Wechsel von Monolith zu Microservices eröffnete uns neue Möglichkeiten zum Testen von Funktionen im Spiegelmodus – mit echtem Benutzer-Traffic, während gleichzeitig das Fehlerrisiko deutlich gesenkt und neue Standards für Leistung und Zuverlässigkeit festgelegt werden konnten. Unser Team kann eine neue Funktion jetzt testen, indem es einen Endpunkt in den Spiegelmodus versetzt und dann auf einwandfreien Betrieb hin beobachtet. Um das Feature live zu schalten, gehen wir dann nach dem Canary-Testmuster vor: Wir leiten zunächst nur 10 % des Traffic durch das aktualisierte System und erhöhen dies nach und nach bis auf 100 %.

Als wir mit der Entwicklung einer zeitgemäßen SRE-Capability begannen, wussten wir, dass sich unsere Microservice-Architektur und unser API-Gateway gut als Hauptfokus für unsere SRE-Engineers eignen würden.

„Anatomie einer Business Capability“ als SRE-Strategie

Als wir das Phoenix-Programm zur kontinuierlichen Verbesserung ins Leben riefen, wollten wir unsere wichtigsten Business Capabilities für die Incident Response als Reliability Engineering neu aufstellen. Zur Vorbereitung las ich mich in einige Paper und Abhandlungen aus der Wissenschaftscommunity über Capabilities oder Fähigkeiten an sich ein: Wie sieht die Anatomie einer generischen Business Capability aus? Was muss man bei der Implementierung einer neuen Capability in einem Unternehmen beachten?

Als Erstes nahm ich mir die Arbeiten von Dorothy Leonard-Barton vor. In Wellsprings of Knowledge spricht sie über die vier Dimensionen einer Business Capability: technische Systeme, Skills, Managementsysteme und ein Wertefundament, das für die gesamte Capability gilt. Zusätzlich las ich Dynamic Capabilities von David Teece. Dort spricht er darüber, wie eine Capability im Laufe der Zeit neu konzipiert und neu durchdacht werden kann. 

All das gab uns den Anstoß, unsere SRE-Strategie anhand der „Anatomie einer Capability“ zu konzipieren. Wir nennen dies auch die „Capability-Pizza“ – eine Pizza, die in sechs gleichgroße Stücke unterteilt ist:

1. Technische Systeme: Frontend- und Backend-Service-Domains, das API-Gateway, New Relic usw. 
2. Skills: Zuverlässigkeitsarchitektur, Problemanalyse, Distributed Tracing
3. Managementsysteme: Management und Innovation im SRE-System, Incident-Management
4. Werte: Aufmerksam, mutig, technisch, kollaborativ und empathisch, datengeleitet
5. Routinetätigkeiten: Reliability Engineering, Monitoring-Setup
6. Lernen: Fähigkeit, neue Technologien und Skills zu übertragen, Fähigkeit zum Optimieren des SRE-Systems

Zusätzlich zur Capability-Pizza verwenden wir ein rekonfigurierbares Systemmodell, um die Capability in Aktion zu zeigen. Mithilfe eines GitOps-Workflows und verschiedener Umgebungen pushen unsere Entwickler:innen die Funktion in der Produktion voran. Wir erwarten von unseren SRE-Engineers, dass sie in der Lage sind, sich ein Low-Level-Designdokument anzusehen, Zuverlässigkeitsmuster zu analysieren und dann selbst zu entscheiden, wie sie die Endpunkte so zuverlässig wie möglich gestalten können.

Proaktive Systemüberwachung und -verbesserung

SRE ist eine datengesteuerte Aufgabe mit spezifischen Zusagen, die ständig überwacht werden müssen. Unsere Engineers definieren goldene Signale für Latenz, Verkehr, Fehler und Sättigung, und für jedes goldene Signal legen wir Service-Level Objectives (SLOs) und Fehlerbudgets fest. Nehmen wir zum Beispiel die Verfügbarkeit: Wenn Sie entscheiden, dass Ihr Server zu 95 % verfügbar sein soll, haben Sie ein Fehlerbudget von 5 %. Gehen 12 Stunden lang Anfragen ein, müssen 95 % dieser Anfragen erfolgreich bearbeitet werden. Selbst wenn 3 % fehlschlagen, haben Sie 97 % Verfügbarkeit und liegen damit immer noch innerhalb Ihres Fehlerbudgets.

Mit New Relic können wir auch Synthetic Monitoring nutzen, um unsere goldenen Signale zu testen und die Customer Journeys auf der gesamten Website zu modellieren. Sehen wir uns beispielsweise unsere Einführung eines modernisierten Login-Prozesses an, denn der Anmeldevorgang zeigt perfekt den Ablauf einer Customer Journey: Dabei simulieren wir die Verfügbarkeit und prüfen, wie lange es für unsere Kund:innen dauert, den gesamten Prozess zu durchlaufen. Geht der Trend bei einem Endpunkt in die falsche Richtung, können wir eine Reaktion forcieren, die das System wieder auf Kurs bringt. Und sobald das System in der synthetischen Instanz gut genug funktioniert, können wir mit Canary-Tests beginnen, um es live zu pushen.

New Relic erleichtert unseren SRE-Fachleuten das Monitoring und Optimieren des Systems enorm. Wir nutzen Application Performance Monitoring (APM) zur Instrumentierung von Anwendungen über den gesamten Architektur-Stack, und Distributed Tracing liefert uns ein detailliertes Bild der Funktion unserer Komponenten. Mit Distributed Tracing werden Serviceanfragen auf ihrem Weg durch verteilte Systeme verfolgt und beobachtet. Dies ist für SRE-Teams wesentlich, um das Ökosystem zu verstehen.

Unser auf Capabilities ausgerichteter Ansatz für SRE und Monitoring ermöglicht es unseren Engineers, proaktiv auf Incidents zu reagieren. Zusätzlich führen wir im Vorfeld einzelner Releases Vorbereitungsmaßnahmen für den Support durch. Dabei geht die leitende Entwicklerin bzw. der Entwickler den Code gemeinsam mit dem/der SRE-Verantwortlichen durch. Und er oder sie kann dann das Servicedesk entsprechend schulen.

Mithilfe goldener Signale und Fehlerbudgets können wir das Risiko bei unseren Produktions-Releases erheblich reduzieren und unser Änderungsmanagement modernisieren. Wenn wir ein neues Feature ausrollen, tun wir dies zunächst in einer Spiegelung, bevor wir es im Canary-Testverfahren in einer Live-Umgebung einführen. Wir verwenden Fehlerbudgets, um festzustellen, ob Feature-Releases für das im Vorfeld genehmigte Standard-Änderungsmanagement geeignet sind, und können so das Engineering beschleunigen. Wurde das Fehlerbudget nicht überschritten, können die Teams so viele Standardänderungen vornehmen, wie sie möchten.

New Relic hilft uns, die Performance im Blick zu behalten und sicherzustellen, dass die Fehleranzahl im Rahmen bleibt. Geht die Fehleranzahl doch über das Budget hinaus, wird das Toolset einem langsameren herkömmlichen Änderungsmanagement unterzogen. Im Rahmen wöchentlicher Meetings gleichen unsere SRE-Manager die tatsächliche Performance der Endpunkte mit den festgelegten SLIs und SLOs ab. Geht der Trend bei einem der Endpunkte in die falsche Richtung, können wir entsprechende Maßnahmen ergreifen, um es wieder auf den richtigen Weg zu bringen.