Mūsų komanda mėgsta eksperimentus. Kiekvienas Slurm yra ne statiškas ankstesnių kartojimas, o patirties apmąstymas ir perėjimas nuo gero prie geresnio. Bet su nusprendėme pritaikyti visiškai naują formatą – suteikti dalyviams kuo artimesnes sąlygas „kovoti“.
Jei trumpai apibūdintume, ką nuveikėme intensyvaus kurso metu: „Statome, laužome, remontuojame,
mes mokomės." SRE yra mažai vertas vien tik teorijoje – tik praktika, realūs sprendimai, tikros problemos.
Dalyviai buvo suskirstyti į komandas, kad energinga konkurencinė dvasia niekam neleistų užmigti ar paleisti „Angry Birds“ „iPhone“ Dmitrijaus Anatoljevičiaus pavyzdžiu.
Problemas, nesklandumus, klaidas ir užduotis dalyviams pateikė keturi mentoriai. Ivanas Kruglovas, pagrindinis Booking.com kūrėjas (Nyderlandai). Benas Tyleris, pagrindinis Booking.com (JAV) kūrėjas. Eduardas Medvedevas, „Tungsten Labs“ (Vokietija) CTO. Jevgenijus Varavva, bendras „Google“ kūrėjas (San Franciskas).
Be to, dalyviai yra suskirstyti į komandas ir varžosi tarpusavyje. Įdomus?
Ivanas, Benas, Eduardas ir Jevgenijus prieš varžybų pradžią žiūri į vargšus „Slurm SRE“ dalyvius maloniais leniniškais žvilgsniais.
Taigi užduotis:
Mes esame mūsų, mes sukursime naują pasaulį...
Yra filmų bilietų kaupimo svetainė. Incidentus sugalvoja mentoriai pagal iš anksto parengtą scenarijų (nors niekas neatmeta ypač įmantrios ir klastingos improvizacijos), svetainės veikimas apibūdinamas įvairiomis metrikomis. Problemos gali būti labai įvairios: bilietai į Mulen Ružo teatrą neįkeliami į duomenų bazę; filmų ir spektaklių plakatai į duomenų bazę įkeliami per daugiau nei 10 sekundžių; atskiro filmo aprašymas sustingsta; 0,1% užsakymų jau rezervuoti; Kartkartėmis mokėjimų apdorojimo sistema minutei ar dviem užstringa. Ir daug, daug, daug nemalonių dalykų, kurie gali ištikti Slurm SRE dalyvį jo realiame darbe.
Mes pasiruošę susitvarkyti su bet kuo... ir su visais.
Mūsų ilgai kenčianti svetainė susideda iš kelių mikropaslaugų. Jo užduotis – apibendrinti visų kino teatrų pasirodymus, kainas ir laisvas vietas, rodo filmų anonsus, leidžia pasirinkti kino teatrą, spektaklį, salę ir vietą, rezervuoti bilietus ir sumokėti už juos. Apskritai viskas, apie ką žiūrovas gali tik pasvajoti. Tačiau vartotojas net neįtaria, kokia titaniška kova dėl svetainės stabilumo ir prieinamumo vyksta viduje.
Intensyviai svetainei sugeneravome SLO, SLI, SLA rodiklius, sukūrėme architektūrą ir infrastruktūrą, įdiegėme svetainę, nustatėme stebėjimą ir įspėjimus. Ir einam.
SLO, SLI, SLA
SLI – aptarnavimo lygio rodikliai. SLO yra paslaugų lygio tikslai. SLA – paslaugų lygio sutartys.
SLA yra ITIL metodologijos terminas, reiškiantis formalų paslaugos kliento ir jo tiekėjo susitarimą, kuriame aprašomas paslaugos aprašymas, šalių teisės ir pareigos bei, svarbiausia, sutartas šios paslaugos teikimo kokybės lygis. paslauga.
SLO yra paslaugos lygio tikslas: paslaugų lygio tikslinė vertė arba verčių diapazonas, kurį matuoja SLI. Įprasta SLO reikšmė yra „SLI ≤ Target“ arba „ Lower Limit ≤ SLI ≤ Upper Limit“.
SLI yra paslaugų lygio rodiklis – kruopščiai apibrėžtas kiekybinis vieno teikiamos paslaugos lygio aspekto matas. Daugumos paslaugų raktas SLI laikomas užklausos delsa – kiek laiko užtrunka atsakymo į užklausą grąžinimas. Kiti įprasti SLI apima klaidų lygį, dažnai išreiškiamą visų gautų užklausų dalimi, ir sistemos pralaidumą, paprastai matuojamą užklausomis per sekundę.
Pirmiausia sudaužysime lėktuvus, o paskui merginas, o paskui merginas...
Vidiniai ir išoriniai veiksniai pradėjo „gadinti“ SLO nuo pat pirmųjų minučių. Viskas krito ant administratorių galvų – kūrėjų klaidos, infrastruktūros gedimai, lankytojų antplūdis ir DDoS atakos. Viskas, kas pablogina SLO.
„Brangūs dalyviai, aš skubu jums įtikti, pirmas dalykas, kurio jums nepavyksta, yra... viskas!
Pakeliui pranešėjai aptarė stabilumą, klaidų biudžetą, testavimo praktiką, trikdžių valdymą ir veiklos apkrovą.
Mes ne kurstytojai, ne staliai...
Tada dalyviai ėmė taisyti reikalus – svarbiausia suprasti, ko griebtis pirmiausia.
„- Viešpatie, aš niekada nemačiau, kad šitaip lūžtų, tokia forma ir tokioje padėtyje!
Taigi, įvyko nelaimė. Mokėjimų apdorojimo paslauga neveikia. Kaip elgtis, kad funkcionalumas būtų atkurtas per trumpiausią įmanomą laiką?
Ekspertai, meiliai žvelgdami į dalyvius, ruošia dar vieną triuką.
Kiekviena komanda organizuoja nelaimingo atsitikimo likvidavimo grupės darbą – įtraukia kolegas, informuoja suinteresuotas šalis (suinteresuotas šalis). Kartu nustatomi prioritetai. Tokiu būdu dalyviai treniravosi dirbti esant spaudimui itin riboto laiko sąlygomis.
"Koks siaubas išėjo?!"
Iškvėpkite... ir užbaikite pratimą
Kartu su pranešėjais, išsprendus kiekvieną problemą ir laikinai stabilizavus svetainę, komanda ištyrė incidentus SRE požiūriu. Išsamiai išanalizavome problemas – jų atsiradimo priežastis, šalinimo eigą. Po to tiek po komandos, tiek kolektyviai priėmėme sprendimus, kaip toliau jų užkirsti kelią: kaip pagerinti stebėseną, kaip išmintingai keisti architektūrą, kaip koreguoti požiūrį į plėtrą ir veikimą, kaip koreguoti reglamentus. Pranešėjai demonstravo pomirtinio vedimo praktiką.
„Kas dar nori kankinimų! - Aš!"
Komandų laimėjimai buvo griežtai ir aiškiai užfiksuoti elektroninėje švieslentėje.
Už pirmąsias vietas – priedas iš dalininkų.
Šaltinis: www.habr.com