In questa pagina
Sono le 02:40 UTC. Uno degli 11 tipi di check regionali di Perstat segnala da Francoforte un errore sulla tua API dei pagamenti. Altre regioni selezionate in base al piano riportano lo stesso risultato, e la regola regionale configurata conferma l’incident.
Quella conferma crea un timestamp operativo. Non classifica l’incident ai sensi di DORA. Se la tua organizzazione lo classifica come incidente grave connesso alle TIC, si applicano le scadenze di segnalazione di DORA.
La parte difficile non è solo redigere le relazioni, ma raccoglierne gli input mentre il tempo scorre. Un registro di monitoraggio può contribuire con i tempi di rilevamento, conferma e ripristino. Da solo non può fornire la classificazione giuridica, l’impatto su clienti o transazioni, la causa radice o la decisione di segnalare.
Per la parte di questo lavoro che riguarda la disponibilità contano tre punti:
- cosa può apportare un registro di monitoraggio
- perché screenshot e thread di Slack sono deboli come unica fonte
- dove si ferma Perstat
Questa non è una consulenza legale: classificazione e segnalazione restano una tua responsabilità. Consulta le fonti primarie: il regolamento (UE) 2022/2554 e lo standard tecnico su contenuto e termini delle notifiche.
Per gli incidenti gravi valgono tre scadenze
DORA si applica dal 17 gennaio 2025. Per gli incidenti gravi connessi alle TIC, l’ articolo 5 del regolamento delegato (UE) 2025/301 della Commissione stabilisce questa sequenza standard:
| Segnalazione | Scadenza | Contenuto |
|---|---|---|
| Notifica iniziale | Entro 4 ore dalla classificazione come grave | Campi iniziali richiesti dal modello di notifica |
| Relazione intermedia | Entro 72 ore dalla notifica iniziale | Fatti e stato attuali |
| Relazione finale | Entro un mese dall’ultima relazione intermedia | Valutazione finale e campi richiesti dal modello |
La notifica iniziale va presentata il prima possibile. Scade entro 4 ore dalla classificazione dell’incidente come grave e non oltre 24 ore dalla presa di conoscenza.
La relazione intermedia va presentata al più tardi entro 72 ore dall’invio della notifica iniziale. Aggiornala senza indebito ritardo quando le attività regolari riprendono. La relazione finale va presentata non oltre un mese dopo la relazione intermedia o dopo l’ultima relazione intermedia aggiornata.
Il termine di 4 ore parte dalla classificazione come grave, non dall’inizio del disservizio. Il limite separato di 24 ore decorre dalla presa di conoscenza. Tieni separati tre timestamp: il rilevamento, il confine dell’incident confermato dalla regola e la classificazione.
Il monitoraggio può fornire i primi due secondo la propria regola documentata. La classificazione è un giudizio giuridico e operativo esterno al prodotto di monitoraggio. L’articolo 5 contiene altri casi particolari, quindi fa fede il testo primario.
Il monitoraggio aiuta a rispondere ad alcune domande
Lo standard UE sulle segnalazioni copre molto più della disponibilità. Un registro di monitoraggio può aiutare a rispondere ad alcune domande dirette:
- Quando è stato rilevato l’incident, e quando è iniziato?
- Per quanto tempo i servizi sono rimasti indisponibili?
- Quali servizi monitorati e regioni di sonda hanno mostrato un impatto?
- Quando è stato ripristinato il servizio, e come lo sai?
Da solo, lo stesso registro non può dire quanti clienti o transazioni siano stati colpiti. Né può, da solo, quantificare l’impatto finanziario o sui dati, stabilire la diffusione geografica in senso giuridico o determinare la causa radice. Anche il downtime misurato dipende dal tipo di monitor documentato e dalla regola sugli incident.
Una pagina di stato può aggiungere un’altra versione pubblica. Se la pubblicazione o le annotazioni differiscono dal registro interno, quella differenza va spiegata. Non dare per scontato che uno scostamento sia impossibile.
Da soli, screenshot e chat sono fonti deboli
Uno screenshot della dashboard e la cronologia di Slack possono essere punti di partenza per ricostruire un disservizio a posteriori. Entrambi possono aggiungere contesto. Nessuno dei due è una fonte unica solida per i timestamp del monitoraggio.
Uno screenshot mostra di solito un numero in un singolo istante, non gli eventi che lo hanno prodotto. Può anche omettere l’orologio, la regola o la fonte.
Un thread di chat registra quando le persone hanno parlato dell’incident, non necessariamente quando il monitoraggio lo ha rilevato o confermato. Messaggi e ricordi possono comunque essere utili, ma vanno riconciliati con il registro di sistema.
Un revisore può chiedere a ragione da dove arriva un timestamp, quale regola lo ha prodotto e se la revisione successiva è visibile. Un registro continuo di eventi risponde a queste domande in modo più diretto di un’immagine ritagliata o di una sequenza ricordata a memoria.
Confini visibili rendono un registro verificabile
Un registro di disponibilità può contribuire al lavoro sulle segnalazioni DORA quando i suoi confini e la revisione successiva sono verificabili. Questo contributo non equivale a una valutazione di compliance.
Il sistema registra i timestamp
I tempi di rilevamento e di ripristino arrivano dal monitoraggio stesso. Vengono registrati mentre accadono, non digitati dopo. Un timestamp vale quanto l’orologio che lo produce.
La conferma ha un ambito esplicito
Il fallimento di una singola sonda regionale può significare che il target è irraggiungibile. Può anche significare che un percorso di rete è instabile. Per gli 11 tipi di check regionali di Perstat, Free usa 2 regioni, Pulse 3, e Sentinel e i piani superiori fino a 6.
La regola regionale è configurabile e usa per impostazione predefinita un quorum di 2 regioni. Per questi monitor, l’inizio registrato dell’incident è la conferma della regola configurata, non la prima sonda fallita.
I monitor agent e heartbeat non usano né regioni né quorum e seguono regole proprie per i segnali in arrivo. È la semantica del prodotto, non la definizione giuridica di incidente secondo DORA.
Le esclusioni manuali restano visibili
Perstat tiene il downtime misurato separato dal registro curato dei disservizi. Le finestre di manutenzione e di esclusione conservano i loro confini reali. Un’esclusione manuale conserva motivo e autore e può essere annullata.
Lo scopo è rendere visibile l’intervento, non abbellire il numero. Questo registro di prodotto non rende un’esclusione automaticamente accettabile per un’autorità di vigilanza o una controparte.
Le pagine di stato possono condividere il registro
Un componente collegato della pagina di stato può usare lo stesso registro di monitor e incident. La pubblicazione resta un’azione esplicita, e le annotazioni pubbliche possono differire dal registro interno.
Una fonte condivisa riduce le ricostruzioni duplicate. Non garantisce che ogni versione pubblica e interna sia identica.
Un esempio editoriale mostra i conti
Il report SLA di esempio pubblico di Perstat è un’illustrazione editoriale e ricalcolabile per un servizio demo. Non è un report cliente generato né un export self-service.
L’esempio ipotizza sei regioni su un trimestre di 91 giorni, cioè 131.040 minuti. Su queste regioni conta 1.572.480 check e un incident confermato:
- 02:40:42 UTC: un check fallisce da eu (Francoforte)
- 02:41:12 UTC: il quorum conferma quando na (Newark) e as (Singapore) concordano
- 02:48:24 UTC: il ripristino è confermato in tutte le regioni
La finestra SLA va dalla conferma al ripristino confermato, dalle 02:41:12 alle 02:48:24 UTC, e dura 7 minuti e 12 secondi. I 30 secondi prima della conferma restano visibili nel registro. Non vengono allungati né accorciati in silenzio. 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.
La disponibilità lorda è del 99,925%, e del 99,994% dopo aver escluso l’unica finestra di manutenzione annunciata. Puoi ricalcolare ognuno di questi numeri di esempio. Descrivono l’esempio editoriale, non il deployment di un cliente.
Parti dalla segnalazione e procedi a ritroso
Prendi un campo della relazione e chiediti dove si trova la risposta. Fallo prima di un incident, non dopo:
| Esigenza di segnalazione | Possibile fonte in Perstat |
|---|---|
| Ora del rilevamento | Timestamp del monitoraggio, registrato in diretta |
| Ora di inizio dell’incident | Conferma della regola configurata per sonde regionali |
| Durata dell’indisponibilità | Finestra tra conferma e ripristino configurati |
| Guasto del servizio o singola route osservata | Risultati regionali degli 11 tipi di check |
| Downtime pianificato o revisione | Manutenzione ed esclusioni con confini, motivo e autore |
| Ripristino osservato | Ripristino secondo la regola configurata del monitor |
I monitor agent e heartbeat usano regole proprie per i segnali in arrivo, quindi non forzarli in un modello di quorum regionale. Se oggi un campo richiesto non ha una fonte, colma la lacuna prima del prossimo evento da segnalare.
Il monitoraggio copre una parte delle segnalazioni DORA
Un prodotto di monitoraggio non ti rende pronto per DORA. Non classifica e non presenta una segnalazione al posto tuo. Questi elementi restano a te:
- ambito
- classificazione
- registro dei fornitori terzi di servizi TIC
- flusso di segnalazione
- valutazione giuridica
Il monitoraggio può apportare queste parti al registro più ampio che il tuo team costruisce:
- timestamp di sistema
- misurazioni
- incident
- manutenzione
- revisione visibile
Gli 11 tipi di check regionali di Perstat includono HTTP, TCP e DNS. A seconda del piano, possono scendere fino a intervalli di 10 secondi tramite MCP.
Questi tipi di check usano fino a sei regioni in base al piano e la regola regionale configurata descritta sopra. Agent e heartbeat non usano né queste regioni né questa regola.
Il control plane è nell’UE, e l’azienda dietro Perstat è tedesca. Questi fatti possono sostenere un registro di disponibilità, non un’affermazione di compliance DORA.
Oggi il registro curato vive nel prodotto, e l’esempio pubblico è editoriale. Ogni vista del monitor offre un report PDF per 7, 14, 30 o 90 giorni, in ogni piano. Il report non è firmato né certificato. Un CSV a livello di organizzazione con manifest è disponibile manualmente su richiesta.
Guarda il tour del prodotto o l’ esempio editoriale senza registrarti. Quando sei pronto, inizia a monitorare gratis.