Unser Team liebt Experimente. Jeder Slurm ist keine statische Wiederholung der vorherigen, sondern eine Reflexion der Erfahrung und ein Übergang vom Guten zum Besseren. Aber mit Wir haben uns entschieden, ein völlig neues Format anzuwenden – um den Teilnehmern Bedingungen zu bieten, die dem „Kampf“ so nahe wie möglich kommen.
Wenn wir kurz skizzieren, was wir im Intensivkurs gemacht haben: „Wir bauen, wir brechen, wir reparieren,
wir studieren." SRE ist in der bloßen Theorie wenig wert – nur Praxis, echte Lösungen, echte Probleme.
Die Teilnehmer wurden in Teams eingeteilt, damit aufgrund des starken Wettbewerbsgeistes niemand einschlafen oder „Angry Birds“ auf dem iPhone starten konnte, ganz nach dem Vorbild von Dmitri Anatoljewitsch.
Probleme, Störungen, Bugs und Aufgaben wurden den Teilnehmern von vier Mentoren zur Verfügung gestellt. Ivan Kruglov, Hauptentwickler bei Booking.com (Niederlande). Ben Tyler, Hauptentwickler bei Booking.com (USA). Eduard Medvedev, CTO bei Tungsten Labs (Deutschland). Evgeniy Varavva, Generalentwickler bei Google (San Francisco).
Darüber hinaus werden die Teilnehmer in Teams eingeteilt und treten gegeneinander an. Interessant?
Ivan, Ben, Eduard und Evgeniy blicken vor Beginn des Wettbewerbs mit freundlichen leninistischen Blicken auf die armen Slurm SRE-Teilnehmer.
Also die Aufgabe:
Wir gehören uns, wir werden eine neue Welt bauen ...
Es gibt eine Website zum Aggregator von Kinokarten. Vorfälle werden von Mentoren in einem vorgefertigten Szenario erfunden (wobei niemand besonders raffinierte und heimtückische Improvisationen ausschließt), die Leistung der Website wird durch verschiedene Metriken beschrieben. Die Probleme können sehr unterschiedlich sein: Tickets für das Moulin Rouge-Theater werden nicht in die Datenbank geladen; Plakate von Filmen und Performances werden in mehr als 10 Sekunden in die Datenbank geladen; die Beschreibung eines einzelnen Films friert ein; 0,1 % der Bestellungen sind bereits reserviert; Von Zeit zu Zeit stürzt das Zahlungsabwicklungssystem für ein oder zwei Minuten ab. Und viele, viele, viele unangenehme Dinge, die einem Slurm SRE-Teilnehmer an seinem eigentlichen Arbeitsplatz widerfahren können.
Wir sind bereit, mit allem und jedem fertig zu werden.
Unsere leidgeprüfte Website besteht aus mehreren Microservices. Seine Aufgabe besteht darin, Daten zu Vorstellungen, Preisen und verfügbaren Plätzen aller Kinos zu sammeln; es zeigt Filmankündigungen an, ermöglicht die Auswahl eines Kinos, einer Vorstellung, eines Saals und eines Ortes sowie die Buchung und Bezahlung von Eintrittskarten. Im Allgemeinen alles, wovon der Betrachter nur träumen kann. Aber der Benutzer ahnt nicht einmal, welch gigantischer Kampf um die Stabilität und Zugänglichkeit der Website im Inneren stattfindet.
Für den Intensivstandort haben wir SLO-, SLI- und SLA-Indikatoren generiert, Architektur und Infrastruktur entwickelt, den Standort bereitgestellt sowie Überwachung und Alarmierung eingerichtet. Und weg gehen wir.
SLO, SLI, SLA
SLI – Service-Level-Indikatoren. SLOs sind Service-Level-Ziele. SLA – Service Level Agreements.
SLA ist ein Begriff aus der ITIL-Methodik, der eine formelle Vereinbarung zwischen dem Kunden einer Dienstleistung und ihrem Lieferanten bezeichnet, die eine Beschreibung der Dienstleistung, die Rechte und Pflichten der Parteien und vor allem das vereinbarte Qualitätsniveau für die Bereitstellung dieser Dienstleistung enthält Service.
Ein SLO ist ein Service-Level-Ziel: ein Zielwert oder Wertebereich für einen Service-Level, der durch den SLI gemessen wird. Ein normaler Wert für SLO ist „SLI ≤ Ziel“ oder „Untergrenze ≤ SLI ≤ Obergrenze“.
Der SLI ist ein Service-Level-Indikator – ein sorgfältig definiertes quantitatives Maß für einen Aspekt des bereitgestellten Service-Levels. Bei den meisten Diensten gilt die Anforderungslatenz als entscheidender SLI – die Zeit, die es dauert, bis eine Antwort auf eine Anforderung zurückgegeben wird. Weitere gängige SLIs sind die Fehlerrate, die oft als Bruchteil aller empfangenen Anfragen ausgedrückt wird, und der Systemdurchsatz, der üblicherweise in Anfragen pro Sekunde gemessen wird.
Zuerst werden wir die Flugzeuge zerstören, dann die Mädchen und dann die Mädchen ...
Interne und externe Faktoren begannen SLO von den ersten Minuten an zu „verderben“. Den Administratoren fiel alles auf den Kopf: Fehler der Entwickler, Ausfälle der Infrastruktur, ein Zustrom von Besuchern und DDoS-Angriffe. Alles, was SLO verschlechtert.
„- Liebe Teilnehmer, ich beeile mich, Ihnen zu gefallen, das erste, woran Sie scheitern, ist... alles!“
Unterwegs diskutierten die Referenten Stabilität, Fehlerbudget, Testpraxis, Management von Unterbrechungen und Betriebsbelastung.
Wir sind keine Heizer, keine Zimmerleute ...
Dann begannen die Teilnehmer, Dinge zu reparieren – die Hauptsache ist, zu verstehen, was sie zuerst greifen sollten.
„- Herr, ich habe es noch nie so, in dieser Form und in dieser Position brechen sehen!“
Es kam also zu einem Unfall. Der Zahlungsabwicklungsdienst ist ausgefallen. Wie kann man vorgehen, um die Funktionsfähigkeit in kürzester Zeit wiederherzustellen?
Mit einem liebevollen Blick auf die Teilnehmer bereiten die Experten einen weiteren Trick vor.
Jedes Team organisiert die Arbeit der Gruppe zur Beseitigung des Unfalls – bindet Kollegen ein, benachrichtigt interessierte Parteien (Stakeholder). Gleichzeitig werden Prioritäten gesetzt. Auf diese Weise wurden die Teilnehmer darauf trainiert, unter äußerst begrenzten zeitlichen Bedingungen unter Druck zu arbeiten.
„Was für ein Horror ist da herausgekommen?!“
Atmen Sie aus... und beenden Sie die Übung
Nachdem jedes Problem gelöst und der Standort vorübergehend stabilisiert worden war, untersuchte das Team gemeinsam mit den Referenten die Vorfälle aus SRE-Sicht. Wir haben die Probleme im Detail analysiert – die Ursachen des Auftretens, den Fortschritt der Beseitigung. Danach haben wir sowohl im Team als auch gemeinsam Entscheidungen darüber getroffen, wie wir sie weiter verhindern können: wie wir die Überwachung verbessern, wie wir die Architektur sinnvoll ändern, wie wir den Ansatz für Entwicklung und Betrieb anpassen und wie wir Vorschriften korrigieren. Die Referenten demonstrierten die Praxis der Obduktion.
„Wer will noch quälen! - ICH!"
Die Erfolge der Mannschaften wurden streng und übersichtlich auf der elektronischen Anzeigetafel erfasst.
Für erste Plätze – ein Bonus von Stakeholdern.
Source: habr.com