Google ACE: Monitoraggio, logging e risoluzione dei problemi operativi — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Risoluzione dei problemi di servizi, risorse e rete

Una risoluzione dei problemi efficiente parte dai sintomi, passa ai confini del sistema e quindi alle risorse e alle dipendenze.

• Stato di salute dei servizi gestiti, stato dei servizi, quote e incidenti regionali

  • Verificare se un incidente è a monte (upstream): controllare lo stato di salute del servizio e gli avvisi regionali recenti. Cercare picchi di errori, latenza elevata o errori di quota.
  • Le quote sono per progetto e spesso per regione; quotaExceeded e rateLimitExceeded nei log indicano throttling. Richiedere aumenti prima di eventi di picco.
  • Modalità di guasto: interruzioni regionali parziali possono apparire come errori intermittenti; configurare il failover multi-regionale dove possibile.

• Stato di salute delle risorse e diagnostica delle VM

  • Utilizzare le operazioni sulle istanze, gli eventi di manutenzione e gli health check. Per i MIG, ispezionare i riavvii di autoriparazione (autohealing) e i fallimenti degli health check per isolare immagini o configurazioni errate.
  • Console seriale della VM per i messaggi di avvio e del kernel:
    • gcloud compute connect-to-serial-port VM_NAME –zone=ZONE
    • Cause comuni: kernel panic, voci fstab errate che bloccano l’avvio, configurazioni di rete non corrette, configurazione errata di OS Login che causa fallimenti SSH.
  • Garantire l’accesso con OS Login tramite chiavi SSH per utente e ruoli IAM (compute.osLogin o compute.osAdminLogin) per un accesso attribuibile.

• Logs Explorer per l’analisi dei guasti

  • Iniziare con i log dei sintomi (5xx, deadlineExceeded), fare pivoting sulle etichette delle risorse, quindi correlare con le modifiche di deployment e i log delle quote. Utilizzare le viste a istogramma per individuare i punti di cambiamento.

• Osservabilità della rete

  • VPC Flow Logs: campionamento per VNIC del traffico a 5 tuple; abilitare sulle subnet. Ottimizzare il campionamento (ad esempio, 0.5) e le opzioni dei metadati per bilanciare prestazioni e dettaglio.
    • gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –flow-sampling=0.5 –aggregation-interval=interval-5-min –metadata=include-all
  • Logging del firewall: catturare le decisioni di allow/deny su regole critiche per diagnosticare blocchi imprevisti o shadowing (regole nascoste).
    • gcloud compute firewall-rules update RULE_NAME –enable-logging
  • Connectivity Tests: modellare e verificare la raggiungibilità tra VPC, peering, Cloud VPN, Cloud Interconnect e regole firewall. Utile per la validazione pre-modifica e il triage degli incidenti.
    • gcloud network-management connectivity-tests create test-a –source-instance=projects/PRJ/zones/ZONE/instances/VM1 –destination-ip=10.0.3.21 –protocol=TCP –destination-port=443
  • Segnali complementari: log di Cloud NAT e dei load balancer per problemi di egress e perimetrali (edge). Le modalità di guasto includono routing asimmetrico, rotte mancanti, regole firewall in ordine errato e vincoli di policy.

Affidabilità, SLO e gestione degli incidenti

La disciplina operativa lega la telemetria agli obiettivi di impatto sull’utente e a un’esecuzione coerente degli incidenti.

• SLO, error budget e baseline

  • Definire gli SLO su SLI incentrati sull’utente (disponibilità, latenza, correttezza). Esempio: il 99,9% delle richieste di lettura viene completato in meno di 200 ms su un periodo di 30 giorni.
  • Monitorare gli error budget e progettare dashboard di riepilogo per servizio e versione di rilascio. Bloccare i rollout in base al consumo del budget.
  • Stabilire baseline di performance prima degli aumenti di traffico; le regressioni vengono rilevate dalla deviazione, non da valori assoluti.

