Vårt team älskar experiment. Varje Slurm är inte en statisk upprepning av de tidigare, utan en reflektion över upplevelsen och en övergång från bra till bättre. Men med vi bestämde oss för att tillämpa ett helt nytt format - för att ge deltagarna förutsättningar så nära "strid" som möjligt.
Om vi kort beskriver vad vi gjorde under intensivkursen: "Vi bygger, vi bryter, vi reparerar,
vi pluggar." SRE är värt lite i enbart teori - bara praktik, verkliga lösningar, verkliga problem.
Deltagarna delades in i lag så att en stark tävlingsanda inte skulle tillåta någon att somna eller lansera "Angry Birds" på iPhone, efter Dmitry Anatolyevichs exempel.
Problem, fel, buggar och uppgifter gavs till deltagarna av fyra mentorer. Ivan Kruglov, huvudutvecklare på Booking.com (Nederländerna). Ben Tyler, huvudutvecklare på Booking.com (USA). Eduard Medvedev, CTO på Tungsten Labs (Tyskland). Evgeniy Varavva, allmän utvecklare på Google (San Francisco).
Dessutom delas deltagarna in i lag och tävlar med varandra. Intressant?
Ivan, Ben, Eduard och Evgeniy tittar på de stackars Slurm SRE-deltagarna med snälla leninistiska kisar inför tävlingsstarten.
Så uppgiften:
Vi är våra, vi ska bygga en ny värld...
Det finns en webbplats för att samla in biobiljetter. Incidenter uppfinns av mentorer i ett förutarbetat scenario (även om ingen utesluter särskilt sofistikerad och lömsk improvisation), sajtens prestanda beskrivs av olika mått. Problemen kan vara väldigt olika: biljetter till Moulin Rouge-teatern laddas inte in i databasen; affischer med filmer och föreställningar laddas in i databasen på mer än 10 sekunder; beskrivningen av en enskild film fryser; 0,1 % av beställningarna är redan reserverade; Då och då kraschar betalningshanteringssystemet i en minut eller två. Och många, många, många obehagliga saker som kan drabba en Slurm SRE-deltagare på sitt riktiga jobb.
Vi är redo att hantera allt...och alla.
Vår långlivade webbplats består av flera mikrotjänster. Dess uppgift är att samla data om föreställningar, priser och tillgängliga platser från alla biografer; den visar filmannonser, låter dig välja en biograf, föreställning, sal och plats, boka och betala för biljetter. I allmänhet allt som tittaren bara kan drömma om. Men användaren misstänker inte ens vilken enorm kamp för stabiliteten och tillgängligheten på webbplatsen som pågår inuti.
För den intensiva platsen genererade vi SLO, SLI, SLA-indikatorer, utvecklade arkitektur och infrastruktur, distribuerade platsen, satte upp övervakning och larm. Och iväg går vi.
SLO, SLI, SLA
SLI - servicenivåindikatorer. SLO:er är servicenivåmål. SLA - servicenivåavtal.
SLA är en ITIL-metodikterm som betecknar ett formellt avtal mellan kunden av en tjänst och dess leverantör, som innehåller en beskrivning av tjänsten, parternas rättigheter och skyldigheter och, viktigast av allt, den överenskomna kvalitetsnivån för tillhandahållandet av denna service.
En SLO är ett servicenivåmål: ett målvärde eller värdeintervall för en servicenivå som mäts av SLI. Ett normalt värde för SLO är "SLI ≤ Target" eller "Lower Limit ≤ SLI ≤ Upper Limit".
SLI är en servicenivåindikator – ett noggrant definierat kvantitativt mått på en aspekt av tjänstenivån. För de flesta tjänster anses nyckel-SLI vara fördröjningsfördröjning - hur lång tid det tar att returnera ett svar på en förfrågan. Andra vanliga SLI:er inkluderar felfrekvens, ofta uttryckt som en bråkdel av alla mottagna förfrågningar, och systemgenomströmning, vanligtvis mätt i förfrågningar per sekund.
Först och främst kommer vi att slå sönder flygplanen, och sedan tjejerna och sedan tjejerna...
Inre och yttre faktorer började "skämma bort" SLO från de allra första minuterna. Allt föll på administratörernas huvuden – utvecklarmisstag, infrastrukturfel, en tillströmning av besökare och DDoS-attacker. Allt som förvärrar SLO.
"- Kära deltagare, jag skyndar mig att behaga er, det första ni misslyckas med är... allt!"
Längs vägen diskuterade talarna stabilitet, felbudget, testpraxis, hantering av avbrott och driftsbelastning.
Vi är inte stokers, inte snickare...
Sedan började deltagarna fixa saker - huvudsaken är att förstå vad man ska ta tag i först.
"- Herre, jag har aldrig sett det gå sönder så här, i denna form och i en sådan position!"
Så en olycka inträffade. Betalningshanteringstjänsten är nere. Hur ska man agera för att återställa funktionaliteten på kortast möjliga tid?
Experterna tittar kärleksfullt på deltagarna och förbereder ytterligare ett knep.
Varje team organiserar gruppens arbete för att eliminera olyckan - involverar kollegor, meddelar berörda parter (intressenter). Samtidigt görs prioriteringar. På så sätt tränade deltagarna på att arbeta under press under extremt begränsade tidsförhållanden.
"Vilken typ av skräck har kommit ut?!"
Andas ut... och avsluta övningen
Tillsammans med talarna, efter att varje problem lösts och platsen tillfälligt stabiliserats, studerade teamet incidenterna ur SRE-synpunkt. Vi analyserade problemen i detalj - orsakerna till förekomsten, framstegen med eliminering. Efter det, både team-för-team och kollektivt, fattade vi beslut om hur vi skulle förebygga dem ytterligare: hur man förbättrar övervakningen, hur man på ett klokt sätt ändrar arkitekturen, hur man anpassar tillvägagångssättet för utveckling och drift, hur man korrigerar regelverk. Talarna demonstrerade praxis att genomföra obduktion.
"Vem mer vill plåga! - Jag!"
Lagens framgångar registrerades strikt och tydligt på den elektroniska resultattavlan.
För förstaplatser - en bonus från intressenter.
Källa: will.com