Echipa noastră adoră experimentele. Fiecare Sloerm nu este o repetare statică a celor anterioare, ci o reflecție asupra experienței și o trecere de la bun la excelență. Dar cu am decis să aplicăm un format complet nou — să oferim participanților condiții cât mai apropiate de cele „de luptă”.
Dacă trebuie să rezumăm ce am făcut în timpul intensivelor: „Construiți, distrugeți, reparați,
învățați”. SRE nu valorează foarte mult în teorie — doar practica, soluțiile reale, problemele reale.
Participanții au fost împărțiți în echipe, astfel încât spiritul competițional energic să nu permită nimănui să adormă sau să deschidă „Angry Birds” pe iPhone, asemenea lui Dmitri Anatolevici.
Problemele, bug-urile și sarcinile au fost asigurate participanților de patru mentori. Ivan Kruglov, Principal Developer la Booking.com (Olanda). Ben Tyler, Principal Developer la Booking.com (SUA). Eduard Medvedev, CTO la Tungsten Labs (Germania). Evgheni Varavva, dezvoltator cu experiență diversă la Google (San Francisco).
Și, pe deasupra, participanții au fost împărțiți în echipe — și concurează între ei. Interesant?
Ivan, Ben, Eduard și Evgheni privesc cu un zâmbet prietenos asupra săracilor participanți la Sloerm SRE înainte de începerea competiției.
Așadar, sarcina este:
Noi, noi vom construi o lume nouă…
Există un site de agregare a biletelor la cinema. Incidentele sunt create de mentori în conformitate cu un scenariu elaborat în prealabil (deși nimeni nu exclude o improvizație sofisticată și vicleană), funcționalitatea site-ului este descrisă prin diverse metrice. Problemele pot varia: biletele teatrului „Moulin Rouge” nu se încarcă în baza de date; afișele filmelor și spectacolelor se încarcă în baza de date în mai mult de 10 secunde; descrierea unui film se blochează; 0,1% din comenzi ajung pe locurile deja rezervate; sistemul de procesare a plăților se întrerupe periodic timp de un minut sau două. Și multe, multe, multe alte neplăceri care pot cădea pe umerii participanților la Sloerm SRE în munca lor reală.
Suntem pregătiți să facem față tuturor… și tuturor.
Sit-ul nostru, mult încercat, este format din mai multe microservicii. Sarcina sa este agregarea datelor despre sesiuni, prețuri și locuri disponibile din toate cinematografiile, afișează anunțuri despre filme, permite alegerea cinematografului, a sesiunii, a sălii și a locului, rezervarea și plata biletelor. În general, tot ce poate visa un spectator. Totuși, utilizatorul nici măcar nu bănuiește ce luptă titanică se desfășoară pentru stabilitatea și disponibilitatea site-ului.
Pentru site-ul în intensificare, am formulat parametrii SLO, SLI, SLA, am dezvoltat arhitectura și infrastructura, am desfășurat site-ul, am configurat monitorizarea și alertarea. Și a început.
SLO, SLI, SLA
SLI - indicatori de nivel de serviciu. SLO - obiective de nivel de serviciu. SLA - acorduri de nivel de serviciu.
SLA este un termen din metodologia ITIL, care desemnează un contract formal între clientul serviciului și furnizorul său, conținând descrierea serviciului, drepturile și obligațiile părților și, cel mai important, nivelul de calitate convenit pentru furnizarea acestui serviciu.
SLO este obiectivul de nivel de serviciu: o valoare țintă sau un interval de valori pentru nivelul de serviciu, care este măsurat de SLI. Valoarea normală pentru SLO este „SLI ≤ valoare țintă” sau „limita inferioară ≤ SLI ≤ limita superioară”.
SLI este un indicator de nivel de serviciu - o măsură cantitativă bine definită a unui aspect al nivelului de serviciu furnizat. Pentru cele mai multe servicii, SLI-ul cheie este timpul de răspuns – cât timp este necesar pentru a returna un răspuns la o cerere. Alte SLI-uri comune includ rata de erori, adesea exprimată ca proporție din toate cererile primite, și capacitatea sistemului, de obicei măsurată în cereri pe secundă.
În primul rând, vom doborî avioanele, iar apoi fetele, iar fetele le vom lăsa pe urmă...
Factorii interni și externi, încă din primele minute, au început să „strice” SLO. Administratorii au fost confruntați cu tot - erori ale dezvoltatorilor, defecțiuni ale infrastructurii, un aflux de vizitatori și atacuri DDoS. Tot ceea ce îmbunătățește SLO-ul.
„- Dragi participanți, mă grăbesc să vă bucur, în primul rând, va cădea… totul!”
Pe parcurs, speakerii au discutat despre reziliență, bugetul de erori, practicile de testare, gestionarea întreruperilor și a sarcinii operaționale.
Nu suntem cărbunari, nu suntem tâmplari...
Aici participanții au început să repare - este esențial să înțelegem cu ce să începem.
«- Dumnezeule, niciodată nu am văzut ceva să se strice așa, în această formă și în această poziție!»
Deci, a avut loc un incident. Serviciul de procesare a plăților a căzut. Cum să acționezi pentru a restabili funcționalitatea în cel mai scurt timp?
Experții, privindu-i blând pe participanți, pregătesc următoarea capcană.
Fiecare echipă își organizează munca grupului pentru eliminarea incidentului - implică colegi, informează părțile interesate. De asemenea, se stabilesc priorități. Astfel, participanții s-au antrenat să lucreze sub presiune în condiții de timp extrem de limitat.
«- Ce grozăvie a ieșit?!»
Au respirat adânc... și au terminat exercițiul.
Împreună cu speakerii, după fiecare problemă rezolvată și stabilizat temporar site-ul, echipele au analizat incidentele din perspectiva SRE. Au analizat în detaliu problemele - cauzele apariției, desfășurarea eliminării. După aceasta, atât pe echipe, cât și colectiv, au luat decizii în privința prevenirii lor ulterioare: cum să îmbunătățească monitorizarea, cum să schimbe corect arhitectura, cum să corecteze abordările de dezvoltare și operare, cum să ajusteze reglementările. Speakerii au demonstrat practica desfășurării post-mortem.
«- Cine mai vrea suferință! — Eu!»
Pe tabela electronică, succesele echipelor erau fixate clar și riguros.
Pentru primele locuri - un premiu din partea părților interesate.
Sursa: habr.com
