Nia teamo amas eksperimentojn. Ĉiu Slurm ne estas senmova ripeto de la antaŭaj, sed pripenso pri la sperto kaj transiro de bona al pli bona. Sed kun ni decidis apliki tute novan formaton - doni al la partoprenantoj kondiĉojn kiel eble plej proksimajn al "batali".
Se ni koncize skizas tion, kion ni faris dum la intensa kurso: „Ni konstruas, ni rompas, ni riparas,
ni studas." SRE malmulte valoras en nura teorio - nur praktiko, veraj solvoj, realaj problemoj.
La partoprenantoj estis dividitaj en teamojn, por ke vigla konkurenciva spirito ne permesu al iu ajn ekdormi aŭ lanĉi "Angry Birds" sur la iPhone, laŭ la ekzemplo de Dmitry Anatolyevich.
Problemoj, eraroj, cimoj kaj taskoj estis provizitaj al la partoprenantoj de kvar mentoroj. Ivan Kruglov, Ĉefprogramisto ĉe Booking.com (Nederlando). Ben Tyler, Ĉefprogramisto ĉe Booking.com (Usono). Eduard Medvedev, CTO ĉe Tungsten Labs (Germanio). Evgeniy Varavva, ĝenerala programisto ĉe Guglo (San Francisco).
Krome, la partoprenantoj estas dividitaj en teamojn kaj konkuras unu kun la alia. Interesaj?
Ivan, Ben, Eduard kaj Evgeniy rigardas la kompatindajn partoprenantojn de Slurm SRE per afablaj leninismaj strabuloj antaŭ la komenco de la konkurso.
Do la tasko:
Ni estas niaj, ni konstruos novan mondon...
Estas retejo de agregaciilo de filmaj biletoj. Okazaĵoj estas inventitaj de mentoroj en antaŭlaborita scenaro (kvankam neniu ekskludas precipe sofistikan kaj insidan improvizon), la agado de la retejo estas priskribita per diversaj metrikoj. La problemoj povas esti tre malsamaj: biletoj por la teatro Moulin Rouge ne estas ŝarĝitaj en la datumbazon; afiŝoj de filmoj kaj prezentoj estas ŝarĝitaj en la datumbazon en pli ol 10 sekundoj; la priskribo de individua filmo frostiĝas; 0,1% de mendoj jam estas rezervitaj; De tempo al tempo la pagpretiga sistemo kraŝas dum unu aŭ du minutoj. Kaj multaj, multaj, multaj malagrablaj aferoj, kiuj povas okazi al partoprenanto de Slurm SRE ĉe lia vera laboro.
Ni pretas pritrakti ion ajn... kaj ĉiujn.
Nia long-suferanta retejo konsistas el pluraj mikroservoj. Ĝia tasko estas kunigi datumojn pri spektakloj, prezoj kaj disponeblaj sidlokoj de ĉiuj kinejoj; ĝi montras filmanoncojn, ebligas al vi elekti kinejon, spektaklon, salonon kaj lokon, rezervi kaj pagi biletojn. Ĝenerale, ĉio, pri kio la spektanto nur povas revi. Sed la uzanto eĉ ne suspektas, kia titana lukto por la stabileco kaj alirebleco de la retejo okazas interne.
Por la intensa retejo, ni generis SLO, SLI, SLA indikilojn, evoluigis arkitekturon kaj infrastrukturon, deplojis la retejon, starigis monitoradon kaj atentigon. Kaj ni foriras.
SLO, SLI, SLA
SLI - servonivelaj indikiloj. SLOoj estas servnivelaj celoj. SLA - servnivelaj interkonsentoj.
SLA estas ITIL-metoda termino, kiu indikas formalan interkonsenton inter la kliento de servo kaj ĝia provizanto, enhavanta priskribon de la servo, la rajtojn kaj devontigojn de la partioj kaj, plej grave, la interkonsentitan nivelon de kvalito por la provizado de ĉi tio. servo.
SLO estas servnivela celo: celvaloro aŭ gamo de valoroj por serva nivelo, kiu estas mezurita de la SLI. Normala valoro por SLO estas "SLI ≤ Celo" aŭ "Malsupra Limo ≤ SLI ≤ Supra Limo".
La SLI estas servnivela indikilo - singarde difinita kvanta mezuro de unu aspekto de la nivelo de servo provizita. Por plej multaj servoj, la ŝlosila SLI estas konsiderata kiel peta latenco - kiom da tempo necesas por resendi respondon al peto. Aliaj oftaj SLIoj inkludas erarprocenton, ofte esprimitan kiel frakcio de ĉiuj petoj ricevitaj, kaj sistemtrairo, kutime mezurita en petoj je sekundo.
Antaŭ ĉio, ni rompos la aviadilojn, kaj poste la knabinojn, kaj poste la knabinojn...
Internaj kaj eksteraj faktoroj komencis "difekti" SLO de la unuaj minutoj. Ĉio falis sur la kapojn de la administrantoj - eraroj de programistoj, misfunkciadoj de infrastrukturoj, enfluo de vizitantoj kaj atakoj DDoS. Ĉio, kio plimalbonigas SLO.
"- Karaj partoprenantoj, mi rapidas plaĉi al vi, la unua afero, kiun vi malsukcesas, estas... ĉio!"
Survoje, la prelegantoj diskutis pri stabileco, erara buĝeto, testa praktiko, administrado de interrompoj kaj funkcia ŝarĝo.
Ni ne estas hejmistoj, ne ĉarpentistoj...
Tiam la partoprenantoj komencis ripari aferojn - la ĉefa afero estas kompreni, kion unue kapti.
"- Sinjoro, mi neniam vidis ĝin rompi tiel, en ĉi tiu formo kaj en tia pozicio!"
Do, okazis akcidento. La pagpretiga servo malfunkcias. Kiel agi por restarigi funkciecon en la plej mallonga ebla tempo?
La fakuloj, ame rigardante la partoprenantojn, preparas alian trukon.
Ĉiu teamo organizas la laboron de la grupo por forigi la akcidenton - implikas kolegojn, sciigas interesatojn (koncernatojn). Samtempe, prioritatoj estas fiksitaj. Tiamaniere, la partoprenantoj trejniĝis por labori sub premo en ekstreme limigitaj tempokondiĉoj.
"Kia hororo aperis?!"
Ekspiri... kaj fini la ekzercon
Kune kun la parolantoj, post kiam ĉiu problemo estis solvita kaj la retejo estis provizore stabiligita, la teamo studis la okazaĵojn el SRE-punkto. Ni analizis la problemojn detale - la kaŭzojn de apero, la progreson de elimino. Post tio, teame kaj kolektive, ni faris decidojn pri kiel plue malhelpi ilin: kiel plibonigi monitoradon, kiel saĝe ŝanĝi la arkitekturon, kiel ĝustigi la aliron al disvolviĝo kaj funkciado, kiel korekti regularojn. La prelegantoj montris la praktikon fari postmortem.
“Kiu alia volas turmenton! - Mi!"
La sukcesoj de la teamoj estis strikte kaj klare registritaj sur la elektronika poenttabulo.
Por unuaj lokoj - gratifiko de koncernatoj.
fonto: www.habr.com