Un amministratore maturo non aspetta i ticket: guarda i report che anticipano i problemi, e quando deve scalare a Google arriva con un caso già istruito. Sono due abitudini che si imparano, e l’esame le tratta come una competenza sola.

Monitorare l’uso: app, storage e dispositivi

La sezione Reporting della Admin console offre report già pronti, distinti dai log grezzi. Gli Apps reports mostrano l’adozione servizio per servizio: quanti utenti attivi su Gmail, Drive, Meet o Chat in un periodo, con quale volume di attività. Servono a due domande diverse: la licenza che state pagando viene usata, e un calo improvviso di attività su un servizio è il primo segnale di un problema che nessuno ha ancora segnalato.

Sullo spazio, la Admin console espone lo storage occupato dall’organizzazione e i maggiori consumatori, mentre il report sugli account riporta lo spazio usato dal singolo utente. È un controllo da fare periodicamente e non a incidente avvenuto: una casella al limite smette di ricevere posta e l’utente segnalerà «la mail non arriva», mandandovi a cercare la causa nel posto sbagliato.

I report sui dispositivi completano il quadro con il parco gestito: sistemi operativi, stato di sincronizzazione, dispositivi in attesa di approvazione. Per l’attività puntuale si passa ai Devices log events, che registrano registrazione, blocco e cancellazione dei dispositivi.

Quando i report della console non bastano, l’esportazione dei log su BigQuery mette a disposizione tabelle di attività e tabelle di usage, incrociabili fra app e collegabili a strumenti di visualizzazione: è la strada per analisi storiche e cruscotti personalizzati.

Report di audit e regole che vi avvisano

I report di audit rispondono alle domande di responsabilità: chi ha cambiato quella impostazione (Admin log events), chi ha effettuato l’accesso e da dove (User log events), chi ha condiviso quel file all’esterno (Drive log events), chi è entrato o uscito da un gruppo, quali app di terze parti hanno ottenuto un token (OAuth Token log events).

Controllarli a mano tutti i giorni non è realistico, e infatti la console permette di trasformare una ricerca in una regola: da Rules > Create rule > Activity si sceglie la sorgente di log, si aggiungono filtri su attributi come Actor o Event, e si definisce l’azione, cioè un alert nell’alert center con severità alta, media o bassa e la notifica via email ai super administrator o a destinatari specifici. Il modello è «se accade x, fai automaticamente y»: per esempio avvisare quando un file di Drive viene condiviso pubblicamente. Tenete presente il tetto di 50 regole per dominio e il fatto che una regola nuova può impiegare fino a 24 ore per diventare pienamente operativa.

Preparare il caso: riproduzione, log e file HAR

Quando un problema va scalato, la qualità delle informazioni decide i tempi. Il primo materiale da raccogliere sono i passi di riproduzione documentati dall’utente: che cosa stava facendo, in quale ordine, che cosa si aspettava e che cosa ha visto, con data, ora e fuso orario, l’indirizzo interessato, il browser o il client con la versione, e uno screenshot del messaggio d’errore per intero. Un caso che dice «Drive non va» non è un caso.

Poi si scelgono i log giusti per il tipo di problema: Email Log Search e le intestazioni complete del messaggio per la posta, i log events pertinenti dall’audit tool per attività e permessi, i log locali del client per Drive for Desktop, i dati del Meet quality tool per audio e video.

Per i problemi che si manifestano nel browser il formato richiesto è il file HAR, la registrazione del traffico di rete della sessione. Si apre la scheda Network degli strumenti per sviluppatori, si attiva la conservazione del log, si ricarica la pagina, si riproduce il problema e si esporta la registrazione. Due cautele: la registrazione deve coprire il momento esatto dell’errore, altrimenti è inutile; e un HAR contiene cookie e dati di sessione, quindi va trattato come materiale sensibile e condiviso solo con il canale di supporto.

Aprire il caso e seguire i rilasci

Prima di aprire, verificate lo stato del servizio e i problemi noti sul Google Workspace Status Dashboard: se l’incidente è già dichiarato, il caso non serve. Se il problema resta vostro, il supporto si contatta dalla Admin console tramite l’icona di aiuto, che avvia la richiesta e fornisce un codice identificativo della sessione oltre al numero del caso. Le buone pratiche sono poche e sempre le stesse: un caso per problema, priorità coerente con l’impatto reale, elenco degli utenti e delle OU coinvolti, indicazione se il comportamento riguarda tutti o un sottoinsieme, e tutti gli allegati raccolti al primo messaggio invece che a rate.

Infine, la manutenzione ordinaria della conoscenza: il blog degli aggiornamenti di Google Workspace annuncia le novità e i loro tempi di distribuzione, il release calendar aiuta a prevederne l’arrivo, e la distinzione fra rapid release e scheduled release spiega perché una funzione compare in un dominio prima che nel vostro. Molti presunti guasti sono soltanto una modifica di interfaccia rilasciata quella settimana.