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

Unser Team liebt Experimente. Jeder Slörm ist keine statische Wiederholung der vorherigen, sondern ein Verständnis der Erfahrungen und der Übergang von gut zu besser. Aber mit Slörm SRE haben wir beschlossen, ein völlig neues Format anzuwenden — den Teilnehmern Bedingungen zu geben, die möglichst nah an den "echten" sind.

Kurz gesagt, was wir während des Intensivkurses getan haben: "Wir bauen, brechen ab, reparieren,
studieren." SRE hat in reiner Theorie wenig Wert — nur Praxis, reale Lösungen, reale Probleme.

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

Probleme, Bugs, Fehler und Aufgaben wurden den Teilnehmern von vier Mentoren bereitgestellt. Ivan Kruglov, Principal Developer bei Booking.com (Niederlande). Ben Tyler, Principal Developer bei Booking.com (USA). Eduard Medvedev, CTO bei Tungsten Labs (Deutschland). Yevgeny Varavva, vielseitiger Entwickler bei Google (San Francisco).

Und die Teilnehmer sind außerdem in Teams eingeteilt — und konkurrieren miteinander. Interessant?

Ivan, Ben, Eduard und Yevgeny schauen mit einem freundlichen, leichten Schmunzeln auf die armen Teilnehmer von Slörm SRE vor Beginn des Wettbewerbs.

Also, die Aufgabe:

Wir werden, wir werden eine neue Welt aufbauen...

Es gibt eine Ticket-Aggregator-Website für Kinos. Die Incidents werden von den Mentoren in einem zuvor ausgearbeiteten Szenario erfunden (obwohl niemand ausgeklügelte und heimtückische Improvisation ausschließt), die Funktionsfähigkeit der Website wird durch verschiedene Metriken beschrieben. Die Probleme können sehr unterschiedlich sein: Tickets für das Theater "Moulin Rouge" werden nicht in die Datenbank geladen; Poster von Filmen und Aufführungen laden länger als 10 Sekunden in die Datenbank; die Beschreibung eines bestimmten Films hängt; 0,1 % der Bestellungen landen bereits auf reservierten Plätzen; gelegentlich bricht die Zahlungsabwicklung für ein bis zwei Minuten zusammen. Und vieles, vieles Unangenehme, das den Teilnehmer von Slörm SRE in seiner tatsächlichen Arbeit begegnen kann.

Wir sind bereit, mit allem... und mit allen umzugehen.

Unsere leidenschaftliche Webseite besteht aus mehreren Mikrodiensten. Ihre Aufgabe ist die Aggregation von Daten zu Vorführungen, Preisen und freien Plätzen aus allen Kinos. Sie zeigt Filmankündigungen, ermöglicht die Auswahl von Kino, Vorführung, Saal und Platz und erlaubt die Buchung sowie Bezahlung von Tickets. Kurz gesagt, alles, wovon der Zuschauer nur träumen kann. Doch der Benutzer ahnt nicht einmal, welch titanischer Kampf um die Stabilität und Verfügbarkeit der Webseite im Hintergrund stattfindet.

Für die Website im Intensivkurs haben wir SLO-, SLI- und SLA-Kennzahlen definiert, die Architektur und Infrastruktur entwickelt, die Seite bereitgestellt, das Monitoring und Alerting eingerichtet. Und es ging los.

SLO, SLI, SLA

SLI – Indikatoren für den Service-Level. SLO – Ziele für den Service-Level. SLA – Vereinbarungen über den Service-Level.

SLA ist ein Begriff aus der ITIL-Methodologie und bezeichnet einen formellen Vertrag zwischen dem Dienstleistungsempfänger und dem Dienstleistungsanbieter. Er enthält eine Beschreibung der Dienstleistung, die Rechte und Pflichten der Parteien und, das Wichtigste, das vereinbarte Qualitätsniveau der bereitgestellten Dienstleistung.

SLO ist das Ziel für den Service-Level: ein Zielwert oder ein Wertebereich für den Service-Level, der durch SLI gemessen wird. Ein normales SLO ist "SLI ≤ Sollwert" oder "untere Grenze ≤ SLI ≤ obere Grenze."

SLI ist der Indikator für den Service-Level – eine sorgfältig definierte quantitative Messgröße eines Aspekts des bereitgestellten Service-Levels. Für die meisten Dienste wird die Antwortzeit als Schlüssel-SLI betrachtet – wie lange es dauert, eine Antwort auf eine Anfrage zurückzugeben. Andere häufige SLIs umfassen die Fehlerquote, oft ausgedrückt als Anteil an allen erhaltenen Anfragen, und die Systemdurchsatzrate, die normalerweise in Anfragen pro Sekunde gemessen wird.

Zunächst werden wir die Flugzeuge zum Absturz bringen, und die Mädchen, na ja, die Mädchen kommen später dran…

Innere und äußere Faktoren begannen ab den ersten Minuten, die SLOs zu "verschlechtern". Den Administratoren prallte alles entgegen – die Fehler der Entwickler, Infrastrukturfehler, ein Ansturm von Besuchern und DDoS-Attacken. Alles, was das SLO verschlechtert.

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

Im Verlauf des Geschehens erörterten die Referenten Stabilität, Fehlerbudget, Testpraktiken, Unterbrechungsmanagement und Betriebsbelastung.

Wir sind keine Kesselwärter, keine Zimmerleute…

Hier begannen die Teilnehmer zu reparieren – das Wichtigste ist zu verstehen, womit man zuerst anfangen soll.

„- Oh Gott, ich habe noch nie gesehen, dass das so kaputtgeht, in diesem Zustand und in dieser Position!“

Es gab also einen Ausfall. Der Zahlungsabwicklungsdienst ist ausgefallen. Wie sollte man handeln, um die Funktionsfähigkeit in kürzester Zeit wiederherzustellen?

Die Experten schauten liebevoll auf die Teilnehmer und bereiteten die nächste Falle vor.

Jedes Team organisiert die Arbeit der Gruppe zur Beseitigung des Ausfalls – es werden Kollegen eingebunden, Interessierte (Stakeholder) informiert. Gleichzeitig werden Prioritäten gesetzt. So übten die Teilnehmer, unter Druck in einer sehr begrenzten Zeit zu arbeiten.

„- Was ist das für ein Horror?!“

Durchgeatmet… und die Übung beendet.

Zusammen mit den Referenten analysierten die Teams nach jeder gelösten Problematik und stabilisierten Website die Vorfälle aus der Sicht des SRE. Sie analysierten die Probleme detailliert – die Ursachen und den Ablauf der Behebung. Danach trafen sie sowohl teamweise als auch kollektiv Entscheidungen zur weiteren Vermeidung dieser Probleme: wie man das Monitoring verbessert, wie man die Architektur sinnvoll ändert, wie man den Ansatz zur Entwicklung und zum Betrieb anpasst, wie man die Regelungen korrigiert. Die Referenten zeigten die Praxis der Durchführung von Post-Mortems.

„- Wer will noch leiden? – Ich!“

Auf dem elektronischen Bildschirm wurden die Erfolge der Teams streng und klar festgehalten.

Für die ersten Plätze – eine Prämie von den Stakeholdern.

Quelle: habr.com