Skip to content

12 - Soglie e ripristino

Guida iniziale · Stato

Questa scheda definisce una proposta operativa concreta. I valori della prima tabella sono nella configurazione già applicata; i nuovi allarmi e la prova di restore qui descritti non sono stati attivati o eseguiti. Gli obiettivi riguardano lo stage, non sono SLA di produzione né un dimensionamento per cento allevamenti.

Base attuale e responsabilità

Voce Configurazione di riferimento
Budget 200 USD/mese, avvisi al 50%, 90% e 100% della spesa corrente, crediti esclusi. Filtro sulle cartelle shared e stage; non rappresenta tutta la spesa aziendale
Destinatari budget Email esplicita di Jacopo; destinatari IAM predefiniti mantenuti. Ricezione effettiva del messaggio da collaudare
Cloud SQL sql-stage, PostgreSQL 17, 1 vCPU / 3,75 GiB, zonale; disco iniziale 40 GB con crescita fino a 100 GB
Backup SQL Automatico giornaliero nella finestra delle 02:00 UTC, otto backup conservati per conteggio; PITR abilitato con sette giorni di log
Backend Access/Farm distribuiti Minimo zero, massimo configurato due istanze per revisione, pool SQL massimo due connessioni per istanza; nessun nuovo valore applicato con questa scheda
Responsabilità Jacopo e Lorenzo gestiscono configurazione, diagnosi e restore. Chi sviluppa un sistema definisce anche le sue metriche applicative e i bisogni di capacità

Fonti: budget Terraform, configurazione bootstrap, modulo SQL, configurazione stage.

Le notifiche di budget non sono un tetto automatico di spesa. Anche il limite Cloud Run non va usato come garanzia di costo: durante un rilascio possono coesistere revisioni e il conteggio reale deve essere osservato. Budget Google · Limiti Cloud Run.

Soglie iniziali proposte

Destinatari proposti: jtedeschi@moonitoring.com e lcipolletti@moonitoring.com, senza creare un altro gruppo. Un referente prende in carico l'incidente e lo segna nel registro condiviso; stage non implica reperibilità notturna. Prima dell'abilitazione verificare canali e ricevere un messaggio di prova.

Segnale Soglia proposta Azione richiesta
Spesa Conservare 100 / 180 / 200 USD effettivi; aggiungere previsione mensile al 100% del budget Revisione consumi congiunta al 90% o previsione oltre 200 USD; niente spegnimento automatico del DB
CPU SQL Oltre 80% per 15 minuti Cercare query lente, attese e carichi di build/dataset; aumentare il tier solo dopo misura
Disco SQL Oltre 80% del disco allocato per 10 minuti; urgenza se almeno 90 GB usati rispetto al tetto di 100 GB Verificare crescita e spazio residuo; niente cancellazione automatica di dati o backup
Connessioni SQL Oltre 70% di max_connections per 10 minuti; urgenza oltre 85% per 5 minuti Verificare pool, revisioni sovrapposte e Job; leggere il limite effettivo, non dedurlo dal numero di aziende
Errori backend 5xx almeno 5% su 5 minuti, con almeno 20 richieste nello stesso intervallo Correlare revisione, errori SQL e log; distinguere risposte IAM negate attese dai 5xx applicativi
Readiness privata Tre fallimenti consecutivi di una sonda IAM ogni 5 minuti Diagnosi rete, IAM e DB. La sonda avvia anche istanze a zero: abilitarla consapevolmente, non dichiararla già disponibile
Backup e PITR Backup fallito, nessun backup riuscito da 30 ore, oppure ultimo istante recuperabile più vecchio di 15 minuti per due controlli consecutivi Incidente di recuperabilità: leggere lo stato reale delle API, non solo il flag Terraform

Per percentuali usare finestre e aggregazioni coerenti; un singolo picco non deve diventare un allarme prolungato. Assenza di campioni HTTP su uno stage inattivo non significa errore; un controllo backup mancante è invece un esito incerto da segnalare. I nomi delle metriche, i filtri per progetto/istanza e le query vanno verificati nell'implementazione prima dell'apply.

