Webinarrak audio eskasa du, beraz, transkribatu dugu.
Nire izena Medvedev Eduard da. Gaur SRE zer den, SRE nola agertu zen, zer lan irizpide dituzten SRE ingeniariek, fidagarritasun irizpideei buruz, pixka bat bere jarraipenari buruz hitz egingo dut. Gainetan ibiliko gara, ordubetean ezin duzulako gauza handirik esan, baina berrikuspen gehigarrirako materialak emango ditut eta denok zure zain gaude. . Moskun urtarrilaren amaieran.
Lehenik eta behin, hitz egin dezagun zer den SRE - Site Reliability Engineering. Eta nola agertzen zen posizio bereizi gisa, norabide bereizi gisa. Dena hasi zen garapen-zirkulu tradizionaletan, Dev eta Ops bi talde guztiz desberdinak direla, normalean bi helburu guztiz desberdinak dituztenak. Garapen taldearen helburua funtzio berriak zabaltzea eta negozioaren beharrak asetzea da. Ops taldearen helburua dena funtzionatzen duela eta ezer apurtzen dela ziurtatzea da. Jakina, helburu hauek elkarren kontrakoak dira zuzenean: dena funtziona dezan eta ezer apurtu ez dadin, funtzio berriak ahalik eta gutxien zabaldu. Horregatik, gaur egun DevOps deitzen den metodologia konpontzen saiatzen ari den barne gatazka asko daude.
Arazoa da ez dugula DevOps-en definizio argirik eta DevOps-en ezarpen argirik. Duela 2 urte Yekaterinburgen egindako hitzaldi batean hitz egin nuen, eta orain arte DevOps atala βZer da DevOpsβ txostenarekin hasi zen. 2017an, Devops-ek ia 10 urte ditu, baina oraindik zer den eztabaidatzen ari gara. Eta oso egoera bitxia da Googlek duela urte batzuk konpontzen saiatu zena.
2016an, Google-k Site Reliability Engineering izeneko liburua kaleratu zuen. Eta hain zuzen ere, liburu honekin hasi zen SRE mugimendua. SRE DevOps paradigmaren inplementazio espezifikoa da enpresa zehatz batean. SRE ingeniariek sistemak modu fidagarrian funtzionatzen dutela ziurtatzeko konpromisoa hartzen dute. Gehienetan garatzaileengandik datoz, batzuetan garapen maila sendoa duten administratzaileengandik. Eta sistema-administratzaileek egiten zutena egiten dute, baina sistemaren garapenean eta kodearen ezagutzan aurrekari sendoak dakar pertsona horiek ez dutela ohiko administrazio-lanetarako joera, automatizaziorako joera baizik.
Bihurtzen da SRE taldeetan DevOps paradigma egitura-arazoak konpontzen dituzten SRE ingeniariak daudelako inplementatzen dela. Hona hemen, Dev eta Ops-en arteko lotura bera, jendeak 8 urtez hitz egiten ari dena. SRE baten eginkizuna arkitekto baten antzekoa da, izan ere, etorri berriak ez dira SRE bihurtzen. Karreraren hasieran dauden pertsonek ez dute oraindik esperientziarik, ez dute beharrezko ezagutza zabala. SREk oso ezagutza sotila eskatzen duelako zehazki zer eta noiz gaizki joan daitekeen jakiteko. Hori dela eta, esperientziaren bat behar da hemen, oro har, bai enpresa barruan eta baita kanpoan ere.
SRE eta devops-en arteko aldea deskribatuko den galdetzen dute. Deskribatu berri dute. SREk erakundean duen lekuaz hitz egin dezakegu. DevOps ikuspegi klasiko honek ez bezala, non Ops oraindik aparteko sail bat den, SRE garapen taldearen parte da. Produktuen garapenean parte hartzen dute. Badago hurbilketa bat non SRE garatzaile batetik bestera pasatzen den rola den. Kodeen berrikuspenetan parte hartzen dute, adibidez, UX diseinatzaileek, garatzaileek beraiek, batzuetan produktuen kudeatzaileek bezala. SREek maila berean lan egiten dute. Onartu behar ditugu, berrikusi behar ditugu, beraz, hedapen bakoitzeko SREk honela dio: "Ongi da, hedapen honek, produktu honek ez du fidagarritasunean eragin negatiborik izango. Eta hala egiten badu, onargarri diren muga batzuen barruan. Honetaz ere hitz egingo dugu.
Horren arabera, SREk betoa du kodea aldatzeko. Eta, oro har, honek gatazka txikiren bat ere ekartzen du SRE gaizki ezartzen bada. Gunearen fidagarritasun ingeniaritzari buruzko liburu berean, zati askok, ezta batek ere, gatazka horiek nola saihestu azaltzen dira.
SRE informazioaren segurtasunarekin zer erlazio duen galdetzen dute. SRE ez dago zuzenean informazioaren segurtasunean parte hartzen. Funtsean, enpresa handietan, hori norbanakoek, probatzaileek, analistek egiten dute. Baina SRE-k haiekin ere elkarreragin egiten du, eragiketa batzuk, konpromiso batzuk, segurtasunari eragiten dioten inplementazio batzuk produktuaren erabilgarritasunari ere eragin diezaioketela. Hori dela eta, SREk bere osotasunean elkarrekintza du edozein talderekin, segurtasun taldeekin barne, analistak barne. Hori dela eta, SREak beharrezkoak dira batez ere DevOps inplementatzen saiatzen direnean, baina, aldi berean, garatzaileen zama handiegia bihurtzen da. Hau da, garapen taldeak berak ezin dio aurre egin orain Ops-en arduradun ere izan behar dutela. Eta aparteko rol bat dago. Eginkizun hori aurrekontuan aurreikusita dago. Batzuetan, eginkizun hau taldearen tamainan ezartzen da, pertsona bereizi bat agertzen da, batzuetan garatzaileetako bat bihurtzen da. Horrela agertzen da lehen SRE taldean.
SREk eragiten duen sistemaren konplexutasuna, eragiketaren fidagarritasunari eragiten dion konplexutasuna, beharrezkoa eta ustekabekoa da. Beharrezko konplexutasuna produktu baten konplexutasuna produktuaren ezaugarri berriek eskatzen duten neurrian handitzen denean da. Ausazko konplexutasuna sistemaren konplexutasuna handitzen denean gertatzen da, baina produktuaren ezaugarriak eta negozioaren eskakizunek ez diote zuzenean eragiten. Bihurtzen da garatzaileak akats bat egin duela nonbait, edo algoritmoa ez dela optimoa, edo produktuaren konplexutasuna areagotzen duten interes gehigarri batzuk sartzen dira behar berezirik gabe. SRE on batek beti moztu beharko luke egoera hau. Hau da, edozein konpromezu, edozein inplementazio, edozein tira eskaera, non zailtasuna ausazko gehiketaren ondorioz handitzen den, blokeatu behar da.
Galdera da zergatik ez kontratatu ingeniari bat, taldean ezagutza asko duen sistema-administratzaile bat. Ingeniari baten rola duen garatzailea, esan digutenez, ez da langileen irtenbiderik onena. Ingeniari baten rola duen garatzailea ez da beti langileen irtenbiderik onena, baina kontua da hemen Ops-en diharduen garatzaile batek automatizaziorako gogo apur bat gehiago duela, ezagutza eta trebetasun apur bat gehiago dituela inplementatzeko. automatizazio hori. Eta horren arabera, eragiketa zehatz batzuetarako denbora ez ezik, errutina ez ezik, MTTR (Mean Time To Recovery, berreskuratzeko denbora) bezalako negozio-parametro garrantzitsuak ere murrizten ditugu. Horrela, eta honetaz ere apur bat geroago hitz egingo dugu, dirua aurrezten dugu antolakuntzarako.
Orain hitz egin dezagun SREren funtzionamendurako irizpideei buruz. Eta lehenik eta behin fidagarritasunari buruz. Enpresa txikietan, startupetan, askotan gertatzen da jendeak bere gain hartzen duela zerbitzua ondo idatzita badago, produktua ondo eta zuzen idatzita badago, funtzionatuko duela, ez dela apurtuko. Hori da, kode ona idazten dugu, beraz, ez dago ezer hausteko. Kodea oso erraza da, ez dago ezer hausteko. Probarik behar ez dugula esaten duten pertsona berberak dira hauek, zeren, begira, hauek dira hiru VPI metodoak, zergatik hautsi hemen.
Hau guztia gaizki dago, noski. Eta pertsona horiei sarritan hozka egiten zaie horrelako kodeak praktikan, gauzak apurtzen direlako. Gauzak batzuetan apurtzen dira ezusteko moduetan. Batzuetan jendeak ezetz esaten du, ez da inoiz gertatuko. Eta denbora guztian gertatzen da. Nahikoa maiz gertatzen da. Horregatik, inork ez du inoiz %100eko erabilgarritasuna lortzeko ahaleginik egiten, %100eko erabilgarritasuna ez baita inoiz gertatzen. Hau da araua. Eta, hortaz, zerbitzu baten erabilgarritasunaz hitz egiten dugunean, beti bederatzirez hitz egiten dugu. 2 bederatzi, 3 bederatzi, 4 bederatzi, 5 bederatzi. Hau geldiune-denbora bihurtzen badugu, adibidez, 5 bederatzi, urtean 5 minutu baino gehiago gelditzen dira, 2 bederatzi 3,5 egun.
Baina bistakoa da uneren batean POI, inbertsioaren errentagarritasuna gutxitzen dela. Bi bederatziretik hiru bederatzira pasatzeak 3 egun baino gehiagoko geldialdi gutxiago esan nahi du. Lau bederatziretik bostera pasatzeak urtean 47 minutuko geldialdi-denbora murrizten du. Eta bilakatzen da negozioarentzat agian ez dela kritikoa izango. Eta, oro har, eskatzen den fidagarritasuna ez da arazo tekniko bat, lehenik eta behin, negozio arazoa da, produktuaren arazoa da. Produktuaren erabiltzaileek zer geldialdi-denbora onargarria den, zer espero duten, zenbat ordaintzen duten, adibidez, zenbat diru galtzen duten, zenbat diru galtzen duen sistemak.
Galdera garrantzitsu bat da gainerako osagaien fidagarritasuna zein den. 4 eta 5 bederatziren arteko aldea ez baita ikusgai egongo 2 bederatziren fidagarritasuna duen smartphone batean. Gutxi gorabehera, zure zerbitzuko telefonoan zerbait apurtzen bada urtean 10 aldiz, ziurrenik 8 aldiz matxura OS aldean gertatu da. Erabiltzailea ohituta dago horretara, eta ez dio kasurik egingo urtean behin gehiagotan. Beharrezkoa da fidagarritasuna handitzearen eta irabaziak handitzearen prezioa korrelazionatzea.
SREri buruzko liburuan, 4 bederatzietatik 3 bederatzira igotzearen adibide on bat dago. Ematen du erabilgarritasunaren igoera %0,1 baino apur bat txikiagoa dela. Eta zerbitzuaren diru-sarrerak urtean milioi bat dolarrekoa badira, diru-sarreren igoera 1 dolar da. Urtean 900 dolar baino gutxiago kostatzen bazaigu merkealdia bederatzi batean handitzea, igoerak zentzu ekonomikoa du. Urtean 900 dolar baino gehiago kostatzen bada, jada ez du zentzurik, diru-sarreren igoerak ez baitu lan-kostuak, baliabideen kostuak, konpentsatzen. Eta 900 bederatzirekin nahikoa izango zaigu.
Hau da, noski, eskaera guztiak berdinak diren adibide sinplifikatu bat. Eta 3 bederatzietatik 4 bederatzira pasatzea nahikoa erraza da, baina aldi berean, adibidez, 2 bederatzietatik 3ra pasatzea, hau dagoeneko 9 mila dolar aurrezten da, zentzu ekonomikoa izan dezake. Berez, egia esan, erregistro-eskaeraren hutsegite orria bistaratzea baino okerragoa da, eskaerrek pisu desberdinak dituzte. Enpresaren ikuspuntutik guztiz bestelako irizpidea izan dezakete, baina, dena den, orokorrean, zerbitzu zehatz batzuei buruz ari ez bagara, nahiko fidagarria den hurbilketa da.
Zerbitzuaren irtenbide arkitektonikoa aukeratzerakoan SRE koordinatzaileetako bat den galdera bat jaso genuen. Demagun lehendik dagoen azpiegituretan integrazioari dagokionez, bere egonkortasunean galerarik egon ez dadin. Bai, SREek, tira eskaerak, konpromisoak, kaleratzeek arkitekturan, zerbitzu berrien sarreran, mikrozerbitzuetan, soluzio berrien ezarpenean eragiten duten modu berean. Zergatik esan nuen esperientzia behar dela, tituluak behar direla. Izan ere, SRE edozein arkitektura eta software irtenbidetako ahots blokeatzaileetako bat da. Horren arabera, ingeniari gisa SRE batek, lehenik eta behin, ulertu behar du, erabaki zehatz batzuek fidagarritasunari, egonkortasunari nola eragingo dioten ulertu behar du, eta hori negozio-beharrekin nola erlazionatzen den ulertu behar du, eta zein ikuspuntutik onar daitekeen eta zein ez.
Hori dela eta, orain fidagarritasun-irizpideez hitz egin dezakegu, SREn tradizioz SLA (Service Level Agreement) gisa definitzen direnak. Seguruenik, termino ezaguna. SLI (Zerbitzu Mailaren Adierazlea). SLO (Zerbitzu Maila Helburua). Zerbitzu-maila-hitzarmena agian termino sinbolikoa da, batez ere sareekin, hornitzaileekin, ostalaritzarekin lan egin baduzu. Zure zerbitzu osoaren errendimendua, zigorrak, akatsengatiko zigor batzuk, neurketak eta irizpideak deskribatzen dituen akordio orokor bat da. Eta SLI erabilgarritasun-metria bera da. Hau da, zer izan daitekeen SLI: zerbitzuaren erantzun denbora, errore kopurua ehunekotan. Banda-zabalera izan liteke fitxategien hosting moduko bat bada. Errekonozimendu-algoritmoei dagokienez, adierazlea izan daiteke, adibidez, erantzunaren zuzentasuna ere. SLO (Service Level Objective), hurrenez hurren, SLI adierazlearen, bere balioa eta epearen konbinazioa da.
Demagun SLA horrelakoa izan daitekeela. Zerbitzua denboraren %99,95ean erabilgarri dago urtean zehar. Edo 99 laguntza-txartel kritiko itxiko dira hiruhileko 3 orduko epean. Edo kontsulten % 85ek hilero 1,5 segundotan jasoko dute erantzuna. Hau da, pixkanaka akatsak eta hutsegiteak nahiko normalak direla ulertzen joango gara. Egoera onargarria da hau, planifikatzen ari gara, horrekin kontatzen ere ari gara neurri batean. Hau da, SREk akatsak egin ditzaketen sistemak eraikitzen ditu, akatsei normaltasunez erantzun behar dietenak, kontuan hartu behar dituztenak. Eta ahal den guztietan, akatsak kudeatu beharko lituzke erabiltzaileak ohartu ez daitezen, edo ohartzen ez daitezen, baina konponbide moduko bat dago, eta horri esker dena ez da erabat eroriko.
Adibidez, bideo bat YouTubera kargatzen baduzu eta YouTube-k ezin du berehala bihurtu, bideoa handiegia bada, formatua optimoa ez bada, eskaerak ez du huts egingo denbora-muga batekin, YouTube-k ez du 502 errorerik emango. , YouTube-k esango du: βDena sortu dugu, zure bideoa prozesatzen ari da. 10 bat minutu barru prest egongo da". Hau da degradazio dotorearen printzipioa, ezaguna dena, adibidez, front-end garapenetik, inoiz hori egin baduzu.
Hitz egingo ditugun hurrengo terminoak, fidagarritasunarekin, akatsekin, itxaropenekin lan egiteko oso garrantzitsuak direnak, MTBF eta MTTR dira. MTBF hutsegiteen arteko batez besteko denbora da. MTTR Berreskuratzeko batez besteko denbora, berreskuratzeko batez besteko denbora. Hau da, zenbat denbora igaro den errorea aurkitu zenetik, akatsa agertu zenetik zerbitzua guztiz funtzionamendu normalera berreskuratu zen arte. MTBF, batez ere, kodearen kalitatearen lanarekin konpontzen da. Hau da, SREek "ez" esan dezaketela. Eta talde osoaren ulermena behar duzu SREk "ez" esaten duenean ez duela kaltegarria delako, ez txarra delako, baizik eta bestela denek sufrituko dutelako.
Berriz ere, artikulu asko, metodo asko, modu asko daude hain maiz aipatzen dudan liburuan ere, nola ziurtatu beste garatzaile batzuk SRE gorrotatzen hasten ez diren. MTTR, berriz, zure SLO (Service Level Objective) lantzeari buruzkoa da. Eta batez ere automatizazioa da. Zeren, adibidez, gure SLO hiruhileko 4 bederatziko funtzionamendu-denbora da. Horrek esan nahi du 3 hilabetetan 13 minutuko geldiunea utzi dezakegula. Eta bihurtzen da MTTR ezin dela 13 minutu baino gehiago izan. 13 minututan gutxienez geldialdi bati erantzuten badiogu, horrek esan nahi du dagoeneko hiruhilekoko aurrekontu osoa agortu dugula. SLO hausten ari gara. 1 minutu erreakzionatzeko eta istripu bat konpontzeko asko da makina batentzat, baina oso laburra gizakiarentzat. Pertsona batek alerta bat jaso arte, erreakzionatu arte, akatsa ulertu arte, dagoeneko hainbat minutu dira. Pertsona batek nola konpondu, zer zehazki konpondu, zer egin ulertu arte, orduan minutu batzuk gehiago dira. Izan ere, zerbitzaria berrabiarazi besterik ez baduzu edo nodo berri bat igo behar baduzu ere, eskuz MTTR 13-7 minutu ingurukoa da dagoeneko. Prozesua automatizatzean, MTTR sarritan segundo batera iristen da, batzuetan milisegundora. Google-k milisegundoei buruz hitz egiten du normalean, baina errealitatean, noski, dena ez da hain ona.
Egokiena, SREk bere lana ia erabat automatizatu beharko luke, horrek zuzenean eragiten baitio MTTRri, bere neurketei, zerbitzu osoaren SLOari eta, horren arabera, negozioaren irabaziari. Denbora gainditzen bada, SREk errua duen galdetzen digu. Zorionez, inork ez du errudun. Eta hau balmeless postmortem izeneko kultura bereizia da, gaur ez dugunaz hitz egingo, baina Slurm-en aztertuko dugu. Oso gai interesgarria da hau, asko hitz egin daitekeena. Gutxi gorabehera, hiruhilekoari emandako denbora gainditzen bada, denon artean apur bat errudun izango da, hau da, denei errua botatzea ez da produktiboa, demagun, beharbada, ez leporatu inori, baizik eta egoera zuzendu eta daukagunarekin lan egin. Nire esperientziaren arabera, ikuspegi hori pixka bat arrotza da talde gehienentzat, batez ere Errusian, baina zentzuzkoa da eta oso ondo funtzionatzen du. Hori dela eta, artikulu eta literaturaren amaieran gai honi buruz irakur dezakezula gomendatuko dizuet. Edo etorri Slurm SREra.
Utzidazu azaltzen. Hiruhileko SLO denbora gainditzen bada, geldialdia 13 minutukoa ez bada, 15ekoa baizik, zein izan daiteke horren erruduna? Jakina, SRE izan daiteke erruduna, argi eta garbi nolabaiteko konpromiso edo hedapen txarra egin zuelako. Datu-zentroko administratzaileak izan daiteke horren erruduna, planifikatu gabeko mantentze-lanen bat egin baitzuen. Datu-zentroko administratzaileak horren erruduna bada, Ops-eko pertsonak da horren erruduna, SLO koordinatzen zuenean mantenua kalkulatu ez zuena. Kudeatzailea, zuzendari teknikoa edo datu-zentroaren kontratua sinatu eta datu-zentroaren SLA-a behar den geldialdirako diseinatuta ez egoteari kasurik egin ez dion norbait da horren erruduna. Horren arabera, pixkanaka egoera honetan guztiak dira errudunak. Eta esan nahi du ez duela ezertarako balio egoera honetan inori errua jartzeak. Baina, noski, zuzendu egin behar da. Horregatik daude postmortemak. Eta irakurtzen badituzu, adibidez, GitHub-en postmortemak, eta kasu zehatz bakoitzean istorio oso interesgarria, txikia eta ustekabekoa bada beti, inork ez duela inoiz esan pertsona zehatz hori erruduna izan zenik ordezkatu dezakezu. Errua prozesu inperfektu zehatzei jartzen zaie beti.
Goazen hurrengo galderara. Automatizazioa. Beste testuinguru batzuetan automatizazioaz hitz egiten dudanean, askotan, zeregin bat automatizatzeko zenbat denbora lan egin dezakezun esaten dizun taula bat aipatzen dut, benetan aurrezten duzuna baino denbora gehiago behar izan gabe automatizatzeko. Zalantza bat dago. Arazoa da SREek zeregin bat automatizatzen dutenean, denbora aurrezten ez ezik, dirua aurrezten dutela, automatizazioak MTTRri zuzenean eragiten diolako. Langileen eta garatzaileen morala salbatzen dute, nolabait esateko, baliabide agorgarria ere bada. Errutina murrizten dute. Eta horrek guztiak eragin positiboa du lanean eta, ondorioz, negozioetan, nahiz eta badirudi automatizazioak ez duela zentzurik denbora kostuei dagokienez.
Izan ere, ia beti hala izan da, eta oso kasu gutxi daude SREren paperean zerbait automatizatu behar ez den. Jarraian, erroreen aurrekontua deritzonaz hitz egingo dugu, akatsen aurrekontua. Izan ere, ematen du dena zuretzat ezarri duzun SLO baino askoz hobea bada, hau ere ez dela oso ona. Hau nahiko txarra da, SLOk beheko muga gisa ez ezik, gutxi gorabeherako goiko muga gisa ere funtzionatzen duelako. Zure buruari % 99ko erabilgarritasuneko SLO bat ezartzen duzunean, eta, hain zuzen ere, % 99,99koa duzunean, negozioari batere kaltetuko ez dioten esperimentuetarako tarte bat daukazula gertatzen da, zuk zeuk zehaztu baituzu hori dena batera, eta zaude. espazio hau ez erabili. Akatsetarako aurrekontua duzu, zure kasuan agortzen ez dena.
Zer egiten dugu horrekin. Literalki denetarako erabiltzen dugu. Produkzio-baldintzetan probak egiteko, errendimenduan eragina izan dezaketen funtzio berriak zabaltzeko, bertsioetarako, mantentze-lanetarako, aurreikusitako geldialdietarako. Alderantzizko araua ere aplikatzen da: aurrekontua agortzen bada, ezin dugu ezer berririk kaleratu, bestela SLO gaindituko dugulako. Aurrekontua dagoeneko agortuta dago, zerbait kaleratu dugu errendimenduari negatiboki eragiten badio, hau da, hau ez bada berez SLO zuzenean handitzen duen konponketa moduko bat, orduan aurrekontutik haratago goaz, eta egoera txarra da. , aztertu behar da , postmortem eta, agian, prozesuen konponketa batzuk.
Hau da, ikusten da zerbitzuak berak ez badu ondo funtzionatzen, eta SLO gastatzen bada eta aurrekontua ez esperimentuetan, ez bertsio batzuetan, baizik eta berez, konponketa interesgarri batzuen ordez, ezaugarri interesgarrien ordez, argitalpen interesgarrien ordez. Sormen-lanen ordez, konponketa ergelei aurre egin beharko diezu aurrekontua itzultzeko, edo SLO editatu, eta hori ere maiz gertatu behar ez den prozesua da.
Hori dela eta, akatsetarako aurrekontu gehiago daukagun egoera batean, denek interesa dute: bai SRE bai garatzaileak. Garatzaileentzat, akatsen aurrekontu handia izateak esan nahi du kaleratzeei, probei, esperimentuei aurre egin diezaiekeela. SREentzat, akatsen aurrekontua eta aurrekontu hori sartzeak esan nahi du zuzenean beren lana ondo egiten ari direla. Eta horrek nolabaiteko lan bateratuaren motibazioari eragiten dio. Zure SREak garatzaile gisa entzuten badituzu, lan onerako leku gehiago izango duzu eta askoz errutina gutxiago.
Bihurtzen da ekoizpenean egindako esperimentuak talde handietan SREren zati oso garrantzitsua eta ia oso bat direla. Eta normalean kaosaren ingeniaritza deitzen zaio, Chaos Monkey izeneko utilitatea kaleratu zuen Netflix-eko taldetik datorrena.
Chaos Monkey-k CI/CD kanalizaziora konektatzen du eta zerbitzaria ausaz huts egiten du ekoizpenean. Berriz ere, SRE egituran, eroritako zerbitzari bat berez txarra ez dela, espero da. Eta aurrekontuaren barruan badago, onargarria da eta ez dio negozioari kalterik egiten. Noski, Netflix-ek nahikoa zerbitzari erredundanteak ditu, nahikoa erreplika, hori guztia konpondu ahal izateko, eta erabiltzailea bere osotasunean ohartu ere egin ez dadin, eta are gehiago inork ez du zerbitzari bat utzi edozein aurrekontutarako.
Netflix-ek horrelako utilitateen multzo osoa izan zuen denbora batez, eta horietako batek, Chaos Gorillak, Amazon-en erabilgarritasun guneetako bat erabat ixten du. Eta horrelakoek, lehenik eta behin, ezkutuko menpekotasunak agerian uzten laguntzen dute, guztiz argi ez dagoenean zerk eragiten duen, zerk zeren araberakoa den. Eta hau, mikrozerbitzu batekin lan egiten ari bazara eta dokumentazioa ez bada guztiz perfektua, baliteke hau ezaguna izatea. Eta, berriro ere, horrek asko laguntzen du eszenaratzean harrapatu ezin dituzun kodean akatsak harrapatzen, edozein eszenaratze ez baita zehatz-mehatz simulazio bat, karga eskala ezberdina delako, karga eredua ezberdina da, ekipamendua da. baita, ziurrenik, beste. Pikoko kargak ere ustekabekoak eta ezustekoak izan daitezke. Eta horrelako probak, berriro ere aurrekontutik haratago joaten ez direnak, oso ondo laguntzen dute eszenaratzeak, autotestak, CI / CD kanalizazioak inoiz harrapatuko ez dituzten azpiegituran akatsak harrapatzen. Eta dena zure aurrekontuan sartuta, berdin dio zure zerbitzua horra jaitsi izana, oso beldurgarria irudituko litzaiokeen arren, zerbitzariak behera egin zuen, a ze amesgaiztoa. Ez, hori normala da, hori ona da, horrek akatsak harrapatzen laguntzen du. Aurrekontua baduzu, gastatu dezakezu.
G: Zer literatura gomenda dezaket? Amaieran zerrenda. Literatura asko dago, txosten batzuk aholkatuko ditut. Nola funtzionatzen du, eta SRE lan egiten du bere software produkturik gabeko enpresetan edo garapen minimoarekin. Adibidez, jarduera nagusia softwarea ez den enpresa batean. Jarduera nagusia softwarea ez den enpresa batean, SRE-k beste leku guztietan bezala funtzionatzen du, enpresa batean software produktuak ere erabili behar dituzulako, garatu ez bada ere, eguneraketak zabaldu behar dituzu, aldatu egin behar duzulako. azpiegitura, hazi behar duzu, eskalatu behar duzu. Eta SREek prozesu horietan egon daitezkeen arazoak identifikatzen eta aurreikusten laguntzen dute eta horiek kontrolatzen laguntzen dute hazkunde batzuk hasi eta negozioaren beharrak aldatu ondoren. Ez baita guztiz beharrezkoa software garapenean parte hartzea SRE bat izateko, gutxienez zerbitzari batzuk badituzu eta gutxienez hazkuntzaren bat izatea espero baduzu.
Gauza bera gertatzen da proiektu txikiekin, erakunde txikiekin, enpresa handiek baitute aurrekontua eta esperimentatzeko espazioa. Baina, aldi berean, esperimentuen fruitu horiek guztiak edonon erabil daitezke, hau da, SRE, noski, Google-n, Netflix-en, Dropbox-en agertu zen. Baina, aldi berean, enpresa txikiek eta startupek dagoeneko material kondentsatua irakur dezakete, liburuak irakurri, txostenak ikusi. Sarriago entzuten hasten dira, adibide zehatzak aztertzen dituzte, ondo iruditzen zait, benetan erabilgarria izan daiteke, hau ere behar dugu, bikaina da.
Hau da, prozesu hauek estandarizatzeko lan nagusi guztiak dagoeneko egin dituzu. Zure enpresan SREren zeregina zehazki zehaztea eta praktika horiek guztiak benetan inplementatzen hastea geratzen zaizu, berriro ere, dagoeneko deskribatuta daudenak. Hau da, enpresa txikientzako printzipio erabilgarriak, hau da beti SLA, SLI, SLO definizioa. Softwarean parte hartzen ez baduzu, barruko SLA eta barne SLO izango dira, akatsetarako barne aurrekontua. Honek ia beti eztabaida interesgarri batzuk sortzen ditu taldean eta negozioan, izan ere, azpiegituretan gastatzen duzula, prozesu idealen antolakuntzan, kanal ideala behar baino askoz gehiago da. Eta IT sailean dituzun 4 bederatzi hauek, orain ez dituzu benetan behar. Baina, aldi berean, denbora pasa dezakezu, akatsetarako aurrekontua beste zerbaitetan gastatu.
Horren arabera, jarraipena eta jarraipena antolatzea erabilgarria da edozein tamainatako enpresarentzat. Eta orokorrean, pentsamolde hau, non akatsak zerbait onargarria diren, non aurrekontua dagoen, non Helburuak dauden, berriz ere baliagarria da edozein tamainatako enpresarentzat, 3 lagunentzako startupetatik hasita.
Hitz egin beharreko Γ±abardura teknikoetatik azkena monitorizazioa da. SLA, SLI, SLO buruz ari bagara, ezin dugu ulertu aurrekontuan sartzen garen ala ez kontrolatu gabe, gure Helburuak betetzen ditugun eta azken SLAn nola eragiten dugun. Hainbeste aldiz ikusi dut monitorizazioa honela gertatzen dela: balioren bat dago, adibidez, zerbitzariari egindako eskaeraren denbora, batez besteko denbora edo datu-baseari egindako eskaerak. Ingeniari batek zehaztutako estandarra du. Neurria arautik desbideratzen bada, mezu elektroniko bat iristen da. Hau dena guztiz alferrikakoa da, oro har, alerta ugari sortzen dituelako, monitorizazioaren mezu ugari, pertsona batek, lehenik eta behin, aldi bakoitzean interpretatu behar dituenean, hau da, metrikaren balioa esan nahi duen ala ez zehaztea. ekintza batzuen beharra. Eta bigarrenik, alerta horiek guztiak ohartzeari uzten dio, funtsean, ekintzarik behar ez zaionean. Jarraipen-arau ona da eta SRE inplementatzen den lehen araua da jakinarazpena ekintza behar denean bakarrik etorri behar dela.
Kasu estandarrean, 3 ekitaldi maila daude. Alertak daude, sarrerak daude, erregistroak daude. Alertak berehalako neurriak hartzea eskatzen dizun edozer dira. Hau da, dena apurtuta dago, oraintxe konpondu behar duzu. Sarrerak dira ekintza atzeratua eskatzen dutenak. Bai, zerbait egin behar duzu, eskuz egin behar duzu zerbait, automatizazioak huts egin du, baina hurrengo minutuetan ez duzu egin beharrik. Erregistroak ekintzarik behar ez duen edozer dira, eta, oro har, gauzak ondo badoaz, inork ez ditu inoiz irakurriko. Erregistroak irakurri beharko dituzu, atzera begiratuta, zerbait apurtu zela ikusi zenean, ez genekien. Edo ikerketa batzuk egin behar dituzu. Baina, oro har, ekintzarik behar ez duen guztia erregistroetara doa.
Honen guztiaren albo-ondorio gisa, zer gertakarik ekintzak behar dituzten definitu badugu eta ekintza horiek zeintzuk izan behar duten ondo deskribatu badugu, horrek esan nahi du ekintza automatizatu daitekeela. Hau da, zer gertatzen den. Alertatik goaz. Goazen ekintzara. Ekintza honen deskribapenera joango gara. Eta gero automatizaziora pasatzen gara. Hau da, edozein automatizazio gertaera baten aurrean erreakzio batekin hasten da.
Jarraipenetik, Behagarritasuna izeneko termino batera igaroko gara. Hitz honen inguruan ere zalaparta pixka bat sortu da azken urteotan. Eta inor gutxik ulertzen du zer esan nahi duen testuingurutik kanpo. Baina puntu nagusia da Behagarritasuna sistemaren gardentasunerako metrika bat dela. Zerbait gaizki joan bada, zein azkar zehaztu dezakezun zer oker egon den eta sistemaren egoera zein den une horretan. Kodeari dagokionez: zein funtzio huts egin zuen, zein zerbitzuk huts egin zuen. Zein zen, adibidez, barne aldagaien egoera, konfigurazioa. Azpiegiturari dagokionez, hau da akatsa zein erabilgarritasun-zonatan gertatu den, eta Kubernetes instalatuta baduzu, orduan zein podetan gertatu den hutsegitea, zein zen podaren egoera. Eta horren arabera, Behagarritasunak harreman zuzena du MTTRrekin. Zerbitzuaren Behagarritasuna zenbat eta handiagoa izan, orduan eta errazagoa da errorea identifikatzea, orduan eta errazagoa da errorea konpontzea, orduan eta errazagoa da errorea automatizatzea, orduan eta txikiagoa izango da MTTR.
Berriz ere enpresa txikietara igaroz, oso ohikoa da galdetzea, orain ere, nola egin aurre taldeen tamainari, eta talde txiki batek SRE bereizi bat kontratatu behar duen ala ez. Lehenago honi buruz hitz egin dut. Startup baten edo, adibidez, talde baten garapenaren lehen faseetan, hori ez da batere beharrezkoa, SRE trantsizio-eginkizuna egin daitekeelako. Eta horrek taldea apur bat suspertuko du, aniztasun pixka bat dagoelako behintzat. Gainera, jendea hazkuntzarekin, oro har, SREren ardurak oso nabarmen aldatuko direlako prestatuko du. Pertsona bat kontratatzen baduzu, orduan, noski, itxaropen batzuk ditu. Eta itxaropen horiek ez dira aldatuko denborarekin, baina baldintzak asko aldatuko dira. Hori dela eta, SRE bat nola kontratatu nahiko zaila da hasierako etapetan. Zure kabuz haztea askoz errazagoa da. Baina pentsatzea merezi du.
Salbuespen bakarra, agian, hazkuntza-eskakizun oso zorrotzak eta ondo definituak daudenean izango da. Hau da, startup baten kasuan, hau inbertitzaileen presio mota bat izan daiteke, hazkuntzaren aurreikuspen moduko bat aldi berean hainbat aldiz. Orduan SRE bat kontratatzea funtsean justifikatuta dago, justifika daitekeelako. Hazkuntzarako eskakizunak ditugu, hazkuntza horrekin ezer hautsi ez denaren arduraduna izango den pertsona behar dugu.
Galdera bat gehiago. Zer egin hainbat aldiz garatzaileek probak gainditzen dituzten funtzio bat mozten dutenean, baina ekoizpena hausten dutenean, oinarria kargatzen dutenean, beste ezaugarri batzuk apurtzen dituztenean, zer prozesu inplementatu behar den. Horren arabera, kasu honetan, akatsen aurrekontua da sartzen dena. Eta zerbitzu batzuk, ezaugarri batzuk dagoeneko probatzen ari dira ekoizpenean. Kanariar izan daiteke, erabiltzaile kopuru txiki bat baino ez denean, baina dagoeneko produkzioan, funtzio bat zabaltzen denean, baina dagoeneko zerbait apurtzen bada, adibidez, erabiltzaile guztien ehuneko erdia, oraindik beteko duela itxaropenarekin. akatsetarako aurrekontua. Horren arabera, bai, errore bat egongo da, erabiltzaile batzuentzat dena hautsiko da, baina hori normala dela esan dugu jada.
SRE tresnei buruzko galdera bat zegoen. Hau da, ba al dago bereziki SREek beste guztiek erabiliko ez luketen zerbait. Izan ere, oso espezializatutako utilitate batzuk daude, badaude software motaren bat, adibidez, kargak simulatzen dituena edo kanariar A / B probetan aritzen dena. Baina, funtsean, SRE tresna-kudea zure garatzaileek dagoeneko erabiltzen dutena da. SRE garapen taldearekin zuzenean elkarreragiten duelako. Eta tresna desberdinak badituzu, sinkronizatzeko denbora behar dela ikusiko da. Batez ere, SREek talde handietan lan egiten badute, hainbat talde egon daitezkeen enpresa handietan, enpresa osoko estandarizazioa da hemen asko lagunduko duena, zeren eta 50 taldetan 50 utilitate ezberdin erabiltzen badira, horrek esan nahi du SREk ezagutu behar dituela. guztiak. Eta, noski, hau ez da inoiz gertatuko. Eta lanaren kalitatea, talde batzuen kontrolaren kalitatea, behintzat, nabarmen jaitsiko da.
Gure webinarra amaitzear dago. Oinarrizko gauza batzuk kontatzea lortu nuen. Noski, ordubetean ezin da SREri buruz ezer esan eta ulertu. Baina espero dut pentsamolde hori, gako nagusiak, transmititzea lortu dudala. Eta gero posible izango da, interesa izanez gero, gaian sakontzea, norberak ikastea, beste pertsona batzuek, beste enpresa batzuetan, nola ezartzen ari diren aztertzea. Eta horren arabera, otsailaren hasieran, zatoz gurera Slurm SREra.
Slurm SRE hiru eguneko ikastaro trinkoa da, orain ari naizenari buruz hitz egingo duena, baina askoz sakontasun handiagoarekin, kasu errealekin, praktikarekin, intentsibo osoa lan praktikoetara zuzenduta dago. Jendea taldetan banatuko da. Denak kasu errealetan arituko zarete lanean. Horren arabera, Ivan Kruglov eta Ben Tyler Booking.com-eko irakasleak ditugu. Google-ko Eugene Barabbas zoragarria dugu, San Frantziskokoa. Eta zerbait esango dizut ere. Beraz, ziurtatu gu bisitatzera.
Beraz, bibliografia. SREri buruzko erreferentziak daude. liburu berean, edo hobeto esanda, Googlek idatzitako SREri buruzko 2 liburutan. Beste bat , non baldintzak eta haien aplikazioa apur bat zehatzagoak diren. Hurrengo 3ak enpresa ezberdinetan SREri buruzko txostenak dira. Lehenengoa - , Google-ko Ben Trainer-en hitzaldia da hau. Bigarrena - . Hirugarrena berriz da . Laugarren txostena , 5 herrialdetan SRE funtsezko 190 langile baino ez dituena. Oso interesgarria da hau guztia ikustea, zeren eta DevOps-ek enpresa ezberdinentzat eta talde ezberdinentzat oso gauza desberdinak esan nahi dituen bezala, SREk oso ardura desberdinak ditu, baita antzeko tamainako enpresetan ere.
Kaosaren ingeniaritzaren printzipioei buruzko beste 2 esteka: , . Eta amaieran Awesome Lists serieko 3 zerrenda daude , buruz eta inguru . SREri buruzko zerrenda izugarri handia da, ez da beharrezkoa dena pasatzea, 200 artikulu inguru daude. Handik gomendatzen ditut ahalmenaren plangintzari buruzko eta errugabeko postmortem buruzko artikuluak.
Artikulu interesgarriak:
Eskerrik asko denbora honetan guztian entzuteagatik. Espero zerbait ikasi izana. Are gehiago ikasteko nahikoa material izatea espero dut. Eta ikusi arte. Otsailean espero dugu.
Webinarra Eduard Medvedev-ek antolatu zuen.
PD: irakurtzea gustuko dutenentzat, Eduardek erreferentzien zerrenda eman zuen. Praktikan ulertzea nahiago dutenak ongi etorriak dira .
Iturria: www.habr.com