Meie meeskond armastab eksperimente. Iga Slurm ei ole eelnevate staatiline kordamine, vaid läbimõtlemine kogemuse üle ja üleminek heast paremasse. Aga koos otsustasime rakendada täiesti uut vormingut - anda osalejatele võimalikult lähedased tingimused "võitlusele".
Kui lühidalt välja tuua, mida intensiivkursuse ajal tegime: „Ehitame, lõhume, parandame,
me õpime." SRE on pelgalt teoorias vähe väärt – ainult praktika, reaalsed lahendused, tõelised probleemid.
Osalejad jagati meeskondadesse, et hoogne võistlusvaim ei laseks Dmitri Anatoljevitši eeskujul kellelgi magama jääda ega iPhone’is “Angry Birdsi” käivitada.
Probleeme, tõrkeid, vigu ja ülesandeid jagasid osalejatele neli mentorit. Ivan Kruglov, Booking.com-i (Holland) peamine arendaja. Ben Tyler, Booking.com-i (USA) peamine arendaja. Eduard Medvedev, Tungsten Labsi (Saksamaa) tehnikajuht. Evgeniy Varavva, Google'i üldarendaja (San Francisco).
Lisaks jagunevad osalejad meeskondadeks ja võistlevad omavahel. Huvitav?
Ivan, Ben, Eduard ja Jevgeniy vaatavad enne võistluse algust vaeseid Slurm SRE osalejaid lahke leninliku pilguga.
Seega ülesanne:
Oleme meie omad, ehitame uut maailma...
Kinopiletite koondaja veebisait on olemas. Juhtumid mõtlevad mentorid välja eelnevalt läbitöötatud stsenaariumi järgi (ehkki keegi ei välista eriti keerulist ja salakavalat improvisatsiooni), saidi toimivust kirjeldavad erinevad mõõdikud. Probleemid võivad olla väga erinevad: Moulin Rouge’i teatri pileteid ei laeta andmebaasi; filmide ja etenduste plakatid laaditakse andmebaasi rohkem kui 10 sekundiga; üksiku filmi kirjeldus külmub; 0,1% tellimustest on juba broneeritud; Aeg-ajalt jookseb maksete töötlemise süsteem minutiks või paariks kokku. Ja palju, palju, palju ebameeldivaid asju, mis võivad Slurm SRE osalejat tema päristööl tabada.
Oleme valmis hakkama saama kõigega...ja kõigiga.
Meie kauakannatanud veebisait koosneb mitmest mikroteenusest. Selle ülesandeks on koondada andmed kõikide kinode etenduste, hindade ja vabade kohtade kohta; see näitab filmiteateid, võimaldab valida kino, etenduse, saali ja koha, broneerida ja tasuda pileteid. Üldiselt kõike seda, millest vaataja võib vaid unistada. Kuid kasutaja isegi ei kahtlusta, milline titaanlik võitlus saidi stabiilsuse ja juurdepääsetavuse eest sees käib.
Intensiivse saidi jaoks genereerisime SLO, SLI, SLA näitajad, arendasime arhitektuuri ja infrastruktuuri, juurutasime saidi, seadistasime jälgimise ja hoiatamise. Ja me läheme minema.
SLO, SLI, SLA
SLI - teenindustaseme indikaatorid. SLO-d on teenusetaseme eesmärgid. SLA – teenusetaseme lepingud.
SLA on ITIL-i metoodika termin, mis tähistab formaalset lepingut teenuse tellija ja teenuse osutaja vahel, mis sisaldab teenuse kirjeldust, poolte õigusi ja kohustusi ning mis kõige tähtsam – kokkulepitud kvaliteeditaset selle osutamiseks. teenus.
SLO on teenusetaseme eesmärk: teenusetaseme sihtväärtus või väärtuste vahemik, mida SLI mõõdab. SLO normaalväärtus on “SLI ≤ sihtmärk” või “Alumine piir ≤ SLI ≤ ülemine piir”.
SLI on teenusetaseme indikaator – hoolikalt määratletud kvantitatiivne mõõdik osutatava teenuse taseme ühe aspekti kohta. Enamiku teenuste puhul loetakse võtme SLI-ks päringu latentsust – kui kaua kulub päringule vastuse tagastamiseks. Teised levinud SLI-d hõlmavad veamäära, mida sageli väljendatakse murdosa kõigist saadud päringutest, ja süsteemi läbilaskevõimet, mida tavaliselt mõõdetakse päringutes sekundis.
Kõigepealt lõhume lennukid ja siis tüdrukud ja siis tüdrukud...
Sisemised ja välised tegurid hakkasid SLO-d "rikkuma" juba esimestest minutitest. Kõik langes administraatorite pähe – arendajate vead, infrastruktuuri tõrked, külastajate sissevool ja DDoS-i rünnakud. Kõik, mis halvendab SLO-d.
"- Kallid osalejad, kiirustan teile meeldima, esimene asi, mis teil ebaõnnestub, on... kõik!"
Teel arutleti stabiilsuse, veaeelarve, testimispraktika, katkestuste ja töökoormuse juhtimise üle.
Me ei ole kütid, mitte puusepad...
Seejärel asusid osalejad asju parandama – peaasi, et aru saaks, millest esimesena haarata.
"- Issand, ma pole kunagi näinud, et see niimoodi puruneks, sellisel kujul ja sellises asendis!"
Niisiis juhtus õnnetus. Maksetöötlusteenus ei tööta. Kuidas toimida, et taastada funktsionaalsus võimalikult lühikese ajaga?
Asjatundjad, kes vaatavad osalejaid hellitavalt, valmistavad ette järjekordset trikki.
Iga meeskond korraldab grupi tööd õnnetuse likvideerimiseks - kaasab kolleege, teavitab huvilisi (huvirühmi). Samal ajal pannakse paika prioriteedid. Sel viisil treenisid osalejad töötama surve all äärmiselt piiratud aja tingimustes.
"Mis õudus on välja tulnud?!"
Hinga välja... ja lõpeta harjutus
Pärast iga probleemi lahendamist ja saidi ajutist stabiliseerimist uuris meeskond koos kõnelejatega juhtumeid SRE vaatepunktist. Analüüsisime probleeme üksikasjalikult - esinemise põhjuseid, kõrvaldamise edenemist. Pärast seda tegime nii meeskondlikult kui ka kollektiivselt otsuseid, kuidas neid veelgi ennetada: kuidas parandada monitooringut, kuidas targalt muuta arhitektuuri, kuidas kohandada lähenemist arendusele ja toimimisele, kuidas korrigeerida regulatsioone. Esinejad demonstreerisid surmajärgse dirigeerimise praktikat.
“Kes veel piina tahab! - Mina!"
Võistkondade õnnestumised kanti rangelt ja selgelt elektroonilisele tabloole.
Esikohtade eest - huvirühmade boonus.
Allikas: www.habr.com