Il budget delle connessioni comprende tutte le revisioni contemporanee: somma(istanze per revisione × pool) + pool dei Job concorrenti + riserva. Manteniamo almeno il 20% del limite per operazioni e margine; un nuovo componente deve rientrare nel totale prima del suo onboarding. Il numero di connessioni non prova capacità di elaborazione, correttezza delle query o isolamento tenant.

Obiettivi e prova di restore proposta

  • RPO obiettivo: 15 minuti con PITR. È la perdita massima di dati che vogliamo accettare; va confrontata con l'ultimo istante effettivamente recuperabile.
  • RTO obiettivo: quattro ore dall'avvio della procedura alla verifica della copia. È l'obiettivo del collaudo tecnico in orario presidiato; non include una promessa di reperibilità o il ripristino completo del prodotto.
  • Il ripiego su backup giornaliero ha obiettivo massimo di 24 ore di dati persi, se il backup è disponibile: è una modalità degradata e non soddisfa il RPO PITR.
  • Prima prova una volta prima della chiusura operativa, poi dopo cambiamenti sostanziali di backup/SQL e almeno trimestralmente. Preventivo della prova entro 10 USD, da verificare prima di creare la copia; non è un limite di spesa imposto automaticamente da Google.

La destinazione proposta è sql-stage-restore-YYYYMMDD in moonitoring-db-stage, con IP privato e isolamento da verificare prima della creazione. Non si cambiano DNS o connessioni delle applicazioni correnti. Il PITR crea una nuova istanza e ripristina tutti i suoi database: non sovrascrivere sql-stage per recuperare soltanto Farm. PITR Google.

Procedura da rendere eseguibile e collaudare:

  1. Leggere backup riusciti e finestra PITR reale, identificare origine, destinazione, orario UTC recuperabile e costo previsto. Progettare e verificare l'isolamento della copia prima di crearla: nello stesso progetto i permessi IAM SQL esistenti possono valere anche per la nuova istanza mentre nasce. Se non si può documentare una separazione efficace nella destinazione proposta, predisporre prima una destinazione isolata. Registrare un campione sintetico prima/dopo l'orario scelto, in uno schema di prova separato e senza dati aziendali.
  2. Creare la copia con un identificativo univoco e registrare l'operazione API. Un timeout del client richiede riconciliazione, non un secondo restore.
  3. Prima di collegare le sonde, verificare rete, login e grant ripristinati. Verificare e rimuovere sulla sola copia gli eventuali login runtime, migratore e altri account applicativi copiati; autorizzare l'identità di collaudo. Confermare l'isolamento deciso al punto 1 prima di proseguire: non cambiare DNS, da solo, non impedisce l'accesso alla copia.
  4. Verificare tramite connessione privata versione PostgreSQL, database, schema, migrazioni, ruoli e campione: dato precedente presente, dato successivo assente. Non eseguire automaticamente il migratore più recente sulla copia prima di controllare cosa è stato recuperato. Nessuna email, webhook o consumer reali.
  5. Misurare punto recuperato, tempi e risultato delle verifiche. Il test termina con successo solo se contenuto e accessi sono corretti entro gli obiettivi; l'istanza RUNNABLE da sola non basta. Un test locale non sostituisce questa prova.
  6. Rimuovere solo copia, sonde e permessi temporanei identificati dalla ricevuta; verificare l'assenza delle risorse e che lo stage originale sia invariato. Un'etichetta con scadenza non cancella da sola l'istanza: la pulizia è un passo operativo verificato, anche quando la prova fallisce.

Prima dell'esecuzione fissare nomi, permessi e preventivo. Registrare poi RPO/RTO osservati, costo, esito e cleanup. Raw e dataset su object storage richiedono prove di recupero separate.

Chiusura: gli allarmi devono produrre una notifica ricevuta e un rientro visibile; il restore deve recuperare il campione con accessi verificati e cleanup. Fino ad allora soglie e RPO/RTO restano obiettivi documentati, non garanzie.