SRE Slurm. Ein durchgehendes Experiment mit Experten von Booking.com und Google.com

Unser Team liebt Experimente. Jeder Slörm ist kein statisches Wiederholen des Vorherigen, sondern eine Reflexion der Erfahrungen und ein Übergang von Gut zu Besserem. Aber mit dem SRE Slörm haben wir uns entschieden, ein völlig neues Format anzuwenden – den Teilnehmern Bedingungen zu geben, die so nah wie möglich an "echten" sind.

Kurz gesagt, woran wir während des Intensivkurses gearbeitet haben: "Wir bauen, zerlegen, reparieren,
lernen". SRE hat kaum Wert in reiner Theorie – nur die Praxis, reale Lösungen und echte Probleme zählen.

Die Teilnehmer wurden in Teams eingeteilt, damit der lebhafte Wettbewerbsgeist niemanden einschlafen oder "Angry Birds" auf dem iPhone spielen lässt, wie es Dmitri Anatolyevich machte.

Vier Mentoren sorgten für Probleme, Bugs und Aufgaben. Ivan Kruglov, Principal Developer bei Booking.com (Niederlande). Ben Tyler, Principal Developer bei Booking.com (USA). Eduard Medvedev, CTO bei Tungsten Labs (Deutschland). Jewgeni Varavva, Allround-Entwickler bei Google (San Francisco).

Außerdem sind die Teilnehmer in Teams eingeteilt – und konkurrieren miteinander. Interessant?

Ivan, Ben, Eduard und Jewgeni blicken mit freundlich-leninistischem Schmunzeln auf die armen Teilnehmer des SRE Slörm vor Beginn des Wettbewerbs.

Also die Aufgabe:

Wir errichten eine neue Welt…

Es gibt eine Aggregator-Website für Kinotickets. Die Vorfälle werden von Mentoren in einem zuvor durchdachten Szenario entworfen (obwohl niemand eine besonders raffinierte und heimtückische Improvisation ausschließt); die Funktionsfähigkeit der Website wird durch verschiedene Metriken beschrieben. Die Probleme können vielfältig sein: Tickets für das Theater 'Moulin Rouge' laden sich nicht in die Datenbank; Film- und Theaterplakate benötigen mehr als 10 Sekunden zum Laden; die Beschreibung eines einzelnen Films bleibt hängen; 0,1 % der Bestellungen landen auf bereits reservierten Plätzen; gelegentlich fällt das Zahlungssystem für ein bis zwei Minuten aus. Und vieles, vieles mehr, was einem Teilnehmer des SRE Slurm bei seiner tatsächlichen Arbeit widerfahren kann.

Wir sind bereit, alles… und jeden zu bewältigen.

Unsere vielschichtige Website besteht aus mehreren Mikrodiensten. Ihre Aufgabe ist die Aggregation von Daten zu Vorführungen, Preisen und Verfügbarkeit von Kinos. Sie zeigt Filmankündigungen an und ermöglicht die Auswahl von Kino, Vorstellung, Saal und Platz sowie die Buchung und Bezahlung von Tickets. Insgesamt bietet sie alles, wovon ein Zuschauer nur träumen kann. Doch der Benutzer ahnt nicht, welcher titaneske Kampf um die Stabilität und Verfügbarkeit der Website im Hintergrund stattfindet.

Für die Website im intensiven Einsatz haben wir SLO-, SLI- und SLA-Kennzahlen festgelegt, die Architektur und Infrastruktur entwickelt, die Seite implementiert sowie Monitoring und Alerting eingerichtet. Und es ging los.

SLO, SLI, SLA

SLI — Service Level Indicators. SLO — Service Level Objectives. SLA — Service Level Agreements.

SLA ist ein Begriff aus der ITIL-Methodologie und bezeichnet einen formalen Vertrag zwischen dem Dienstnutzer und dem Dienstanbieter, der die Dienstleistung, die Rechte und Pflichten der Parteien sowie, das Wichtigste, den vereinbarten Qualitätsstandard für die Bereitstellung dieser Dienstleistung enthält.

SLO — das ist die Servicelevel-Objective: ein angestrebter Wert oder ein Wertebereich für den Servicelevel, der durch SLI gemessen wird. Der Normalwert für SLO ist «SLI ≤ Zielwert» oder «untere Grenze ≤ SLI ≤ obere Grenze».

SLI ist ein Servicelevel-Indicator — eine sorgfältig definierte quantitative Messung eines Aspekts des bereitgestellten Servicelevels. Für die meisten Dienste wird die Anfrageverzögerung als key SLI betrachtet — die Zeit, die benötigt wird, um eine Antwort auf eine Anfrage zurückzugeben. Weitere gängige SLIs sind die Fehlerrate, oft ausgedrückt als Anteil aller eingegangenen Anfragen, und die Systemdurchsatzrate, die normalerweise in Anfragen pro Sekunde gemessen wird.

Zuerst werden wir die Flugzeuge zum Absturz bringen, und die Frauen, die Frauen kommen danach...

Innere und äußere Faktoren begannen schon in den ersten Minuten, das SLO zu „beeinträchtigen“. Alles fiel den Administratoren auf den Kopf — sowohl Programmierfehler als auch Infrastrukturfehler, ein Ansturm von Besuchern und DDoS-Angriffe. Alles, was das SLO verschlechtert.

„- Liebe Teilnehmer, ich freue mich, euch mitteilen zu können, dass zuerst alles fällt… alles!“

Im Verlauf der Diskussion behandelten die Referenten Aspekte wie Robustheit, Fehlerbudget, Testpraktiken, Unterbrechungsmanagement und Betriebslast.

Wir sind weder Kesselwärter noch Zimmerleute...

Hier begannen die Teilnehmer zu reparieren – das Wichtigste ist, den ersten Schritt zu verstehen.

„Oh Gott, ich habe noch nie gesehen, dass das so kaputtgeht, in dieser Form und Haltung!“

Also, ein Vorfall ist geschehen. Der Zahlungsdienst ist ausgefallen. Wie geht man vor, um die Funktionsfähigkeit in kürzester Zeit wiederherzustellen?

Die Experten werfen einen liebevollen Blick auf die Teilnehmer und bereiten eine weitere Herausforderung vor.

Jedes Team organisiert die Arbeit der Gruppe zur Behebung des Vorfalls – Kollegen werden eingebunden und die Stakeholder informiert. Gleichzeitig werden Prioritäten festgelegt. So trainierten die Teilnehmer, unter Druck und in extrem begrenztem Zeitrahmen zu arbeiten.

„Was ist das für ein schrecklicher Anblick?!“

Durchatmen… und das Übung beendet.

Gemeinsam mit den Sprechern hat das Team nach jeder gelösten Problematik und temporär stabilisierten Website die Vorfälle aus der Perspektive des SRE untersucht. Es wurden die Probleme im Detail analysiert — Ursachen, Abläufe der Behebung. Danach haben sowohl im Team als auch kollektiv Entscheidungen zur weiteren Vermeidung getroffen: wie man das Monitoring verbessert, die Architektur sinnvoll verändert, den Ansatz zur Entwicklung und Betrieb korrigiert und die Richtlinien anpasst. Die Sprecher haben die Praxis der Nachbesprechung demonstriert.

„- Wer möchte noch leiden! — Ich!“

Auf der elektronischen Anzeigetafel wurden die Erfolge der Teams streng und präzise festgehalten.

Für die ersten Plätze — eine Belohnung von den Stakeholdern.

Quelle: habr.com