L'ingegneria dell'affidabilità del sito (SRE) utilizza l'ingegneria del software per automatizzare le attività operative IT, come la gestione del sistema di produzione, la gestione delle modifiche, la risposta agli incidenti e persino la risposta alle emergenze, che altrimenti verrebbero eseguite manualmente dagli amministratori di sistema (amministratori di sistema). 

Il principio alla base dell'SRE è che l'utilizzo del codice software per automatizzare la supervisione di sistemi software di grandi dimensioni è una strategia più scalabile e sostenibile rispetto all'intervento manuale, soprattutto quando tali sistemi si estendono o migrano nel cloud.

L'SRE può anche ridurre o rimuovere gran parte dell'attrito naturale tra i team di sviluppo, che vogliono rilasciare continuamente software nuovo o aggiornato in produzione, e i team operativi, che non vogliono rilasciare alcun tipo di aggiornamento o nuovo software senza essere completamente sicuri che non causerà interruzioni o altri problemi operativi. Di conseguenza, sebbene non sia strettamente richiesta per DevOps, l'SRE è in linea con i principi DevOps e può svolgere un ruolo importante nel successo di DevOps.

Il concetto di SRE è attribuito a Ben Treynor Sloss, VP of Engineering di Google, che ha notoriamente scritto che "l'SRE è ciò che succede quando si chiede a un ingegnere del software di progettare un team operativo".

Un tecnico dell'affidabilità del sito è uno sviluppatore di software con esperienza nelle operazioni IT, qualcuno che sa programmare e che capisce come mantenere l'allerta in un ambiente IT su larga scala. 

Gli ingegneri dell'affidabilità del sito dedicano metà del loro tempo a svolgere operazioni IT manuali e attività di amministrazione del sistema: analisi dei registri, ottimizzazione delle prestazioni, applicazione di patch, test degli ambienti di produzione, risposta agli incidenti, conduzione di autopsie. Il resto del loro tempo, sviluppano codice che automatizza tali attività. Il loro obiettivo è di dedicare meno tempo all'ex e più tempo all'ultimo.

A un livello superiore, il team SRE funge da ponte tra i team di sviluppo e i team operativi, consentendo al team di sviluppo di portare in produzione un nuovo software o nuove funzionalità il più rapidamente possibile. Riescono a fare ciò garantendo anche un livello accettabile di prestazioni delle operazioni IT e di rischio di errore, in linea con gli accordi sul livello di servizio (SLA) che l'organizzazione ha stipulato con i suoi clienti. Sulla base della loro esperienza e di una vasta gamma di dati operativi, il team SRE aiuta i team di sviluppo e operativi a stabilire

• Indicatori del livello di servizio (SLI): misurazioni del livello di servizio fornito dai sistemi, metriche come la disponibilità (tempo di attività) o la latenza.
  
  
• Obiettivi del livello di servizio (SLO): mezzi concordati per misurare gli indicatori del livello di servizio.
  
  
• Budget di errore: il periodo di tempo massimo in cui un sistema può fallire o avere prestazioni inferiori senza violare i termini contrattuali dello SLA. Più che una metrica, il budget di errore è lo strumento utilizzato da un team di ingegneri dell'affidabilità del sito per riconciliare automaticamente il ritmo di innovazione di un'azienda con l'affidabilità del servizio. 

Il budget di errore è lo strumento utilizzato da un team SRE per riconciliare automaticamente l'affidabilità del servizio di un'azienda con il ritmo di sviluppo e innovazione del software. 

Supponiamo che lo SLA di un'azienda prometta un tempo di attività del 99,99% (un obiettivo di disponibilità comune) all'anno. Ciò significa che il budget di errore mensile, ovvero la quantità totale di tempo di inattività consentita senza conseguenze contrattuali per un determinato mese, è di circa 4 minuti e 23 secondi.

