Echipa noastră iubește experimentele. Fiecare Slurm nu este o repetiție statică a celor anterioare, ci o reflecție asupra experienței și o tranziție de la bine la mai bun. Dar cu am decis să aplicăm un format complet nou - să oferim participanților condiții cât mai apropiate de „luptă”.
Dacă descriem pe scurt ce am făcut în timpul cursului intensiv: „Construim, spargem, reparăm,
studiem.” SRE valorează puțin în teorie - doar practică, soluții reale, probleme reale.
Participanții au fost împărțiți în echipe, astfel încât un spirit competitiv viguros să nu permită nimănui să adoarmă sau să lanseze „Angry Birds” pe iPhone, urmând exemplul lui Dmitri Anatolyevich.
Probleme, erori, erori și sarcini au fost furnizate participanților de către patru mentori. Ivan Kruglov, dezvoltator principal la Booking.com (Olanda). Ben Tyler, dezvoltator principal la Booking.com (SUA). Eduard Medvedev, CTO la Tungsten Labs (Germania). Evgeniy Varavva, dezvoltator general la Google (San Francisco).
În plus, participanții sunt împărțiți în echipe și concurează între ei. Interesant?
Ivan, Ben, Eduard și Evgeniy se uită la bieții participanți la Slurm SRE cu strabii leniniste amabile înainte de începerea competiției.
Deci sarcina:
Suntem ai noștri, vom construi o lume nouă...
Există un site web de agregare a biletelor de film. Incidentele sunt inventate de mentori într-un scenariu pre-lucrat (deși nimeni nu exclude improvizația deosebit de sofisticată și insidioasă), performanța site-ului este descrisă de diverse metrici. Problemele pot fi foarte diferite: biletele pentru teatrul Moulin Rouge nu sunt încărcate în baza de date; postere de filme și spectacole sunt încărcate în baza de date în mai mult de 10 secunde; descrierea unui film individual îngheață; 0,1% din comenzi sunt deja rezervate; Din când în când, sistemul de procesare a plăților se blochează pentru un minut sau două. Și multe, multe, multe lucruri neplăcute care se pot întâmpla unui participant Slurm SRE la locul său de muncă adevărat.
Suntem gata să ne descurcăm cu orice... și pe toată lumea.
Site-ul nostru de lungă suferință constă din mai multe microservicii. Sarcina sa este de a agrega date despre spectacole, prețuri și locuri disponibile din toate cinematografele, afișează anunțuri de film, vă permite să selectați un cinema, un spectacol, o sală și un loc, să rezervați și să plătiți biletele. În general, tot ceea ce privitorul nu poate decât să viseze. Dar utilizatorul nici măcar nu bănuiește ce luptă titanică pentru stabilitatea și accesibilitatea site-ului are loc în interior.
Pentru site-ul intensiv, am generat indicatori SLO, SLI, SLA, am dezvoltat arhitectura și infrastructura, am implementat site-ul, am configurat monitorizarea și alertarea. Și plecăm.
SLO, SLI, SLA
SLI - indicatori de nivel de serviciu. SLO-urile sunt obiective la nivel de serviciu. SLA - acorduri de nivel de servicii.
SLA este un termen de metodologie ITIL care denotă un acord formal între clientul unui serviciu și furnizorul acestuia, care conține o descriere a serviciului, drepturile și obligațiile părților și, cel mai important, nivelul de calitate convenit pentru furnizarea acestui serviciu. serviciu.
Un SLO este un obiectiv de nivel de serviciu: o valoare țintă sau un interval de valori pentru un nivel de serviciu care este măsurat de SLI. O valoare normală pentru SLO este „SLI ≤ Target” sau „Lower Limit ≤ SLI ≤ Upper Limit”.
SLI este un indicator al nivelului de serviciu - o măsură cantitativă atent definită a unui aspect al nivelului de serviciu furnizat. Pentru majoritatea serviciilor, cheia SLI este considerată a fi latența cererii - cât timp durează pentru a returna un răspuns la o solicitare. Alte SLI obișnuite includ rata de eroare, adesea exprimată ca o fracțiune din toate cererile primite, și debitul sistemului, de obicei măsurat în cereri pe secundă.
În primul rând, vom sparge avioanele, apoi fetele, apoi fetele...
Factorii interni și externi au început să „strice” SLO încă din primele minute. Totul a căzut pe capul administratorilor – greșeli ale dezvoltatorilor, defecțiuni ale infrastructurii, un aflux de vizitatori și atacuri DDoS. Tot ceea ce agravează SLO.
„- Dragi participanți, mă grăbesc să vă mulțumesc, primul lucru pe care îl eșuați este... totul!”
Pe parcurs, vorbitorii au discutat despre stabilitate, bugetul de erori, practica de testare, managementul întreruperilor și sarcina operațională.
Nu suntem fogări, nu dulgheri...
Apoi participanții au început să repare lucrurile - principalul lucru este să înțeleagă ce să apuce mai întâi.
„- Doamne, n-am văzut niciodată să se spargă așa, în această formă și într-o asemenea poziție!”
Deci, a avut loc un accident. Serviciul de procesare a plăților este oprit. Cum să acționezi pentru a restabili funcționalitatea în cel mai scurt timp posibil?
Experții, privind cu afecțiune la participanți, pregătesc un alt truc.
Fiecare echipă organizează munca grupului pentru eliminarea accidentului - implică colegii, anunță părțile interesate (părți interesate). În același timp, se stabilesc prioritățile. În acest fel, participanții s-au antrenat să lucreze sub presiune în condiții de timp extrem de limitate.
„Ce fel de groază a ieșit?!”
Expiră... și termină exercițiul
Împreună cu difuzoarele, după ce fiecare problemă a fost rezolvată și șantierul a fost stabilizat temporar, echipa a studiat incidentele din punct de vedere SRE. Am analizat problemele în detaliu - cauzele apariției, progresul eliminării. După aceea, atât echipă cu echipă, cât și colectiv, am luat decizii cu privire la cum să le prevenim în continuare: cum să îmbunătățim monitorizarea, cum să schimbăm cu înțelepciune arhitectura, cum să ajustam abordarea dezvoltării și funcționării, cum să corectăm reglementările. Vorbitorii au demonstrat practica conducerii post-mortem.
„Cine mai vrea chinul! - Eu!"
Succesele echipelor au fost consemnate strict și clar pe tabela electronică.
Pentru primele locuri - un bonus de la părțile interesate.
Sursa: www.habr.com