Quando tutti i processi interni vengono dichiarati critici, l'organizzazione finisce per avere avvisi continui, reperibilità difficili da sostenere e impegni che nessuno riesce a mantenere. Il problema non è soltanto tecnico: si diluisce la reale priorità di un'interruzione e aumenta il costo operativo di applicazioni, integrazioni e dati che potrebbero invece tollerare un'attesa, una rielaborazione o un'alternativa manuale.
La decisione utile non consiste nell'etichettare un sistema come «importante». Consiste nel concordare quale conseguenza per il business sia inaccettabile, per quanto tempo e a quali condizioni. Da qui, alcuni processi richiederanno un accordo sul livello di servizio (SLA); altri funzioneranno meglio con un'aspettativa operativa, un obiettivo interno rivedibile o semplicemente buone pratiche di supporto.
Questo quadro consente di giustificare le priorità davanti ai team di prodotto, business e tecnologia senza scegliere numeri d'istinto né trasformare ogni richiesta in un obbligo di disponibilità permanente.
SLA, obiettivo operativo e buona pratica: impegni diversi
Uno SLA è un impegno esplicito relativo a un servizio definito. In genere stabilisce ambito, orari, metriche, responsabilità, esclusioni e un meccanismo di revisione o escalation. Non equivale a promettere che non vi saranno mai incidenti: esprime quale livello di funzionamento è atteso e come viene gestito il mancato rispetto dell'impegno.
Nelle operazioni interne, è utile distinguerlo da due strumenti più leggeri:
- Obiettivo di livello di servizio: un traguardo misurabile che orienta le operazioni, come completare una sincronizzazione entro un'ora concordata. Può essere rivisto senza considerare ogni scostamento come un inadempimento contrattuale.
- Aspettativa operativa: una regola di lavoro chiara, ma meno rigida. Per esempio, controllare una coda di richieste nei giorni lavorativi o pubblicare un report all'inizio della giornata.
- Buona pratica: una procedura auspicabile, come monitorare gli errori o documentare un ripristino manuale. È preziosa, ma non dovrebbe essere presentata come una garanzia se mancano capacità, copertura e responsabili in grado di sostenerla.
La differenza decisiva è la conseguenza. Se un'interruzione blocca ricavi, obblighi operativi critici o l'assistenza ai clienti e non esiste una soluzione ragionevole, uno SLA è spesso giustificato. Se il team può riprogrammare l'attività, usare i dati del giorno precedente o completare il lavoro manualmente, un'aspettativa operativa sarà spesso più onesta ed efficiente.
Non assegnate uno SLA in base alla visibilità del richiedente o all'anzianità del sistema. Assegnatelo in base al danno verificabile causato dalla mancata erogazione del servizio entro una specifica finestra temporale.
Le cinque domande per classificare ogni processo
Prima di discutere percentuali di disponibilità o tempi di risposta, classificate il processo usando le stesse domande per tutti i team. La conversazione smette di essere una negoziazione astratta e diventa una valutazione del rischio.
- Qual è l'impatto se non funziona? Descrivete l'effetto su ordini, operazioni, conformità, utenti o decisioni. Evitate risposte generiche come «è molto importante». Individuate quale azione non può essere svolta e chi rimane bloccato.
- Qual è la reale finestra di utilizzo? Un portale usato per inoltrare ordini durante l'intera giornata non ha la stessa esigenza di un caricamento dati notturno. Definite giorni, fasce orarie, chiusure e picchi noti.
- Da cosa dipende? Elencate applicazioni, API, fornitori, credenziali, reti, dati di origine e team responsabili. Un impegno può coprire solo ciò che il team è in grado di osservare e gestire.
- Esiste un'alternativa manuale o degradata? Stabilite se sia possibile registrare temporaneamente le informazioni, accettare ordini attraverso un altro canale, consultare una copia precedente o ritentare un'attività. Valutate anche la reale capacità dell'alternativa, non solo la sua esistenza teorica.
- Quale perdita di dati o ritardo è tollerabile? Distinguete l'indisponibilità dall'integrità. Un processo può accettare due ore di ritardo, ma non una transazione duplicata, dati incompleti o la perdita di modifiche.
Documentate le risposte insieme a un responsabile di business e a uno tecnico. Se non esiste accordo sull'impatto o sulla tolleranza, non esiste ancora una base per stabilire un livello di servizio: vi è una decisione di business in sospeso.
Una matrice di criticità utile per applicazioni e integrazioni
Una matrice semplice evita che la classificazione dipenda da chi presenta la richiesta. Valutate ogni dimensione come bassa, media o alta: impatto, sensibilità alla finestra di utilizzo, assenza di alternativa, rischio sui dati e complessità delle dipendenze.
- Criticità alta: impatto diretto e immediato, finestra ristretta o continua, nessuna alternativa praticabile e rischio significativo di perdita o incoerenza. Richiede SLA, monitoraggio, escalation definita e test di ripristino.
- Criticità media: il ritardo incide sul lavoro o su decisioni rilevanti, ma esiste una modalità degradata o un margine di recupero. Richiede obiettivi operativi misurabili, monitoraggio degli errori e revisione periodica.
- Criticità bassa: il processo migliora l'efficienza, ma può attendere, essere rielaborato o sostituito temporaneamente. Sono sufficienti un'aspettativa operativa, la prioritizzazione nel backlog e il supporto nell'orario concordato.
La categoria va applicata al servizio specifico, non all'intera applicazione. Una stessa piattaforma può contenere un portale transazionale critico, un report di consultazione rinviabile e un'esportazione mensile. Un unico SLA globale nasconderebbe queste differenze e imporrebbe costi inutili.
Esempio di classificazione
Un portale per gli ordini può avere criticità alta se gli utenti non possono inoltrarli attraverso un altro canale e un'interruzione blocca le operazioni. La sincronizzazione notturna del catalogo potrebbe avere criticità media se può essere ritentata prima dell'apertura o se il catalogo precedente consente di operare temporaneamente. Un report interno di monitoraggio può avere criticità bassa se viene consultato una volta al giorno e i suoi dati possono arrivare in ritardo.
Questo esempio non determina una categoria universale. Se la sincronizzazione alimenta prezzi obbligatori o se il report attiva una decisione regolamentata, la valutazione cambia. La classificazione dipende dalla conseguenza e dalla finestra temporale, non dal tipo di tecnologia.
Cosa deve includere uno SLA interno sostenibile
Uno SLA utile deve essere specifico e gestibile. Promettere «alta disponibilità» o «assistenza rapida» crea ambiguità al momento di un incidente. Un documento breve può invece definire con precisione che cosa viene erogato e come viene misurato.
- Ambito: processo, interfacce, utenti e risultato atteso. Indicate quali componenti restano esclusi.
- Orario di servizio: fascia operativa garantita, calendario applicabile e finestre di manutenzione.
- Metriche: disponibilità del processo, tempo di rilevamento, tempo della prima risposta, tempo di ripristino o ritardo massimo ammissibile. Misurate i risultati, non soltanto l'attività del team.
- Responsabili: responsabile di business, responsabile tecnico, team che gestisce l'incidente e responsabili di ciascuna dipendenza.
- Esclusioni: dati di origine non ricevuti, interruzioni di terze parti, modifiche non approvate o utilizzo oltre la capacità prevista. Non sono scuse: delimitano il controllo effettivo.
- Escalation: canale di avviso, livelli di gravità, persone che decidono le misure di continuità e comunicazione agli interessati.
Evitate di copiare obiettivi di fornitori o di altri prodotti. Un valore è difendibile solo se risponde a un'esigenza di business e se architettura, osservabilità e capacità di risposta consentono di rispettarlo. Le pratiche di ingegneria dell'affidabilità rese popolari da Google distinguono tra indicatori, obiettivi e accordi proprio per evitare che un'aspirazione diventi una promessa impossibile.
Come definire metriche senza scegliere numeri arbitrari
Partite dall'esigenza, non da una percentuale. Chiedete: «Qual è l'ultimo momento in cui questo risultato deve essere disponibile per evitare il danno individuato?». La risposta definisce un limite operativo. Confrontate poi il limite con i dati storici, le dipendenze e la capacità di recupero.
Per la disponibilità, misurate la capacità di completare l'azione rilevante, non soltanto il fatto che una pagina risponda. Per un'integrazione, può essere più utile misurare la percentuale di esecuzioni completate e il ritardo dei record rispetto allo stato di un server. Per il ripristino, separate due decisioni:
- Obiettivo di tempo di ripristino: quanto può durare l'interruzione prima di ripristinare il servizio o attivare un'alternativa.
- Obiettivo del punto di ripristino: quante informazioni possono andare perse o restare in attesa di riconciliazione dopo l'incidente.
Definite inoltre un budget di errore operativo: il margine di mancato rispetto che può essere tollerato durante un periodo prima di dare priorità all'affidabilità rispetto ai nuovi miglioramenti. Se il margine si esaurisce ripetutamente, non basta irrigidire lo SLA; occorre rivedere il progetto, la dipendenza esterna, l'automazione, la capacità di supporto o persino la necessità del processo.
Dipendenze, cambiamenti e segnali per rivedere l'impegno
L'errore più frequente consiste nel garantire un risultato end-to-end quando diverse parti non sono sotto lo stesso controllo. Se al flusso partecipano un'API esterna, un team dati o un fornitore di comunicazioni, documentate la dipendenza e concordate il relativo obiettivo. Se tale accordo non esiste, formulate l'impegno in modo condizionato: cosa farà il team quando riceverà dati validi o quando la terza parte ripristinerà il servizio.
Rivedete ogni classificazione quando compare uno di questi segnali:
- Il processo inizia a essere utilizzato in nuovi orari o da più team.
- L'alternativa manuale scompare oppure non è più praticabile per via dei volumi.
- Aumentano gli errori ricorrenti, le rielaborazioni o gli interventi manuali.
- Vengono aggiunte integrazioni, modifiche ai dati o nuovi punti di guasto.
- Un incidente rivela che l'impatto reale è stato maggiore o minore di quello documentato.
Stabilite una revisione periodica e anche una revisione successiva agli incidenti rilevanti. L'esito non deve necessariamente essere un impegno più stringente: può consistere nel ridurre l'ambito, creare una modalità degradata, migliorare un avviso, separare un servizio critico da un'attività rinviabile o ridurre uno SLA che non risponde più all'utilizzo reale.
Checklist per prendere e mantenere la decisione
- Descrivete il risultato di business erogato dal processo.
- Definite impatto, finestra di utilizzo, alternativa, dipendenze e tolleranza a perdita o ritardo.
- Classificate il processo in base alla criticità, non l'applicazione nel suo complesso.
- Assegnate uno SLA solo ai risultati il cui mancato rispetto causa un danno inaccettabile.
- Per tutti gli altri, definite un obiettivo operativo o una chiara aspettativa di supporto.
- Verificate che le metriche siano osservabili e che vi siano responsabili in grado di intervenire.
- Documentate esclusioni e piani di continuità prima che si verifichi un incidente.
- Rivedete l'impegno in caso di cambiamenti nell'utilizzo, nelle dipendenze o nell'impatto.
La maturità non consiste nell'avere più SLA. Consiste nel fare in modo che ogni impegno rifletta un'esigenza reale, sia misurabile e disponga di una risposta operativa praticabile. Questa disciplina protegge sia chi dipende dal servizio sia i team che devono mantenerlo.