Il database GitLab del 2017: retrospettiva su backup e segnali di errore
Parliamo del tuo progetto →Il post-mortem GitLab del 2017 offre uno spunto utile per verificare backup, notifiche e ripristino: una retrospettiva storica con un esercizio applicabile anche a un piccolo team. GitLab, 10 febbraio 2017
Nel resoconto pubblicato il 10 febbraio 2017 sull’incidente del 31 gennaio, GitLab descrive backup interrotti da un’incompatibilità tra versioni di pg_dump e database, notifiche di errore respinte e il recupero tramite una snapshot disponibile. Sono fatti del caso storico, non una descrizione dell’infrastruttura GitLab attuale.
La domanda operativa
La lettura editoriale Dedaloop è questa: chi osserva che un backup non è stato prodotto e chi verifica che sia utilizzabile? Pianificare un’attività, ricevere un segnale di completamento e recuperare un servizio sono tre verifiche diverse.
Non serve replicare l’incidente per discuterle. Il laboratorio proposto usa un database fittizio e una scheda di controllo; non richiede cancellazioni in produzione e non rappresenta un intervento svolto per un cliente.
Una prova in tre passaggi
- Inventario: elenca per il servizio scelto strumento di backup, versione, destinazione, frequenza e responsabile. Se un campo è sconosciuto, annotalo come attività da completare.
- Segnalazione: in un ambiente di test, usa il meccanismo di prova previsto dal sistema di monitoraggio per verificare destinatario, canale alternativo e presa in carico. Non bloccare deliberatamente i backup reali.
- Recupero: ripristina un dataset di prova in un ambiente separato e controlla dati noti. Annota dipendenze, credenziali necessarie e passaggi che richiedono una persona specifica.
Non confondere gli indicatori
L’età dell’ultimo backup valido, l’ultimo allarme effettivamente ricevuto e la data dell’ultima prova di ripristino rispondono a domande differenti. Tenerli separati aiuta a vedere un sistema che produce copie ma non è mai stato provato, oppure un allarme inviato a un destinatario non più operativo.
Per chiudere la sessione, assegna un proprietario a ogni lacuna e stabilisci quando ripetere la prova. Un aggiornamento di versione è un’occasione per ricontrollare la compatibilità degli strumenti, non una prova automatica che qualcosa si romperà.
Il valore di questa storia non è attribuire a un singolo errore tutti i problemi di un’organizzazione. È trasformare un resoconto pubblico in domande verificabili sul proprio servizio, mantenendo distinta l’esperienza documentata di GitLab dalle scelte che proponiamo oggi.