Principi e procedure SRE: i cicli virtuosi
Se è vero che "le azioni definiscono ciò che si è", questo è il concetto principale di questo modulo. In questa unità vengono descritte due procedure spesso considerate l'aspetto fondamentale di SRE. Entrambi derivano dal principio che è importante creare "cicli virtuosi", che in questo contesto sono procedure che creano cicli di feedback in un'organizzazione per contribuire a migliorarne continuamente le prestazioni. Poiché saranno disponibili interi moduli successivi relativi a queste due procedure, qui viene offerta solo una panoramica di ognuna.
Ciclo virtuoso 1: indicatori del livello di servizio (SLI) e obiettivi del livello di servizio (SLO)
Nella parte precedente di questo modulo è stata sottolineata l'importanza del lavoro finalizzato a un "livello di affidabilità appropriato". In questa sezione viene esaminata l'applicazione di questo concetto.
Si supponga di voler aggiungere all'ambiente di produzione un nuovo servizio, già creato o ancora in fase di pianificazione. Una parte importante del processo consiste nel prendere alcune decisioni in merito all'affidabilità desiderata. Se il codice non viene interamente scritto personalmente, queste decisioni vengono prese, aspetto fondamentale, in collaborazione con gli sviluppatori che creano il servizio.
La prima decisione consiste nell'individuare quali indicatori verranno usato per l'integrità del servizio (indicatore del livello di servizio o SLI). Si tratta di rispondere alla domanda "Come verificare se il servizio è attivo e funziona correttamente?" Esistono molti modi per tenere traccia degli indicatori SLI, che verranno esaminati in dettaglio più avanti. Tuttavia, questi indicatori sono in genere:
- Misure del successo rispetto all'errore. Il servizio completa correttamente un'operazione una certa percentuale di tempo?
- Misure della tempistica. È stata restituita una risposta entro una determinata soglia di tempo?
- Misure della velocità effettiva. È stata elaborata una certa quantità di dati?
Oppure una combinazione di tutte queste misure.
Per semplicità, si può affermare che l'indicatore del livello di servizio (SLI) corrisponde alla frequenza delle operazioni riuscite, indicata tramite un codice HTTP 200 (a differenza del codice 500 o di altri codici).
Una volta definito un indicatore delle prestazioni del servizio, bisogna decidere il relativo livello di affidabilità che ci si aspetta o si desidera. Ad esempio, si prevede che in un determinato momento della giornata si verifichi una frequenza di errore del 20% per il servizio? In questa descrizione vengono usati numeri elevati arrotondati per maggiore semplicità. Nei moduli successivi la complessità e la precisione delle affermazioni saranno maggiori ("quali utenti riscontreranno questa frequenza di errore? alcuni? la maggior parte?" e così via). Questa aspettativa, creata in collaborazione con lo sviluppatore del servizio, è l'obiettivo del livello di servizio (SLO, Service Level Objective).
L'obiettivo del livello di servizio (SLO) deve essere un elemento che può essere misurato con precisione e rappresentato nel sistema di monitoraggio. Deve essere un obiettivo chiaro relativo all'affidabilità del servizio: ma quale valore è considerato accettabile? Non sono ammesse approssimazioni del tipo “penso che il servizio abbia funzionato bene nell'ultima settimana, ma è difficile dirlo”. Il servizio raggiunge l'obiettivo del livello di servizio (SLO) oppure non lo raggiunge. I dati devono essere chiari. Se il servizio non raggiunge l'obiettivo del livello di servizio (SLO), ripetutamente per un determinato periodo di tempo, significa che si stanno verificando problemi che devono essere risolti.
Budget degli errori
È ragionevole ritenere che un'organizzazione possa intervenire se un servizio non soddisfa il relativo SLO. Ma, in SRE questo concetto viene ulteriormente esteso ai casi in cui lo SLO viene soddisfatto o superato. Alcune organizzazioni usano gli obiettivi del livello di servizio (SLO) per creare i cosiddetti “budget degli errori”.
Per illustrare questo concetto, si consideri il servizio di esempio descritto in precedenza e il relativo obiettivo del livello di servizio (SLO) pari all'80% di operazioni riuscite (ovvero il servizio "deve essere attivo l'80% del tempo"). Con un obiettivo del livello di servizio (SLO) pari all'80% di tempo di attività si stabilisce che il servizio deve essere attivo per l'80% del tempo. E il rimanente 20%? Un tempo di inattività inferiore al 20% non rappresenterà un problema poiché è stato stabilito che un 20% di tempo di attività in più non è importante ai fini dell'obiettivo del servizio.
Di conseguenza, se tale periodo di tempo non rappresenta un problema, quali altre operazioni sono possibili? Un'operazione certamente possibile consiste nel modificare il servizio in esecuzione aggiornandolo, ad esempio con una nuova versione che aggiunge alcune funzionalità. Se la nuova versione rimane attiva e non aggiunge alcun tempo di inattività, non si verificherà alcun problema. Se la nuova versione riduce la stabilità del sistema e restituisce errori per un altro 10% del tempo dedicato al debug, va ancora bene. Tutto ciò rientra ancora nel budget dell'inaffidabilità consentita.
Il budget degli errori è la differenza tra la piena affidabilità potenziale del servizio e l'affidabilità desiderata (100% - 80% = 20%). In questo caso, il budget degli errori offre un'inaffidabilità possibile del 20%, ovvero il 20% di tempo in cui "il fatto che un servizio sia o meno attivo non è un problema poiché la specifica è comunque rispettata". Sarà possibile attingere a quel 20% del tempo e spenderlo nel modo desiderato (ad esempio con più versioni) fino a esaurimento del budget disponibile.
I budget degli errori vengono usati in alcune organizzazioni anche per la situazione meno auspicabile, ovvero quando l'obiettivo del livello di servizio (SLO) non viene raggiunto. In questo caso è possibile scegliere di intraprendere un'azione più severa. Si supponga che si stiano verificando problemi e che il servizio rimanga attivo il 60% del tempo, in base all'indicatore del livello di servizio (SLI) specificato. L'obiettivo (SLO) non è stato raggiunto. Il servizio ha esaurito il budget degli errori. L'organizzazione può scegliere di mantenere la versione attuale a discapito di quella pianificata perché un'altra modifica al sistema non potrebbe che peggiorarne ulteriormente lo stato di affidabilità. I budget degli errori vengono in genere calcolati per un determinato periodo di tempo, come un mese, un trimestre e così via. Il calcolo avviene in modo continuo e quindi, in caso di miglioramento dell'affidabilità del servizio, il budget viene restituito.
Durante questo periodo di rilasci limitati, l'organizzazione può scegliere di rimuovere alcune risorse tecniche dallo sviluppo di funzionalità per destinarle ad attività per l'affidabilità. Con l'obiettivo di individuare e migliorare la fonte dei problemi che hanno causato il colpo di SLO del servizio.
La ragione per cui si parla di “alcune organizzazioni” relativamente ai budget degli errori è che la loro implementazione, in particolare nel caso in cui vengano usati per il rilascio delle versioni, richiede un'accettazione ufficiale. Nel prendere una decisione, l'organizzazione deve essere disposta a trattenere una versione se l'affidabilità del servizio fino ad allora non è stata accettabile. Non tutte le organizzazioni sono disposte a prendere una decisione di questo tipo. Non è infatti l'unica risposta possibile a un budget degli errori esaurito, ma si tratta di quella più comune.
In un modulo separato verranno esaminati in maggior dettaglio gli indicatori SLI, gli obiettivi SLO e i budget degli errori. Ma è utile qui evidenziare l'aspetto del ciclo virtuoso di queste procedure. In teoria, questo ciclo virtuoso offre alle organizzazioni la possibilità di descrivere, comunicare e agire relativamente all'affidabilità di un servizio, stimolando tutti a impegnarsi per migliorarla. Questo ciclo di feedback può essere estremamente importante.
Ciclo virtuoso 2: postmortem senza colpevoli
Il concetto di postmortem, ovvero dell'analisi retrospettiva di un evento significativo in genere indesiderato, non è affatto specifico della disciplina SRE (Site Reliability Engineering). Non è neanche raro nel settore operations. L'unico aspetto originale è l'insistenza da parte degli SRE sulla necessità di avere postmortem “senza colpevoli”. Gli SRE devono concentrarsi sull'errore a livello di processo o di tecnologia durante l'evento imprevisto e non sulle azioni di persone specifiche. "Quale elemento del processo in corso ha consentito a X di eseguire l'azione che ha portato all'errore? Quali informazioni non erano disponibili o importanti per la persona tanto da portarla a una conclusione errata? Quali misure di salvaguardia dovevano essere implementate per impedire che si verificasse un errore così irreversibile?" Queste sono il genere di domande che vengono poste in un postmortem senza colpevoli.
Il senso e l'indirizzamento di queste domande è fondamentale. Vengono ricercati metodi per migliorare i sistemi o i processi, non metodi per punire le persone che usando i sistemi o i processi hanno contribuito in maniera del tutto involontaria all'interruzione del servizio. È importante ricordare che “non si può licenziare la via per l'affidabilità”. Un'organizzazione che licenzia una persona ogni volta che si verifica un errore di produzione (con poche eccezioni), non impara nulla da tali eventi. Al contrario, l'unica persona rimasta avrà timore di qualsiasi cambiamento.
Un processo di postmortem efficace in un'organizzazione crea invece un ciclo virtuoso. Consente all'organizzazione di imparare dalle interruzioni del servizio e di continuare a migliorare i propri sistemi offrendo analisi e follow-up appropriati.
Questo comportamento verso le interruzioni e gli errori considerati dall'organizzazione come opportunità di apprendimento e miglioramento è uno dei principi chiave dell'approccio Site Reliability Engineering (SRE). La creazione di cicli virtuosi per cogliere queste opportunità e indirizzare l'organizzazione verso una maggiore affidabilità è un altro dei principi chiave.
Nell'unità successiva verranno descritti altri principi e procedure relative al lato umano di SRE.