SRE av Slurm. Ett kontinuerligt experiment med experter från Booking.com och Google.com

Vårt team älskar att experimentera. Varje Slörm är inte en statisk upprepning av det förflutna, utan en reflektion över erfarenheter och en övergång från det goda till det bästa. Men med Slörm SRE har vi beslutat att tillämpa ett helt nytt format — att ge deltagarna förhållanden som är så nära "strids"-förhållanden som möjligt.

För att kort sammanfatta vad vi sysselsatte oss med under intensiven: "Vi bygger, förstör, lagar,
studerar". SRE betyder lite i ren teori — endast praktik, verkliga lösningar, verkliga problem.

Deltagarna delades in i lag för att den livliga tävlingsandan inte skulle få någon att somna eller spela "Angry Birds" på iPhone, som Dmitrij Anatoljevitj gjorde.

Problem, buggar och uppgifter hanterades av fyra mentorer. Ivan Kruglov, Principal Developer på Booking.com (Nederländerna). Ben Tyler, Principal Developer på Booking.com (USA). Eduard Medvedev, CTO på Tungsten Labs (Tyskland). Jevgenij Varavva, utvecklare med bred profil på Google (San Francisco).

Och dessutom var deltagarna indelade i lag — och tävlade mot varandra. Intressant?

Ivan, Ben, Eduard och Jevgenij ser på de stackars deltagarna av Slörm SRE med vänlig, men skeptisk blick innan tävlingen börjar.

Så uppgiften:

Vi ska bygga vår, vår nya värld…

Det finns en webbplats som aggregerar biobiljetter. Incidenter skapas av mentorer utifrån ett noggrant utarbetat manus (även om ingen utesluter särskilt finurlig och slug improvisation), och webbplatsens funktionalitet beskrivs med olika mätvärden. Problematiken kan vara av olika slag: biljetter till teatrar som "Moulin Rouge" laddas inte upp i databasen; affischer för filmer och föreställningar laddas upp i databasen på mer än 10 sekunder; beskrivningen av en specifik film hänger; 0,1% av beställningarna hamnar på redan reserverade platser; betalningshanteringssystemet kan ibland falla bort i ett par minuter. Och mycket, mycket, mycket obehagligt som kan drabba deltagaren av Slörm SRE i sitt verkliga arbete.

Vi är redo att hantera allt… och alla.

Vår kämpande webbplats består av flera mikrotjänster. Den har som uppgift att aggregera data om filmer, priser och lediga platser från alla biografer; den visar filmtrailers, låter användaren välja bio, föreställning, salong och plats, samt att boka och betala biljetter. Kort sagt, allt vad en åskådare kan drömma om. Men användaren har ingen aning om den titanska kampen för webbplatsens stabilitet och tillgänglighet som pågår bakom kulisserna.

För webbplatsen under intensiven har vi formulerat SLO-, SLI- och SLA-mått, utvecklat arkitektur och infrastruktur, distribuerat webbplatsen, ställt in övervakning och alerting. Och så var vi igång.

SLO, SLI, SLA

SLI är indikatorer för servicenivå. SLO är servicenivåmål. SLA är serviceavtal.

SLA är en term inom ITIL-metodologin som betecknar ett formellt avtal mellan tjänstekunden och dess leverantör, vilket innehåller en beskrivning av tjänsten, rättigheter och skyldigheter för parterna och, viktigast av allt, den överenskomna kvaliteten på den aktuella tjänsten.

SLO är servicenivåmålet: ett mål eller ett intervall av värden för servicenivån, som mäts med SLI. Ett normalt värde för SLO är "SLI ≤ målvärde" eller "lägre gräns ≤ SLI ≤ övre gräns."

SLI är en indikator på servicenivån – en noggrant definierad kvantitativ mätning av en aspekt av den tillhandahållna servicenivån. För de flesta tjänster betraktas fördröjningen av en begäran som den nyckel-SLI – hur lång tid det tar att återlämna ett svar på begäran. Andra vanliga SLI inkluderar felfrekvens, ofta uttryckt som andel av alla mottagna begärningar, och systemets kapacitet, vanligtvis mätt i begärningar per sekund.

Först ska vi krascha flygplanen, och sedan tjejerna, tjejerna får vänta…

Inre och yttre faktorer började direkt att "förstöra" SLO. Allt rasade över administratörerna – både utvecklarfel, infrastrukturfel, ökad besökstrafik och DDoS-attacker. Allt som försämrar SLO.

"- Kära deltagare, jag har glädjen att meddela er att först och främst kommer allt att krascha…!"

Under tiden diskuterade talarna stabilitet, error budget, testmetoder, hantering av avbrott och operativ belastning.

Vi är varken kolare eller snickare…

Här började deltagarna reparera — det viktigaste är att förstå vad man ska ta itu med först.

“- Herregud, jag har aldrig sett något gå sönder så här, i detta skick och i denna position!”

Så, en incident inträffade. Betalningsbehandlingstjänsten kraschade. Hur ska vi agera för att återfå funktionaliteten på kortast möjliga tid?

Experterna, med ett ömt öga på deltagarna, förbereder nästa knep.

Varje team organiserar arbetet för att åtgärda incidenten — kopplar in kollegor, informerar intressenter. Samtidigt sätts prioriteringar. Så tränade deltagarna för att arbeta under press i en mycket begränsad tidsram.

“- Vad är det för skräck som kommit fram?!“

Vi andades ut... och avslutade övningen.

Tillsammans med talarna efter varje löst problem och tillfälligt stabiliserad webbplats studerade teamen incidenterna ur ett SRE-perspektiv. De analyserade problemen i detalj — orsaker, lösningsförlopp. Efter detta fattade de, både inom team och kollektivet, beslut om hur man skulle förebygga dem i framtiden: hur man kan förbättra övervakningen, hur man klokt kan ändra arkitekturen, hur man bör justera tillvägagångssättet för utveckling och drift, hur man kan korrigera reglerna. Talarna visade praktiken att genomföra post-mortem.

“- Vem vill ha mer plåga! — Jag!”

På den elektroniska tavlan registrerades teamens framgångar strikt och tydligt.

För första platsen — en belöning från intressenterna.

Källa: habr.com