Vores team elsker eksperimenter. Hver slurm er ikke en statisk gentagelse af de foregående, men en refleksion over oplevelsen og en overgang fra godt til bedre. Men med vi besluttede at anvende et helt nyt format - for at give deltagerne betingelser så tæt som muligt på "kamp".
Hvis vi kort skitserer, hvad vi gjorde under det intensive kursus: "Vi bygger, vi går i stykker, vi reparerer,
vi studerer." SRE er kun lidt værd i teorien - kun praksis, reelle løsninger, reelle problemer.
Deltagerne blev opdelt i hold, så en kraftig konkurrenceånd ikke ville tillade nogen at falde i søvn eller starte "Angry Birds" på iPhone, efter Dmitry Anatolyevichs eksempel.
Problemer, fejl, fejl og opgaver blev givet til deltagerne af fire mentorer. Ivan Kruglov, hovedudvikler hos Booking.com (Holland). Ben Tyler, hovedudvikler hos Booking.com (USA). Eduard Medvedev, CTO hos Tungsten Labs (Tyskland). Evgeniy Varavva, generel udvikler hos Google (San Francisco).
Desuden er deltagerne opdelt i hold og konkurrerer med hinanden. Interessant?
Ivan, Ben, Eduard og Evgeniy ser på de stakkels Slurm SRE-deltagere med venlige leninistiske skelene før konkurrencestart.
Så opgaven:
Vi er vores, vi vil bygge en ny verden...
Der er en hjemmeside for aggregator for biografbilletter. Hændelser er opfundet af mentorer i et forudbearbejdet scenarie (selvom ingen udelukker særlig sofistikeret og snigende improvisation), er webstedets ydeevne beskrevet af forskellige målinger. Problemerne kan være meget forskellige: billetter til Moulin Rouge-teatret indlæses ikke i databasen; plakater af film og forestillinger indlæses i databasen på mere end 10 sekunder; beskrivelsen af en individuel film fryser; 0,1% af ordrerne er allerede reserveret; Fra tid til anden går betalingsbehandlingssystemet ned i et minut eller to. Og mange, mange, mange ubehagelige ting, der kan ramme en Slurm SRE-deltager på sit rigtige job.
Vi er klar til at håndtere alt...og alle.
Vores langmodige hjemmeside består af flere mikrotjenester. Dens opgave er at samle data om shows, priser og ledige pladser fra alle biografer; den viser filmannonceringer, giver dig mulighed for at vælge en biograf, show, sal og sted, bestille og betale for billetter. Generelt alt det, som seeren kun kan drømme om. Men brugeren har ikke engang mistanke om, hvilken titanisk kamp for stabiliteten og tilgængeligheden af webstedet, der foregår indeni.
Til det intensive websted genererede vi SLO, SLI, SLA-indikatorer, udviklede arkitektur og infrastruktur, implementerede webstedet, opsatte overvågning og alarmering. Og væk går vi.
SLO, SLI, SLA
SLI - serviceniveauindikatorer. SLO'er er serviceniveaumål. SLA - serviceniveauaftaler.
SLA er et ITIL-metodologisk udtryk, der betegner en formel aftale mellem kunden af en tjeneste og dennes leverandør, der indeholder en beskrivelse af tjenesten, parternes rettigheder og forpligtelser og, vigtigst af alt, det aftalte kvalitetsniveau for leveringen af denne. service.
En SLO er et serviceniveaumål: en målværdi eller et værdiområde for et serviceniveau, der måles af SLI. En normal værdi for SLO er "SLI ≤ Target" eller "Lower Limit ≤ SLI ≤ Upper Limit".
SLI er en serviceniveauindikator - et nøje defineret kvantitativt mål for et aspekt af det leverede serviceniveau. For de fleste tjenester anses nøgle-SLI for at være anmodningsforsinkelse - hvor lang tid det tager at returnere et svar på en anmodning. Andre almindelige SLI'er omfatter fejlrate, ofte udtrykt som en brøkdel af alle modtagne anmodninger, og systemgennemstrømning, normalt målt i anmodninger pr. sekund.
Først og fremmest vil vi bryde flyene, og så pigerne, og så pigerne...
Interne og eksterne faktorer begyndte at "spolere" SLO fra de allerførste minutter. Alt faldt på administratorernes hoveder - udviklerfejl, infrastrukturfejl, en tilstrømning af besøgende og DDoS-angreb. Alt hvad der forværrer SLO.
"- Kære deltagere, jeg skynder mig at behage jer, det første I fejler er... alt!"
Undervejs diskuterede talerne stabilitet, fejlbudget, testpraksis, håndtering af afbrydelser og driftsbelastning.
Vi er ikke stokere, ikke tømrere...
Så begyndte deltagerne at ordne ting - det vigtigste er at forstå, hvad de skal have fat i først.
"- Herre, jeg har aldrig set det gå i stykker på denne måde, i denne form og i sådan en stilling!"
Så der skete en ulykke. Betalingsbehandlingstjenesten er nede. Hvordan handler man for at genoprette funktionaliteten på kortest mulig tid?
Eksperterne ser kærligt på deltagerne og forbereder endnu et trick.
Hvert team organiserer gruppens arbejde for at eliminere ulykken - involverer kolleger, underretter interesserede parter (interessenter). Samtidig prioriteres der. På den måde trænede deltagerne i at arbejde under pres under ekstremt begrænsede tidsforhold.
"Hvilken slags rædsel er der kommet ud?!"
Pust ud... og afslut øvelsen
Sammen med talerne, efter at hvert problem var løst, og stedet var midlertidigt stabiliseret, studerede holdet hændelserne ud fra et SRE-synspunkt. Vi analyserede problemerne i detaljer - årsagerne til forekomsten, fremskridtet med eliminering. Derefter traf vi både team-for-team og kollektivt beslutninger om, hvordan vi kunne forebygge dem yderligere: hvordan man forbedrer overvågningen, hvordan man klogt ændrer arkitekturen, hvordan man justerer tilgangen til udvikling og drift, hvordan man retter reguleringer. Talerne demonstrerede praksis med at udføre obduktion.
"Hvem ellers ønsker pine! - jeg!"
Holdenes succeser blev strengt og tydeligt noteret på den elektroniske resultattavle.
For førstepladser - en bonus fra interessenter.
Kilde: www.habr.com