Che cos'è l'SRE? Come si collega a DevOps?

SRE sta per Site Reliability Engineering. Si basa sui principi di DevOps per portare un approccio ingegneristico alle operazioni IT. SRE utilizza il software per automatizzare il funzionamento del sistema, identificare i problemi e implementare risoluzioni.

Il concetto di SRE sviluppato da Google. Si basa sull'idea che il codice e il software sono il modo più efficace per gestire sistemi su larga scala. Le procedure manuali avviate da un team separato comportano il rischio di supervisione e incoerenza.

In questo articolo imparerai cos'è l'SRE e come aiuta a semplificare le operazioni cloud. Spiegheremo anche dove SRE si sovrappone a DevOps, nonché i modi in cui differisce.

Dove si trova SRE Adeguato alla consegna del software?

SRE riguarda la gestione delle operazioni. Entra nel processo di consegna del software dopo che il codice è stato sviluppato, rivisto e distribuito. Gli ingegneri dell'affidabilità del sito di solito osservano, mantengono e ottimizzano i servizi distribuiti, assumendosi le responsabilità degli amministratori.

La caratteristica distintiva di SRE rispetto alle operazioni tradizionali è l'enfasi che pone sull'automazione. I controlli dell'infrastruttura, la gestione delle modifiche, gli audit e la risposta agli incidenti dovrebbero essere tutti automatizzati all'interno del modello. Il professionista SRE si concentra sul provisioning e sull'esecuzione di strumenti software che realizzano queste attività, invece di interagire direttamente con il sistema stesso.

SRE unifica aspetti disparati dell'esperienza di gestione delle operazioni. L'utilizzo di un processo basato su strumenti significa che ci sono meno posti in cui si verificano i problemi. Questo aiuta ad aumentare la stabilità man mano che i sistemi crescono, anche se le dimensioni del team SRE rimangono statiche.

Cosa fanno effettivamente gli ingegneri SRE?< /h2>

Gli ingegneri SRE sono generalmente sviluppatori di software che hanno anche esperienza con i servizi di produzione operativi. Questo dà loro una consapevolezza olistica del processo di consegna, dal code commit alla risoluzione degli incidenti. Useranno queste conoscenze per progettare e implementare meccanismi per la distribuzione e il monitoraggio degli ambienti live.

Come “affidabilità” è letteralmente nel nome, i team SRE sono anche responsabili della misurazione del tempo di attività e dell'ideazione di modi per migliorarlo. Gli ingegneri SRE stabiliscono gli obiettivi del livello di servizio (SLO) che forniscono obiettivi di affidabilità per l'organizzazione. Stabiliranno e osserveranno gli indicatori del livello di servizio (SLI) che informano se gli obiettivi sono stati raggiunti, come il tasso di errore, il throughput delle richieste e il conteggio dei ticket. Gli SRE saranno coinvolti nella scrittura degli accordi sul livello di servizio (SLA) condivisi anche con i clienti.

Gli ingegneri SRE sono gli efficaci guardiani delle nuove implementazioni. La loro attenzione a preservare la stabilità significa che a volte provocheranno blocchi di distribuzione se uno SLO o SLA sta per essere violato. Il team SRE può indirizzare gli sviluppatori a concentrarsi sull'affrontare la causa degli incidenti, invece di continuare a implementare nuovi lavori.

Nessun servizio può aspettarsi di funzionare con un'affidabilità del 100%. SRE riconosce questo concedendo agli sviluppatori un “budget di errore” che sono autorizzati a “spendere.” Una volta che il budget è stato superato da nuovi bug, ticket o interruzioni, affrontare i problemi diventa una priorità di tutti fino a quando il budget di errore e gli SLO non vengono ripristinati.

Potrebbe essere un ingegnere SRE chi completa questo lavoro correttivo scrivendo nuovo codice. Poiché il team SRE ha una formazione in ingegneria del software, è attrezzato per affrontare i problemi di propria iniziativa. In tempi in cui il servizio funziona correttamente, le persone con ruoli SRE tornano a essere sviluppatori regolari. Gli ingegneri SRE di Google dovrebbero dedicare almeno la metà del loro tempo al lavoro di sviluppo.

Questo equilibrio unico tra sviluppo e operazioni aiuta a preservare la capacità dell'ingegnere SRE di supervisionare il processo di consegna. Il loro livello di visibilità è inestimabile quando si tratta di individuare i rischi che potrebbero causare un incidente. Incoraggia inoltre gli ingegneri a ridurre al minimo il tempo dedicato alle attività operative implementando nuovi strumenti e procedure automatizzate. Questo può creare un ciclo autosufficiente: un maggiore grado di automazione di solito rende il servizio più affidabile, riducendo il carico di lavoro operativo per il team SRE. A loro volta, gli ingegneri sono liberi di tornare allo sviluppo, aumentando il throughput.

Come si allinea SRE con DevOps?

DevOps è un termine di vasta portata che descrive l'utilizzo di tecnologie e metodologie moderne per fornire software di qualità superiore più rapidamente. Ciò si ottiene riducendo il divario tra i team di sviluppo e operativi, quindi sovrapponendo l'automazione al processo di distribuzione del software.