Supponiamo ora che il team di sviluppo voglia implementare alcune nuove funzionalità o miglioramenti al sistema. Se il sistema funziona al di sotto del budget degli errori, il team può fornire le nuove funzionalità. In caso contrario, il team non può consegnare le nuove funzioni fino a quando non avrà collaborato con il team operativo per portare questi errori o interruzioni a un livello accettabile.

In questo modo, i budget di errore aiutano i team di sviluppo e i team operativi a

• Migliora la stabilità e le prestazioni dei servizi.
  
  
• Prendi decisioni basate sui dati riguardo all'implementazione di nuove funzioni o applicazioni.
  
  
• Massimizza l'innovazione assumendo i rischi entro limiti accettabili.

DevOps è un modo moderno per fornire applicazioni di qualità superiore in tempi più rapidi, automatizzando il ciclo di vita della distribuzione del software e offrendo ai team di sviluppo e operativi una maggiore responsabilità condivisa e un maggiore input nel lavoro reciproco. 

Come l'SRE, il DevOps rende l'azienda più agile, bilanciando la necessità di fornire più applicazioni e modifiche più velocemente con la necessità di non "interrompere" l'ambiente di produzione. E, proprio come l'SRE, anche il DevOps mira a raggiungere questo equilibrio stabilendo un rischio di errori accettabile. SRE e DevOps sembrano così simili che alcuni esperti affermano che sono la stessa cosa, ma la maggior parte vede le pratiche SRE come modi eccellenti per implementare i principi DevOps. Per esempio:

Principi DevOps: ridurre i silo organizzativi, sfruttare gli strumenti e l'automazione.

Pratica SRE: utilizza gli stessi strumenti di automatizzazione e miglioramento delle operazioni utilizzati dagli sviluppatori per sviluppare e migliorare il software.

Principi DevOps: accetta il fallimento come normale e implementa modifiche graduali.

Pratica SRE: Utilizza i budget di errore per distribuire continuamente nuove caratteristiche e funzionalità entro livelli accettabili.

Principio DevOps: misurare tutto.

Pratica SRE: basare le decisioni relative al rilascio di un nuovo software sulle metriche SLA.

Oltre a supportare il successo di DevOps, l'ingegneria dell'affidabilità del sito può aiutare un'azienda a

• Ottenere una maggiore visibilità sull'integrità dei servizi monitorando le metriche, i log e le tracce in tutti i servizi dell'organizzazione e fornendo un contesto per identificare le cause principali in caso di incidente.
  
  
• Quantifica il costo del tempo di inattività aiutando i team di sviluppo e operativi a comprendere il costo delle violazioni degli SLA e aiutando il management a quantificare l'impatto dell'affidabilità del sistema sulla produzione, le vendite, il marketing, il servizio clienti e altre funzioni aziendali.
  
  
• Ottimizzare la risposta agli incidenti creando processi di chiamata efficienti e semplificando i workflow di avviso.
  
  
• Costruire un centro operativo di rete moderno combinando la comprensione approfondita delle operazioni IT con l'apprendimento automatico e l'automazione, per inviare avvisi direttamente alla persona responsabile di risolvere il problema.

La migrazione da data center IT tradizionali e on-premise a ambienti di hybrid cloud è uno dei motivi principali per cui l'azienda media genera ogni anno da due a tre volte più dati operativi. Sempre più spesso, l'SRE è considerato fondamentale per sfruttare questi dati per automatizzare l'amministrazione dei sistemi, le operazioni e la risposta agli incidenti e per migliorare l'affidabilità aziendale anche quando l'ambiente IT diventa più complesso.

Un approccio allo sviluppo cloud-native, in particolare la creazione di applicazioni come microservizi e la loro distribuzione in container, può semplificare lo sviluppo, la distribuzione e la scalabilità delle applicazioni. Ma lo sviluppo cloud-native crea anche un ambiente sempre più distribuito che complica l'amministrazione, le operazioni e la gestione. Un team SRE può supportare il rapido ritmo di innovazione abilitato da un approccio cloud-native e garantire o migliorare l'affidabilità del sistema, senza caricare di ulteriore pressione operativa i team DevOps.