Assumi la responsabilità del servizio dopo il deployment

Definisci il servizio da cui dipendono gli utenti

Il deployment rende disponibile il software. La gestione operativa lo mantiene utile mentre cambiano utenti, dipendenze, traffico e requisiti. Un generatore di codice non elimina questo lavoro continuo.

Per un’esportazione fittizia dei clienti, agli utenti serve più di una pagina raggiungibile. Servono i record autorizzati nel formato richiesto e in tempi accettabili. Il servizio deve anche impedire l’accesso ai dati di un’altra organizzazione.

Indica il responsabile prima del rilascio. Registra chi risponde fuori dall’orario normale, se rientra nell’impegno del servizio. Un fornitore può svolgere parte del lavoro, ma l’organizzazione deve comunque avere un percorso chiaro per decisioni e comunicazione.

Scegli segnali che aiutino ad agire

Un indicatore di livello di servizio, o SLI, misura una proprietà definita del comportamento del servizio. Un obiettivo di livello di servizio, o SLO, fissa un obiettivo per quell’indicatore in un periodo dichiarato. Scegli l’obiettivo dalle esigenze degli utenti e dalla capacità operativa.

Le indicazioni SRE di Google spiegano questo approccio e l’uso di un error budget nelle decisioni sull’affidabilità. Non copiare l’obiettivo di un altro servizio senza verificarne il significato. Indicazioni sugli SLO, esempio di policy sull’error budget.

Per l’esportazione, definisci cosa conta come richiesta ammessa riuscita. Separa i rifiuti previsti dai guasti del sistema. Documenta le esclusioni, così una metrica non può migliorare semplicemente nascondendo richieste difficili.

Evita di registrare esportazioni complete nei log per migliorare la visibilità. Raccogli il minimo necessario a diagnosticare il problema e proteggine l’accesso.

Prepara la risposta agli incidenti

Decidi chi coordina, chi indaga e chi comunica. In un piccolo team i ruoli possono coincidere, ma le responsabilità devono restare chiare. Conserva un registro di osservazioni e azioni.

Le indicazioni di Google sulla risposta agli incidenti evidenziano coordinamento e comunicazione insieme alla mitigazione tecnica. Una correzione tecnicamente corretta può comunque lasciare gli utenti senza informazioni o più operatori a eseguire modifiche in conflitto. Risposta agli incidenti.

Un agente può riassumere log o confrontare ipotesi entro confini dei dati approvati. Non deve ottenere autorità illimitata sulla produzione perché l’incidente è urgente. Usa un percorso di escalation definito per gli accessi eccezionali.

Esercita il recupero e finanzia la manutenzione

Prova la procedura di recupero con dati fittizi rappresentativi. Individua cosa il rollback del codice non può annullare, inclusi record eliminati o messaggi già inviati. Registra tempo e informazioni necessari per ripristinare il servizio.

Assegna il lavoro continuo: aggiornamenti delle dipendenze, revisioni degli accessi, rinnovo dei certificati dove applicabile, modifiche della capacità e correzioni della documentazione. Un servizio senza capacità di manutenzione accumula obblighi dopo la fine del budget di lancio.

Dopo un incidente, scegli miglioramenti che affrontino le cause osservate. Collegali a implementazione e verifica. Così si chiude il ciclo di vita: le prove operative cambiano ciò che il team specificherà e costruirà in seguito.