Vores team elsker eksperimenter. Hver SLØRM er ikke en statisk gentagelse af de tidligere, men en forståelse af erfaringerne og en overgang fra det gode til det bedre. Men med har vi besluttet at anvende et helt nyt format — at give deltagerne forhold, der er så tæt på "kamp" som muligt.
Hvis man kort beskriver, hvad vi har lavet på intensivkurset: "Bygger, nedbryder, reparerer,
undersøger." SRE betyder ikke så meget i ren teori — kun praksis, virkelige løsninger, virkelige problemer.
Deltagerne blev opdelt i hold for at den friske konkurrenceånd ikke skulle få nogen til at falde i søvn eller starte "Angry Birds" på iPhone som eksemplet med Dmitrij Anatolievitj.
Problemer, glitches, bugs og opgaver blev sørget for af fire mentorer. Ivan Kruglov, Principal Developer hos Booking.com (Holland). Ben Tyler, Principal Developer hos Booking.com (USA). Eduard Medvedev, CTO hos Tungsten Labs (Tyskland). Evgeny Varavva, alsidig udvikler hos Google (San Francisco).
Og deltagerne er også opdelt i hold — og konkurrerer mod hinanden. Interessant?
Ivan, Ben, Eduard og Evgeny ser med en venlig Lenin-agtig glimt på de stakkels deltagere af SLØRM SRE før konkurrencen starter.
Så opgaven er:
Vi vil bygge vores, vi vil bygge en ny verden...
Der er en aggregator hjemmeside for biografbilletter. Mentorerne finder på hændelser i et forudarbejdet scenarie (selvom ingen udelukker en særlig udsøgt og snedig improvisation), og hjemmesidens funktionalitet beskrives med forskellige målinger. Problemerne kan være af meget forskellig art: billetter til teateret "Moulin Rouge" indlæses ikke i databasen; film- og teaterplakater indlæses i databasen på mere end 10 sekunder; beskrivelsen af en enkelt film fryser; 0,1% af bestillingerne havner allerede på reserverede pladser; betalingsbehandlingssystemet falder periodisk ud i et minut eller to. Og meget, meget, meget ubehageligt kan falde ned over deltageren i SLØRM SRE i deres virkelige arbejde.
Vi er klar til at håndtere alt... og alle.
Vores meget prøvede hjemmeside består af flere mikrotjenester. Dens opgave er at aggregere data om filmvisninger, priser og ledige pladser fra alle biografer; den viser filmtrailere, giver mulighed for at vælge biograf, visning, sal og plads, samt at reservere og betale for billetter. Kort sagt, alt hvad seeren kan drømme om. Men brugeren aner ikke, hvilken titanisk kamp der foregår indeni for at sikre stabilitet og tilgængelighed af hjemmesiden.
Til hjemmesiden under intensivet har vi udviklet SLO, SLI, SLA-mål, designet arkitektur og infrastruktur, deployeret hjemmesiden, samt sat overvågning og alarmering op. Og så gik det løs.
SLO, SLI, SLA
SLI — service-level indicators. SLO — service-level objectives. SLA — service-level agreements.
SLA er et begreb fra ITIL-metodologien, der betegner en formel kontrakt mellem tjenesteudbyderen og kunden, som indeholder beskrivelse af tjenesten, rettigheder og forpligtelser for parterne og vigtigst af alt, den aftalte kvalitet af leveringen af denne tjeneste.
SLO er service-level objective: målværdi eller værdinterval for service-niveauet, der måles af SLI. Det normale for SLO er "SLI ≤ målværdi" eller "nederste grænse ≤ SLI ≤ øverste grænse".
SLI er en service-level indicator — en omhyggeligt defineret kvantitativ måling af et aspekt ved det leverede serviceniveau. For de fleste tjenester betragtes anmodningsforsinkelsen som den vigtigste SLI — hvor lang tid der kræves for at returnere et svar på en anmodning. Andre almindelige SLI inkluderer fejlfrekvens, ofte udtrykt som andel af alle modtagne anmodninger, og systemets båndbredde, som normalt måles i anmodninger pr. sekund.
Først skal vi ødelægge flyene, og pigerne, ja pigerne kommer senere…
Interne og eksterne faktorer begyndte allerede fra starten at "ødelægge" SLO. Alt muligt ramte administratorerne — både udviklerfejl, infrastrukturfejl, og et stigende antal besøgende, samt DDoS-angreb. Alt, hvad der forværrer SLO.
"- Kære deltagere, jeg har gode nyheder; det første, der sker, er, at alt falder…!"
Undervejs diskuterede talerne modstandsdygtighed, error budget, testpraksis, forstyrrelseshåndtering og driftsbelastning.
Vi er hverken fyrmestre eller snedkere…
Her begyndte deltagerne at reparere - det vigtigste er at forstå, hvad man skal tage fat på først.
- Gud, jeg har aldrig set noget gå i stykker på den måde og i den stilling!
Så skete der en ulykke. Betalingsbehandlingssystemet er nede. Hvordan handler man for at genoprette driften på kortest mulig tid?
Eksperterne kaster et venligt blik på deltagerne og forbereder den næste udfordring.
Hvert team organiserer arbejdet med at afhjælpe ulykken - de involverer kolleger og informerer interessenterne. Samtidig opstilles prioriteter. Deltagerne træner under pres og i ekstremt begrænsede tidsrammer.
- Hvad er det for et rædsel, der er dukket op?!
Vi trak vejret dybt… og afsluttede øvelsen.
Sammen med talerne studerede holdene efter hver løst problem og midlertidigt stabiliseret websted hændelserne fra et SRE-perspektiv. Vi analyserede problemerne - årsagerne, løsningen. Derefter tog de både gruppevis og kollektivt beslutninger om, hvordan de kunne forhindre dem fremadrettet: hvordan man forbedrer overvågningen, hvordan man korrekt ændrer arkitekturen, hvordan man justerer udviklings- og driftsmetoderne, hvordan man korrigerer reglerne. Talerne demonstrerede praksis for post-mortem afholdelse.
- Hvem vil have flere kvaler! - Jeg!
På den elektroniske tavle registreredes teamenes fremskridt strengt og tydeligt.
For førstepladserne - en belønning fra interessenterne.
Kilde: habr.com