• Riduzione del rumore degli alert

  • Preferire alert a livello di servizio piuttosto che a livello di istanza. Utilizzare condizioni basate sulla velocità di variazione (rate-of-change) e sui percentili. Applicare il throttling delle notifiche, la chiusura automatica degli incidenti e il silenziamento degli alert per le finestre di manutenzione.
  • Deduplicare gli alert tramite etichette e policy comuni; utilizzare un routing consapevole delle dipendenze per evitare di allertare sia il database che l’applicazione per lo stesso incidente.

• Flusso di lavoro per la risposta agli incidenti

  • Effettuare il triage e dichiarare la gravità; assegnare i ruoli (incident commander, operations, communications, scribe).
  • Percorsi di escalation: rotazioni di reperibilità (on-call), esperti di materia (subject-matter expert) e supporto del fornitore (includere ID progetto, ID richiesta, timestamp e region nei ticket di supporto).
  • Comunicazione: mantenere un’unica fonte di verità (canale di chat e documento dell’incidente). Fornire aggiornamenti periodici agli stakeholder con impatto, mitigazione e tempi stimati di risoluzione (ETA).
  • Playbook di mitigazione: rollback, failover, disabilitazione di feature flag o aggiunta di capacità. Preferire modifiche reversibili con un raggio d’impatto (blast radius) limitato.

• Revisione post-incidente e RCA

  • Basato sulle evidenze: correlare metriche, log, trace ed eventi di modifica. Includere quali segnali di rilevamento si sono attivati, perché o perché no, e il tempo di rilevamento/mitigazione (time-to-detect/mitigate).
  • Identificare i fattori contribuenti, non solo la causa prossima. Catturare azioni concrete (action item) con responsabili e scadenze; aggiornare di conseguenza i runbook e gli alert.
  • Una cultura “blameless” (senza colpe) incoraggia la piena trasparenza e le correzioni sistemiche.

• Runbook operativi

  • Struttura: trigger e rilevamento, albero di diagnosi rapida, mitigazioni sicure, passaggi di rollback/ripristino, verifica e criteri di uscita.
  • Mantenere comandi e filtri pronti per il copia-incolla; verificare i privilegi minimi (least-privilege) di IAM per i soccorritori (ad esempio, storage.objectCreator per backup di sola scrittura; service account dedicati per la workload identity).
  • Versionare i runbook con il change management; testarli durante i game day.

Scenario pratico

Northwind Outfitters gestisce una piattaforma di e-commerce regionale su Google Cloud. A seguito di un recente picco di traffico, gli utenti segnalano intermittentemente timeout del checkout e ricerche di prodotti lente. Il team operativo deve ripristinare rapidamente l’affidabilità, ridurre il rumore degli alert e rafforzare la diagnostica su più progetti.

Approccio:

1. Consolidare il monitoraggio tra i progetti

• Azione: Creare un singolo workspace di Monitoring e collegare i progetti prod, payments e search. Costruire una dashboard “User Journey” che mostri disponibilità, latenza e tassi di errore per il checkout e la ricerca.
• Motivazione: La visibilità centralizzata supporta il triage a livello di servizio e correla i problemi tra servizi (ad esempio, la latenza della ricerca che si ripercuote in timeout del checkout).

2. Implementare SLO e alerting basato sul burn-rate

• Azione: Definire gli SLO: 99,9% di checkout sotto i 400 ms, 99,95% di ricerche sotto i 250 ms. Creare alert di burn-rate multi-finestra (2% in 1 ora e 5% in 5 minuti) sugli SLI di latenza e tasso di errore. Notificare il personale reperibile (on-call) tramite paging, gli stakeholder tramite chat.
• Motivazione: Gli alert di burn-rate intercettano regressioni veloci e lenti consumi sostenuti senza inviare notifiche per la normale varianza.

3. Aggiungere controlli di uptime sintetici con content match

• Azione: Configurare controlli di uptime TCP e HTTPS per gli entrypoint pubblici e un controllo di uptime privato per l’API di pagamento interna, convalidando che il corpo della risposta contenga “ok”.
• Motivazione: Rileva la raggiungibilità e i fallimenti parziali come backend instradati in modo errato o upstream degradati.

