Oltre 1 milione di eventi di audit log al mese in PostgreSQL, con backup e replay
Come abbiamo costruito un unico registro operativo che copre tutto il ciclo di vita amministrativo, legale e HR di un’azienda italiana — composto da fonti esterne, e mai scritto senza lasciare traccia.
Il registro operativo di un’azienda italiana è insolitamente esigente.
Deve modellare i tipi documento della fatturazione elettronica, l’autofatturazione, i modelli di versamento, le ritenute, le prestazioni occasionali e i congedi di legge — un ciclo di vita che la maggior parte dei sistemi generalisti si limita ad approssimare.
E attraversa contabilità, area legale e HR invece di stare comodamente dentro una delle tre.
Due cose hanno determinato tutto il resto:
Step 1: Quasi tutti i dati nascono fuori dall’azienda
Le fatture arrivano come XML strutturato. I movimenti bancari arrivano come esportazioni. Gli IBAN vengono validati contro un servizio esterno prima di essere considerati attendibili. Gli indirizzi vengono geocodificati.
Le riunioni arrivano come registrazioni e diventano trascrizioni con lo speaker etichettato. La documentazione viene tradotta fra inglese e italiano mantenendo intatto il markup. L’attività produttiva viene letta dal gestionale stesso.
Diciotto fonti esterne al lancio, con altre aggiunte nel tempo. Ognuna arriva attraverso un’unica funzione di ingestione invece che da un’importazione su misura, e atterra già verificata contro il sistema che la possiede.
Le fatture fornitore si riconciliano poi automaticamente con i movimenti bancari, portandosi dietro uno stato di abbinamento esplicito invece di una spunta manuale.
Step 2: Niente può cambiare senza lasciare traccia
Ogni scrittura passa da una policy a livello di riga in PostgreSQL prima di atterrare. Ogni riga che atterra fa scattare un trigger che registra il valore precedente, il valore nuovo e esattamente quali campi sono cambiati.
Quell’audit log non è un report che qualcuno legge. È il meccanismo di replica.
Le righe non ancora sincronizzate vengono rigiocate dentro un database di standby indipendente, che a sua volta serve una copia in sola lettura dell’intera applicazione per il disaster recovery.
Un meccanismo, tre mestieri: permessi, storico, ripristino. Niente può essere cambiato in silenzio, perché l’azienda segue obblighi di conformità stringenti che impongono di sapere con chiarezza chi ha fatto cosa, quando e con quali permessi.
Un ciclo di vita che nessun sistema generico modella
Tipi di fattura elettronica, autofatturazione, ritenute e congedi di legge, fra contabilità, legale e HR insieme.
Dati che nascono altrove
Diciotto fonti esterne al lancio, ognuna con la sua forma e i suoi modi di rompersi.
Modifiche che non devono mai restare non registrate
Ogni scrittura si porta dietro il valore vecchio, quello nuovo e i campi che si sono mossi.
Ogni modifica è registrata, e tutto si può ricostruire.
Risolvere un problema di conformità non richiede più giorni di indagine. Il registro risponde a chi ha cambiato cosa, quando e con quali permessi — direttamente, dal log stesso.
Fatture fornitore e movimenti bancari si riconciliano da soli, portandosi dietro uno stato di abbinamento esplicito invece di una spunta su un foglio.
Ogni modifica nel sistema è attribuibile — chi, quando, quali campi, quale valore c’era prima — senza che nessuno debba ricordarsi di annotare niente.
Il disaster recovery smette di essere un backup periodico e diventa una conseguenza continua di come funzionano le scritture. La seconda copia non è mai indietro più di un replay.
Amministrazione, legale e HR hanno un unico posto dove verificare cosa è successo a valle di un problema di conformità, e risolverlo in fretta.
Problemi di dati di questa forma?
Se qualcosa qui somiglia alla tua situazione, dicci quale parte. Risposta garantita entro 2 ore lavorative (CET).
Arrigo Lupori
Fondatore e Amministratore