Finora questo suona simile a SRE. Tuttavia SRE ha un unico obiettivo in mente – affidabilità – mentre DevOps considera anche le preoccupazioni tangenziali, come l'efficienza degli sviluppatori e la velocità di consegna. È degno di nota il fatto che DevOps sia spesso considerato un ponte tra lo sviluppo e le operazioni mentre SRE li fonde insieme. In SRE le attività di sviluppo e operazioni vengono completate dalle stesse persone, con lo sviluppo che ottiene la maggior parte dell'attenzione.

Per questi motivi SRE può essere visto come un'implementazione specifica di DevOps. Sebbene gli obiettivi generali siano simili e fortemente allineati, SRE descrive un metodo per raggiungerli: utilizzare budget di errore, SLO e SLI per proteggere i servizi dagli errori, quindi implementare protezioni che consentano alla distorsione del lavoro di tornare allo sviluppo.

< p>Benjamin Treynor Sloss, l'ingegnere di Google che ha coniato il termine SRE, afferma che SRE può essere visto come “un'implementazione specifica di DevOps con alcune estensioni idiosincratiche”. In alternativa, puoi invertire il modello e avvicinarti a DevOps “come una generalizzazione di diversi principi SRE fondamentali a una gamma più ampia di organizzazioni, strutture di gestione e personale.”

Un modo significativo in cui SRE differisce da DevOps è la sua dipendenza dai dati. DevOps è spesso visto come un insieme di principi per spostare in modo efficiente il codice dalle workstation degli sviluppatori agli ambienti di produzione. Ciò significa lavorare in termini di commit, richieste di unione, pipeline e contenitori. SRE è una strategia per implementare le modifiche con la massima affidabilità e ridotte possibilità di regressione. Un SRE efficace richiede un'osservazione e un'analisi continue per capire dove si sono verificati gli errori e come potrebbero ripetersi in futuro. È più investigativo e consapevole di una tipica implementazione DevOps.

SRE è una buona mossa professionale?

SRE ha iniziato solo di recente ad attirare l'attenzione del mainstream. Può essere difficile trovare un ruolo SRE perché molte organizzazioni devono ancora riconoscere i vantaggi del modello. In alcuni casi una forma di SRE può essere presente all'interno di un'organizzazione, ma ciò potrebbe non riflettersi nei ruoli che pubblicizzano.

Nonostante la sua natura specializzata, SRE è in genere una buona mossa di carriera. Richiede un'intersezione di competenze, che vanno dallo sviluppo del software fino al funzionamento dei servizi e alla risposta agli incidenti, con un buon grado di profondità in ciascuna. Ci sono pochi candidati in grado di offrire questo, il che significa che i ruoli SRE tendono ad essere posizioni redditizie.

Un'analisi di GitLab nell'aprile 2022 ha rilevato solo 21.000 aperture SRE mentre c'erano 104.000 posizioni DevOps. Tuttavia, i dati di Glassdoor hanno indicato una fascia di stipendio fino a $ 300.000 per il lavoro SRE, rispetto a $ 234.000 per DevOps.

Passare a un ruolo SRE potrebbe essere un'opportunità gratificante per le persone che desiderano rimanere nel campo dello sviluppo mentre acquisiscono esperienza pratica nel funzionamento del servizio. È particolarmente adatto a persone che trovano i ruoli di amministratore tradizionali troppo ripetitivi e pratici. In qualità di SRE, dovrai automatizzare le operazioni, cercare opportunità per migliorare la qualità del servizio e contribuire agli sforzi di sviluppo regolari dopo che il cercapersone degli incidenti è diventato silenzioso.

Conclusione

Site Reliability Engineering utilizza metodi comunemente associati allo sviluppo di software per automatizzare le operazioni di servizio. Gli ingegneri SRE sono sviluppatori esperti che hanno anche familiarità con le sfide dell'esecuzione e della scalabilità dei servizi in produzione. Stabiliscono una catena di strumenti per misurare e ottimizzare l'affidabilità, assumendo le attività precedentemente gestite da amministratori di sistema dedicati.

SRE può essere visto come un'implementazione dei principi DevOps. La nomina di ingegneri SRE dovrebbe tradursi in un servizio più resiliente in grado di accettare cambiamenti rapidi. Ciò consente di raggiungere l'obiettivo di DevOps di accelerare la distribuzione del software senza influire sulla qualità. SRE definisce una strategia specifica che lavora in tal senso enfatizzando la misurazione dei dati, nonché l'unificazione del talento di sviluppo e operativo.

Mentre DevOps è ora ampiamente compreso nella comunità, SRE rimane un'area di interesse emergente per molti organizzazioni. Le aperture possono essere più difficili da trovare, ma tendono ad essere più redditizi quando compaiono. Ciò riflette il variegato insieme di competenze che gli ingegneri SRE devono possedere. È probabile che la domanda cresca rapidamente nei prossimi due anni, quindi ora è il momento per i candidati e le organizzazioni di iniziare a prestare attenzione al passaggio all'SRE.

LEGGI SUCCESSIVO

› 8 Segnali che l'alimentatore del tuo computer non funziona
› Volevamo un replicatore di Star Trek e tutto ciò che avevamo erano macchine Keurig
› Recensione di Apple iPhone 14: la scelta sicura che vale la pena acquistare
› Come risolvere “Il tuo sistema ha esaurito la memoria dell'applicazione” su un Mac
› Qual è il servizio di streaming più economico per gli sport in diretta?