U webinar hà un audio poviru, cusì l'avemu trascrittu.
Mi chjamu Medvedev Eduard. Oghje parleraghju di ciò chì SRE hè, cumu SRE apparsu, chì criteri di travagliu anu l'ingegneri SRE, un pocu di criteri di affidabilità, un pocu di u so monitoraghju. Andemu nantu à e cime, perchè ùn pudete micca dì assai in un'ora, ma daraghju materiali per rivisioni supplementari, è vi aspittemu tutti. . in Mosca à a fini di ghjennaghju.
Prima, parlemu di ciò chì SRE hè - Site Reliability Engineering. E cumu pareva cum'è una pusizione separata, cum'è una direzzione separata. Tuttu hà cuminciatu cù u fattu chì in i circles di sviluppu tradiziunali, Dev è Ops sò duie squadre completamente diverse, di solitu cù dui scopi completamente diversi. L'obiettivu di u squadra di sviluppu hè di sparghje e funzioni novi è risponde à i bisogni di l'affari. U scopu di a squadra Ops hè di assicurà chì tuttu funziona è nunda si rompe. Ovviamente, questi ugettivi si cuntraditenu direttamente: per tuttu u travagliu è nunda di rompe, sparghje novi funziunalità u più pocu pussibule. Per via di questu, ci sò parechji cunflitti interni chì a metodulugia chì hè issa chjamata DevOps prova di risolve.
U prublema hè chì ùn avemu micca una definizione chjara di DevOps è una implementazione chjara di DevOps. Aghju parlatu in una cunferenza in Ekaterinburgu 2 anni fà, è finu à avà a sezione DevOps hà cuminciatu cù u rapportu "Chì hè DevOps". In 2017, Devops hà quasi 10 anni, ma avemu sempre discutendu ciò chì hè. È questu hè una situazione assai strana chì Google hà pruvatu à risolve uni pochi anni fà.
In 2016, Google hà publicatu un libru chjamatu Site Reliability Engineering. È in fattu, hè cù stu libru chì u muvimentu SRE principia. SRE hè una implementazione specifica di u paradigma DevOps in una cumpagnia specifica. L'ingegneri SRE sò impegnati à assicurà chì i sistemi operanu in modu affidabile. A maiò parte venenu da sviluppatori, qualchì volta amministratori cù un forte sfondate di sviluppu. È facenu ciò chì l'amministratori di u sistema facianu, ma un forte sfondate in u sviluppu è a cunniscenza di u sistema in termini di codice porta à u fattu chì queste persone ùn sò micca inclinati à u travagliu amministrativu di rutina, ma sò inclinati à l'automatizazione.
Ci hè chì u paradigma DevOps in i squadre SRE hè implementatu da u fattu chì ci sò ingegneri SRE chì risolve i prublemi strutturali. Eccu, a stessa cunnessione trà Dev è Ops chì a ghjente hà parlatu dapoi 8 anni. U rolu di un SRE hè simile à quellu di un architettu in chì i novi ùn diventanu SRE. E persone à l'iniziu di a so carriera ùn anu micca ancu una sperienza, ùn anu micca l'ampiezza necessaria di a cunniscenza. Perchè SRE richiede una cunniscenza assai sottile di esattamente ciò chì è quandu esattamente pò sbaglià. Dunque, una certa sperienza hè necessaria quì, in regula, sia in l'impresa sia fora.
Si dumandanu se a diffarenza trà SRE è devops serà descritta. Hè stata appena descritta. Pudemu parlà di u locu di u SRE in l'urganizazione. A cuntrariu di questu approcciu DevOps classicu, induve Ops hè sempre un dipartimentu separatu, SRE hè parte di u squadra di sviluppu. Sò implicati in u sviluppu di u produttu. Ci hè ancu un approcciu induve SRE hè un rolu chì passa da un sviluppatore à l'altru. Participanu à rivisioni di codice in u listessu modu cum'è, per esempiu, i diseggiani UX, i sviluppatori stessi, à volte i gestori di produttu. I SRE travaglianu à u listessu livellu. Avemu bisognu di appruvà, avemu bisognu di rivisione, perchè per ogni implementazione u SRE dicerà: "Va bè, sta implementazione, stu pruduttu ùn hà micca un impattu negativu nantu à a affidabilità. È s'ellu hè, allora in certi limiti accettabili. Parlaremu ancu di questu.
Per quessa, u SRE hà un veto per cambià u codice. È in generale, questu porta ancu à qualchì tipu di cunflittu chjucu se u SRE hè implementatu incorrectamente. In u stessu libru nantu à l'Ingenieria di Affidabilità di u Situ, parechje parte, mancu una, dicenu cumu per evità sti cunflitti.
Si dumandanu cumu SRE hè in relazione à a sicurità di l'infurmazioni. SRE ùn hè micca direttamente implicatu in a sicurità di l'infurmazioni. In fondu, in e grande cumpagnie, questu hè fattu da individui, testatori, analisti. Ma SRE interagisce ancu cun elli in u sensu chì certi operazioni, alcuni cummit, certi implementazioni chì affettanu a sicurità pò ancu influenzà a dispunibilità di u pruduttu. Dunque, SRE in generale hà interazzione cù qualsiasi squadre, cumpresi squadre di sicurezza, cumpresi analisti. Per quessa, i SRE sò principarmenti necessarii quandu anu pruvatu à implementà DevOps, ma à u stessu tempu, u pesu per i sviluppatori diventa troppu grande. Vale à dì, a squadra di sviluppu stessu ùn pò più affruntà u fattu chì avà anu ancu bisognu di esse rispunsevuli di Ops. È ci hè un rolu separatu. Stu rolu hè pianificatu in u budget. Calchì volta stu rolu hè stabilitu in a dimensione di a squadra, una persona separata appare, qualchì volta unu di i sviluppatori diventa. Hè cusì chì u primu SRE appare in a squadra.
A cumplessità di u sistema chì hè affettatu da SRE, a cumplessità chì afecta l'affidabilità di l'operazione, hè necessariu è accidintali. A cumplessità necessaria hè quandu a cumplessità di un pruduttu aumenta à a misura necessaria da e novi caratteristiche di u produttu. A cumplessità aleatoria hè quandu a cumplessità di u sistema aumenta, ma a funzione di u produttu è i bisogni di l'affari ùn affettanu micca direttamente questu. Ci hè chì u sviluppatore hà fattu un sbagliu in un locu, o l'algoritmu ùn hè micca ottimali, o alcuni interessi supplementari sò introdutti chì aumentanu a cumplessità di u pruduttu senza bisognu speciale. Un bonu SRE deve sempre tagliate sta situazione. Vale à dì, ogni impegnu, ogni implementazione, ogni dumanda di pull, induve a difficultà hè aumentata per l'aghjunzione aleatoria, deve esse bluccata.
A quistione hè perchè micca solu ingaghjate un ingegnere, un amministratore di sistema cun assai cunniscenze in a squadra. Un sviluppatore in u rolu di un ingegnere, ci hè dettu, ùn hè micca a megliu suluzione di staffing. Un sviluppatore in u rolu di un ingegnere ùn hè micca sempre a megliu suluzione di staffing, ma u puntu quì hè chì un sviluppatore chì hè impegnatu in Ops hà un pocu più desideriu per l'automatizazione, hà un pocu più cunniscenza è un set di cumpetenze per implementà. sta automatizazione. È per quessa, riducemu micca solu u tempu per alcune operazioni specifiche, micca solu a rutina, ma dinò paràmetri di cummerciale cusì impurtanti cum'è MTTR (Mean Time To Recovery, tempu di ricuperazione). Cusì, è avemu da parlà ancu di questu un pocu dopu, risparmiemu soldi per l'urganizazione.
Avà parlemu di i criteri per u funziunamentu di SRE. È prima di tuttu di affidabilità. In picculi imprese, startups, spessu succede chì a ghjente assume chì se u serviziu hè scrittu bè, se u pruduttu hè scrittu bè è currettamente, hà da travaglià, ùn si rompe micca. Hè cusì, scrivimu un bonu codice, cusì ùn ci hè nunda di rompe. U codice hè assai simplice, ùn ci hè nunda di rompe. Quessi sò circa i stessi persone chì dicenu chì ùn avemu micca bisognu di teste, perchè, fighjate, questi sò i trè metudi VPI, perchè rompe quì.
Questu hè tuttu sbagliatu, sicuru. E queste persone sò assai spessu muzzicate da un tali codice in pratica, perchè e cose si rompenu. E cose si rompenu qualchì volta in i modi più imprevedibili. Calchì volta a ghjente dice micca, ùn succede mai. È succede tuttu u tempu. Succede abbastanza spessu. È hè per quessa chì nimu ùn si sforza mai per a dispunibilità 100%, perchè a dispunibilità 100% ùn succede mai. Questu hè a norma. È per quessa, quandu parlemu di a dispunibilità di un serviziu, parlemu sempre di nove. 2 nove, 3 nove, 4 nove, 5 nove. Se traducemu questu in downtime, allora, per esempiu, 5 nove, allora questu hè un pocu più di 5 minuti di downtime per annu, 2 nove hè 3,5 ghjorni di downtime.
Ma hè evidenti chì in un certu puntu ci hè una diminuzione di POI, u ritornu di l'investimentu. Passà da dui nove à trè nove significa menu downtime di più di 3 ghjorni. Passà da quattru nove à cinque riduce i tempi di inattività di 47 minuti annu. È risulta chì per l'affari pò esse micca criticu. È in generale, a fiducia necessaria ùn hè micca un prublema tecnicu, prima di tuttu, hè un prublema cummerciale, hè un prublema di produttu. Chì livellu di downtime hè accettatu per l'utilizatori di u pruduttu, ciò chì aspettanu, quantu paganu, per esempiu, quantu soldi perdenu, quantu soldi perde u sistema.
Una quistione impurtante quì hè quale hè l'affidabilità di i cumpunenti restante. Perchè a diffarenza trà 4 è 5 nove ùn serà micca visibile in un smartphone cù 2 nove di affidabilità. À pocu pressu, se qualcosa si rompe in un smartphone in u vostru serviziu 10 volte à l'annu, più prubabilmente 8 volte l'avaria hè accaduta da u latu di u SO. L'utilizatore hè abituatu à questu, è ùn fate micca attente à una volta più à l'annu. Hè necessariu correlate u prezzu di l'aumentu di affidabilità è di i profitti.
Solu in u libru di SRE ci hè un bon esempiu di crescita à 4 nove da 3 nove. Risulta chì l'aumentu di a dispunibilità hè un pocu menu di 0,1%. È se l'ingudu di u serviziu hè $ 1 milione annu, allura l'aumentu di i rivenuti hè $ 900. S'ellu ci costa menu di $ 900 à l'annu per aumentà l'accessibilità di nove, l'aumentu hè sensu finanziariu. Se custa più di 900 dollari annu, ùn hè più sensu, perchè l'aumentu di i rivenuti simpricimenti ùn cumpensà micca i costi di u travagliu, i costi di risorse. È 3 nove seranu abbastanza per noi.
Questu hè di sicuru un esempiu simplificatu induve tutte e dumande sò uguali. E passendu da 3 nove à 4 nove hè abbastanza faciule, ma à u stessu tempu, per esempiu, andendu da 2 nove à 3, questu hè digià un risparmiu di 9 mila dollari, pò esse sensu finanziariu. Naturalmente, in realità, u fallimentu di a dumanda di iscrizzione hè peggiu di u fallimentu di vede a pagina, e dumande anu pesi diffirenti. Puderanu un criteriu completamente diversu da un puntu di vista di l'affari, ma in ogni modu, in regula, s'ellu ùn parlemu micca di certi servizii specifichi, questu hè una approssimazione abbastanza affidabile.
Avemu ricevutu una dumanda se SRE hè unu di i coordinatori quandu sceglie una suluzione architettonica per u serviziu. Dicemu in quantu à l'integrazione in l'infrastruttura esistente, perchè ùn ci hè micca perdita in a so stabilità. Iè, SRE, in u listessu modu chì pull requests, commits, releases affettanu l'architettura, l'intruduzioni di novi servizii, i microservizii, l'implementazione di novi suluzioni. Perchè aghju dettu prima chì l'esperienza hè necessaria, qualificazioni sò necessarie. In fatti, SRE hè una di e voci bluccanti in ogni suluzione architettonica è software. In cunsiquenza, un SRE cum'è ingegnere deve, prima di tuttu, micca solu capisce, ma ancu capisce cumu alcune decisioni specifiche affettanu a affidabilità, a stabilità, è capisce cumu questu hè in relazione cù i bisogni di l'affari, è da quale puntu di vista pò esse accettabile è chì micca.
Dunque, avà pudemu parlà solu di criteri di affidabilità, chì sò tradizionalmente definiti in SRE cum'è SLA (Service Level Agreement). Probabilmente un termine familiar. SLI (indicatore di livellu di serviziu). SLO (Ughjettivu di Livellu di serviziu). L'Accordu di Livellu di serviziu hè forse un termu simbolicu, soprattuttu s'ellu avete travagliatu cù rete, cù fornituri, cù hosting. Questu hè un accordu generale chì descrive a prestazione di u vostru serviziu tutale, penalità, alcune penalità per errori, metriche, criteri. È SLI hè a metrica di dispunibilità stessu. Hè ciò chì SLI pò esse: u tempu di risposta da u serviziu, u numeru di errori in percentuale. Puderia esse larghezza di banda s'ellu hè una sorta di hosting di file. Quandu si tratta di l'algoritmi di ricunniscenza, l'indicatore pò esse, per esempiu, ancu a correzione di a risposta. SLO (Service Level Objective) hè, rispettivamente, una cumminazione di l'indicatore SLI, u so valore è u periodu.
Dicemu chì u SLA puderia esse cusì. U serviziu hè dispunibule 99,95% di u tempu in tuttu l'annu. O 99 biglietti di supportu criticu seranu chjusi in 3 ore per trimestre. O 85% di e dumande riceveranu risposte in 1,5 seconde ogni mese. Vale à dì, gradualmente venemu à capisce chì l'errori è i fallimenti sò abbastanza normali. Questa hè una situazione accettabile, avemu a pianificà, ci cuntemu ancu in una certa misura. Vale à dì, SRE custruisce sistemi chì ponu sbaglià, chì deve risponde nurmalmente à l'errore, chì deve piglià in contu. È ogni volta chì hè pussibule, anu da trattà l'errori in tale manera chì l'utilizatore o ùn li nota micca, o avvistà, ma ci hè una sorta di soluzione, grazia à quale tuttu ùn cascà micca cumplettamente.
Per esempiu, se caricate un video in YouTube, è YouTube ùn pò micca cunvertisce immediatamente, se u video hè troppu grande, se u formatu ùn hè micca ottimale, allora a dumanda naturalmente ùn falla micca cù un timeout, YouTube ùn darà micca un errore 502. , YouTube dicerà: "Avemu creatu tuttu, u vostru video hè processatu. Serà pronta in circa 10 minuti ". Questu hè u principiu di a degradazione grazia, chì hè familiar, per esempiu, da u sviluppu front-end, se avete mai fattu questu.
I prossimi termini chì avemu da parlà, chì sò assai impurtanti per travaglià cù affidabilità, cù errori, cù l'aspettattivi, sò MTBF è MTTR. MTBF hè u tempu mediu trà fallimenti. MTTR Mean Time To Recovery, tempu mediu di ricuperazione. Questu hè, quantu tempu hè passatu da u mumentu chì l'errore hè statu scupertu, da u mumentu chì l'errore hè apparsu à u mumentu chì u serviziu hè stata restaurata à u funziunamentu normale. MTBF hè principarmenti fissu da u travagliu nantu à a qualità di codice. Questu hè, u fattu chì i SRE ponu dì "nè". È avete bisognu di capiscenu di tutta a squadra chì quandu SRE dice "nè", ùn dice micca perchè hè dannusu, micca perchè hè male, ma perchè altrimente tutti soffrenu.
In novu, ci sò assai articuli, assai metudi, assai manere ancu in u libru stessu chì mi riferite cusì spessu, cumu per assicurà chì l'altri sviluppatori ùn cumincianu micca à odià SRE. MTTR, invece, si tratta di travaglià nantu à i vostri SLOs (Service Level Objective). È hè soprattuttu l'automatizazione. Perchè, per esempiu, u nostru SLO hè un uptime di 4 nove per trimestre. Questu significa chì in 3 mesi pudemu permette 13 minuti di downtime. È risulta chì MTTR ùn pò esse più di 13 minuti. Se rispondemu à almenu 13 downtime in 1 minuti, questu significa chì avemu digià esauritu tuttu u budgetu per u trimestre. Rompemu u SLO. 13 minuti per reagisce è riparà un crash hè assai per una macchina, ma assai cortu per un umanu. Perchè finu à chì una persona riceve una alerta, finu à ch'ellu reagisce, finu à chì capisce l'errore, hè digià parechji minuti. Finu à chì una persona capisce cumu per riparà, ciò chì esattamente per riparà, chì fà, allora questu hè un pocu di minuti. È in fattu, ancu s'è avete solu bisognu di riavvia u servitore, cum'è risulta, o suscitarà un novu node, allora manualmente MTTR hè digià circa 7-8 minuti. Quandu l'automatizazione di u prucessu, MTTR assai spessu righjunghji una seconda, qualchì volta millisecondi. Google di solitu parla di millisecondi, ma in realtà, sicuru, tuttu ùn hè micca cusì bellu.
Ideale, l'SRE deve automatizà u so travagliu quasi cumpletamente, perchè questu affetta direttamente u MTTR, i so metrichi, u SLO di u serviziu sanu, è, per quessa, u prufittu cummerciale. Se u tempu hè superatu, ci hè dumandatu se SRE hè in culpa. Fortunatamente, nimu hè culpèvule. È questu hè una cultura separata chjamata balmeless postmortem, chì ùn parlemu micca oghje, ma l'analizeremu nantu à Slurm. Questu hè un tema assai interessante chì pò esse parlatu assai. À pocu pressu, se u tempu attribuitu per quartu hè superatu, allora un pocu di tutti hè culpèvule, chì significa chì culpisce tutti ùn hè micca pruduttivu, invece, forse ùn culpisce micca à nimu, ma curreghje a situazione è travaglià cù ciò chì avemu. In a mo spirimintà, questu approcciu hè un pocu alienu à a maiò parte di e squadre, in particulare in Russia, ma hè sensu è funziona assai bè. Dunque, vi cunsigliu à a fine di l'articulu è a literatura chì pudete leghje nantu à questu tema. O venite à Slurm SRE.
Lasciami spiegà. Se u tempu SLO per trimestre hè superatu, se u downtime ùn era micca 13 minuti, ma 15, quale pò esse culpèvule per questu? Di sicuru, SRE pò esse culpèvule, perchè chjaramente hà fattu qualchì tipu di cattivu impegnu o implementazione. L'amministratore di u centru di dati pò esse culpèvule per questu, perchè puderia avè realizatu qualchì tipu di mantenimentu micca pianificatu. Se l'amministratore di u centru di dati hè culpèvule per questu, allora a persona di Ops hè culpèvule per questu, chì ùn hà micca calculatu u mantenimentu quandu hà coordinatu u SLO. U manager, u direttore tecnicu o qualchissia chì hà firmatu u cuntrattu di u centru di dati è ùn hà micca attentu à u fattu chì u SLA di u centru di dati ùn hè micca pensatu per u tempu d'inattività necessariu hè culpèvule per questu. Per quessa, tutti à pocu à pocu in questa situazione sò culpèvule. È significa chì ùn ci hè nunda di culpisce à qualchissia in questa situazione. Ma, sicuru, deve esse currettu. Hè per quessa chì ci sò post mortems. E se leghjite, per esempiu, GitHub postmortems, è questu hè sempre una storia assai interessante, chjuca è inespettata in ogni casu, pudete rimpiazzà chì nimu ùn dice mai chì sta persona particulare era culpèvule. A culpa hè sempre postu nantu à i prucessi imperfetti specifichi.
Passemu à a quistione dopu. L'automatizazione. Quandu parlu di l'automatizazione in altri cuntesti, mi riferite à spessu à una tavula chì vi dice quantu tempu pudete travaglià per automatizà un compitu senza piglià più tempu per automatizà quellu chì veramente salvà. Ci hè un scontru. A catch hè chì quandu i SRE automatizanu un compitu, ùn solu risparmianu u tempu, risparmianu soldi, perchè l'automatizazione affetta direttamente MTTR. Salvanu, per dì cusì, a morale di l'impiegati è di i sviluppatori, chì hè ancu una risorsa exhaustible. Reducenu a rutina. È tuttu questu hà un effettu pusitivu nantu à u travagliu è, in u risultatu, in l'affari, ancu s'ellu pare chì l'automatizazione ùn hà micca sensu in termini di costi di tempu.
In fatti, quasi sempre hà, è ci sò assai pochi casi induve qualcosa ùn deve esse automatizatu in u rolu di SRE. Dopu avemu da parlà di ciò chì hè chjamatu u budget di l'errore, u budget per l'errore. In fatti, si trova chì se tuttu hè assai megliu per voi cà u SLO chì avete stabilitu per sè stessu, questu hè ancu micca assai bonu. Questu hè piuttostu male, perchè SLO ùn funziona micca solu cum'è un bassu, ma ancu cum'è un limite superiore apprussimativu. Quandu avete stabilitu un SLO di dispunibilità di 99%, è in fattu avete 99,99%, risulta chì avete qualchì spaziu per esperimenti chì ùn dannu micca l'affari in tuttu, perchè tù stessu avete determinatu questu tuttu inseme, è site. stu spaziu ùn aduprà. Avete un budgetu per i sbagli, chì in u vostru casu ùn hè micca usatu.
Chì facemu cun ellu. U usemu per literalmente tuttu. Per pruvà in cundizioni di produzzione, per sparghje e funzioni novi chì ponu influenzà u rendiment, per i versioni, per u mantenimentu, per i tempi di inattività pianificati. A regula inversa s'applica ancu: se u budgetu hè esauritu, ùn pudemu micca liberà nunda di novu, perchè altrimenti superemu u SLO. U budgetu hè digià esauritu, avemu liberatu qualcosa s'ellu affetta negativamente u rendiment, vale à dì, s'ellu ùn hè micca una sorta di correzione chì in sè stessu aumenta direttamente u SLO, allora andemu oltre u budgetu, è questu hè una mala situazione. , ci vole à esse analizatu, post mortem, è possibbilmente alcune correzioni di prucessu.
Vale à dì, si trova chì, se u serviziu stessu ùn funziona micca bè, è SLO hè spesu è u budgetu hè spesu micca in esperimenti, micca in certi versioni, ma da ellu stessu, invece di qualchi correzioni interessanti, invece di funzioni interessanti, invece di versioni interessanti. Invece di qualsiasi travagliu criativu, vi tuccherà à trattà cù riparazioni stupidi per ritruvà u budgetu in ordine, o edità u SLO, è questu hè ancu un prucessu chì ùn deve micca troppu spessu.
Dunque, risulta chì in una situazione induve avemu più budgetu per l'errori, tutti sò interessati: sia SRE sia sviluppatori. Per i sviluppatori, un grande budgetu per i bug significa chì pudete trattà cù versioni, testi, esperimenti. Per i SRE, un budgetu per l'errori è entra in quellu budget significa chì facenu direttamente u so travagliu bè. È questu affetta a motivazione di qualchì tipu di travagliu cumuni. Se ascolta i vostri SRE cum'è sviluppatori, avete più spaziu per un bonu travagliu è assai menu rutina.
Ci hè chì l'esperimenti in a pruduzzione sò una parte assai impurtante è quasi integrale di SRE in grande squadre. È hè generalmente chjamatu ingegneria di caos, chì vene da a squadra di Netflix chì hà liberatu una utilità chjamata Chaos Monkey.
Chaos Monkey si cunnetta à a pipeline CI / CD è crashes casualmente u servitore in produzzione. In novu, in a struttura SRE, parlemu di u fattu chì un servitore abbattutu ùn hè micca male in sè stessu, hè aspittatu. È s'ellu hè in u budgetu, hè accettabile è ùn dannu micca l'affari. Di sicuru, Netflix hà abbastanza servitori redundant, abbastanza replicazione, per chì tuttu questu pò esse riparatu, è cusì chì l'utilizatori in generale ùn anu mancu nutatu, è ancu di più nimu ùn lascia un servitore per ogni budget.
Netflix hà avutu una suite intera di tali utilità per un tempu, unu di i quali, Chaos Gorilla, chjude cumpletamente una di e Zone di Disponibilità di Amazon. E tali cose aiutanu à revelà, prima, dependenzii nascosti, quandu ùn hè micca sanu sanu chjaru ciò chì affetta ciò chì, ciò chì dipende di ciò chì. È questu, sè vo avete travagliatu cù un microserviziu, è a documentazione ùn hè micca perfetta, questu pò esse familiarizatu per voi. È dinò, questu aiuta assai per catturà errori in u codice chì ùn pudete micca catturà nantu à staging, perchè ogni staging ùn hè micca esattamente una simulazione esatta, per u fattu chì a scala di carica hè diversa, u mudellu di carica hè diversu, l'equipaggiu hè ancu, assai prubabilmente, altri. I picchi di carica pò ancu esse imprevisu è imprevisible. E tali teste, chì di novu ùn vanu oltre u budgetu, aiutanu assai bè à catturà errori in l'infrastruttura chì staging, autotests, CI / CD pipeline ùn mai catturà. È finu à chì tuttu hè inclusu in u vostru budgetu, ùn importa micca chì u vostru serviziu hè cascatu quì, ancu s'ellu pareva assai paura, u servitore hè cascatu, chì incubo. No, hè normale, hè bonu, chì aiuta à catturà i bug. Sì avete un budgetu, pudete gastru.
Q: Chì letteratura possu ricumandà ? Lista à a fine. Ci hè una mansa di literatura, vi cunsigliu uni pochi di rapporti. Cumu funziona, è SRE travaglia in cumpagnie senza u so propiu software o cù u sviluppu minimu. Per esempiu, in una impresa induve l'attività principale ùn hè micca software. In una impresa, induve l'attività principale ùn hè micca un software, SRE travaglia esattamente u listessu cum'è in ogni locu, perchè in una impresa hè ancu bisognu di utilizà, ancu s'ellu ùn hè micca sviluppatu, i prudutti di software, avete bisognu di roll out updates, avete bisognu di cambià. l'infrastruttura, avete bisognu di cresce, avete bisognu di scala. E SRE aiutanu à identificà è prediche i prublemi pussibuli in questi prucessi è cuntrullà elli dopu chì una certa crescita principia è i bisogni di l'affari cambianu. Perchè ùn hè assolutamente micca necessariu d'esse implicatu in u sviluppu di software per avè un SRE si avete almenu uni pochi di servitori è avete bisognu di avè almenu una certa crescita.
U stessu passa per i picculi prughjetti, picculi urganisazioni, perchè e grande cumpagnie anu u budgetu è u spaziu per sperimentà. Ma à u stessu tempu, tutti questi frutti di esperimenti ponu esse usatu in ogni locu, vale à dì, SRE, sicuru, apparsu in Google, in Netflix, in Dropbox. Ma à u stessu tempu, e piccule imprese è startups ponu digià leghje materiale condensatu, leghje libri, fighjate rapporti. Cumincianu à sente più spessu, fighjenu esempi specifichi, pensu chì va bè, pò esse veramente utile, avemu ancu bisognu di questu, hè grande.
Questu hè, tuttu u travagliu principale nantu à a standardizazione di sti prucessi hè digià fattu per voi. Resta per voi di determinà u rolu di SRE specificamente in a vostra cumpagnia è cumincià à implementà in realtà tutte queste pratiche, chì, di novu, sò digià descritte. Questu hè, da i principii utili per i picculi imprese, questu hè sempre a definizione di SLA, SLI, SLO. Se ùn site micca implicatu in u software, allora questi seranu SLA interni è SLO interni, un budgetu internu per l'errori. Questu quasi sempre porta à qualchi discussioni interessanti in a squadra è in l'affari, perchè pò esse chì spende in infrastruttura, in qualchì tipu d'urganizazione di prucessi ideali, u pipeline ideale hè assai più di ciò chì hè necessariu. È questi 4 nove chì avete in u dipartimentu di l'informatica, ùn ne avete micca veramente bisognu. Ma à u stessu tempu, pudete passà u tempu, spende u budgetu per i sbagli nantu à qualcosa altru.
Per quessa, u monitoraghju è l'urganizazione di u monitoraghju hè utile per una cumpagnia di ogni dimensione. E in generale, sta manera di pensà, induve i sbagli sò qualcosa accettabile, induve ci hè un budgetu, induve ci sò Obiettivi, hè novu utile per una cumpagnia di ogni dimensione, partendu da startups per 3 persone.
L'ultimu di i sfumaturi tecnichi per parlà hè u monitoraghju. Perchè s'è no parlemu di SLA, SLI, SLO, ùn pudemu micca capisce senza monitorà s'ellu ci entremu in u budgetu, s'ellu rispettemu i nostri Obiettivi, è cumu influenzamu u SLA finali. Aghju vistu tante volte chì u monitoraghju succede cusì: ci hè qualchì valore, per esempiu, u tempu di una dumanda à u servitore, u tempu mediu, o u numeru di dumande à a basa di dati. Hà un standard determinatu da un ingegnere. Se a metrica devia da a norma, allora un e-mail arriva. Tuttu chistu hè assolutamente inutile, in regula, perchè porta à una tale quantità di alerti, un saccu di messagi da u monitoraghju, quandu una persona, prima, deve interpretà ogni volta, vale à dì, stabilisce se u valore di a metrica significa. a necessità di qualchì azione. E in segundu, si ferma solu di nutà tutte queste alerti, quandu in fondu ùn ci hè micca bisognu d'azzione da ellu. Hè una bona regula di monitoraghju è a prima regula quandu SRE hè implementatu hè chì a notificazione deve vene solu quandu l'azzione hè necessaria.
In u casu standard, ci sò 3 livelli di avvenimenti. Ci sò avvisi, ci sò biglietti, ci sò logs. L'alerte sò tuttu ciò chì esige di piglià azzione immediata. Questu hè, tuttu hè rottu, avete bisognu di riparà avà. I biglietti sò ciò chì richiede l'azzione ritardata. Iè, avete bisognu di fà qualcosa, avete bisognu di fà qualcosa manualmente, l'automatizazione hà fiascatu, ma ùn avete micca bisognu di fà per i prossimi minuti. I logs sò qualcosa chì ùn hà micca bisognu d'azzione, è in generale, se e cose vanu bè, nimu ùn li leghjerà mai. Vi tuccherà solu à leghje i logs quandu, in retrospettiva, si girò fora chì qualcosa rumpiu per qualchì tempu, ùn avemu micca cunnisciutu di questu. O avete bisognu di fà qualchì ricerca. Ma in generale, tuttu ciò chì ùn hà micca bisognu d'azzione va à i logs.
Cum'è un effettu secundariu di tuttu questu, se avemu definitu ciò chì l'avvenimenti necessitanu l'azzioni è avemu descrittu bè ciò chì queste azzioni deve esse, questu significa chì l'azzione pò esse automatizata. Hè ciò chì succede. Andemu da l'alerta. Andemu à l'azzione. Andemu à a descrizzione di sta azione. E poi andemu à l'automatizazione. Vale à dì, ogni automatizazione principia cù una reazione à un avvenimentu.
Da u monitoraghju, andemu à un termu chjamatu Osservabilità. Ci hè statu ancu un pocu di hype intornu à sta parolla per l'ultimi anni. E poche persone capiscenu ciò chì significa fora di u cuntestu. Ma u puntu principale hè chì l'Osservabilità hè una metrica per a trasparenza di u sistema. Se qualcosa hè andatu sbagghiatu, quantu rapidamente pudete determinà ciò chì esattamente hè andatu sbagliatu è quale era u statu di u sistema in quellu mumentu. In termini di codice: quale funzione hà fiascatu, chì serviziu hà fallutu. Chì era u statu di, per esempiu, variàbili internu, cunfigurazione. In quantu à l'infrastruttura, questu hè in quale zona di dispunibilità hè accadutu u fallimentu, è se avete qualchì Kubernetes, allora in quale pod hè accadutu u fallimentu, quale era u statu di u pod. È per quessa, Observability hà una relazione diretta cù MTTR. A più alta l'Osservabilità di u serviziu, u più faciule hè di identificà l'errore, u più faciule hè di riparà l'errore, u più faciule hè di automatizà l'errore, u più bassu u MTTR.
Trascendendu di novu à e piccule imprese, hè assai cumuni di dumandà, ancu avà, cumu si tratta di a dimensione di a squadra, è s'ellu una piccula squadra hà bisognu di cuntrullà un SRE separatu. Dighjà parlatu di questu un pocu prima. In i primi fasi di sviluppu di una startup o, per esempiu, una squadra, questu ùn hè micca necessariu, perchè SRE pò esse fattu un rolu di transizione. E questu hà da rinviviscia a squadra un pocu, perchè ci hè almenu una certa diversità. E in più, prepararà a ghjente per u fattu chì cù a crescita, in generale, e rispunsabilità di SRE cambianu assai significativamente. Sè vo cuntrate una persona, tandu, sicuru, hà qualchi aspettative. E queste aspettative ùn cambianu micca cù u tempu, ma i requisiti cambianu assai. Dunque, cumu cuntrullà un SRE hè abbastanza difficiule in i primi tempi. Cresce u vostru propiu hè assai più faciule. Ma vale a pena di pensà.
L'unica eccezzioni, forsi, hè quandu ci sò esigenze di crescita assai strette è ben definite. Questu hè, in u casu di una startup, questu pò esse un tipu di pressione da i investituri, un tipu di previsione per a crescita parechje volte à una volta. Allora l'assunzione di un SRE hè basamente ghjustificatu perchè pò esse ghjustificatu. Avemu bisognu di crescita, avemu bisognu di una persona chì serà rispunsevuli di u fattu chì cù un tali crescita nunda ùn romperà.
Una altra dumanda. Cosa da fà quandu parechji volte i sviluppatori taglianu una funzione chì passa i testi, ma rompe a produzzione, carica a basa, rompe altre funziunalità, chì prucessu per implementà. Dunque, in questu casu, hè u budgetu per l'errore chì hè introduttu. E alcuni di i servizii, alcune di e funziunalità sò digià pruvati in a produzzione. Pò esse canarinu, quandu solu un picculu numeru di utilizatori, ma digià in a pruduzzione, una funzione hè dispiegata, ma digià cun l'aspittà chì, se qualcosa si rompe, per esempiu, per a mità di percentu di tutti l'utilizatori, hà sempre scuntrà u budget per errori. In cunsiquenza, sì, ci sarà un errore, per certi utilizatori tuttu si romperà, ma avemu digià dettu chì questu hè normale.
Ci era una quistione nantu à i strumenti SRE. Vale à dì, ci hè qualcosa in particulare chì i SRE anu utilizatu chì tutti l'altri ùn anu micca. In fatti, ci sò qualchi utilità altamente specializate, ci hè un tipu di software chì, per esempiu, simula carichi o hè impegnatu in teste A / B di canari. Ma in fondu u toolkit SRE hè ciò chì i vostri sviluppatori sò digià utilizatu. Perchè SRE interagisce direttamente cù a squadra di sviluppu. È s'è vo avete arnesi differente, vi sarà chì ci vole tempu à sincronizà. In particulare s'ellu SREs travaglia in grande squadre, in grande cumpagnie induve ci ponu esse parechje squadre, hè a standardizazione di l'impresa chì aiuterà assai quì, perchè se 50 utilità diverse sò usate in 50 squadre, questu significa chì l'SRE deve cunnosce. tutti. È di sicuru questu ùn succederà mai. È a qualità di u travagliu, a qualità di cuntrollu di almenu una parte di e squadre diminuite significativamente.
U nostru webinar hè ghjuntu à a fine. Aghju riesciutu à dì qualchi cose basi. Di sicuru, nunda di SRE pò esse dettu è capitu in una ora. Ma speru ch'e aghju sappiutu trasmette sta manera di pensà, i punti chjave principali. È tandu serà pussibule, s'ellu hè interessatu, per sfondà in u tema, amparà nantu à u vostru propiu, fighjate cumu hè implementatu da altre persone, in altre imprese. È dunque, à principiu di ferraghju, venite à noi à Slurm SRE.
U Slurm SRE hè un cursu intensivu di trè ghjorni chì parlerà di ciò chì parlu avà, ma cù assai più prufundità, cù casi veri, cù a pratica, tuttu u intensivu hè destinatu à u travagliu praticu. A ghjente serà divisa in squadre. Tutti vi travaglià nantu à casi veri. Dunque, avemu istruttori di Booking.com Ivan Kruglov è Ben Tyler. Avemu un maravigliu Eugene Barabbas da Google, da San Francisco. È vi dicu ancu qualcosa. Allora assicuratevi di visitàci.
Dunque, a bibliografia. Ci sò referenze nantu à SRE. nant'à u listessu libru, o piuttostu nantu à 2 libri nantu à SRE, scritti da Google. Un altru , induve i termini è a so applicazione sò un pocu più detallati. I prossimi 3 sò rapporti nantu à SRE in diverse cumpagnie. Primu - , Questu hè un keynote da Ben Trainer di Google. Sicondu - . U terzu hè di novu . Quartu rapportu da , chì hà solu 5 impiegati chjave SRE in 190 paesi. Hè assai interessante di vede tuttu questu, perchè cum'è DevOps significa cose assai diverse per diverse cumpagnie è ancu diverse squadre, SRE hà rispunsabilità assai diverse, ancu in cumpagnie di dimensioni simili.
2 ligami più nantu à i principii di l'ingegneria di u caosu: , . È à a fine ci sò 3 listi da a serie Awesome Lists about , circa è circa . A lista di SRE hè incredibilmente grande, ùn hè micca necessariu di passà per tuttu, ci sò circa 200 articuli. Aghju cunsigliatu assai articuli da quì nantu à a pianificazione di capacità è nantu à u postmortem senza culpa.
Artìculu interessante:
Ti ringraziu per esse à sente mi tuttu stu tempu. Spergu chì avete amparatu qualcosa. Spergu chì avete abbastanza materiale per amparà ancu di più. È ci si vede. Spergu chì in ferraghju.
U webinar hè stata ospitata da Eduard Medvedev.
PS : per quelli chì piace à leghje, Eduard hà datu una lista di riferimenti. Quelli chì preferenu capiscenu in pratica sò benvenuti .
Source: www.habr.com