Teamet vårt elsker eksperimenter. Hver Slurm er ikke en statisk repetisjon av de forrige, men en refleksjon over opplevelsen og en overgang fra god til bedre. Men med vi bestemte oss for å bruke et helt nytt format - for å gi deltakerne betingelser så nærme som mulig "kamp".
Hvis vi kort skisserer hva vi gjorde under intensivkurset: «Vi bygger, vi bryter, vi reparerer,
vi studerer." SRE er lite verdt i ren teori - bare praksis, reelle løsninger, reelle problemer.
Deltakerne ble delt inn i lag slik at en kraftig konkurranseånd ikke ville tillate noen å sovne eller starte "Angry Birds" på iPhone, etter eksemplet til Dmitry Anatolyevich.
Problemer, feil, feil og oppgaver ble gitt til deltakerne av fire mentorer. Ivan Kruglov, hovedutvikler hos Booking.com (Nederland). Ben Tyler, hovedutvikler hos Booking.com (USA). Eduard Medvedev, CTO ved Tungsten Labs (Tyskland). Evgeniy Varavva, generell utvikler hos Google (San Francisco).
Dessuten er deltakerne delt inn i lag og konkurrerer med hverandre. Interessant?
Ivan, Ben, Eduard og Evgeniy ser på de stakkars Slurm SRE-deltakerne med snille leninistiske skråblikk før konkurransestart.
Så oppgaven:
Vi er våre, vi skal bygge en ny verden...
Det er et nettsted for aggregator for kinobilletter. Hendelser er oppfunnet av mentorer i et forhåndsarbeidet scenario (selv om ingen utelukker spesielt sofistikert og lumsk improvisasjon), er ytelsen til nettstedet beskrevet av forskjellige beregninger. Problemene kan være svært forskjellige: billetter til Moulin Rouge-teatret lastes ikke inn i databasen; plakater av filmer og forestillinger lastes inn i databasen på mer enn 10 sekunder; beskrivelsen av en individuell film fryser; 0,1 % av bestillingene er allerede reservert; Fra tid til annen krasjer betalingsbehandlingssystemet i et minutt eller to. Og mange, mange, mange ubehagelige ting som kan ramme en Slurm SRE-deltaker på sin virkelige jobb.
Vi er klare til å håndtere alt...og alle.
Vårt langmodige nettsted består av flere mikrotjenester. Dens oppgave er å samle data om forestillinger, priser og tilgjengelige seter fra alle kinoer; den viser filmkunngjøringer, lar deg velge en kino, forestilling, sal og sted, bestille og betale for billetter. Generelt alt som seeren bare kan drømme om. Men brukeren mistenker ikke engang hvilken titanisk kamp for stabiliteten og tilgjengeligheten til nettstedet som foregår på innsiden.
For det intensive nettstedet genererte vi SLO, SLI, SLA-indikatorer, utviklet arkitektur og infrastruktur, distribuerte nettstedet, satte opp overvåking og varsling. Og vi går.
SLO, SLI, SLA
SLI - servicenivåindikatorer. SLO-er er servicenivåmål. SLA - servicenivåavtaler.
SLA er et ITIL-metodikkbegrep som betegner en formell avtale mellom kunden av en tjeneste og dens leverandør, som inneholder en beskrivelse av tjenesten, partenes rettigheter og plikter og, viktigst av alt, det avtalte kvalitetsnivået for levering av denne service.
En SLO er et servicenivåmål: en målverdi eller verdiområde for et servicenivå som måles av SLI. En normal verdi for SLO er “SLI ≤ Target” eller “Lower Limit ≤ SLI ≤ Upper Limit”.
SLI er en servicenivåindikator – et nøye definert kvantitativt mål på ett aspekt av tjenestenivået som tilbys. For de fleste tjenester anses nøkkel-SLI å være forespørselsforsinkelse - hvor lang tid det tar å returnere et svar på en forespørsel. Andre vanlige SLI-er inkluderer feilfrekvens, ofte uttrykt som en brøkdel av alle mottatte forespørsler, og systemgjennomstrømning, vanligvis målt i forespørsler per sekund.
Først av alt skal vi knuse flyene, og så jentene, og så jentene...
Interne og eksterne faktorer begynte å "ødelegge" SLO fra de første minuttene. Alt falt på administratorenes hoder – utviklerfeil, infrastrukturfeil, en tilstrømning av besøkende og DDoS-angrep. Alt som forverrer SLO.
"- Kjære deltakere, jeg skynder meg å glede dere, det første du feiler er... alt!"
Underveis diskuterte foredragsholderne stabilitet, feilbudsjett, testpraksis, håndtering av avbrudd og driftsbelastning.
Vi er ikke stokere, ikke snekkere...
Så begynte deltakerne å fikse ting - det viktigste er å forstå hva de skal ta først.
"- Herre, jeg har aldri sett det gå i stykker slik, i denne formen og i en slik posisjon!"
Så det skjedde en ulykke. Betalingsbehandlingstjenesten er nede. Hvordan handle for å gjenopprette funksjonalitet på kortest mulig tid?
Ekspertene, som ser kjærlig på deltakerne, forbereder et nytt triks.
Hvert team organiserer arbeidet til gruppen for å eliminere ulykken - involverer kolleger, varsler interesserte parter (interessenter). Samtidig blir det prioritert. På denne måten trente deltakerne på å jobbe under press under ekstremt begrensede tidsforhold.
"Hva slags redsel har kommet ut?!"
Pust ut... og fullfør øvelsen
Sammen med foredragsholderne, etter at hvert problem var løst og stedet ble midlertidig stabilisert, studerte teamet hendelsene fra et SRE-synspunkt. Vi analyserte problemene i detalj - årsakene til forekomsten, fremdriften av eliminering. Etter det, både team-for-team og kollektivt, tok vi beslutninger om hvordan vi skulle forebygge dem ytterligere: hvordan vi kan forbedre overvåkingen, hvordan vi skal endre arkitekturen, hvordan vi skal justere tilnærmingen til utvikling og drift, hvordan korrigere regelverk. Foredragsholderne demonstrerte praksisen med å gjennomføre post mortem.
«Hvem andre vil ha pine! - JEG!"
Lagenes suksesser ble strengt og tydelig registrert på den elektroniske resultattavlen.
For førsteplasser - en bonus fra interessenter.
Kilde: www.habr.com