Il webinar ha un audio scadente, quindi abbiamo fatto una trascrizione.
Mi chiamo Medvedev Eduard. Oggi parlerò di cos'è SRE, come è apparso SRE, quali sono i criteri di lavoro per gli ingegneri SRE, un po' dei criteri di affidabilità, un po' del suo monitoraggio. Esagereremo, perché non si può dire molto in un'ora, ma ti darò il materiale per un ulteriore esame e ti aspettiamo tutti a . a Mosca alla fine di gennaio.
Innanzitutto, parliamo di cos'è SRE (Site Reliability Engineering). E come appariva come una posizione separata, come una direzione separata. Tutto è iniziato con il fatto che nei circoli di sviluppo tradizionali, Dev e Ops sono due team completamente diversi, di solito con due obiettivi completamente diversi. L'obiettivo del team di sviluppo è implementare nuove funzionalità per soddisfare le esigenze aziendali. L'obiettivo del team operativo è assicurarsi che tutto funzioni e che nulla si rompa. Ovviamente questi obiettivi si contraddicono direttamente a vicenda: affinché tutto funzioni e nulla si rompa, è meglio implementare nuove funzionalità il meno possibile. Per questo motivo sorgono molti conflitti interni che la metodologia ora chiamata DevOps sta cercando di risolvere.
Il problema è che non abbiamo una definizione chiara di DevOps e una chiara implementazione di DevOps. Ho parlato a una conferenza a Ekaterinburg 2 anni fa e fino ad ora la sezione DevOps iniziava con il rapporto "Cos'è DevOps". Nel 2017, devops ha quasi 10 anni, ma stiamo ancora discutendo su cosa sia. E questa è una situazione molto strana che Google ha cercato di risolvere qualche anno fa.
Nel 2016, Google ha pubblicato un libro intitolato “Site Reliability Engineering”. E infatti fu con questo libro che ebbe inizio il movimento SRE. SRE è un'opzione specifica per implementare il paradigma DevOps in un'azienda specifica. Gli ingegneri SRE si sono posti l'obiettivo di garantire un funzionamento affidabile dei sistemi. Sono presi principalmente da sviluppatori, a volte da amministratori con un forte background di sviluppo. E fanno quello che facevano gli amministratori di sistema, ma un forte background nello sviluppo e nella conoscenza del sistema dal punto di vista del codice porta al fatto che queste persone non sono propense al lavoro amministrativo di routine, ma sono inclini all'automazione.
Si scopre che il paradigma DevOps nei team SRE è implementato dal fatto che ci sono ingegneri SRE che risolvono problemi strutturali. Eccola, la stessa connessione tra Dev e Ops di cui si parla da 8 anni. Il ruolo di un SRE è simile a quello di un architetto in quanto i principianti non diventano SRE. Le persone all'inizio della loro carriera non hanno ancora alcuna esperienza e non hanno la necessaria ampiezza di conoscenze. Perché SRE richiede una conoscenza molto sofisticata di cosa e quando esattamente può andare storto. Pertanto, qui è necessaria una sorta di esperienza, di regola, sia all'interno dell'azienda che all'esterno.
Chiedono se verrà descritta la differenza tra SRE e devops. È appena stata descritta. Possiamo parlare del posto di SRE nell'organizzazione. A differenza del classico approccio DevOps, in cui Ops è ancora un dipartimento separato, SRE fa parte del team di sviluppo. Sono coinvolti nello sviluppo del prodotto. Esiste anche un approccio in cui SRE è un ruolo che passa da uno sviluppatore a un altro. Partecipano alle revisioni del codice allo stesso modo, ad esempio, dei progettisti UX, degli stessi sviluppatori e talvolta dei product manager. Gli SRE operano a questo stesso livello. Abbiamo bisogno della loro approvazione, abbiamo bisogno della loro revisione, in modo che per ogni implementazione l'SRE dica: “Ok, questa implementazione, questo prodotto non influirà negativamente sull'affidabilità. E se lo farà, sarà entro limiti accettabili”. Parleremo anche di questo.
Di conseguenza, la SRE ha diritto di veto sulle modifiche del codice. E in generale, questo porta anche a qualche piccolo conflitto se SRE viene implementato in modo errato. Nello stesso libro sull'ingegneria dell'affidabilità del sito, molte parti, anche più di una, spiegano come evitare questi conflitti.
Le persone si chiedono in che modo l'SRE si collega alla sicurezza delle informazioni. SRE non è direttamente coinvolta nella sicurezza delle informazioni. Soprattutto nelle grandi aziende, questo viene fatto da singole persone, tester e analisti. Ma SRE interagisce anche con essi, nel senso che alcune operazioni, alcuni commit, alcune distribuzioni che incidono sulla sicurezza possono incidere anche sulla disponibilità del prodotto. Pertanto, SRE in generale interagisce con qualsiasi team, compresi i team di sicurezza, compresi gli analisti. Pertanto, gli SRE sono necessari principalmente quando si cerca di implementare DevOps, ma l’onere per gli sviluppatori diventa troppo grande. Cioè, il team di sviluppo stesso non può più far fronte al fatto che ora deve essere responsabile anche delle operazioni. E appare un ruolo separato. Questo ruolo è previsto nel budget. A volte questo ruolo è integrato nelle dimensioni del team, appare una persona separata, a volte diventa uno degli sviluppatori. Ecco come appare il primo SRE nella squadra.
La complessità del sistema influenzata dall'SRE, la complessità che influisce sull'affidabilità operativa, può essere necessaria o accidentale. La complessità necessaria è quando la complessità del prodotto aumenta nella misura in cui le nuove funzionalità del prodotto lo richiedono. La complessità casuale si verifica quando la complessità del sistema aumenta, ma le funzionalità del prodotto e i requisiti aziendali non influiscono direttamente su questo. Si scopre che o lo sviluppatore ha commesso un errore da qualche parte, oppure l'algoritmo non è ottimale, oppure vengono introdotti alcuni interessi aggiuntivi che aumentano inutilmente la complessità del prodotto. Un buon SRE dovrebbe sempre evitare questa situazione. Cioè, qualsiasi commit, qualsiasi distribuzione, qualsiasi richiesta pull che aumenta la complessità a causa di aggiunte casuali dovrebbe essere bloccata.
La domanda è: perché non assumere semplicemente un ingegnere, un amministratore di sistema con molta conoscenza, per unirsi al team. Uno sviluppatore nel ruolo di ingegnere, ci viene detto, non è la soluzione ottimale per il personale. Uno sviluppatore nel ruolo di ingegnere non è sempre la soluzione ottimale per il personale, ma il punto qui è che uno sviluppatore impegnato in Ops ha un po' più desiderio di automazione, ha un po' più di conoscenze e competenze per implementarlo automazione. E di conseguenza, riduciamo non solo il tempo per alcune operazioni specifiche, non solo la routine, ma anche parametri aziendali importanti come l'MTTR (Mean Time To Recovery, tempo di recupero). Così, e anche di questo parleremo tra poco, facciamo risparmiare soldi all'organizzazione.
Ora parliamo dei criteri per il lavoro SRE. E prima di tutto sull'affidabilità. Nelle piccole aziende e nelle startup capita spesso che le persone presuppongano che se il servizio è scritto bene, se il prodotto è scritto bene e correttamente, funzionerà, non si romperà. Questo è tutto, scriviamo un buon codice, quindi non c'è nulla da rompere. Il codice è molto semplice, non c'è nulla da rompere. Si tratta più o meno delle stesse persone che dicono che non abbiamo bisogno di test, perché guarda, questi sono tre metodi VPI, perché preoccuparsi?
Tutto questo è sbagliato, ovviamente. E queste persone molto spesso nella pratica vengono danneggiate da questo tipo di codice, perché le cose si rompono. Le cose a volte si rompono nei modi più imprevedibili. A volte le persone dicono di no, non accadrà mai. E succede ancora. Succede abbastanza spesso. Ed è per questo che nessuno aspira mai alla disponibilità al 100%, perché la disponibilità al 100% non esiste mai. Questa è la norma. Ed è per questo che parliamo sempre di nove quando parliamo di disponibilità del servizio. 2 nove, 3 nove, 4 nove, 5 nove. Se lo traduciamo in tempi di inattività, allora, ad esempio, 5 nove sono poco più di 5 minuti di inattività all'anno, 2 nove sono 3,5 giorni di inattività.
Ma è ovvio che ad un certo punto si verifica una diminuzione dei POI e del ritorno sull'investimento. Passare da due nove a tre nove significa ridurre i tempi di inattività di oltre 3 giorni. Passare da quattro nove a cinque riduce i tempi di inattività di 47 minuti all'anno. E si scopre che questo potrebbe non essere fondamentale per le imprese. E in generale, l'affidabilità richiesta non è una questione tecnica, prima di tutto è una questione aziendale, è una questione di prodotto. Quale livello di inattività è accettabile per gli utenti del prodotto, cosa si aspettano, quanto pagano, ad esempio, quanti soldi perdono, quanti soldi perde il sistema.
Una domanda importante è qual è l'affidabilità dei restanti componenti. Perché la differenza tra 4 e 5 nove non sarà visibile su uno smartphone con 2 nove di affidabilità. In parole povere, se qualcosa si rompe su uno smartphone nel tuo servizio 10 volte all'anno, molto probabilmente 8 volte il guasto si è verificato sul lato del sistema operativo. L'utente è abituato a questo e non presterà attenzione una volta in più all'anno. È necessario confrontare il prezzo dell'aumento dell'affidabilità e dell'aumento dei profitti.
Proprio nel libro sull'SRE c'è un buon esempio di aumento a 4 nove da 3 nove. Risulta che l'aumento della disponibilità è leggermente inferiore allo 0,1%. E se le entrate del servizio ammontano a 1 milione di dollari all’anno, l’aumento delle entrate sarà di 900 dollari. Se aumentare la disponibilità di nove unità ci costa meno di 900 dollari all’anno, l’aumento ha senso dal punto di vista finanziario. Se costa più di 900 dollari all’anno, non ha più senso, perché l’aumento delle entrate semplicemente non compensa i costi del lavoro e delle risorse. E 3 nove ci basteranno.
Questo è ovviamente un esempio semplificato in cui tutte le richieste sono uguali. E da 3 nove a 4 nove è abbastanza facile passare, ma allo stesso tempo, ad esempio, passare da 2 nove a 3 è già un risparmio di 9mila dollari, può avere senso finanziario. Naturalmente, in realtà, la mancata registrazione di una richiesta è peggiore della mancata visualizzazione di una pagina; le richieste hanno pesi diversi. Potrebbero avere criteri completamente diversi dal punto di vista aziendale, ma, di regola, se non stiamo parlando di servizi specifici, questa è un'approssimazione abbastanza affidabile.
Abbiamo ricevuto una domanda se l'SRE è uno dei coordinatori nella scelta della soluzione architetturale per il servizio. Ciò è accettabile in termini di integrazione nell'infrastruttura esistente in modo che non vi sia alcuna perdita nella sua stabilità. Sì, gli SRE influenzano le pull request, i commit e i rilasci allo stesso modo; influenzano l’architettura, l’implementazione di nuovi servizi, i microservizi e l’implementazione di nuove soluzioni. Perché ho detto prima che serve esperienza, servono qualifiche. In effetti, SRE è una delle voci di blocco in qualsiasi soluzione architetturale e software. Di conseguenza, un SRE come ingegnere deve, prima di tutto, non solo capire, ma anche capire come alcune decisioni specifiche influenzeranno l'affidabilità, la stabilità e capire come ciò si collega alle esigenze aziendali e da quale punto di vista ciò può essere accettabile , e quale no.
Pertanto è giunto il momento di parlare di criteri di affidabilità, che in SRE sono tradizionalmente definiti SLA (Service Level Agreement). Molto probabilmente un termine familiare. SLI (indicatore del livello di servizio). SLO (Obiettivo del livello di servizio). L'accordo sul livello di servizio è forse un termine significativo, soprattutto se hai lavorato con reti, provider e hosting. Questo è un accordo generale che descrive la prestazione dell'intero servizio, penalità, alcune penalità per errori, metriche, criteri. E SLI è la metrica stessa dell'accessibilità. Cioè cosa può essere SLI: tempo di risposta da parte del servizio, numero di errori in percentuale. Potrebbe trattarsi di larghezza di banda se parliamo di qualche tipo di file hosting. Se parliamo di algoritmi di riconoscimento, l'indicatore può essere anche, ad esempio, la correttezza della risposta. Lo SLO (Service Level Objective) è, rispettivamente, una combinazione dell'indicatore SLI, del suo valore e del periodo.
Diciamo che lo SLA potrebbe essere così. Il servizio è disponibile per il 99,95% del tempo durante tutto l'anno. Oppure 99 ticket di supporto tecnico critico verranno chiusi entro 3 ore a trimestre. Oppure l'85% delle domande riceverà risposta entro 1,5 secondi ogni mese. Cioè, stiamo gradualmente arrivando a capire che gli errori e i fallimenti sono abbastanza normali. Questa è una situazione accettabile, la stiamo pianificando, in una certa misura ci contiamo. Cioè, SRE costruisce sistemi che possono commettere errori, che devono rispondere normalmente agli errori e che devono tenerne conto. E se possibile, dovrebbero gestire gli errori in modo tale che l'utente non li noti o li noti, ma esiste una sorta di soluzione alternativa in modo che tutto non vada completamente in pezzi.
Ad esempio, se carichi un video su YouTube e YouTube non riesce a convertirlo subito, se il video è troppo grande, se il formato non è ottimale, allora la richiesta naturalmente non fallirà con un timeout, YouTube non visualizzerà un 502 errore, YouTube dirà: “Abbiamo creato tutto, il tuo video è in fase di elaborazione. Sarà pronto tra circa 10 minuti." Questo è il principio del grazioso degrado, che è familiare, ad esempio, dallo sviluppo front-end se lo hai mai fatto.
I prossimi termini di cui parleremo, molto importanti per lavorare con affidabilità, con errori, con aspettative, sono MTBF e MTTR. MTBF è il tempo medio tra i guasti. MTTR Mean Time To Recovery, tempo medio di recupero. Cioè, quanto tempo è trascorso dal momento in cui è stato rilevato l'errore, dal momento in cui è apparso l'errore fino al momento in cui il servizio è stato ripristinato al funzionamento completamente normale. L'MTBF viene corretto principalmente lavorando sulla qualità del codice. Cioè il fatto che gli SRE possano dire “no”. E tutta la squadra deve capire che quando l’SRE dice “no”, non lo dice perché è dannoso, non perché è cattivo, ma perché altrimenti tutti soffriranno.
Ancora una volta, ci sono molti articoli, molti metodi, molti modi, anche nello stesso libro a cui faccio spesso riferimento, su come assicurarsi che altri sviluppatori non inizino a odiare SRE. MTTR, d'altra parte, riguarda il lavoro sul tuo SLO (Service Level Objective). E questa è principalmente automazione. Perché, ad esempio, il nostro SLO prevede un tempo di attività di 4 nove al trimestre. Ciò significa che in 3 mesi possiamo concederci 13 minuti di inattività. E si scopre che il nostro MTTR non può essere superiore a 13 minuti. Se impieghiamo 13 minuti per reagire ad almeno 1 downtime, significa che abbiamo già esaurito l'intero budget del trimestre. Stiamo violando lo SLO. 13 minuti per reagire e correggere un guasto sono tanti per una macchina, ma molto pochi per una persona. Perché nel momento in cui una persona riceve un avviso, nel momento in cui reagisce, nel momento in cui capisce l’errore, sono già passati pochi minuti. Fino a quando una persona non capisce come risolverlo, cosa riparare esattamente, cosa fare, ci vorranno ancora qualche minuto. E infatti, anche se hai solo bisogno di riavviare il server, come risulta, o creare un nuovo nodo, l'MTTR richiede manualmente circa 7-8 minuti. Quando si automatizza un processo, l'MTTR raggiunge molto spesso un secondo, a volte millisecondi. Google di solito parla di millisecondi, ma in realtà, ovviamente, non è tutto così buono.
Idealmente, un SRE dovrebbe automatizzare quasi completamente il proprio lavoro, poiché ciò influisce direttamente sull'MTTR, sui suoi parametri, sullo SLO dell'intero servizio e, di conseguenza, sui profitti aziendali. Se il tempo viene superato, ci viene chiesto se la colpa è della SRE. Fortunatamente la colpa non è attribuita a nessuno. E questa è una cultura separata, che si chiama postmortem senza balme, di cui non parleremo oggi, ma analizzeremo a Slurm. Questo è un argomento molto interessante di cui si potrebbe parlare molto. In parole povere, se viene superato il tempo assegnato per trimestre, allora tutti sono un po' colpevoli, il che significa che incolpare tutti non è produttivo, invece forse non incolpiamo nessuno, ma correggiamo la situazione e lavoriamo con quello che abbiamo. Nella mia esperienza, questo approccio è un po’ estraneo alla maggior parte delle squadre, soprattutto in Russia, ma ha senso e funziona molto bene. Pertanto, alla fine consiglierò articoli e letteratura che puoi leggere su questo argomento. Oppure vieni a Slurm SRE.
Lasciatemi spiegare. Se il tempo SLO del trimestre viene superato, se il tempo di inattività non è stato di 13 minuti, ma di 15, di chi è la colpa? Naturalmente, la colpa potrebbe essere dell'SRE perché ha chiaramente effettuato un commit o una distribuzione errata. La colpa potrebbe essere dell'amministratore del data center, che potrebbe aver effettuato una manutenzione non programmata. Se la colpa è dell'amministratore del data center, è colpa anche della persona dell'Ops che non ha calcolato la manutenzione al momento della stipula dello SLO. La colpa è del manager, del direttore tecnico o di qualcuno che ha firmato il contratto del data center e non ha prestato attenzione al fatto che lo SLA del data center non è progettato per il tempo di inattività richiesto. Di conseguenza, tutti sono un po’ responsabili di questa situazione. Ciò significa che non ha senso dare la colpa a qualcuno in particolare per questa situazione. Ma ovviamente è necessario correggerlo. Ecco perché esistono le autopsie. E se leggi, ad esempio, le autopsie di GitHub, e questa è sempre una storia molto interessante, piccola e inaspettata in ogni caso specifico, puoi sostituire il fatto che nessuno dice mai che questa persona in particolare fosse da incolpare. La colpa viene sempre attribuita a specifici processi carenti.
Passiamo alla domanda successiva. Automazione. Io di solito, quando parlo di automazione in altri contesti, molto spesso faccio riferimento a una tabella che parla di quanto tempo puoi lavorare sull'automazione di un compito in modo da non impiegare per automatizzarlo più tempo di quanto generalmente risparmi. C'è un problema. Il problema è che quando gli SRE automatizzano un’attività, non solo risparmiano tempo, ma anche denaro perché l’automazione ha un impatto diretto sull’MTTR. Salvano, per così dire, il morale di dipendenti e sviluppatori, che è anche una risorsa esauribile. Riducono la routine. E tutto ciò si ripercuote positivamente sul lavoro e, di conseguenza, sugli affari, anche se sembra che l’automazione non abbia senso in termini di costi in termini di tempo.
In effetti, è quasi sempre così e sono pochissimi i casi in cui non vale la pena automatizzare qualcosa nel ruolo SRE. Successivamente parleremo di quello che viene chiamato budget degli errori, budget per gli errori. In effetti, si scopre che se stai andando molto meglio dello SLO che ti sei prefissato, anche questo non è molto buono. Ciò è piuttosto negativo, perché SLO funziona non solo come limite inferiore, ma anche come limite superiore approssimativo. Quando ti imposti uno SLO con disponibilità del 99%, e in effetti hai il 99,99%, si scopre che hai un po' di spazio per la sperimentazione, il che non danneggerà affatto l'azienda, perché tu stesso hai determinato tutto questo insieme, e tu avere questo spazio, non usarlo. Hai un budget per gli errori, che nel tuo caso non viene speso.
Cosa ne facciamo? Lo usiamo letteralmente per tutto. Per i test in condizioni di produzione, per l'implementazione di nuove funzionalità che possono influire sulle prestazioni, per i rilasci, per la manutenzione, per i tempi di inattività pianificati. Vale anche la regola opposta: se il budget è esaurito non possiamo rilasciare nulla di nuovo, perché altrimenti supereremo lo SLO. Il budget è già esaurito, abbiamo rilasciato qualcosa, se influisce negativamente sulle prestazioni, cioè se non si tratta di una sorta di correzione che di per sé aumenta direttamente lo SLO, allora stiamo superando il budget e questa è una brutta situazione , richiede analisi, post-mortem e possibilmente qualche correzione del processo.
Cioè, si scopre che se il servizio stesso non funziona bene, e lo SLO viene speso e il budget non viene speso in esperimenti, non in eventuali versioni, ma da solo, quindi invece di alcune soluzioni interessanti, invece di soluzioni interessanti funzionalità, invece di versioni interessanti. Invece di svolgere qualsiasi lavoro creativo, dovrai apportare modifiche stupide per rimettere in ordine il budget o modificare lo SLO, e anche questo è un processo che non dovrebbe accadere troppo spesso.
Pertanto, si scopre che in una situazione in cui abbiamo più budget per gli errori, tutti sono interessati: sia SRE che sviluppatori. Per gli sviluppatori, un budget elevato per gli errori significa che possono gestire rilasci, test ed esperimenti. Per gli SRE, un budget per gli errori e l’iscrizione in questo budget significa che stanno effettivamente facendo un buon lavoro. E questo influenza la motivazione di una sorta di lavoro congiunto. Se ascolti i tuoi SRE come sviluppatori, avrai più spazio per fare un buon lavoro e molti meno compiti.
Si scopre che gli esperimenti di produzione sono una parte abbastanza importante e quasi integrale dell'SRE nei grandi team. E di solito si chiama ingegneria del caos, che viene dal team di Netflix che ha rilasciato un'utilità chiamata Chaos Monkey.
Chaos Monkey si connette alla pipeline CI/CD e blocca casualmente il server in produzione. Ancora una volta, nella struttura SRE diciamo che un server in crash non è di per sé un male, è previsto. E se è incluso nel budget, è accettabile e non danneggia l'azienda. Naturalmente, Netflix ha abbastanza server ridondanti, abbastanza repliche, che tutto questo può essere risolto senza che l'utente nel suo insieme se ne accorga, e certamente nessuno lasci un server per nessun budget.
Netflix un tempo aveva tutta una serie di tali utilità, una delle quali, Chaos Gorilla, disabilita completamente una delle zone di disponibilità in Amazon. E queste cose aiutano bene a identificare, in primo luogo, le dipendenze nascoste, quando non è del tutto chiaro cosa influenza cosa, cosa dipende da cosa. E questo, se stai lavorando con un microservizio e la documentazione non è del tutto perfetta, potrebbe esserti familiare. E ancora, questo aiuta a individuare errori nel codice che non è possibile individuare durante l'allestimento, perché qualsiasi allestimento non è una simulazione accurata, a causa del fatto che la scala di carico è diversa, il modello di carico è diverso, anche l'attrezzatura è, la maggior parte probabilmente, altro. I carichi di punta possono anche essere imprevisti e imprevedibili. E tali test, che ancora una volta non vanno oltre il budget, aiutano molto a individuare errori nell'infrastruttura che staging, autotest e pipeline CI/CD non riusciranno mai a rilevare. E finché tutto questo è compreso nel tuo budget, non importa che il tuo servizio sia caduto lì, anche se sembrerebbe molto spaventoso, il server si è bloccato, che incubo. No, è normale, va bene, aiuta a individuare gli errori. Se hai un budget, puoi spenderlo.
Domanda: quale letteratura posso consigliare? L'elenco è alla fine. C'è molta letteratura, consiglierei diversi rapporti. Come funziona e se SRE funziona in aziende senza un proprio prodotto software o con uno sviluppo minimo. Ad esempio, in un'impresa, dove l'attività principale non è il software. In un'azienda, dove l'attività principale non è il software, SRE funziona esattamente come altrove, perché in un'azienda è necessario utilizzare, anche se non si sviluppano, prodotti software, è necessario implementare aggiornamenti, devi cambiare l’infrastruttura, devi crescere, devi scalare. Inoltre, gli SRE aiutano a identificare e prevedere possibili problemi in questi processi e a controllarli dopo l'inizio della crescita e il cambiamento delle esigenze aziendali. Perché non è assolutamente necessario impegnarsi nello sviluppo di software per avere SRE, se hai almeno diversi server e ti aspetti almeno una certa crescita.
Lo stesso vale per i piccoli progetti, le piccole organizzazioni, perché le grandi aziende hanno budget e spazio per la sperimentazione. Ma allo stesso tempo, tutti questi frutti di esperimenti possono essere utilizzati ovunque, ovvero gli SRE, ovviamente, sono apparsi su Google, Netflix e Dropbox. Ma allo stesso tempo, le piccole aziende e le startup possono già leggere materiale sintetico, leggere libri e guardare rapporti. Cominciano a sentirne parlare più spesso, guardano esempi specifici, penso, ok, questo può davvero essere utile, ne abbiamo bisogno anche noi, fantastico.
Cioè, tutto il lavoro principale sulla standardizzazione di questi processi è già stato svolto per te. Tutto quello che devi fare è definire il ruolo di SRE specificamente nella tua azienda e iniziare a implementare concretamente tutte queste pratiche, che, ancora una volta, sono già state descritte. Cioè, da principi utili per le piccole aziende, questa è sempre la definizione di SLA, SLI, SLO. Se non sei coinvolto nel software, si tratterà di SLA interni e SLO interni, budget interno per errori. Ciò porta quasi sempre ad alcune discussioni interessanti all'interno del team e all'interno dell'azienda, perché potrebbe risultare che stai spendendo molto più del necessario per l'infrastruttura, per una sorta di organizzazione di processi ideali, una pipeline ideale. E questi 4 nove che hai nel reparto IT, non ti servono più adesso. Ma allo stesso tempo era possibile dedicare tempo, spendere il budget per gli errori su qualcos'altro.
Di conseguenza, il monitoraggio e l'organizzazione del monitoraggio sono utili per un'azienda di qualsiasi dimensione. E in generale, questo modo di pensare, dove gli errori sono qualcosa di accettabile, dove c'è un budget, dove esistono degli obiettivi, torna utile per un'azienda di qualsiasi dimensione, a partire da una startup di 3 persone.
L'ultima delle sfumature tecniche di cui possiamo parlare è il monitoraggio. Perché se parliamo di SLA, SLI, SLO, non possiamo capire senza monitorare se rientriamo nel budget, se rispettiamo i nostri Obiettivi e come influenziamo sullo SLA finale. Ho osservato molte volte che il monitoraggio avviene nel modo seguente: c'è qualche valore, ad esempio l'ora di una richiesta al server, il tempo medio o il numero di richieste al database. Ha uno standard determinato dall'ingegnere. Se la metrica si discosta dalla norma, viene inviata un'e-mail. Tutto questo è assolutamente inutile, di regola, perché porta a una tale saturazione eccessiva di avvisi, una saturazione eccessiva di messaggi di monitoraggio, quando una persona, in primo luogo, deve interpretarli ogni volta, cioè determinare se il valore della metrica significa la necessità di una sorta di azione. In secondo luogo, smette semplicemente di notare tutti questi avvisi, quando praticamente non è richiesta alcuna azione da parte sua. Cioè, una buona regola di monitoraggio e la primissima regola quando si implementa l’SRE è che una notifica dovrebbe arrivare solo quando è richiesta un’azione.
Nel caso standard ci sono 3 livelli di eventi. Ci sono avvisi, ci sono ticket, ci sono registri. Gli avvisi sono tutto ciò che richiede un'azione immediata da parte tua. Cioè, è tutto rotto, deve essere aggiustato adesso. I ticket sono qualcosa che richiede un'azione in sospeso. Sì, devi fare qualcosa, devi fare qualcosa manualmente, l'automazione ha fallito, ma non devi farlo nei prossimi minuti. I log sono tutto ciò che non richiede intervento e in genere, se le cose vanno bene, nessuno li leggerà mai. Sarà necessario leggere i registri solo quando, a posteriori, si scopre che qualcosa si è rotto da tempo, non lo sapevamo. Oppure è necessario fare qualche tipo di indagine. Ma in generale, tutto ciò che non richiede alcuna azione va nei registri.
Come effetto collaterale di tutto ciò, se abbiamo identificato quali eventi richiedono azioni e abbiamo ben descritto quali dovrebbero essere tali azioni, ciò significa che l'azione può essere automatizzata. Cioè, cosa succede. Veniamo da un'allerta. Andiamo all'azione. Andiamo alla descrizione di questa azione. E poi passiamo all’automazione. Cioè, qualsiasi automazione inizia con una reazione a un evento.
Dal monitoraggio si passa ad un termine chiamato Osservabilità. Negli ultimi anni c’è stata anche un po’ di pubblicità intorno a questa parola. E poche persone capiscono cosa significhi fuori contesto. Ma il punto principale è che l’Osservabilità è una metrica della trasparenza del sistema. Se qualcosa è andato storto, quanto velocemente puoi determinare cosa è andato storto esattamente e quale era lo stato del sistema in quel momento. Dal punto di vista del codice: quale funzione ha fallito, quale servizio ha fallito. Qual era lo stato, ad esempio, delle variabili interne, della configurazione. Da un punto di vista dell'infrastruttura, questo è in quale zona di disponibilità si è verificato l'errore e, se si dispone di una sorta di Kubernetes, in quale pod si è verificato l'errore, qual era lo stato del pod. E di conseguenza, l’Osservabilità ha una relazione diretta con MTTR. Maggiore è l'Osservabilità del servizio, più facile è identificare l'errore, più facile è correggere l'errore, più facile è automatizzare l'errore, più basso è l'MTTR.
Se torniamo alle piccole aziende, molto spesso ci chiedono, anche adesso, cosa fare con le dimensioni del team e se è necessario assumere un SRE separato in un piccolo team. Ne ho già parlato poco prima. Nelle prime fasi di sviluppo di una startup o, ad esempio, di un team, ciò non è affatto necessario, perché SRE può assumere un ruolo transitorio. E questo ravviverà un po’ la squadra, perché almeno un po’ di diversità c’è. Inoltre, preparerà le persone al fatto che man mano che crescono, in generale, le responsabilità di SRE cambieranno in modo molto significativo. Se assumi una persona, ovviamente ha delle aspettative. E queste aspettative non cambieranno nel tempo, ma i requisiti cambieranno molto. Pertanto, assumere un SRE è piuttosto difficile nelle fasi iniziali. È molto più facile allevare il tuo. Ma vale la pena pensarci.
L’unica eccezione, probabilmente, avviene quando vigono requisiti di altezza molto rigidi e ben definiti. Cioè, nel caso di una startup, potrebbe trattarsi di una sorta di pressione da parte degli investitori, di una sorta di previsione di crescita più volte contemporaneamente. Quindi assumere un SRE è generalmente giustificato perché può essere giustificato. Abbiamo esigenze di crescita, abbiamo bisogno di una persona che abbia la responsabilità di garantire che nulla si rompa con tale crescita.
Un'altra domanda. Cosa fare quando più volte gli sviluppatori tagliano una funzionalità che supera i test, ma interrompe il prodotto, carica il database, interrompe altre funzionalità, quale processo implementare. Di conseguenza, in questo caso viene introdotto un budget per gli errori. E alcuni servizi, alcune funzionalità vengono testate immediatamente in produzione. Questo può essere un canary, quando solo un piccolo numero di utenti, ma già in produzione, sta implementando una funzionalità, ma con l'aspettativa che se qualcosa si rompe, ad esempio, per mezzo punto percentuale di tutti gli utenti, rientrerà comunque nei limiti budget per gli errori. Di conseguenza, sì, si verificherà un errore, per alcuni utenti tutto si romperà, ma abbiamo già detto che questo è normale.
C'era una domanda sugli strumenti SRE. Cioè, c'è qualcosa di specifico che gli SRE userebbero e che tutti gli altri non userebbero? In effetti, ci sono alcune utilità altamente specializzate, ci sono alcuni software che, ad esempio, simulano i carichi o eseguono test A/B canary. Ma fondamentalmente, gli strumenti SRE sono ciò che i tuoi sviluppatori stanno già utilizzando. Perché l'SRE interagisce direttamente con il team di sviluppo. E se disponi di strumenti diversi, risulta che ci vuole tempo per sincronizzarsi. Soprattutto se gli SRE lavorano in team di grandi dimensioni, in grandi aziende dove possono esserci più team, la standardizzazione a livello aziendale sarà molto utile qui, perché se 50 team utilizzano 50 utilità diverse, ciò significa che l'SRE deve conoscerle tutte. E ovviamente questo non accadrà mai. E la qualità del lavoro, la qualità del controllo di almeno alcune squadre diminuiranno in modo significativo.
Il nostro webinar sta gradualmente giungendo al termine. Sono riuscito a dirti alcune cose basilari. Naturalmente, nulla di SRE può essere detto e compreso in un'ora. Ma spero di essere riuscito a trasmettere questo modo di pensare, i principali punti chiave. E poi, se sei interessato, puoi approfondire l'argomento, studiare da solo e vedere come viene implementato da altre persone, in altre aziende. E di conseguenza, all'inizio di febbraio, vieni da noi a Slurm SRE.
Slurm SRE è un corso intensivo di tre giorni che coprirà approssimativamente ciò di cui sto parlando ora, ma con una profondità molto maggiore, con casi reali, con la pratica, l'intero intensivo è finalizzato al lavoro pratico. Le persone saranno divise in squadre. Lavorerete tutti su casi reali. Di conseguenza, abbiamo istruttori di Booking.com Ivan Kruglov e Ben Tyler. Abbiamo un meraviglioso Evgeniy Varabbas di Google, da San Francisco. E ti dirò anche una cosa. Quindi assicurati di venire a trovarci.
Quindi, un elenco di riferimenti. Ci sono collegamenti su SRE. su quello stesso libro, o meglio su 2 libri sull'SRE, scritti da Google. Un altro , dove i termini e la loro applicazione vengono spiegati un po' più in dettaglio. I prossimi 3 sono rapporti sull'SRE in diverse aziende. Primo - , questo è un keynote di Ben Trainer di Google. Secondo - . Il terzo riguarda di nuovo . Quarto rapporto da , che conta solo 5 dipendenti chiave SRE in 190 paesi. È molto interessante osservare tutto questo, perché proprio come DevOps significa cose molto diverse per aziende diverse e persino team diversi, SRE ha responsabilità molto diverse, anche in aziende di dimensioni simili.
Altri 2 link sui principi dell'ingegneria del caos: , . E alla fine ci sono 3 elenchi della serie Awesome Lists in merito , circa e circa . L'elenco su SRE è incredibilmente vasto, non è necessario esaminarlo tutto, ci sono circa 200 articoli. Consiglio vivamente gli articoli sulla pianificazione della capacità e sull'autopsia irreprensibile.
Articolo interessante:
Grazie per avermi ascoltato per tutto questo tempo. Spero che tu abbia imparato qualcosa. Spero che tu abbia abbastanza materiale per imparare ancora di più. E ci vediamo dopo. Speriamo a febbraio.
Il webinar è stato condotto da Eduard Medvedev.
PS: per chi ama leggere, Eduard ha fornito un elenco di riferimenti. Coloro che preferiscono capirlo nella pratica sono i benvenuti su .
Fonte: habr.com