Sleurm SRE. En hel eksperiment med eksperter fra Booking.com og Google.com

Teamet vårt elsker eksperimenter. Hver Slørm er ikke et statisk gjentakelse av tidligere, men en forståelse av erfaringer og en overgang fra det gode til det bedre. Men med Slørm SRE har vi bestemt oss for å bruke et helt nytt format – å gi deltakerne forhold som er så nær «krigsforhold» som mulig.

Kort sagt om hva vi gjorde på intensivkurset: «Vi bygger, ødelegger, fikser,
lærer». SRE har lite verdi i ren teori – det er kun praksis, reelle løsninger og virkelige problemer som teller.

Deltakerne ble delt inn i lag for at den livlige konkurranseånden ikke skulle la noen sovne eller begynne å spille «Angry Birds» på iPhone som eksempelvis Dmitrij Anatoljevitsj.

Problemer, bugs, og oppgaver ble gitt til deltakerne av fire mentorer. Ivan Kruglov, Principal Developer hos Booking.com (Nederland). Ben Tyler, Principal Developer hos Booking.com (USA). Eduard Medvedev, CTO hos Tungsten Labs (Tyskland). Evgenij Varavva, allsidig utvikler hos Google (San Francisco).

Og deltakerne er delt inn i lag – og konkurrerer med hverandre. Interessant?

Ivan, Ben, Eduard og Evgenij ser med et vennlig Lenin-lignende blikk på de stakkars deltakerne før Slørm SRE-konkurransen begynner.

Så oppgaven er:

Vi vil bygge vår, vår nye verden…

Det finnes en nettsted-aggregator for kinobilletter. Hendelsene blir funnet på av mentorene i et nøye utarbeidet manus (selv om ingen utelukker spesielt utsøkt og utspekulert improvisasjon), og nettstedets funksjonalitet beskrives med ulike metrikker. Problemene kan være mange og varierte: billetter til teateret «Moulin Rouge» laster ikke inn i databasen; poster for filmer og forestillinger laster inn i databasen på mer enn 10 sekunder; beskrivelsen av en enkelt film henger; 0,1% av bestillingene havner allerede på reserverte plasser; betalingssystemet faller fra i ett minutt eller to. Og alt det ubehagelige som kan ramme deltakerne i Slørm SRE i deres virkelige arbeid.

Vi er klare til å takle alt… og alle.

Vår utsatte nettside består av flere mikrotjenester. Dens oppgave er å aggregere data om visninger, priser og tilgjengelige seter fra alle kinoer, vise filmannonser, la brukeren velge kino, visning, sal og sete, samt å reservere og betale for billetter. I grunn er det alt en seer kan drømme om. Men brukeren aner ikke om den titanske kampen for stabilitet og tilgjengelighet som foregår internt.

For nettsiden under intensivprogrammet har vi dannet SLO-, SLI- og SLA-mål, utviklet arkitektur og infrastruktur, deployert nettstedet, satt opp overvåkning og varsling. Og så begynte det.

SLO, SLI, SLA

SLI er tjenestenivåindikatorer. SLO er tjenestenivåmål. SLA er tjenestenivåavtaler.

SLA er en term fra ITIL-metodikk, som betegner en formell avtale mellom tjenestemottakeren og tjenesteleverandøren, som inneholder en beskrivelse av tjenesten, rettigheter og plikter for partene, og viktigst av alt, den avtalte kvaliteten på tjenesten som tilbys.

SLO er målet for tjenestenivå: et målverdi eller et spenn av verdier for tjenestenivået, som måles gjennom SLI. Den normale verdien for SLO er «SLI ≤ målverdi» eller «nedre grense ≤ SLI ≤ øvre grense».

SLI er en indikator for tjenestenivå - en nøye definert kvantitativ måling av ett aspekt ved det leverte tjenestenivået. For de fleste tjenester er den viktigste SLI responstid - hvor lang tid det tar å returnere et svar på en forespørsel. Andre vanlige SLI inkluderer feilmengde, ofte uttrykt som andelen av alle mottatte forespørselene, og systemets gjennomstrømning, vanligvis målt i forespørslene per sekund.

Først må vi knuse flyene, så jentene, jentene tar vi senere...

Interne og eksterne faktorer begynte å «ødelegge» SLO fra de første minuttene. Alt mulig ble kastet over hodene på administratorene - både utviklerfeil, infrastrukturfeil, økt trafikk og DDoS-angrep. Alt som forverrer SLO.

«- Kjære deltakere, jeg har gleden av å meddele, det første som skjer er at dere mister... alt!»

Underveis diskuterte foredragsholderne robusthet, fe budget, testpraksis, håndtering av avbrudd og operasjonell belastning.

Vi er verken fyrbøtere eller snekkere...

Her begynte deltakerne å fikse — det viktigste er å forstå hva man skal ta tak i først.

«- Herregud, jeg har aldri sett noe sånt bryte sammen, i en sånn tilstand og i en sånn stilling!»

Så, en ulykke har skjedd. Betalingsbehandlingssystemet har krasjet. Hva skal man gjøre for å gjenopprette funksjonaliteten så raskt som mulig?

Ekspertene kaster et vennlig blikk på deltakerne og forbereder en ny utfordring.

Hver gruppe organiserer arbeidet med å eliminere ulykken — involverer kolleger, informerer interessenter. Samtidig settes prioriteringer. Slik trente deltakerne på å jobbe under press i uhyre begrenset tid.

«- Hva i all verden er dette for noe?!»

De trakk pusten ... og fullførte øvelsen.

Sammen med foredragsholderne etter hvert løst problem og midlertidig stabilisert nettsted, studerte teamene hendelsene fra SREs perspektiv. De analyserte detaljert problemene — årsakene og prosessen for å løse dem. Deretter, både som lag og kollektivt, tok de beslutninger om videreforebygging: hvordan forbedre overvåkingen, hvordan endre arkitekturen fornuftig, hvordan justere tilnærmingen til utvikling og drift, og hvordan korrigere regelverkene. Foredragsholderne viste hvordan en post-mortem gjennomføres.

«- Hvem vil ha mer lidelse! — Jeg!»

På det elektroniske tavlen ble lagenes fremgang strengt og tydelig registrert.

For førsteplassene — premie fra interessentene.

Kilde: habr.com