Quando un utente segnala che «qualcosa non funziona», la differenza fra un amministratore efficace e uno che tira a indovinare sta nell’ordine delle mosse: prima si delimita il perimetro del problema, poi si guardano le prove, e solo alla fine si tocca una configurazione.

Dove vivono le prove: Reporting e Audit and investigation

Il punto di partenza è la Admin console, alla voce Reporting > Audit and investigation. Qui confluiscono oltre quaranta sorgenti di log events: Admin log events per le modifiche fatte dagli amministratori, User log events per accessi e cambi di stato degli account, Drive log events per creazione, spostamento e condivisione dei file, e poi Calendar, Chat, Meet, Groups, Devices, OAuth Token, SAML e Vault.

Il flusso di lavoro è sempre lo stesso. Si sceglie la sorgente di log, si usa Add a filter per aggiungere condizioni su attributi come Actor, Event, Date o IP address, si combinano i filtri e si esegue la ricerca. Nelle edizioni base i filtri si sommano in AND; le edizioni premium aprono l’investigation tool del security center, che aggiunge query annidate, raggruppamento dei risultati per attributo e azioni sui risultati. L’esportazione arriva a 100.000 righe per download: utile quando l’analisi va fatta fuori dalla console o allegata a un caso di supporto.

Due avvertenze pratiche. La prima: la visibilità sui log dipende dai privilegi amministrativi assegnati, quindi un delegato che «non vede niente» spesso non ha un problema tecnico ma un ruolo troppo stretto. La seconda: i log raccontano le azioni, non le intenzioni. Un evento va sempre letto insieme al suo attore, al suo orario e al suo indirizzo IP.

Leggere una voce di log senza farsi ingannare

Cercare in un log significa cercare tre cose diverse: un messaggio di errore esplicito, un’attività anomala (un accesso da un paese in cui non avete dipendenti, una condivisione massiva verso l’esterno) e un pattern, cioè la ripetizione che trasforma un caso isolato in un incidente.

Il pattern più redditizio nella pratica quotidiana è la correlazione fra Admin log events e il momento in cui gli utenti hanno iniziato a lamentarsi: moltissimi «guasti» sono in realtà una modifica di policy applicata a un’unità organizzativa il giorno prima. Se venti utenti della stessa OU perdono una funzione nello stesso pomeriggio, la causa è quasi certamente una riga negli Admin log events.

Per non trarre conclusioni sbagliate servono due numeri. La retention: la maggior parte dei log events resta disponibile 6 mesi, i Vault log events a tempo indefinito, mentre Email Log Search copre solo gli ultimi 30 giorni. E il lag, cioè il ritardo con cui un evento compare: Admin, Drive, Chat, Meet, Devices e SAML sono in near real time (qualche minuto), Calendar e Groups possono richiedere decine di minuti fino a un paio d’ore, gli OAuth Token log events un paio d’ore. L’errore classico è dichiarare «non risulta nulla» dieci minuti dopo un evento Calendar: il log non è vuoto, è solo in ritardo.

Escludere il disservizio globale prima di scavare

Prima di aprire dieci filtri, controllate il Google Workspace Status Dashboard, che riporta lo stato di ciascun servizio (Gmail, Drive, Calendar, Meet, Chat) e la cronologia degli incidenti con gli aggiornamenti pubblicati da Google.

Il dashboard funziona come discriminante. Se segnala un’interruzione sul servizio interessato, la diagnosi si ferma lì: il vostro lavoro diventa comunicare l’incidente agli utenti, indicare eventuali soluzioni temporanee e seguire gli aggiornamenti. Se invece è tutto verde e il problema riguarda pochi utenti, la causa è quasi sempre locale: una configurazione applicata a un’OU o a un gruppo, una licenza mancante, la rete dell’ufficio o il client sul dispositivo. Il dashboard descrive lo stato globale del servizio, non il vostro dominio: un problema che colpisce solo la vostra organizzazione non comparirà mai lì.

Dal sintomo alla modifica di mail policy

I problemi di posta sono la categoria più frequente, ed è anche quella in cui la diagnosi si traduce direttamente in una raccomandazione di policy. Email Log Search, sui 30 giorni disponibili, dice dove il messaggio si è fermato attraverso il delivery status.

La lettura dei principali stati guida la soluzione. Quarantined significa che un’impostazione ha spedito il messaggio in quarantena: si rivedono le regole di quarantine e le content compliance rules, oppure si stabilisce chi presidia le code di Manage quarantined messages. Marked spam su corrispondenza legittima e ricorrente suggerisce di aggiungere il mittente agli approved senders o, con cautela e solo per infrastrutture di cui rispondete, alle IP allowlists. Rejected o Dropped indicano un blocco in uscita per reputazione o filtro antispam in uscita, quindi un problema del mittente, non del destinatario. Bounced rimanda a un indirizzo inesistente o a una policy restrittiva.

Altre raccomandazioni tipiche: attivare un catch-all mailbox per la posta indirizzata male, impostare routing o split delivery quando parte delle caselle vive ancora su un sistema legacy, usare le address lists per applicare un’impostazione a persone o domini specifici. Un messaggio che in Email Log Search mostra un transit time interno a Google inferiore a dieci minuti ma arriva in ritardo scarica la responsabilità sul provider a valle: in quel caso la policy da cambiare non è la vostra.