4. Ottimizzare le rotte e la conservazione dei log

• Azione: Creare bucket di log dedicati: ops (90 giorni), security-audit (2 anni, CMEK). Indirizzare i log di Admin Activity, Data Access, System Event e Policy Denied a BigQuery tramite sink per l’analisi. Aggiungere esclusioni per gli health check troppo verbosi (chatty).
• Motivazione: Una conservazione dimensionata correttamente controlla i costi; BigQuery consente un’analisi forense rapida. Le esclusioni riducono il rumore senza perdere evidenze critiche.

5. Abilitare la diagnostica dell’applicazione

• Azione: Strumentare i servizi con OpenTelemetry per Trace; abilitare Error Reporting per backend e frontend; implementare Profiler sul servizio di checkout con profili CPU e heap a un campionamento conservativo.
• Motivazione: I trace identificano i percorsi critici (hot path) di latenza; Error Reporting evidenzia nuovi gruppi di errori; Profiler rivela contesa della CPU e perdite di memoria (memory leak) con un basso overhead.

6. Rafforzare l’osservabilità della rete

• Azione: Abilitare i VPC Flow Logs sulle subnet di produzione (campionamento 0.5, includi tutti i metadati) e il logging del firewall sulle regole di allow/deny per il traffico in entrata (ingress) verso i servizi di ricerca e pagamento. Creare Connectivity Tests dal livello web alla ricerca e dai pagamenti a Cloud SQL.
• Motivazione: I log di flusso e del firewall espongono pacchetti persi (drop), ritrasmissioni e regole nascoste (shadowed rule); i Connectivity Tests convalidano la raggiungibilità e identificano le configurazioni errate.

7. Diagnostica a livello di risorsa e accesso sicuro

• Azione: Per le VM instabili, ispezionare i problemi di avvio con la console seriale:
  • gcloud compute connect-to-serial-port checkout-vm –zone=us-central1-a
  • Se è richiesto l’accesso SSH, imporre OS Login e concedere il ruolo compute.osAdminLogin al gruppo “ops-admins”. Ogni amministratore utilizza la propria chiave SSH.
• Motivazione: I log della console seriale rivelano errori del kernel e di init. OS Login con chiavi per utente garantisce un accesso attribuibile e con privilegi minimi.

8. Verifica delle quote e dello stato di salute della region

• Azione: Esaminare gli eventi recenti di quotaExceeded nei log; aumentare la quota regionale di API e IP per l’autoscaling della ricerca. Controllare gli avvisi sullo stato del servizio per la region interessata; spostare temporaneamente il traffico con la ponderazione del load balancer.
• Motivazione: Il throttling delle quote e gli incidenti regionali sono fonti comuni di fallimenti intermittenti; lo scaling proattivo e l’indirizzamento del traffico mitigano l’impatto.

9. Riduzione del rumore e aggiornamento dei runbook

• Azione: Sostituire gli alert sulla CPU per istanza con alert di saturazione a livello di servizio. Aggiungere finestre di manutenzione per silenziare gli alert non azionabili. Aggiornare i runbook con nuove query di triage, dashboard di trace e procedure di rollback.
• Motivazione: Riduce l’affaticamento da paging e accelera risposte coerenti e sicure.

10. Revisione post-incidente e azioni correttive

• Azione: Condurre una revisione ‘blameless’. Correlare gli incidenti di burn-rate con l’aumento della latenza di coda (tail latency) della ricerca e un recente rollout di un indice. Azioni correttive (action item): aggiungere rilasci canary per la ricerca, guardrail sulla dimensione dell’indice e margine (headroom) per l’autoscaler; impegnarsi a testare periodicamente i canali di alerting.
• Motivazione: Una RCA basata sulle evidenze previene le recidive e migliora il rilevamento, la mitigazione e la resilienza.

← Implementazione · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →