Tre domande per verificare i report SLA

La percentuale è solo l’affermazione. Chi esamina il report può anche chiedere quali finestre l’hanno prodotta, quali modifiche sono state fatte e da dove arrivano i timestamp.

In questa pagina

Il numero in cima a un report SLA è un’affermazione: 99,95%, questo trimestre, nero su bianco. Un cliente, l’ufficio acquisti, un auditor o un’autorità di vigilanza può fare una domanda più difficile: come fai a saperlo? Le evidenze richieste e la conclusione dipendono dal loro perimetro.

La domanda conta negli ambiti regolamentati. DORA si applica dal 17 gennaio 2025, e la NIS2 stabilisce obblighi di segnalazione degli incidenti per i soggetti che rientrano nel suo ambito.

Stabilire se uno dei due quadri si applica, come classificare un incident e quale scadenza decorre sono decisioni giuridiche e operative. Queste decisioni stanno fuori da uno strumento di monitoraggio. Chi esamina il report ha comunque bisogno di evidenze da poter verificare.

Tre lacune meritano un controllo, ed ecco come trovarle nel tuo report. Sono domande di verifica, non una previsione sull’esito di un audit.

Parti dalla percentuale e procedi a ritroso

Fai tre domande alla percentuale:

  • Quali finestre hanno contato come downtime?
  • Quali finestre sono state escluse, e perché?
  • Che cosa ha registrato i timestamp?

Un report che non sa rispondere a queste tre domande è più difficile da ricalcolare. È il test circoscritto usato qui, e non presuppone un comportamento universale degli auditor.

Le finestre arrotondate sono la prima lacuna

Molti report riducono i disservizi a cifre tonde. Una finestra diventa “circa 15 minuti”, oppure tutto ciò che sta sotto i 10 minuti viene scartato come rumore.

Il risultato si legge bene, ma non si può ricostruire. Un auditor non può ricalcolare una percentuale da una finestra smussata.

La posta in gioco è aritmetica. Un obiettivo del 99,95% su un trimestre di 91 giorni lascia circa 65 minuti di budget di downtime su 131.040 minuti. Una sola finestra arrotondata dalla parte sbagliata può nascondere uno sforamento reale o inventarne uno.

Se un incident di 7 minuti e 12 secondi viene registrato come “circa 15 minuti”, hai sovrastimato il tuo stesso downtime di quasi 8 minuti senza motivo. Se lo arrotondi a zero, hai cancellato in silenzio un’evidenza che un’autorità potrà poi confrontare con il reclamo di un cliente.

Come chiuderla. Registra i confini reali al secondo e lascia che la percentuale ne derivi. Una finestra arrotondata a 15 minuti non ha un aspetto migliore e non si può difendere.

Le esclusioni silenziose sono la seconda lacuna

Tieni distinti due percorsi. La manutenzione annunciata ha un programma e un annuncio prima della finestra. La revisione dei falsi positivi avviene dopo la misurazione e richiede un proprio autore, un motivo, l’effetto prima/dopo e la possibilità di annullarla.

Nessuno dei due percorsi decide cosa un contratto o chi esamina il report debba accettare.

Come chiuderla. Mostra i confini reali e la provenienza di ciascun percorso. Etichetta la manutenzione annunciata come pianificata, ed etichetta una correzione successiva come revisione. Non presentare l’una come l’altra, e non rimuovere in silenzio nessuna delle due dal registro verificabile.

La misurazione autodichiarata è la terza lacuna

È la lacuna che i team si aspettano di meno, perché riguarda il punto di osservazione, non i conti.

Se i tuoi dati di disponibilità arrivano da una sola sonda, o peggio dalla stessa infrastruttura che si è guastata, un auditor ha un’obiezione legittima. Non puoi distinguere un tuo problema di rete da un guasto reale del servizio. Chi ricostruisce la timeline a posteriori non può nemmeno dimostrare che i timestamp non siano stati aggiustati.

Come chiuderla. Misura dall’esterno del sistema monitorato. Registra osservazioni da più di un percorso selezionato in base al piano prima di contare un incident.

L’accordo tra più località è un’evidenza correlata da più percorsi. Riduce la dipendenza da una singola route, ma non dimostra la causa radice o l’origine giuridica.

Lascia che il sistema di monitoraggio apponga i timestamp mentre gli eventi accadono. Documenta la regola che ha trasformato quelle osservazioni in un incident.

Un report solido ha tre proprietà

Le tre proprietà sono poco appariscenti:

  • confini reali delle finestre
  • percorsi di manutenzione e revisione visibili ed etichettati in modo distinto
  • misurazione presa dall’esterno del sistema e confermata tra più regioni

Niente di tutto questo alza il tuo uptime. Rende il tuo uptime verificabile e dà a chi esamina il report una base da controllare. Un numero lusinghiero che non puoi difendere vale meno di uno onesto che puoi difendere.

Leggi una riga del report di esempio

Un registro si capisce meglio vedendolo che descrivendolo, perciò Perstat pubblica un esempio editoriale. Il report SLA di esempio illustra un solo trimestre per un servizio demo, e ogni numero al suo interno torna. Non è un report cliente generato automaticamente.

Un check fallisce a Francoforte alle 02:40:42 UTC, ma l’incident non si apre lì. Trenta secondi dopo, le sonde di Newark e Singapore concordano che il servizio è irraggiungibile. Il quorum conferma, e l’incident si apre alle 02:41:12 UTC. Il monitor di esempio applica una regola di 1 check fallito per regione con un quorum di 2 regioni, non l’impostazione predefinita di 2 check consecutivi.

Quella conferma è l’inizio della finestra conteggiata, dalle 02:41:12 alle 02:48:24 UTC. La finestra non parte dal primo check fallito né da un minuto arrotondato.

La finestra di manutenzione di 90 minuti, più avanti nello stesso mese, è esclusa, ma resta nel report con il timestamp del suo annuncio. La disponibilità lorda è del 99,925%. Dopo aver escluso quella manutenzione annunciata, è del 99,994%.

L’aritmetica editoriale si può ricalcolare. L’esempio non è una relazione di assurance né una segnalazione regolamentare.

Classificazione e segnalazione restano al tuo team

Un prodotto di monitoraggio non stabilisce per nessuno la compliance a DORA o NIS2. Classificazione, invio delle segnalazioni e scadenze restano una tua responsabilità. Uno strumento può apportare timestamp di sistema, misurazioni, registri di manutenzione e cura visibile alle evidenze più ampie che il tuo team raccoglie.

Se il tuo report attuale non sa rispondere alle tre domande qui sopra, conviene saperlo adesso. Per ora l’unico costo è un numero un po’ meno lusinghiero.

Puoi iniziare a monitorare gratis o prima fare un giro nel prodotto. Non ti serve una telefonata commerciale per vedere come viene tenuto il registro.