Al nostre equip li encanten els experiments. Cada Slurm no és una repetició estàtica dels anteriors, sinó una reflexió sobre l'experiència i una transició del bé al millor. Però amb vam decidir aplicar un format completament nou: donar als participants condicions el més properes possibles al "combat".
Si resumim breument què vam fer durant el curs intensiu: “Construïm, trenquem, reparem,
estem estudiant". SRE val poc en teoria: només pràctica, solucions reals, problemes reals.
Els participants es van dividir en equips perquè un esperit competitiu vigorós no permetés a ningú adormir-se o llançar "Angry Birds" a l'iPhone, seguint l'exemple de Dmitry Anatolyevich.
Quatre mentors van proporcionar problemes, errors, errors i tasques als participants. Ivan Kruglov, desenvolupador principal de Booking.com (Països Baixos). Ben Tyler, desenvolupador principal de Booking.com (EUA). Eduard Medvedev, CTO de Tungsten Labs (Alemanya). Evgeniy Varavva, desenvolupador general de Google (San Francisco).
A més, els participants es divideixen en equips i competeixen entre ells. Interessant?
L'Ivan, el Ben, l'Eduard i l'Evgeniy miren els pobres participants de Slurm SRE amb amables ulls leninistes abans de l'inici de la competició.
Així que la tasca:
Som nostres, construirem un món nou...
Hi ha un lloc web d'agregació d'entrades de pel·lícules. Els incidents són inventats pels mentors en un escenari pre-treballat (tot i que ningú exclou la improvisació especialment sofisticada i insidiosa), el rendiment del lloc es descriu per diverses mètriques. Els problemes poden ser molt diferents: les entrades per al teatre Moulin Rouge no es carreguen a la base de dades; els pòsters de pel·lícules i actuacions es carreguen a la base de dades en més de 10 segons; la descripció d'una pel·lícula individual es congela; El 0,1% de les comandes ja estan reservades; De tant en tant, el sistema de processament de pagaments es bloqueja durant un minut o dos. I moltes, moltes, moltes coses desagradables que poden passar a un participant de Slurm SRE a la seva feina real.
Estem preparats per gestionar qualsevol cosa... i tothom.
El nostre sofert lloc web consta de diversos microserveis. La seva tasca és agregar dades d'espectacles, preus i seients disponibles de tots els cinemes; mostra anuncis de pel·lícules, permet seleccionar un cinema, espectacle, sala i lloc, reservar i pagar entrades. En general, tot allò que l'espectador només pot somiar. Però l'usuari ni tan sols sospita quina lluita titànica per l'estabilitat i l'accessibilitat del lloc està passant a l'interior.
Per al lloc intensiu, vam generar indicadors SLO, SLI, SLA, vam desenvolupar l'arquitectura i la infraestructura, vam desplegar el lloc, vam configurar el seguiment i l'alerta. I marxem.
SLO, SLI, SLA
SLI - indicadors de nivell de servei. Els SLO són objectius de nivell de servei. SLA - acords de nivell de servei.
SLA és un terme de metodologia ITIL que denota un acord formal entre el client d'un servei i el seu proveïdor, que conté una descripció del servei, els drets i obligacions de les parts i, el més important, el nivell de qualitat acordat per a la prestació d'aquest. servei.
Un SLO és un objectiu de nivell de servei: un valor objectiu o rang de valors per a un nivell de servei que es mesura pel SLI. Un valor normal per a SLO és "SLI ≤ Target" o "Límit inferior ≤ SLI ≤ Límit superior".
El SLI és un indicador de nivell de servei: una mesura quantitativa acuradament definida d'un aspecte del nivell de servei prestat. Per a la majoria de serveis, l'SLI clau es considera la latència de la sol·licitud: el temps que triga a tornar una resposta a una sol·licitud. Altres SLI comuns inclouen la taxa d'error, sovint expressada com una fracció de totes les sol·licituds rebudes, i el rendiment del sistema, mesurat normalment en sol·licituds per segon.
Primer de tot, trencarem els avions, i després les noies, i després les noies...
Els factors interns i externs van començar a "malatar" SLO des dels primers minuts. Tot va caure al cap dels administradors: errors dels desenvolupadors, errors en la infraestructura, afluència de visitants i atacs DDoS. Tot el que empitjora SLO.
"- Benvolguts participants, m'afanyo a agradar-vos, el primer que falleu és... tot!"
Durant el camí, els ponents van parlar d'estabilitat, pressupost d'errors, pràctiques de prova, gestió d'interrupcions i càrrega operativa.
No som fogoners, ni fusters...
Aleshores, els participants van començar a arreglar les coses: el més important és entendre què cal agafar primer.
"- Senyor, mai l'he vist trencar-se així, en aquesta forma i en tal posició!"
Així doncs, es va produir un accident. El servei de processament de pagaments està caigut. Com actuar per restaurar la funcionalitat en el menor temps possible?
Els experts, mirant afectuosament els participants, estan preparant un altre truc.
Cada equip organitza el treball del grup per eliminar l'accident: implica els companys, notifica les parts interessades (stakeholders). Al mateix temps, s'estableixen prioritats. D'aquesta manera, els participants es van entrenar per treballar sota pressió en condicions de temps extremadament limitats.
"Quin tipus d'horror ha sortit?!"
Exhala... i acaba l'exercici
Juntament amb els ponents, després de resoldre cada problema i estabilitzar temporalment el solar, l'equip va estudiar les incidències des del punt de vista de l'SRE. Hem analitzat els problemes en detall: les causes de l'aparició, el progrés de l'eliminació. Després d'això, tant equip per equip com col·lectivament, vam prendre decisions sobre com prevenir-los encara més: com millorar la supervisió, com canviar l'arquitectura amb prudència, com ajustar l'enfocament de desenvolupament i funcionament, com corregir la normativa. Els ponents van demostrar la pràctica de la realització d'autopsia.
“Qui més vol turment! - Jo!"
Els èxits dels equips es van registrar de manera estricta i clara al marcador electrònic.
Per als primers llocs - una bonificació de les parts interessades.
Font: www.habr.com