Qual è la procedura per il debug di un errore di sola produzione?

Question

Lasciatemi dire in anticipo che sono così ignorante su questo argomento che non so nemmeno se questa domanda abbia o meno risposte obiettive. Se finisce con "non", cancellerò o voterò per chiudere il post.

Ecco lo scenario: ho appena scritto un piccolo servizio web. Funziona sulla mia macchina. Funziona sulla macchina del mio team lead. Funziona, per quanto posso dire, su ogni macchina ad eccezione del server di produzione. L'eccezione che il server di produzione sputa in caso di errore proviene da un file JAR di terze parti ed è sciatta sulle informazioni. Eseguo ricerche sul Web per ore, ma non trovo nulla di utile.

Quindi qual è la procedura per rintracciare un problema che si verifica solo su macchine di produzione? C'è una metodologia standard, o forse una categoria/famiglia di strumenti, per questo?

L'errore che ha ispirato questa domanda è già stato risolto, ma ciò è dovuto più alla buona fortuna che a un solido approccio al debug. Sto chiedendo questa domanda per riferimento futuro.

EDIT:
La risposta a questa finora sembra essere riassunta da una sola parola: registrazione. L'unico problema con la registrazione è che richiede lungimiranza. Cosa succede se una situazione si verifica in un sistema esistente con una registrazione scadente o se il cliente è preoccupato per i dati sensibili e non desidera in primo luogo sistemi di registrazione estesi nel sistema?

Alcune questioni connesse:
Test accounts and products in a production system
Running test on Production Code/Server

Answer 1

Oltre al logging, che è di valore inestimabile, ecco alcune altre tecniche che io ei miei colleghi abbiamo utilizzato nel corso degli anni ... tornando alle finestre a 16 bit su macchine client a cui non avevamo accesso. (Sono uscito con me stesso?) Certo, non tutto può/funzionerà.

• Analizza tutti i comportamenti visualizzati.
• Riprodurre, se possibile, riprodurlo.
• Verifica scrivania, cammina attraverso il codice che sospetti.
• Rubber duck it with team members E persone che hanno poca o nessuna familiarità con il codice. Più devi spiegare qualcosa a qualcuno, più possibilità hai di scoprire qualcosa.
• Non essere frustrato. Fai una pausa di 5-10 minuti. Fai una rapida passeggiata attraverso l'edificio/strada/qualunque cosa. Non pensare al problema per quel tempo.
• Ascolta il tuo istinto.

Answer 2

Questo è uno degli scenari di debug più difficili. La risposta dipenderà dai dettagli del sistema di produzione. È un sistema che hai il pieno controllo su di esso? Oppure è installato nella macchina di un cliente e hai bisogno di passare attraverso numerose telefonate solo per ottenere l'accesso al file di log o modificare un parametro di configurazione?

Credo che la maggior parte delle persone concorderà che il modo più efficace di eseguire il debug di questo è utilizzare la registrazione. È necessario agire in modo proattivo e aggiungere quante più informazioni di registrazione possibili. Tuttavia, devi essere in grado di abilitare e disabilitare la registrazione su richiesta. Estesi registri di debug in un sistema di produzione potrebbero uccidere le prestazioni. Per lo stesso motivo è necessario essere in grado di abilitare solo parti specifiche del logging. Crea logici gruppi di stampe per la registrazione e abilita solo quella che ritieni possa darti le informazioni più pertinenti.

Answer 3

Ho usato un sistema di registrazione configurabile come Log4J per vedere cosa sta succedendo alle esecuzioni di produzione, questo presuppone che gli sviluppatori abbiano inserito utili informazioni di debug nei log.

Ma attenzione che la registrazione potrebbe esporre alcuni dati privati ​​sensibili, che dovrebbero essere codificati e/o saltati quando possibile.

Answer 4

In genere, il "debugging" [cioè il collegamento a un processo e l'ispezione dell'esecuzione] non è fattibile - per molte ragioni non meno importante è la sensibilità dei dati [ad esempio, gli sviluppatori vengono raramente qualificati \ eliminati per ispezionare i dati che manipolano]

Quindi questo di solito si riduce a dedurre l'esecuzione da fonti secondarie e artefatti. Questo poi si riduce a ...

• registrazione,
• registrazione,
• registrazione,

Una grande maggioranza di software scritto in questi giorni cade in uno dei campi di Java o .Net, in modo da sfruttare log4j e log4net, rispettivamente.

Anche avere una guida alla configurazione ops-centrica a prova di buller e processo di validazione aiuta. Ricordare che le persone responsabili dell'hardware e dell'ambiente raramente comprendono i requisiti di configurazione delle applicazioni che ospitano.

Answer 5

Insieme alla registrazione, altre tecniche includono il salvataggio dei dati di richiesta che è possibile immettere successivamente nel proprio sistema "identico". Questo potrebbe essere semplice come salvare ogni richiesta HTTP che si riceve in un file per un'analisi successiva. In questo momento probabilmente stai registrando molte di queste informazioni (in particolare URL per GETs), devi solo aggiungere intestazioni e richiedere corpi al mix.

L'aggiunta di ulteriori dettagli ai messaggi di errore è utile anche. Ad esempio, quando si ottiene un'eccezione da una routine, è possibile aggiungere i parametri utilizzati in tale chiamata all'errore Exception. O, almeno, informazioni sullo stato globale (chi ha effettuato il login, quale modulo di alto livello si trovavano, quale funzione di alto livello chiamavano, ecc.).

Answer 6

Vorrei iniziare con il piccolo, facile da controllare le differenze tra produzione e test. Elimina le cose ovvie come permessi, firewall, versioni diverse, ecc. Attraverso test effettivi. L'unica volta che ho tagliato gli angoli e dico oh, non può essere quello, lo è.

Quindi ho la priorità di test più costosi per verosimiglianza e costo. Essere creativo. Pensa a cose davvero strane che potrebbero causare il comportamento che vedi.

Answer 7

Alcuni consigli:

• essere preparato il bug potrebbe essere causato da molteplici cause, in modo che cerca di non restringere la mente alla ricerca di una sola causa.
• Utilizzare il gestore errori non gestito, che tiene traccia degli errori e aggregare i difetti simili (greylog, ELMAH).
• Considerare il debug post-mortem con i file mini-dump.
• Avere un intervallo di tempo fisso per un approccio rapido e sporco, quindi procedere con approccio sistematico.
• Prova modulo di revisione del codice difettoso con uno dei tuoi colleghi. La vista fresca potrebbe essere utile.
• Dividere e conquistare utilizzando il sistema di controllo della versione (GIT, SVN).
• Fai attenzione alle correzioni, perché circa il 4% di tutte le correzioni finisce con l'introduzione di nuovi bug.
• Non lasciare che la pressione per il bug di correzione rapida in produzione per farti omettere le procedure di controllo di qualità standard (ad esempio recensioni di codice).
• Dopo il fissaggio, assicurati di aver scritto test automatici nel caso in cui il bug tornasse qualche tempo dopo.