L'ingegneria dell'affidabilità del sito (site reliability engineering, SRE) utilizza tecniche di ingegneria del software per automatizzare le attività delle operazioni IT - ad esempio 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. 

Il principio alla base della SRE è che l'utilizzo del codice software per automatizzare la supervisione di grandi sistemi software è una strategia più scalabile e sostenibile rispetto all'intervento manuale, soprattutto con l'estensione e la migrazione di tali sistemi al cloud.

La SRE può anche ridurre o rimuovere gran parte delle naturali frizioni tra i team di sviluppo, che desiderano rilasciare continuamente in produzione software nuovo o aggiornato, e i team di operazioni, che non vogliono rilasciare alcun tipo di aggiornamento o nuovo software senza essere assolutamente sicuri che non causi interruzioni o altri problemi di funzionamento. Di conseguenza, sebbene non assolutamente richiesta per DevOps, la SRE si allinea strettamente 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 presso Google, che per definire SRE disse: "SRE è ciò che accade quando chiedi a un ingegnere del software di progettare un team di operazioni".

Uno specialista SRE è uno sviluppatore di software con esperienza nelle operazioni IT - qualcuno che sa come scrivere codice e comprende anche come assicurarsi che un ambiente IT su larga scala continui ad operare. 

Gli specialisti SRE dedicano non più della metà del loro tempo all'esecuzione di operazioni IT manuali e attività di amministrazione del sistema - analisi dei log, ottimizzazione delle prestazioni, applicazione di patch, test degli ambienti di produzione, risposta agli incidenti, esecuzione di post-mortem - e trascorrono il resto del proprio tempo a sviluppare codice che automatizzi tali attività. Il loro obiettivo nel tempo è dedicare molto meno tempo al primo aspetto e molto più al secondo.

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

• SLI (service level indicator): misurazioni del livello di servizio fornito dai sistemi - metriche quali disponibilità (tempo di attività) o latenza
  
  
• SLO (service level objective): strumenti concordati per misurare gli SLI
  
  
• Budget di errori: la quantità massima di tempo per cui un sistema può avere dei malfunzionamenti o prestazioni non ottimali senza violare i termini contrattuali dello SLA. Più che una metrica, il budget di errori è lo strumento utilizzato da un team SRE per conciliare automaticamente il ritmo di innovazione di un'azienda con la sua affidabilità del servizio. 

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

Supponiamo che lo SLA di un'azienda assicuri un tempo di attività annuale del 99,99% (un obiettivo di disponibilità comune). Ciò significa che il budget di errori mensile - ossia il totale dei tempi di inattività consentiti senza conseguenze contrattuali per un dato mese - è di circa 4 minuti e 23 secondi.

Ora supponiamo che il team di sviluppo voglia implementare alcune nuove funzionalità o dei miglioramenti al sistema. Se il sistema è in esecuzione al di sotto del budget di errori, il team potrà distribuire le nuove funzioni. In caso contrario, il team non potrà distribuire le nuove funzioni finché non collaborerà con il team di operazioni per ridurre tali errori o interruzioni a un livello accettabile.

In questo modo, i budget di errori aiutano i team di sviluppo e i team di operazioni a

• Migliorare la stabilità e le prestazioni dei servizi
  
  
• Prendere decisioni basate sui dati riguardo all'implementazione di nuove funzioni o applicazioni
  
  
• Massimizzare l'innovazione assumendo rischi entro limiti accettabili

DevOps è un metodo moderno per fornire più velocemente applicazioni di qualità superiore, automatizzando il ciclo di vita della distribuzione del software e dando ai team di sviluppo e operazioni più responsabilità condivise e più accesso al lavoro reciproco. 

Alla stregua di SRE, DevOps rende un'azienda più agile bilanciando la necessità di fornire più velocemente applicazioni e modifiche con la necessità di evitare di "interrompere" l'ambiente di produzione. E, come SRE, DevOps mira a raggiungere questo equilibrio definendo un rischio di errori accettabile. In effetti, SRE e DevOps sembrano così simili che alcuni esperti affermano che siano la stessa cosa, ma la maggior parte considera le prassi SRE come un metodo eccellente per implementare i principi DevOps. Ad esempio:

Principi DevOps: ridurre i silos organizzativi, sfruttare la strumentazione e l'automazione

Prassi SRE: utilizzare la stessa strumentazione per automatizzare e migliorare le operazioni utilizzata dagli sviluppatori per sviluppare e migliorare il software

Principi DevOps: accettare il malfunzionamento come normale, implementare modifiche graduali

Prassi SRE: utilizzare i budget di errori per implementare continuamente nuove funzioni e caratteristiche entro livelli accettabili di

Principio DevOps: misurare tutto

Prassi SRE: basare le decisioni per il rilascio di nuovo software sulle metriche SLA

Per scoprire di più su DevOps, guarda questo video (5:58):

Oltre a supportare il successo di DevOps, la SRE può aiutare un'azienda a:

• Acquisire una maggiore visibilità sull'integrità dei servizi  monitorando metriche, log e tracce in tutti i servizi dell'organizzazione e fornendo un contesto per identificare le cause ultime in caso di incidente.
  
  
• Quantificare il costo dei tempi di inattività aiutando i team di sviluppo e di operazioni a comprendere il costo delle violazioni degli SLA e aiutando la direzione a quantificare l'impatto dell'affidabilità del sistema su produzione, vendite, marketing, servizio clienti e altre funzioni aziendali.
  
  
• Ottimizzare la risposta agli incidenti creando processi efficienti di reperibilità e semplificando i flussi di lavoro di avviso.
  
  
• Costruire un moderno centro operativo di rete combinando una conoscenza approfondita delle operazioni IT con il machine learning e l'automazione, per inviare avvisi direttamente alla persona incaricata di far fronte al problema.

La migrazione dall'IT tradizionale e dai data center on-premise ad ambienti cloud ibridi è uno dei motivi principali per cui l'azienda media genera da due a tre volte più dati operativi ogni anno. La SRE è vista sempre più come 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 di sviluppo nativo del cloud  - in particolare la creazione di applicazioni come microservizi e la relativa implementazione in container - può semplificare lo sviluppo, l'implementazione la scalabilità delle applicazioni. Ma lo sviluppo nativo del cloud crea anche un ambiente sempre più distribuito che complica amministrazione, operazioni e gestione. Un team SRE può supportare il rapido ritmo d'innovazione abilitato da un approccio nativo del cloud e garantire o migliorare l'affidabilità del sistema, senza esercitare ulteriore pressione operativa sui team DevOps.