Site Reliability Engineering è il processo che prevede l'utilizzo dei processi operativi e la loro assegnazione al team di progettazione software per l'automazione.
I team IT cercano costantemente di adottare le metodologie SRE. Site Reliability Engineering prende le pratiche delle operazioni e le passa ai team di progettazione software per l'automazione delle attività umane, la risoluzione dei problemi e la gestione dei sistemi. Un team SRE è responsabile della gestione delle modifiche, della risposta alle emergenze, del monitoraggio, della disponibilità, delle prestazioni, della latenza, dell'efficienza e della pianificazione della capacità dei servizi. In genere si occupa della scrittura di software per l'automazione dei processi.
SRE è un'ottima risorsa per l'affidabilità e la scalabilità del software, in quanto i sistemi possono essere gestiti tramite codice. Ciò produce un equilibrio tra garantire l'affidabilità di un prodotto e delle sue funzionalità e rilasciare nuovi prodotti e funzionalità.
Ben Treynor Sloss di Google è la mente che si cela dietro il site reliability engineering. Viene descritto come "SRE è ciò che accade quando chiedi a un ingegnere del software di progettare le funzioni delle operazioni". Il concetto è stato sviluppato dopo aver analizzato i conflitti tra i team delle operazioni, che desiderano garantire che le funzioni non causino problemi o inconvenienti agli utenti finali, e i team di sviluppo, che desiderano rilasciare nuove funzioni non appena sono pronte per il roll out. SRE costituisce una riconciliazione tra i due team.
Google ha pubblicato un libro su SRE disponibile gratuitamente online. Offre un'analisi approfondita del ruolo di SRE e delle best practice consigliate per l'esecuzione. Le parti II e III, rispettivamente principi e pratiche, sono degne di nota.
Principi SRE: secondo Google, i principi fondamentali di SRE sono:
- Assunzione del rischio: fornire approcci neutrali alla gestione dei servizi utilizzando i budget per gli errori.
- Obiettivi del livello di servizio: fornisce raccomandazioni per gli indicatori non vincolati agli accordi ed esamina il modo in cui SRE utilizza i termini.
- Eliminazione del lavoro pesante: per eliminare le attività comuni e ripetitive prive di valore.
- Monitoraggio dei sistemi distribuiti: evita sempre di ignorare ciò che accade nell'organizzazione ai fini dell'affidabilità.
- Progettazione delle release: tiene conto attentamente delle release per garantire che siano coerenti e non contribuiscano all'interruzione del servizio.
- Semplicità: un sistema troppo complesso può ridurre l'affidabilità e diventare difficile da riportare a una forma più semplice.
Il ruolo di un/un'ingegnere addetto/a all'affidabilità del sito deve essere svolto da qualcuno o qualcuna con esperienza in ambito software: non si tratta di una posizione di livello base. Un'esecuzione corretta di SRE richiede una maggiore fluidità nell'ingegneria del software e la comprensione di un sistema di grande dimensione e complessità.
Un/un'ingegnere addetto/a all'affidabilità del sito deve mostrare la giusta mentalità per la posizione. Le competenze tecniche sono necessarie, ma è fondamentale anche una comprensione concettuale delle operazioni. È importante che SRE si fondi sui tradizionali processi di sviluppo software, ma è altrettanto importante una comprensione olistica dei processi aziendali e lo sviluppo di un sistema affidabile.
Nell'organizzazione, è compito di tutti essere più affidabili possibili, applicando di conseguenza gli importanti principi SRE. Applica un modello di affidabilità a ogni team e dedica del tempo a discutere di come l'affidabilità possa essere adottata da ogni team e influenzare tutti.
I nuovi lanci sono autorizzati in base alle prestazioni correnti del prodotto: in genere le applicazioni non funzionano il 100% del tempo. Il team SRE ha il compito di elaborare un accordo sul livello dei servizi per definire il sistema e il modo in cui verrà utilizzato per gli utenti finali. Una parte comune di un accordo a livello di servizio è un error budget, ossia la soglia massima per interruzioni ed errori.
Il personale dei team di sviluppo e dei team SRE è condiviso, il che significa che aggiungendo un membro SRE se ne rimuove uno dal team di sviluppo e viceversa. Il sistema è a regolazione autonoma per evitare contese tra team di sviluppo e team SRE a causa di esigenze di personale. I team SRE sono in grado di codificare e sviluppare, il che li aiuta a collaborare con il team di sviluppo.
I team SRE possono spostarsi tra i vari progetti, in quanto creano un forte senso di motivazione e dedizione che consente ai membri del team di perseguire obiettivi aziendali e personali.
- Sviluppo di software per aiutare le operazioni e i team
- Risoluzione dei problemi di escalation
- Ottimizzazione dei processi a richiesta
- Documentazione delle conoscenze del team
- Revisione post-incidente
I team SRE possono essere perfettamente in linea con le esigenze delle operazioni IT, dell'ingegneria del software e del supporto per fornire solide fondamenta e rapporti tra i team, contribuendo a cicli di feedback, collaborazione e affidabilità.
I team SRE guardano al quadro più ampio per guidare i diversi team verso un unico obiettivo.
Un ruolo importante nel ruolo SRE consiste nell'eliminare le inefficienze e nell'identificare le operazioni semplici da automatizzare. È possibile smettere di occuparsi delle attività che portano via di tempo e aumentare l'efficienza senza dover eseguire un gran numero di operazioni manuali.
Le pratiche SRE non trovano applicazione solo nel settore tecnologico. Una cultura SRE può essere estesa a e-commerce, servizio clienti e settore manifatturiero.
DevOps è un metodo per sviluppare e distribuire software di elevata qualità, combinando sviluppo e operazioni software allo scopo di fondere i rispettivi ruoli. SRE è un metodo che tende a essere più incentrato sul lato dello sviluppo che sul lato operativo di DevOps.
Scopri di più su DevOps
Modernizza le operazioni per i team DevOps e SRE
I container Linux sono in grado di fornire la tecnologia necessaria per uno sviluppo nativo nel cloud: i container supportano l'unificazione dell'ambiente per integrazione, automazione, sviluppo e distribuzione. Kubernetes è in grado di automatizzare i container Linux necessari.
Non esiste un singolo set di strumenti uniforme per SRE. Tuttavia, è fondamentale sviluppare funzioni SRE all'interno di un'azienda in combinazione con l'automazione per garantire scalabilità e ripetibilità.
ServiceNow offre maggiore valore fungendo da ponte per il lavoro tra più team, grazie alla registrazione dei microservizi, alla correlazione dei dati osservabili, alla disponibilità di metriche di affidabilità, all'automazione delle modifiche e alla previsione degli errori, il tutto mantenendo intatti gli strumenti esistenti.
Crea il tuo prossimo piano di trasformazione SRE con ServiceNow.