La 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 dei cambiamenti, la risposta agli incidenti e persino la risposta alle emergenze, che altrimenti potrebbero essere eseguiti manualmente dagli amministratori di sistema. 

Il principio alla base di 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 operativi 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 strettamente richiesto per  DevOps, la SRE si allinea strettamente con i principi DevOps e può svolgere un ruolo importante nel  successo di DevOps.

Il concetto della SRE è attribuito a Ben Treynor Sloss, VP of Engineering di Google, che per definire SRE disse: "SRE è ciò che accade quando chiedi a un ingegnere del software di progettare un team operativo".

Uno specialista SRE è uno sviluppatore di software con esperienza nelle operazioni IT, ha conoscenze di programmazione e sa anche come assicurarsi che un ambiente IT di grandi dimensioni 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 registri, ottimizzazione delle prestazioni, applicazione di patch, test degli ambienti di produzione, risposta agli incidenti, esecuzione di postmortem, 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 operativi, 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 operativi a definire

• Service level indicators (SLI): Misurazioni del livello di servizio fornito dai sistemi, metriche quali disponibilità (uptime) o latenza
• Service level objectives (SLOs): Strumenti concordati per misurare gli indicatori del livello di servizio
• Budget di errore: La quantità massima di tempo per cui un sistema può avere dei malfunzionamenti o prestazioni inferiori senza violare i termini contrattuali dello SLA. Più che una metrica, il budget di errore è lo strumento utilizzato da un team SRE  per conciliare 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 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 errore 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 miglioramenti al sistema. Se il sistema ha un budget di errore basso, il team potrà distribuire le nuove funzionalità. In caso contrario, il team non potrà distribuire le nuove funzionalità finché non collaborerà con il team operativo per ridurre tali errori o interruzioni a un livello accettabile.

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

• Migliorare la stabilità e le prestazioni dei servizi
• Prendere decisioni sull'implementazione di nuove funzionalità o applicazioni che siano basate sui dati
• 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 degli altri. 

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 accettabile di errori. In effetti, SRE e DevOps sembrano così simili che alcuni esperti affermano che sono la stessa cosa, ma la maggior parte considera le pratiche SRE come un metodo eccellente per implementare i principi DevOps. Ad esempio:

Principi DevOps: Ridurre i silos organizzativi, sfruttare gli strumenti e l'automazione

Pratiche SRE: Utilizzare gli stessi strumenti per automatizzare e migliorare le operazioni utilizzati dagli sviluppatori per sviluppare e migliorare il software

Principi DevOps: Accettare l'errore come normale, implementare cambiamenti graduali

Pratiche SRE: Utilizzare budget di errore per implementare continuamente nuove funzionalità e caratteristiche entro livelli accettabili di

Principio DevOps: Misurare tutto

Pratica SRE: Basare le decisioni per il rilascio di nuovo software sulle  metriche

Per ulteriori informazioni 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 principali in caso di incidente.
• Quantificare il costo dei tempi di inattività  aiutando i team di sviluppo e operativi 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 la machine learning e l'automazione, per inviare avvisi direttamente alla persona responsabile della risoluzione del problema.

La migrazione  dall'IT tradizionale e dai data center on-premise ad ambienti  cloud ibridi  è uno dei motivi principali per cui l'impresa media genera  da due a tre volte più dati operativi ogni anno. SRE è visto 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  cloud-native , in particolare la creazione di applicazioni quali  microservizi  e la loro distribuzione in  contenitori , 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 amministrazione, operazioni e gestione. Un team SRE può supportare ritmo rapido d'innovazione grazie ad un approccio cloud-native e garantire o migliorare l'affidabilità del sistema, senza esercitare ulteriore pressione operativa sui team DevOps.

IBM Cloud Pak for Watson AIOps riunisce  i dati operativi attraverso stack e strumenti IT in silos, per offrire al team SRE  una visione olistica dell'intero ambiente IT. Fornisce inoltre una AI potente per prevedere e risolvere in modo proattivo i problemi prima che diventino incidenti. Con IBM Cloud Pak for Watson AIOps puoi acquisire una comprensione più profonda di metriche ed eventi, anticipare e calcolare i rischi e automatizzare le tue operazioni IT per ridurre i rischi e abbassare i costi. 

Scopri di più su  IBM Cloud Pak for Watson AIOps.

Scopri come l'applicazione dell'AI e dell'automazione alle operazioni IT può aiutare gli specialisti SRE a garantire la resilienza e la solidità delle applicazioni aziendali e a liberare tempo prezioso e talento per supportare l'innovazione. Leggi 'An SRE Journey to AIOps'

Attraverso il percorso di apprendimento lo specialista  IBM Cloud Professional SRE , crea competenze e impara come un IBM Cloud SRE rende i sistemi affidabili, applica i moderni modelli di progettazione Cloud al codice e crea soluzioni durature per le esigenze dei clienti e i problemi di servizio.

Registrati per un IBMid e crea il tuo  account IBM Cloud.