Sleərm SRE. Pidev eksperimenteerimine ekspertidega Booking.com ja Google.com.

Meie meeskond armastab katsetada. Iga SLRM ei ole staatiliselt korduv eelneva, vaid kogemuse analüüs ja üleminek heast paremale. Kuid SLRM SRE otsustasime rakendada täiesti uut formaati — luua osalejatele tingimused, mis on võimalikult lähedased "lahingutingimustele".

Kui lühidalt kirjeldada, millega me intensiivselt tegelesime: "Ehitatame, lõhkume, parandame,
uurime." SRE-l pole teoorias suurt väärtust — ainult praktika, reaalsed lahendused, reaalsed probleemid.

Osalejad jagati meeskondadesse, et elav võistlusvaim ei laseks kedagi uinuda ega "Angry Birdsi" iPhone'is käivitada Dmitri Anatoljevitši eeskujul.

Probleeme, vigu, bug'e ja ülesandeid tagas osalejatele neli mentorit. Ivan Kruglov, Booking.com-i peamine arendaja (Holland). Ben Tyler, Booking.com-i peamine arendaja (USA). Eduard Medvedev, Tungsten Labs-i CTO (Saksamaa). Evgeni Varavva, Google'i mitmekesine arendaja (San Francisco).

Ja osalejad on jagatud meeskondadesse — ja võistlevad omavahel. Kas see ei ole huvitav?

Ivan, Ben, Eduard ja Evgeni vaatavad heatahtliku Lenini pilguga vaeseid SLRM SRE osalejaid enne võistluse algust.

Nii et ülesanne:

Meie oma, me ehitame uue maailma…

On olemas piletite kogumise veebisait. Õnnetuste stsenaariume kirjutavad mentorid ette töötatud plaani kohaselt (kuigi keegi ei välista erilisi ja kavalate improviseerimist), saidi töökindlust kirjeldatakse erinevate mõõdikute järgi. Probleemid võivad olla väga erinevad: «Moulin Rouge» teatri piletid ei laadi andmebaasi; filmide ja etenduste plakatid laaditakse andmebaasi enam kui 10 sekundi jooksul; ühe filmiga seotud kirjeldus hangub; 0,1% tellimustest jõuab juba reserveeritud kohtadele; perioodiliselt kukub maksesüsteem minutiks-kaks ära. Ja palju-palju-palju ebameeldivat, mis võib tabada SRE Slërm osalist tema tõelisel tööl.

Me oleme valmis kõikide väljakutsetega toime tulema… ja kõigiga.

Meie paljuda teid hästi teenindav veebisait koosneb mitmest mikroteenusest. Selle ülesanne on koguda andmeid seansside, hindade ja vaba kohtade kohta kõikides kinodes, see kuvab filmide eelvaateid, võimaldab valida kino, seansi, saali ja kohta, broneerida ja maksta pileteid. Ühesõnaga, kõik, millest vaataja vaid unistada oskab. Ainult et kasutaja ei aimagi, milline titaanlik võitlus stabiilsuse ja saidi kergesti kätte saamise nimel toimub selle sees.

Intensiivkursuse jaoks koostasime saidile SLO, SLI, SLA näitajad, töötasime välja arhitektuuri ja infrastruktuuri, juurutame saidi, seadistasime jälgimise ja häirete süsteemi. Ja läks lahti.

SLO, SLI, SLA

SLI — teenuse taseme indikaatorid. SLO — teenuse taseme eesmärgid. SLA — teenuse taseme lepingud.

SLA — ITILi metoodika termin, mis tähistab ametlikku lepingut teenuse tellija ja selle pakkuja vahel, mis sisaldab teenuse kirjeldust, osapoolte õigusi ja kohustusi ning mis on kõige tähtsam, kokku lepitud kvaliteeditase, millega seda teenust osutatakse.

SLO — see teenus taseme eesmärk: sihttase või vahemik teenuse taseme väärtuste jaoks, mida mõõdetakse SLI kaudu. Tavaline SLO väärtus on "SLI ≤ sihttase" või "madalam piir ≤ SLI ≤ ülemine piir".

SLI on teenuse taseme näitaja — hoolikalt määratletud kvantitatiivne mõõdik ühe teenuse taseme aspekti kohta. Enamiku teenuste puhul peetakse peamiseks SLI-ks päringu latentsust — kui kaua kulub vastuse saamiseks. Teised levinud SLI-d hõlmavad vigade määra, mis sageli väljendatakse kõigi saadud päringute osakaaluna, ja süsteemi läbilaskevõimet, mida mõõdetakse tavaliselt päringutes sekundis.

Esiteks purustame lennukid, aga tüdrukud, tüdrukud pärast…

Sisemised ja välised tegurid hakkasid esimesest hetkest SLO-d "rikkuma". Kõik kukkus administraatorite kaela — nii arendajate vead, infrastruktuuri tõrked, külastajate vool kui ka DDoS-rünnakud. Kõik see halvendab SLO-d.

"- Kallid osalejad, mul on hea meel teid rõõmustada, kõigepealt kukub teil... kõik!"

Esitluste käigus arutati vastupidavust, vigade eelarvet, testimise praktikat, katkestuste ja operatiivkoormuse juhtimist.

Me ei ole ei kütjad ega puusepad...

Siin hakkasid osalejad parandama — peamine on mõista, millest alustada.

„- Jumal küll, ma pole kunagi näinud, et see nii katki läheks, sellises seisus ja sellises asendis!”

Nii et toimus õnnetus. Makseteenuste süsteem kukkus alla. Kuidas tegutseda, et taastada funktsionaalsus võimalikult kiiresti?

Eksperdid vaatavad osalejatele heldelt ja valmistavad järgmise üllatuse.

Iga meeskond korraldab grupi tööd õnnetuse likvideerimiseks — kaasatakse kolleege, teavitatakse huvitatud osalisi (stakeholders). Samuti määratakse prioriteedid. Nii harjutasid osalejad töötama surve all äärmiselt piiratud ajatingimustes.

„- Mis see hirmsa asi on?!“

Hingeti sügavalt… ja lõpetati harjutus.

Koos esinejatega uuriti pärast iga lahendatud probleemi ja ajutiselt stabiliseeritud veebisaiti SRE meeskond sündmusi. Probleemide analüüsimine oli põhjalik – tekkepõhjused ja lahendamine. Pärast seda, nii meeskondlikult kui kollektiivselt, tehti otsus nende edasise ennetamise osas: kuidas paremini jälgida, kuidas õigesti muuta arhitektuuri, kuidas kohandada arendus- ja töökorraldust, kuidas reguleerida protseduure. Esinejad demonstreerisid post-mortem'i praktikate läbiviimist.

„- Kes veel tahab piinlemist! — Mina!”

Elektroonilisel tahvlil fikseeriti rangelt ja selgelt meeskondade edusammud.

Esikohtade eest – preemia sidusrühmadelt.

Allikas: habr.com