Lo schema che vive solo nel database in funzione

Tutto ciò che questo servizio fa sta nel controllo di versione. Il codice, quanto meno. Il database su cui gira sono 32 tabelle, e 15 di esse non hanno una definizione da nessuna parte nel repository — nessun CREATE TABLE, nessun file di schema, niente. Se il server andasse perso, il codice tornerebbe identico e la forma dei dati andrebbe ricostruita da quello che il codice si trova a chiedere.

Queste cifre vengono dal confronto fra il database in funzione e 736 file, 5.671.710 caratteri di repository. Non sono una stima.

Come sparisce metà di uno schema

Non è sciatteria, ed è proprio questo a renderlo degno di essere scritto. Ogni singolo passo era ragionevole.

Le tabelle create prima del codice attuale non sono mai state messe per iscritto, perché all'epoca c'erano e basta. Le tabelle aggiunte da allora sono arrivate con script di migrazione, e quelli sono nel repository — da lì vengono le 17 definizioni. Le colonne aggiunte più tardi sono arrivate con un ALTER TABLE di una riga digitato a un prompt, perché digitarlo era più veloce che scrivere uno script per una modifica che dura un secondo.

Gli indici sono il caso peggiore. Un indice si aggiunge quando qualcosa è lento, nel momento in cui è lento, e risolve subito. Non resta nessun artefatto, niente da rileggere, niente che fallisca se te ne dimentichi. Undici dei trentadue indici secondari di qui esistono esattamente per questo e non sono registrati da nessuna parte.

La tabella in cui stanno i contatori stessi, 166.438 righe, è fra le quindici senza definizione nel repository.

Che cosa si rompe davvero

Poco, fino a un momento preciso: quando il database viene ripristinato da un dump.

Un dump porta con sé la struttura, quindi un ripristino diretto va bene. Il pericolo è ogni percorso che ricostruisce una tabella invece di ripristinarla — un trasloco su un'altra macchina, l'import di tabelle scelte, la ricreazione da uno script. I dati tornano, gli indici silenziosamente no. Niente fallisce. Le query restituiscono le risposte giuste. Ci mettono solo di più, e la causa è invisibile, perché l'unica traccia di che cosa fosse l'indice sta sulla macchina che non ce l'ha più.

È questo il guasto da nominare: un indice mancante non produce un errore, produce una risposta corretta più lenta. Non c'è un test per questo, perché i test passano.

Che cosa facciamo nel frattempo

La posizione onesta è che questo non è risolto. Lo schema oggi non è nel repository. Quello che c'è è meno di una soluzione e meglio di niente:

Un dump prima di qualunque cosa distruttiva, tenuto fuori dalla radice web. Un ripristino davvero eseguito almeno una volta, invece che dato per fatto. E un elenco breve, controllato dopo ogni ripristino, degli indici che si sa esistere solo nel database in funzione — perché alla macchina si può chiedere quali indici ha, e la risposta si può confrontare con l'ultima volta.

La versione generale vale per più dei database. Se una parte del sistema sta solo nel sistema in funzione, non ne hai una copia, ne hai un ostaggio. La domanda che vale la pena porsi su qualunque pezzo di infrastruttura non è «è salvato» ma «se questa macchina sparisse, che cosa non si potrebbe ricostruire dal repository». Qui la risposta è quindici tabelle e undici indici, e per saperlo è servito un pomeriggio.