Mūsu komanda mīl eksperimentus. Katrs Slērm ir nevis statisks iepriekšējo atkārtojums, bet pieredzes apzināšanās un pāreja no laba uz labāku. Bet mēs nolēmām ieviest pilnīgi jaunu formātu — dot dalībniekiem apstākļus, kas maksimāli tuvu „kaujas” apstākļiem.
Ja īsi iezīmēt, ar ko mēs nodarbojāmies intensīvā laikā: „Būvējam, lauļam, remontējam,
izpētām”. SRE ir mazs jēgas tukšā teorijā — tikai prakse, reālas risinājumi, reālas problēmas.
Dalībnieki tika sadalīti komandās, lai dzīvīgais sacensību gars nepieļautu nevienam aizmigt vai palaist „Angry Birds” uz iPhone pēc Dimitrija Anatoljeviča parauga.
Problēmas, kļūdas, bugu un uzdevumi tika nodrošināti ar četriem mentoriem. Ivans Kruglovs, galvenais izstrādātājs Booking.com (Nīderlande). Bens Tailers, galvenais izstrādātājs Booking.com (ASV). Eduards Medvedevs, CTO Tungsten Labs (Vācija). Evgenijs Varava, vispārējs izstrādātājs Google (Sanfrancisko).
Un dalībnieki vēl ir sadalīti komandās — un sacenšas savā starpā. Interesanti?
Ivans, Bens, Eduards un Evgenijs ar labo lenina skatu skatās uz nabaga dalībniekiem SRE Slērm pirms sacensību sākuma.
Tātad uzdevums:
Mēs mēs, mēs uzcelsim jauno pasauli…
Ir vietne biļešu agregatoram uz kino. Incidences izdomā mentori iepriekš sagatavotā scenārijā (lai gan neviens neizslēdz īpaši izsmalcinātu un neticamu improvizāciju), vietnes darbība tiek aprakstīta ar dažādām metrikām. Problēmas var būt visdažādākās: teātra „Mulen Rž” biļetes neiekraujas datubāzē; filmu un izrāžu plakāti tiek iekrauti datubāzē ilgāk par 10 sekundēm; konkrēta filma iestrēgst; 0,1% pasūtījumu nonāk uz jau rezervētām vietām; periodiski uz mirkli vai diviem iznāk apmaksas sistēma. Un daudz, daudz, daudz nepatīkamu lietu, kas var uznākt uz dalībnieka SRE Slērm reālajā darbā.
Mēs esam gatavi tikt galā ar visu… un visiem.
Mūsu grūtā vietne sastāv no vairākiem mikroservisiem. Tās uzdevums ir datu apkopošana par seansiem, cenām un brīvajām vietām visos kinoteātros, tā rāda filmu priekšskatījumus, ļauj izvēlēties kinoteātri, seansu, zāli un vietu, rezervēt un apmaksāt biļetes. Īsāk sakot, viss, par ko skatītājs var tikai sapņot. Tomēr lietotājs pat nenojauš, cik milzīga cīņa par vietnes stabilitāti un pieejamību norisinās iekšpusē.
Intensīvajā kursā mēs izstrādājām SLO, SLI, SLA rādītājus, izveidojām arhitektūru un infrastruktūru, izvietojām vietni, konfigurējām uzraudzību un trauksmes sistēmu. Un sākās.
SLO, SLI, SLA
SLI — pakalpojumu līmeņa rādītāji. SLO — pakalpojumu līmeņa mērķi. SLA — pakalpojumu līmeņa vienošanās.
SLA — ITIL metodoloģijas termins, kas apzīmē oficiālu līgumu starp pakalpojuma pasūtītāju un tā sniedzēju, kas ietver pakalpojuma aprakstu, pušu tiesības un pienākumus un, pats galvenais, saskaņoto kvalitātes līmeni attiecīgā pakalpojuma sniegšanā.
SLO ir pakalpojumu līmeņa mērķis: mērķa vērtība vai vērtību diapazons pakalpojumu līmenim, ko mēra SLI. Normāla SLO vērtība ir "SLI ≤ mērķa vērtība" vai "apakšējā robeža ≤ SLI ≤ augšējā robeža".
SLI ir pakalpojumu līmeņa rādītājs — rūpīgi definēta kvantitatīva mēra vērtība par vienu no pakalpojumu līmeņa aspektiem. Lielākajā daļā pakalpojumu kā galveno SLI uzskata pieprasījuma aizturi — cik ilgs laiks nepieciešams, lai atgrieztu atbildi uz pieprasījumu. Citas izplatītas SLI ietver kļūdu biežumu, ko bieži izsaka kā visus saņemtos pieprasījumus, un sistēmas caurlaidspēju, parasti tiek mērīta pieprasījumos sekundē.
Pirmkārt, mēs salauzīsim lidmašīnas, nu un meitenes, meitenes pēc tam...
Iekšējie un ārējie faktori no pirmajām minūtēm sāka "bojāt" SLO. Administrātoriem uzgāzās viss — gan izstrādātāju kļūdas, gan infrastruktūras atteices, gan apmeklētāju pieplūdums, gan DDoS uzbrukumi. Viss, kas pasliktina SLO.
"- Dārgie dalībnieki, steidzos jūs iepriecināt, pirmkārt, jums nokrīt… viss!"
Tiekoties, runātāji apsprieda izturību, kļūdu budžetu, testēšanas praksi, traucējumu pārvaldību un operatīvo slodzi.
Mēs neesam krāsotāji, ne arī galdnieki...
Šeit dalībnieki sāka remontēt — galvenais ir saprast, ar ko sākt vispirms.
„- Dievs, es nekad neesmu redzējis, ka tas tā sabrūk, tādā veidā un tādā pozīcijā!”
Un tā notika avārija. Maksājumu apstrādes pakalpojums apstājās. Ko darīt, lai atjaunotu darbību minimālajā laikā?
Eksperti maigi skatās uz dalībniekiem un sagatavo nākamo jautājumu.
Katrs komanda organizē avārijas novēršanas grupas darbu — piesaista kolēģus, informē ieinteresētās puses. Vienlaikus tiek veidoti prioritātes. Tā dalībnieki trenējās strādāt stresa apstākļos ļoti ierobežotā laikā.
„- Kas tas par šausmām?!"
Ieelpojām… un pabeidzām uzdevumu.
Kopā ar runātājiem pēc katra atrisināta problēma un pagaidu stabilizētās vietnes komandas pētīja incidentus no SRE skatpunkta. Detalizēti analizēja problēmas — to rašanās cēloņus, novēršanas gaitu. Pēc tam gan komandās, gan kopā pieņēma lēmumus par to tālāku novēršanu: kā uzlabot uzraudzību, kā pareizi mainīt arhitektūru, kā korektēt pieeju izstrādei un ekspluatācijai, kā labot regulējumus. Runātāji demonstrēja post-mortem procedūru.
„- Kas vēl grib ciešanas! — Es!”
Uz elektroniskā tablo stingri un skaidri tika fiksēti komandu panākumi.
Par pirmajām vietām — balva no ieinteresētajām pusēm.
Avots: habr.com
