El seminari web té un àudio deficient, així que vam fer una transcripció.
Em dic Medvedev Eduard. Avui parlaré de què és l'SRE, com va aparèixer l'SRE, quins són els criteris de treball dels enginyers SRE, una mica de criteris de fiabilitat, una mica del seu seguiment. Anirem per sobre, perquè no pots dir gaire en una hora, però et donaré materials per a una revisió addicional i tots t'esperem a . a Moscou a finals de gener.
Primer, parlem de què és SRE - Site Reliability Engineering -. I com va aparèixer com una posició separada, com una direcció separada. Tot va començar amb el fet que en els cercles de desenvolupament tradicionals, Dev i Ops són dos equips completament diferents, normalment amb dos objectius completament diferents. L'objectiu de l'equip de desenvolupament és implementar noves funcions per satisfer les necessitats empresarials. L'objectiu de l'equip d'operacions és assegurar-se que tot funcioni i que no es trenqui res. Òbviament, aquests objectius es contradiuen directament: perquè tot funcioni i no es trenqui res, és millor desplegar noves funcions el menys possible. A causa d'això, sorgeixen molts conflictes interns, que la metodologia que ara s'anomena DevOps està intentant resoldre.
El problema és que no tenim una definició clara de DevOps i una implementació clara de DevOps. Vaig parlar en una conferència a Ekaterinburg fa 2 anys, i fins ara la secció DevOps començava amb l'informe "Què és DevOps". El 2017, devops té gairebé 10 anys, però encara estem discutint sobre què és. I aquesta és una situació molt estranya que Google va intentar resoldre fa uns anys.
El 2016, Google va publicar un llibre anomenat "Enginyeria de fiabilitat del lloc". I de fet, va ser amb aquest llibre que va començar el moviment SRE. SRE és una opció específica per implementar el paradigma DevOps en una empresa específica. Els enginyers SRE es van marcar com a objectiu garantir un funcionament fiable dels sistemes. S'han extret principalment de desenvolupadors, de vegades d'administradors amb una sòlida formació en desenvolupament. I fan el que solien fer els administradors de sistemes, però una sòlida formació en desenvolupament i coneixement del sistema des del punt de vista del codi fa que aquestes persones no s'inclinen al treball administratiu rutinari, sinó que s'inclinen a l'automatització.
Resulta que el paradigma DevOps en equips SRE s'implementa pel fet que hi ha enginyers SRE que resolen problemes estructurals. Aquí està, la mateixa connexió entre Dev i Ops de la qual la gent parla des de fa 8 anys. El paper d'un SRE és similar al d'un arquitecte, ja que els novells no esdevenen SRE. Les persones al començament de la seva carrera no tenen encara cap experiència i no tenen l'amplitud de coneixements requerida. Perquè SRE requereix un coneixement molt sofisticat de què i quan exactament pot sortir malament. Per tant, aquí es necessita algun tipus d'experiència, per regla general, tant dins de l'empresa com fora.
Demanen si es descriurà la diferència entre SRE i devops. Acaba de ser descrita. Podem parlar del lloc de l'SRE en l'organització. A diferència de l'enfocament clàssic de DevOps, on Ops encara és un departament independent, SRE forma part de l'equip de desenvolupament. Estan involucrats en el desenvolupament del producte. Fins i tot hi ha un enfocament on SRE és un paper que passa d'un desenvolupador a un altre. Participen en les revisions de codi de la mateixa manera que, per exemple, els dissenyadors d'UX, els mateixos desenvolupadors i, de vegades, els gestors de productes. Els SRE operen en aquest mateix nivell. Necessitem la seva aprovació, necessitem la seva revisió, de manera que per a cada desplegament l'SRE digui: “D'acord, aquest desplegament, aquest producte no afectarà negativament la fiabilitat. I si ho fa, estarà dins d'uns límits acceptables". D'això també en parlarem.
En conseqüència, l'SRE té un veto sobre els canvis de codi. I, en general, això també comporta un petit conflicte si SRE s'implementa incorrectament. En aquest mateix llibre sobre l'enginyeria de fiabilitat del lloc, moltes parts, fins i tot més d'una, expliquen com evitar aquests conflictes.
La gent es pregunta com es relaciona l'SRE amb la seguretat de la informació. SRE no està directament implicat en la seguretat de la informació. Principalment a les grans empreses, això ho fan persones individuals, provadors i analistes. Però SRE també interactua amb ells en el sentit que algunes operacions, alguns compromisos, alguns desplegaments que afecten la seguretat també poden afectar la disponibilitat del producte. Per tant, SRE en general té interacció amb qualsevol equip, inclosos els de seguretat, inclosos els analistes. Per tant, els SRE es necessiten principalment quan s'intenta implementar DevOps, però la càrrega per als desenvolupadors és massa gran. És a dir, el propi equip de desenvolupament ja no pot fer front al fet que ara també han de ser responsables d'Os. I apareix un paper a part. Aquesta funció està prevista al pressupost. De vegades, aquest paper s'incorpora a la mida de l'equip, apareix una persona separada, de vegades un dels desenvolupadors es converteix en ella. Així apareix el primer SRE de l'equip.
La complexitat del sistema que es veu afectada per SRE, complexitat que afecta la fiabilitat operativa, pot ser necessària o accidental. La complexitat necessària és quan la complexitat del producte augmenta en la mesura que requereixen les noves característiques del producte. La complexitat aleatòria és quan la complexitat del sistema augmenta, però la característica del producte i els requisits empresarials no ho afecten directament. Resulta que el desenvolupador va cometre un error en algun lloc, o l'algoritme no és òptim, o s'introdueixen alguns interessos addicionals que augmenten la complexitat del producte innecessàriament. Un bon SRE sempre hauria d'evitar aquesta situació. És a dir, qualsevol commit, qualsevol desplegament, qualsevol sol·licitud d'extracció que augmenti la complexitat a causa d'addicions aleatòries s'hauria de bloquejar.
La pregunta és per què no només contractar un enginyer, un administrador de sistemes amb molts coneixements, per unir-se a l'equip. Se'ns diu que un desenvolupador en el paper d'un enginyer no és la solució de personal més òptima. Un desenvolupador en el paper d'enginyer no sempre és la solució de personal òptima, però el punt aquí és que un desenvolupador que es dedica a Ops té una mica més de ganes d'automatització, té una mica més de coneixements i habilitats per implementar-ho. automatització. I en conseqüència, reduïm no només el temps d'algunes operacions específiques, no només la rutina, sinó també paràmetres empresarials tan importants com MTTR (Mean Time To Recovery, temps de recuperació). Així, i d'això també en parlarem una mica més endavant, estalviem diners per a l'organització.
Ara parlem dels criteris per al treball SRE. I en primer lloc sobre la fiabilitat. En petites empreses i startups, sovint passa que la gent assumeix que si el servei està ben escrit, si el producte està escrit bé i correctament, funcionarà, no es trencarà. Això és tot, escrivim un bon codi, així que no hi ha res a trencar. El codi és molt senzill, no hi ha res a trencar. Són gairebé les mateixes persones que diuen que no necessitem proves, perquè, mira, aquests són tres mètodes VPI, per què molestar-te?
Tot això està malament, és clar. I aquesta gent sovint es fa mal amb aquest tipus de codi a la pràctica, perquè les coses es trenquen. De vegades les coses es trenquen de les maneres més imprevisibles. De vegades la gent diu que no, que no passarà mai. I encara passa. Passa força sovint. I és per això que ningú s'esforça mai per aconseguir el 100% de disponibilitat, perquè mai es produeix el 100% de disponibilitat. Aquesta és la norma. I per això sempre parlem de nou quan parlem de disponibilitat del servei. 2 nou, 3 nou, 4 nou, 5 nou. Si traduïm això en temps d'inactivitat, aleshores, per exemple, 5 nou són una mica més de 5 minuts d'inactivitat per any, 2 nou són 3,5 dies d'inactivitat.
Però és obvi que en algun moment hi ha una disminució del PDI i del retorn de la inversió. Passar de dos nou a tres nou significa reduir el temps d'inactivitat en més de 3 dies. Passar de quatre nou a cinc redueix el temps d'inactivitat en 47 minuts per any. I resulta que això pot no ser crític per als negocis. I, en general, la fiabilitat necessària no és un problema tècnic, en primer lloc, és un problema comercial, és un problema de producte. Quin nivell de temps d'inactivitat és acceptable per als usuaris del producte, què esperen, quant paguen, per exemple, quants diners perden, quants diners perd el sistema.
Una pregunta important és quina és la fiabilitat dels components restants. Perquè la diferència entre 4 i 5 nou no serà visible en un telèfon intel·ligent amb 2 nou de fiabilitat. A grans trets, si alguna cosa es trenca en un telèfon intel·ligent del vostre servei 10 vegades a l'any, probablement 8 vegades l'avaria es va produir al costat del sistema operatiu. L'usuari està acostumat a això i no li prestarà atenció una vegada més a l'any. Cal comparar el preu d'augmentar la fiabilitat i augmentar els beneficis.
Només al llibre sobre SRE hi ha un bon exemple d'augmentar a 4 nou de 3 nou. Resulta que l'augment de la disponibilitat és una mica inferior al 0,1%. I si els ingressos del servei són d'1 milió de dòlars anuals, l'augment dels ingressos és de 900 dòlars. Si augmentar la disponibilitat en nou ens costa menys de 900 dòlars anuals, l'augment té sentit financer. Si costa més de 900 dòlars anuals, ja no té sentit, perquè l'augment dels ingressos simplement no compensa els costos laborals i els costos dels recursos. I amb 3 nou ens n'hi haurà prou.
Aquest és, per descomptat, un exemple simplificat on totes les sol·licituds són iguals. I de 3 nou a 4 nou és bastant fàcil, però al mateix temps, per exemple, passar de 2 nou a 3 és ja un estalvi de 9 mil dòlars, pot tenir sentit financer. Naturalment, en realitat, no registrar una sol·licitud és pitjor que no mostrar una pàgina; les sol·licituds tenen pes diferents. Poden tenir criteris completament diferents des del punt de vista empresarial, però tot i així, per regla general, si no estem parlant de cap servei específic, aquesta és una aproximació bastant fiable.
Vam rebre una pregunta sobre si l'SRE és un dels coordinadors a l'hora d'escollir una solució arquitectònica per al servei. Això és acceptable pel que fa a la integració a la infraestructura existent perquè no hi hagi pèrdua en la seva estabilitat. Sí, els SRE influeixen de la mateixa manera en les sol·licituds d'extracció, les confirmacions i els llançaments; influeixen en l'arquitectura, la implementació de nous serveis, els microserveis i la implementació de noves solucions. Per què he dit abans que necessites experiència, necessites qualificacions? De fet, SRE és una de les veus de bloqueig de qualsevol solució arquitectònica i de programari. En conseqüència, un SRE com a enginyer ha, en primer lloc, no només entendre, sinó també comprendre com algunes decisions específiques afectaran la fiabilitat, l'estabilitat i entendre com això es relaciona amb les necessitats empresarials, i des de quin punt de vista això pot ser admissible, i amb la qual no ho és.
Per tant, ara és el moment de parlar de criteris de fiabilitat, que en SRE es defineixen tradicionalment com a SLA (Service Level Agreement). Probablement un terme conegut. SLI (indicador de nivell de servei). SLO (Service Level Objective). L'acord de nivell de servei és potser un terme significatiu, especialment si heu treballat amb xarxes, proveïdors i allotjament. Aquest és un acord general que descriu el rendiment de tot el vostre servei, penalitzacions, algunes penalitzacions per errors, mètriques i criteris. I SLI és la mètrica d'accessibilitat en si. És a dir, què pot ser SLI: temps de resposta del servei, nombre d'errors en percentatge. Això podria ser ample de banda si estem parlant d'algun tipus d'allotjament de fitxers. Si parlem d'algoritmes de reconeixement, l'indicador pot ser fins i tot, per exemple, la correcció de la resposta. SLO (Service Level Objective) és, respectivament, una combinació de l'indicador SLI, el seu valor i període.
Diguem que el SLA podria ser així. El servei està disponible el 99,95% del temps durant tot l'any. O 99 tiquets d'assistència tècnica crítica es tancaran en un termini de 3 hores per trimestre. O el 85% de les consultes es respondran en 1,5 segons cada mes. És a dir, a poc a poc anem entenent que els errors i els errors són força normals. Aquesta és una situació acceptable, ens ho estem planificant, fins i tot hi comptem en certa mesura. És a dir, SRE construeix sistemes que poden cometre errors, que han de respondre amb normalitat als errors i que els han de tenir en compte. I si és possible, haurien de gestionar els errors de manera que l'usuari no els noti o els noti, però hi ha algun tipus de solució perquè no s'ensorri del tot.
Per exemple, si pengeu un vídeo a YouTube i YouTube no el pot convertir immediatament, si el vídeo és massa gran, si el format no és òptim, la sol·licitud, naturalment, no fallarà amb un temps d'espera, YouTube no mostrarà un 502. error, YouTube dirà: "Ho hem creat tot, el teu vídeo s'està processant. Estarà llest en uns 10 minuts". Aquest és el principi de degradació graciosa, que és familiar, per exemple, des del desenvolupament frontal si ho heu fet alguna vegada.
Els propers termes dels quals parlarem, molt importants per treballar amb fiabilitat, amb errors, amb expectatives, són MTBF i MTTR. MTBF és el temps mitjà entre falles. MTTR Mean Time To Recovery, temps mitjà fins a la recuperació. És a dir, quant de temps ha passat des que es va detectar l'error, des que va aparèixer l'error fins que es va restablir el servei al funcionament totalment normal. MTBF es corregeix principalment treballant la qualitat del codi. És a dir, el fet que els SRE puguin dir “no”. I tot l'equip ha d'entendre que quan l'SRE diu "no", no ho diu perquè sigui perjudicial, no perquè sigui dolent, sinó perquè si no, tothom patirà.
De nou, hi ha molts articles, molts mètodes, moltes maneres, fins i tot en el mateix llibre al qual em refereixo sovint, com assegurar-me que altres desenvolupadors no comencin a odiar SRE. MTTR, d'altra banda, tracta de treballar el vostre SLO (Service Level Objective). I això és sobretot automatització. Perquè, per exemple, el nostre SLO és un temps de funcionament de 4 nou per trimestre. Això vol dir que en 3 mesos podem permetre 13 minuts d'inactivitat. I resulta que el nostre MTTR no pot ser més de 13 minuts. Si triguem 13 minuts a reaccionar a almenys 1 temps d'inactivitat, això vol dir que ja hem esgotat tot el pressupost del trimestre. Estem violant l'SLO. 13 minuts per reaccionar i corregir una fallada és molt per a una màquina, però molt poc per a una persona. Perquè quan una persona rep una alerta, quan reacciona, quan descobreix l'error, ja són uns minuts. Fins que una persona entengui com arreglar-ho, què arreglar exactament, què fer, trigarà uns minuts més. I de fet, fins i tot si només necessiteu reiniciar el servidor, com resulta, o augmentar un nou node, MTTR triga uns 7-8 minuts manualment. Quan s'automatitza un procés, MTTR sovint arriba a un segon, de vegades mil·lisegons. Google acostuma a parlar de mil·lisegons, però en realitat, és clar, les coses no són tan bones.
Idealment, un SRE hauria d'automatitzar gairebé completament el seu treball, perquè això afecta directament el MTTR, les seves mètriques, l'SLO de tot el servei i, en conseqüència, els beneficis empresarials. Si se supera el temps, ens demanen si la culpa és de l'SRE. Afortunadament, la culpa no és a ningú. I aquesta és una cultura a part, que s'anomena postmortem sense bàlsam, de la qual avui no parlarem, sinó que analitzarem a Slurm. Aquest és un tema molt interessant del qual es pot parlar molt. A grans trets, si es supera el temps assignat per trimestre, la culpa és de tots una mica, és a dir, que culpar a tothom no és productiu, en canvi, potser, no culpem ningú, sinó que corregim la situació i treballem amb el que tenim. Segons la meva experiència, aquest enfocament és una mica aliè a la majoria d'equips, especialment a Rússia, però té sentit i funciona molt bé. Per tant, al final us recomanaré articles i literatura que podeu llegir sobre aquest tema. O vine a Slurm SRE.
Deixa'm explicar. Si es supera el temps SLO del trimestre, si el temps d'inactivitat no va ser de 13 minuts, sinó de 15, qui pot ser el culpable d'això? Per descomptat, l'SRE pot tenir la culpa perquè clarament va fer un mal compromís o desplegament. L'administrador del centre de dades pot ser el culpable d'això, perquè pot haver realitzat algun manteniment no programat. Si l'administrador del centre de dades és el culpable d'això, la persona d'Ops també té la culpa de no calcular el manteniment quan s'acorda l'SLO. Aquesta és culpa del gerent, director tècnic o algú que va signar el contracte del centre de dades i no va prestar atenció al fet que el SLA del centre de dades no està dissenyat per al temps d'inactivitat requerit. En conseqüència, tothom té una mica de culpa d'aquesta situació. I això vol dir que no té sentit culpar a ningú en particular d'aquesta situació. Però és clar que s'ha de corregir. Per això existeixen les autopsies. I si llegiu, per exemple, les autopsies de GitHub, i aquesta és sempre una història molt interessant, petita i inesperada en cada cas concret, podeu substituir que ningú digui mai que aquesta persona en concret en tingués la culpa. La culpa sempre es dóna a processos deficients específics.
Passem a la següent pregunta. Automatització. Normalment, quan parlo d'automatització en altres contextos, molt sovint em refereixo a una taula que parla de quant de temps pots treballar en l'automatització d'una tasca per no trigar més temps a automatitzar-la del que estalvies generalment. Hi ha una trampa. El problema és que quan els SRE automatitzen una tasca, no només estalvien temps, sinó que estalvien diners perquè l'automatització afecta directament a MTTR. Salven, per dir-ho així, la moral dels empleats i desenvolupadors, que també és un recurs esgotable. Redueixen la rutina. I tot això té un efecte positiu en el treball i, per tant, en el negoci, encara que sembli que l'automatització no té sentit pel que fa als costos de temps.
De fet, gairebé sempre ho fa, i hi ha molt pocs casos en què no val la pena automatitzar alguna cosa en el rol SRE. A continuació parlarem del que s'anomena pressupost d'errors, pressupost d'errors. De fet, resulta que si ho estàs fent molt millor que l'SLO que t'has proposat, això tampoc és molt bo. Això és bastant dolent, perquè SLO funciona no només com a límit inferior, sinó també com a límit superior aproximat. Quan et fixes un SLO del 99% de disponibilitat, i de fet en tens el 99,99%, resulta que tens un espai per a l'experimentació, que no perjudicarà gens el negoci, perquè tu mateix ho has determinat tot plegat, i tu tingueu aquest espai no el feu servir. Tens un pressupost per errors, que en el teu cas no es gasta.
Què estem fent amb ell? L'utilitzem literalment per a tot. Per a proves en condicions de producció, per implementar noves funcions que poden afectar el rendiment, per a llançaments, per al manteniment, per als temps d'inactivitat planificats. També s'aplica la regla contrària: si s'esgota el pressupost, no podem estrenar res de nou, perquè sinó superarem l'SLO. El pressupost ja s'ha esgotat, hem llançat alguna cosa, si afecta negativament el rendiment, és a dir, si no es tracta d'una mena d'arranjament que en si mateix augmenti directament el SLO, aleshores estem superant el pressupost, i aquesta és una mala situació. , requereix anàlisi, post mortem i, possiblement, alguna correcció del procés.
És a dir, resulta que si el servei en si no funciona bé, i el SLO es gasta i el pressupost no es gasta en experiments, no en cap llançament, sinó sol, en lloc d'algunes correccions interessants, en lloc d'interessants. característiques, en lloc de llançaments interessants. En lloc de fer cap treball creatiu, haureu de fer correccions tontes per recuperar el pressupost o editar el SLO, i aquest també és un procés que no hauria de passar massa sovint.
Per tant, resulta que en una situació en què tenim més pressupost per errors, tothom està interessat: tant SRE com desenvolupadors. Per als desenvolupadors, un gran pressupost per a errors significa que poden fer front a llançaments, proves i experiments. Per als SRE, un pressupost per errors i entrar en aquest pressupost significa que realment estan fent una bona feina. I això afecta la motivació d'algun tipus de treball conjunt. Si escolteu els vostres SRE com a desenvolupadors, tindreu més espai per fer una bona feina i moltes menys tasques.
Resulta que els experiments en producció són una part bastant important i gairebé integral de l'SRE en grans equips. I normalment es diu enginyeria del caos, que prové de l'equip de Netflix que va llançar una utilitat anomenada Chaos Monkey.
Chaos Monkey es connecta a la canalització CI/CD i bloqueja aleatòriament el servidor en producció. De nou, a l'estructura SRE diem que un servidor bloquejat no és dolent en si mateix, és d'esperar. I si s'inclou al pressupost, és acceptable i no perjudica el negoci. Per descomptat, Netflix té prou servidors redundants, prou rèplica, que tot això es pot arreglar sense que l'usuari en conjunt se n'adoni i, certament, ningú no deixi un servidor per a cap pressupost.
En un moment, Netflix tenia tot un conjunt d'utilitats, una de les quals, Chaos Gorilla, desactiva completament una de les zones de disponibilitat d'Amazon. I aquestes coses ajuden bé a identificar, en primer lloc, les dependències ocultes, quan no està del tot clar què influeix en què, què depèn de què. I això, si esteu treballant amb un microservei i la documentació no és del tot perfecta, potser us resulti familiar. I de nou, això ajuda a detectar errors en el codi que no podeu detectar durant la posada en escena, perquè qualsevol posada en escena no és una simulació precisa, a causa del fet que l'escala de càrrega és diferent, el patró de càrrega és diferent, l'equip també és, la majoria. probable, un altre. Els pics de càrrega també poden ser inesperats i impredictibles. I aquestes proves, que de nou no van més enllà del pressupost, ajuden molt bé a detectar errors en la infraestructura que la posada en escena, les proves automàtiques i les canonades CI/CD mai no detectaran. I sempre que tot això estigui inclòs al vostre pressupost, no importa que el vostre servei hagi baixat allà, tot i que semblaria molt espantós, el servidor s'ha estavellat, quin malson. No, això és normal, això és bo, ajuda a detectar errors. Si tens pressupost, el pots gastar.
Pregunta: quina literatura puc recomanar? La llista està al final. Hi ha molta literatura, recomanaria diversos informes. Com funciona i si SRE funciona en empreses sense producte de programari propi o amb un desenvolupament mínim. Per exemple, en una empresa, on l'activitat principal no és el programari. En una empresa, on l'activitat principal no és el programari, l'SRE funciona exactament igual que en qualsevol altre lloc, perquè en una empresa també cal utilitzar, encara que no desenvolupi, productes de programari, cal llançar actualitzacions, cal canviar la infraestructura, cal créixer, cal escalar. I els SRE ajuden a identificar i predir possibles problemes en aquests processos i controlar-los després que s'iniciï algun creixement i les necessitats empresarials canviïn. Perquè no és absolutament necessari dedicar-se al desenvolupament de programari per tenir SRE, si teniu almenys diversos servidors i espereu almenys un cert creixement.
El mateix passa amb els petits projectes, les petites organitzacions, perquè les grans empreses tenen el pressupost i l'espai per a l'experimentació. Però al mateix temps, tots aquests fruits dels experiments es poden utilitzar a qualsevol lloc, és a dir, els SRE, per descomptat, van aparèixer a Google, Netflix i Dropbox. Però, al mateix temps, les petites empreses i les startups ja poden llegir material condensat, llegir llibres i veure informes. Comencen a escoltar-ne més sovint, miren exemples concrets, crec que, d'acord, això pot ser realment útil, també ho necessitem, genial.
És a dir, tota la feina principal d'estandardització d'aquests processos ja s'ha fet per vosaltres. Tot el que has de fer és definir el paper de l'SRE específicament a la teva empresa i començar a implementar realment totes aquestes pràctiques, que, de nou, ja s'han descrit. És a dir, a partir de principis útils per a petites empreses, aquesta és sempre la definició de SLA, SLI, SLO. Si no esteu involucrat en programari, aquests seran SLA interns i SLO interns, pressupost intern per errors. Això gairebé sempre porta a algunes discussions interessants dins de l'equip i dins del negoci, perquè pot resultar que gasteu molt més del necessari en infraestructura, en algun tipus d'organització dels processos ideals, un pipeline ideal. I aquests 4 nou que tens al departament d'informàtica, ara no els necessites. Però, al mateix temps, era possible gastar temps, gastar el pressupost per errors en una altra cosa.
En conseqüència, el seguiment i l'organització del seguiment és útil per a una empresa de qualsevol mida. I en general, aquesta manera de pensar, on els errors són quelcom acceptable, on hi ha pressupost, on hi ha Objectius, torna a ser útil per a una empresa de qualsevol mida, començant per una startup de 3 persones.
L'últim dels matisos tècnics del que podem parlar és el seguiment. Perquè si parlem de SLA, SLI, SLO, no podem entendre sense controlar si ens adaptem al pressupost, si complim amb els nostres Objectius i com influïm en el SLA final. He observat moltes vegades que el seguiment es fa de la següent manera: hi ha algun valor, per exemple, el temps d'una sol·licitud al servidor, el temps mitjà o el nombre de peticions a la base de dades. Té un estàndard determinat per l'enginyer. Si la mètrica es desvia de la norma, s'envia un correu electrònic. Tot això és absolutament inútil, per regla general, perquè condueix a una sobresaturació d'alertes, una sobresaturació dels missatges de seguiment, quan una persona, en primer lloc, ha d'interpretar-los cada vegada, és a dir, determinar si el valor mètric significa la necessitat de algun tipus d'acció. I en segon lloc, simplement deixa de notar totes aquestes alertes, quan bàsicament no li cal cap acció. És a dir, una bona regla de seguiment i la primera regla a l'hora d'implementar SRE és que una notificació només hauria de venir quan es requereixi una acció.
En el cas estàndard hi ha 3 nivells d'esdeveniments. Hi ha alertes, hi ha entrades, hi ha registres. Les alertes són qualsevol cosa que requereixi una acció immediata de la vostra part. És a dir, tot està trencat, s'ha d'arreglar ara mateix. Les entrades són quelcom que requereix una acció pendent. Sí, cal fer alguna cosa, cal fer alguna cosa manualment, l'automatització ha fallat, però no cal que ho faci en els propers minuts. Els registres són tot allò que no requereix acció i, en general, si les coses van bé, ningú els llegirà mai. Caldrà llegir els registres només quan, en retrospectiva, resulti que alguna cosa es va trencar durant un temps, no ho sabíem. O cal fer algun tipus d'investigació. Però, en general, tot allò que no requereix cap acció va als registres.
Com a efecte secundari de tot això, si hem identificat quins esdeveniments requereixen accions i hem descrit bé quines haurien de ser aquestes accions, això vol dir que l'acció es pot automatitzar. És a dir, què passa. Venim d'una alerta. Passem a l'acció. Anem a la descripció d'aquesta acció. I després anem cap a l'automatització. És a dir, qualsevol automatització comença amb una reacció a un esdeveniment.
Del monitoratge passem a un terme anomenat Observabilitat. També hi ha hagut una mica de bombo al voltant d'aquesta paraula durant els darrers anys. I poca gent entén què significa això fora de context. Però el punt principal és que l'observabilitat és una mètrica de la transparència del sistema. Si alguna cosa va fallar, amb quina rapidesa podeu determinar què va fallar exactament i quin era l'estat del sistema en aquell moment. Des del punt de vista del codi: quina funció ha fallat, quin servei ha fallat. Quin era l'estat de, per exemple, variables internes, configuració. Des del punt de vista de la infraestructura, és a quina zona de disponibilitat s'ha produït l'error i, si teniu algun tipus de Kubernetes, en quin pod s'ha produït l'error, quin era l'estat del pod. I en conseqüència, Observability té una relació directa amb MTTR. Com més gran sigui l'Observabilitat del servei, més fàcil serà identificar l'error, més fàcil serà corregir l'error, més fàcil serà automatitzar l'error, menor serà el MTTR.
Si tornem a passar a les petites empreses, molt sovint es pregunten, fins i tot ara, què fer amb la mida de l'equip i si és necessari contractar un SRE a part en un petit equip. D'això ja n'he parlat una mica abans. En les primeres etapes de desenvolupament d'una startup o, per exemple, d'un equip, això no és gens necessari, perquè l'SRE es pot convertir en un paper de transició. I això animarà una mica l'equip, perquè almenys hi ha una mica de diversitat. I a més prepararà la gent per al fet que a mesura que creixin, en general, les responsabilitats de l'SRE canviaran de manera molt significativa. Si contracteu una persona, llavors, per descomptat, té algunes expectatives. I aquestes expectatives no canviaran amb el temps, però els requisits canviaran molt. Per tant, contractar un SRE és bastant difícil en les primeres etapes. És molt més fàcil criar el teu. Però val la pena pensar-hi.
L'única excepció, probablement, és quan hi ha requisits d'alçada molt estrictes i ben definits. És a dir, en el cas d'una startup, això podria ser una mena de pressió dels inversors, una mena de previsió de creixement diverses vegades alhora. Aleshores, contractar un SRE generalment es justifica perquè es pot justificar. Tenim requisits de creixement, necessitem una persona que s'encarregui de garantir que amb aquest creixement no es trenqui res.
Una pregunta més. Què fer quan diverses vegades els desenvolupadors tallen una funció que passa proves, però trenca el producte, carreguen la base de dades, trenca altres funcions, quin procés implementar. En conseqüència, en aquest cas, s'introdueix un pressupost per errors. I alguns serveis, algunes funcions es posen a prova immediatament en producció. Això pot ser un canari, quan només un nombre reduït d'usuaris, però ja en producció, estan desplegant una funció, però amb l'expectativa que si alguna cosa es trenca, per exemple, per a mig per cent de tots els usuaris, encara encaixarà dins del pressupost per errors. En conseqüència, sí, hi haurà un error, per a alguns usuaris tot es trencarà, però ja hem dit que això és normal.
Hi havia una pregunta sobre les eines SRE. És a dir, hi ha alguna cosa específica que utilitzarien els SRE que tots els altres no farien? De fet, hi ha algunes utilitats molt especialitzades, hi ha algun programari que, per exemple, simula càrregues o fa proves A/B canàries. Però bàsicament, les eines SRE són el que ja estan utilitzant els vostres desenvolupadors. Perquè l'SRE interactua directament amb l'equip de desenvolupament. I si tens diferents eines, resulta que es necessita temps per sincronitzar-se. Sobretot si els SRE treballen en grans equips, en grans empreses on hi pot haver diversos equips, aquí serà molt útil l'estandardització a tota l'empresa, perquè si 50 equips fan servir 50 utilitats diferents, això vol dir que l'SRE les ha de conèixer totes. I, per descomptat, això no passarà mai. I la qualitat del treball, la qualitat del control d'almenys alguns dels equips disminuirà significativament.
El nostre webinar s'està acabant a poc a poc. He aconseguit explicar-te algunes coses bàsiques. Per descomptat, no es pot dir ni entendre res sobre SRE en una hora. Però espero haver aconseguit transmetre aquesta manera de pensar, els principals punts clau. I després, si us interessa, podeu aprofundir en el tema, estudiar pel vostre compte i veure com ho estan implementant altres persones, en altres empreses. I en conseqüència, a principis de febrer, vine a Slurm SRE.
Slurm SRE és un curs intensiu de tres dies que abastarà aproximadament el que parlo ara, però amb molta més profunditat, amb casos reals, amb pràctica, tot l'intensiu s'adreça al treball pràctic. La gent es dividirà en equips. Tots estareu treballant en casos reals. En conseqüència, tenim instructors de Booking.com Ivan Kruglov i Ben Tyler. Tenim un meravellós Evgeniy Varabbas de Google, de San Francisco. I també et diré una cosa. Així que no deixeu de venir a visitar-nos.
Per tant, una llista de referències. Hi ha enllaços a SRE. sobre aquest mateix llibre, o més aviat sobre 2 llibres sobre SRE, escrits per Google. Un altre , on s'expliquen amb una mica més de detall els termes i la seva aplicació. Els 3 següents són informes sobre SRE a diferents empreses. Primer - , aquesta és una ponència de Ben Trainer de Google. segon - . La tercera torna a tractar . Quart informe de , que només compta amb 5 empleats clau de SRE a 190 països. És molt interessant mirar tot això, perquè de la mateixa manera que DevOps significa coses molt diferents per a diferents empreses i fins i tot per a diferents equips, SRE té responsabilitats molt diferents, fins i tot en empreses de mides similars.
2 enllaços més sobre els principis de l'enginyeria del caos: , . I al final hi ha 3 llistes de la sèrie Awesome Lists sobre sobre i aproximadament . La llista de SRE és increïblement enorme, no cal que ho passeu tot, hi ha uns 200 articles. Recomano molt els articles sobre la planificació de la capacitat i l'autopsia sense culpa.
Article interessant:
Gràcies per escoltar-me tot aquest temps. Espero que hagis après alguna cosa. Espero que tingueu prou materials per aprendre encara més. I fins després. Tant de bo al febrer.
El seminari web va ser organitzat per Eduard Medvedev.
PD: per als que els agrada llegir, l'Eduard ha facilitat una llista de referències. Aquells que prefereixen entendre-ho a la pràctica són benvinguts a .
Font: www.habr.com