Ekipi ynë i pëlqen eksperimentet. Çdo Slurm nuk është një përsëritje statike e të mëparshmeve, por një reflektim mbi përvojën dhe një kalim nga e mira në më të mirë. Por me vendosëm të aplikonim një format krejtësisht të ri - t'u japim pjesëmarrësve kushte sa më të afërta për të "luftuar".
Nëse përshkruajmë shkurt atë që bëmë gjatë kursit intensiv: “Ne ndërtojmë, thyejmë, riparojmë,
ne po studiojmë." SRE vlen pak në teori - vetëm praktikë, zgjidhje reale, probleme reale.
Pjesëmarrësit u ndanë në ekipe në mënyrë që një shpirt i fuqishëm konkurrues të mos lejonte askënd të binte në gjumë ose të lëshonte "Angry Birds" në iPhone, duke ndjekur shembullin e Dmitry Anatolyevich.
Problemet, defektet, gabimet dhe detyrat iu dhanë pjesëmarrësve nga katër mentorë. Ivan Kruglov, Zhvilluesi kryesor në Booking.com (Holandë). Ben Tyler, Zhvilluesi kryesor në Booking.com (SHBA). Eduard Medvedev, CTO në Tungsten Labs (Gjermani). Evgeniy Varavva, zhvillues i përgjithshëm në Google (San Francisko).
Për më tepër, pjesëmarrësit ndahen në ekipe dhe konkurrojnë me njëri-tjetrin. Interesante?
Ivan, Ben, Eduard dhe Evgeniy shikojnë pjesëmarrësit e varfër Slurm SRE me vështrime të mira leniniste përpara fillimit të konkursit.
Pra detyra:
Ne jemi tanët, do të ndërtojmë një botë të re...
Ekziston një faqe interneti për grumbullimin e biletave të filmit. Incidentet janë shpikur nga mentorët në një skenar të para-punuar (megjithëse askush nuk përjashton improvizimin veçanërisht të sofistikuar dhe tinëzar), performanca e sitit përshkruhet nga metrika të ndryshme. Problemet mund të jenë shumë të ndryshme: biletat për teatrin Moulin Rouge nuk ngarkohen në bazën e të dhënave; posterat e filmave dhe shfaqjeve ngarkohen në bazën e të dhënave në më shumë se 10 sekonda; përshkrimi i një filmi individual ngrin; 0,1% e porosive janë tashmë të rezervuara; Herë pas here, sistemi i përpunimit të pagesave rrëzohet për një ose dy minuta. Dhe shumë, shumë, shumë gjëra të pakëndshme që mund t'i ndodhin një pjesëmarrësi Slurm SRE në punën e tij të vërtetë.
Ne jemi gati të trajtojmë çdo gjë...dhe të gjithë.
Faqja jonë e internetit e vuajtur përbëhet nga disa mikroshërbime. Detyra e tij është të grumbullojë të dhëna për shfaqjet, çmimet dhe vendet e disponueshme nga të gjitha kinematë; ai tregon njoftimet e filmave, ju lejon të zgjidhni një kinema, shfaqje, sallë dhe vend, të rezervoni dhe paguani biletat. Në përgjithësi, gjithçka që shikuesi mund të ëndërrojë vetëm. Por përdoruesi as nuk dyshon se çfarë lufte titanike për stabilitetin dhe aksesin e faqes po ndodh brenda.
Për sitin intensiv, ne krijuam tregues SLO, SLI, SLA, zhvilluam arkitekturë dhe infrastrukturë, vendosëm sitin, vendosëm monitorimin dhe sinjalizimin. Dhe largohemi.
SLO, SLI, SLA
SLI - treguesit e nivelit të shërbimit. SLO-të janë qëllime të nivelit të shërbimit. SLA - marrëveshje të nivelit të shërbimit.
SLA është një term i metodologjisë ITIL që tregon një marrëveshje formale midis klientit të një shërbimi dhe furnizuesit të tij, që përmban një përshkrim të shërbimit, të drejtat dhe detyrimet e palëve dhe, më e rëndësishmja, nivelin e dakorduar të cilësisë për ofrimin e këtij shërbimi. shërbimi.
Një SLO është një objektiv i nivelit të shërbimit: një vlerë e synuar ose një gamë vlerash për një nivel shërbimi që matet nga SLI. Një vlerë normale për SLO është "SLI ≤ Target" ose "Limit Lower ≤ SLI ≤ Upper Limit".
SLI është një tregues i nivelit të shërbimit - një masë sasiore e përcaktuar me kujdes e një aspekti të nivelit të shërbimit të ofruar. Për shumicën e shërbimeve, SLI kyç konsiderohet të jetë vonesa e kërkesës - sa kohë duhet për të kthyer një përgjigje ndaj një kërkese. SLI-të e tjera të zakonshme përfshijnë shkallën e gabimit, shpesh e shprehur si një pjesë e të gjitha kërkesave të marra, dhe xhiron e sistemit, zakonisht i matur në kërkesa për sekondë.
Fillimisht do të thyejmë aeroplanët, pastaj vajzat dhe më pas vajzat...
Faktorët e brendshëm dhe të jashtëm filluan të "prishnin" SLO që në minutat e para. Gjithçka ra mbi kokat e administratorëve - gabimet e zhvilluesve, dështimet e infrastrukturës, një fluks vizitorësh dhe sulme DDoS. Gjithçka që përkeqëson SLO.
"- Të dashur pjesëmarrës, nxitoj t'ju kënaq, gjëja e parë që dështoni është... gjithçka!"
Gjatë rrugës, folësit diskutuan për stabilitetin, buxhetin e gabimeve, praktikën e testimit, menaxhimin e ndërprerjeve dhe ngarkesën operacionale.
Ne nuk jemi stoker, as marangoz...
Pastaj pjesëmarrësit filluan të rregullojnë gjërat - gjëja kryesore është të kuptoni se çfarë të kapni së pari.
"- Zot, nuk e kam parë kurrë të thyhet kështu, në këtë formë dhe në një pozicion të tillë!"
Pra, ka ndodhur një aksident. Shërbimi i përpunimit të pagesave nuk funksionon. Si të veproni për të rivendosur funksionalitetin në kohën më të shkurtër të mundshme?
Ekspertët, duke i parë me dashuri pjesëmarrësit, po përgatisin një tjetër truk.
Secili ekip organizon punën e grupit për eliminimin e aksidentit - përfshin kolegët, njofton palët e interesuara (aktorët). Në të njëjtën kohë, përcaktohen prioritetet. Në këtë mënyrë, pjesëmarrësit u trajnuan për të punuar nën presion në kushte kohore jashtëzakonisht të kufizuara.
“Çfarë tmerri ka dalë?!”
Nxirrni frymën... dhe përfundoni ushtrimin
Së bashku me folësit, pasi çdo problem u zgjidh dhe vendi u stabilizua përkohësisht, ekipi studioi incidentet nga një këndvështrim SRE. Ne i analizuam problemet në detaje - shkaqet e shfaqjes, ecuria e eliminimit. Pas kësaj, si ekip për ekip ashtu edhe kolektivisht, morëm vendime se si t'i parandalojmë më tej: si të përmirësojmë monitorimin, si të ndryshojmë me mençuri arkitekturën, si të rregullojmë qasjen ndaj zhvillimit dhe funksionimit, si të korrigjojmë rregulloret. Folësit demonstruan praktikën e kryerjes së pas vdekjes.
“Kush do tjetër mundim! - Unë!"
Sukseset e skuadrave u regjistruan rreptësisht dhe qartë në tabelën elektronike të rezultateve.
Për vendet e para - një bonus nga palët e interesuara.
Burimi: www.habr.com