Nessun deploy senza monitor.

Il 29 maggio una funzione per controlli aggiuntivi sulle policy di quota è arrivata in Service Control senza feature flag e senza gestione degli errori sul nuovo percorso. Il 12 giugno una modifica di policy ha prodotto campi vuoti, e i binari sono andati in crash in tutto il mondo con un errore di null pointer. Google ha scritto che il suo primo rapporto sull’incident è arrivato circa un’ora dopo l’inizio dei crash, perché l’infrastruttura di Cloud Service Health era a sua volta fuori uso. Ha scritto anche che alcuni clienti avevano su Google Cloud la propria infrastruttura di monitoraggio, che stava fallendo a sua volta e li lasciava senza un segnale dell’incident.

Cosa mostra un check dall’esternoQuell’ultima frase è l’argomento a favore del monitoraggio esterno, con le parole dell’operatore stesso: un monitoraggio sulla stessa piattaforma cade con lei. Perstat controlla dall’esterno, da un massimo di 6 regioni con un quorum, e la sua infrastruttura di sonde non gira sulla piattaforma che osserva. Una pagina di stato su un’infrastruttura separata avrebbe informato i tuoi clienti durante quell’ora.

Fonte: Rapporto sull’incident di Google Cloud, 2025-06-12 · The Register, 2025-06-16

Uno script pensato per cancellare le istanze di un’app dismessa ha ricevuto ID di siti invece di ID di app. Dalle 07:38 UTC ha cancellato interi siti di clienti nell’arco di 23 minuti. Il primo ticket di un cliente è arrivato alle 07:46 UTC, dopo 8 minuti, e il processo per gli incident gravi è partito alle 08:17 UTC. Il primo aggiornamento della pagina di stato è arrivato alle 09:03 UTC, dopo 85 minuti, e la prima dichiarazione esterna ampia sui social il 7 aprile, dopo 41 ore. Il ripristino ha richiesto fino a 14 giorni ed era automatizzato solo in parte.

Cosa mostra un check dall’esternoUn check HTTP dell’URL del tuo tenant da più regioni segnala il disservizio dopo 2 check consecutivi falliti, senza aspettare un ticket di supporto. Alcuni clienti hanno perso Statuspage e Opsgenie insieme ai siti, quindi pagina di stato e alert non devono stare presso il provider di cui dovrebbero mostrare il disservizio. Nessun monitoraggio avrebbe accorciato i 14 giorni.

Fonte: Post-incident review di Atlassian, 2022-04-29

Il CEO ha scritto che l’azienda rinnova con precisione migliaia di domini ogni anno, eppure il processo di rinnovo automatico del suo dominio principale è fallito. La dichiarazione ha indicato come causa un errore umano e di processo. I clienti si sono lamentati pubblicamente su Twitter.

Cosa mostra un check dall’esternoUn check del dominio riporta la data di scadenza con giorni di anticipo, da un sistema che non dipende dal rinnovo automatico che è fallito. Un check DNS da più regioni avrebbe segnalato la perdita di risoluzione dopo 2 check consecutivi falliti. Una pagina di stato su un altro dominio avrebbe portato il messaggio mentre marketo.com non risolveva, ma nessun check può rinnovare il dominio.

Fonte: Knowledge base di Marketo (Adobe), P1 del 25 luglio 2017 · The Drum, 2017-07-26

Mentre riparava la replica, un ingegnere ha rimosso la directory dei dati sul primario invece che sul secondario. I backup pg_dump non esistevano, perché lo script eseguiva pg_dump 9.2 contro PostgreSQL 9.6 e falliva. GitLab ha scritto che le notifiche per i job cron falliti venivano inviate via email, ma DMARC non era abilitato per quelle email, quindi il ricevente le rifiutava. Gli snapshot dei dischi non erano abilitati per i server del database, e restava solo uno snapshot LVM manuale vecchio di 6 ore.

Cosa mostra un heartbeatUn heartbeat funziona come dead man’s switch: il job di backup invia un segnale dopo il successo, e Perstat avvisa se il segnale manca, con o senza un’email di errore. Il caso mostra anche che gli alert non devono dipendere da un solo canale, che può fallire a sua volta. L’escalation dovrebbe quindi passare su più percorsi e richiedere una presa in carico. Un heartbeat non controlla se il backup si può ripristinare: quello resta compito di un test di ripristino.

Fonte: Post-mortem di GitLab, 2017-02-10 · The Register, 2017-02-01, sulle 5 tecniche di backup