Gestione errori J2EE - Applicazione e utente

Question

Ho una domanda relativa alla gestione degli errori in un'applicazione J2EE. La nostra attuale applicazione è utilizzata da molti utenti e di conseguenza riceviamo molti ticket di supporto. La maggior parte di questi ticket sono relativi all'utente, ma il 5-10% sono eccezioni relative al sistema, errori non gestiti, ecc.

Abbiamo i controlli di base sulla gestione delle eccezioni nel codice (necessita di lavori), ma dalla mia esperienza mostrando un messaggio generico all'utente non aiuta ad accelerare il processo di risoluzione dei problemi.

Quello che sto cercando è una raccomandazione su un buon errore nella gestione del modello di progettazione in modo da considerare uno scenario:

1. Il codice ha un errore
2. L'errore viene gestito
3. All'utente viene mostrato un messaggio di errore non tecnico con un codice di errore specifico.
4. Il team di supporto non tecnico può utilizzare questo codice di errore per visualizzare l'area (pagina, sezione, ..) nell'applicazione in cui è successo e cosa l'utente potrebbe aver fatto (informazioni prepopolate dal team di sviluppo in un riferimento dell'assistenza clienti guida).
5. Il team di supporto tecnico può utilizzare il codice per azzerare direttamente la classe / JSP ecc. e la riga di codice che ha attivato tale eccezione.
6. Utilizziamo un modulo di registrazione in cui maggior parte (non tutti) gli errori Tomcat stdout sono registrati dalla sessione dell'utente ... al codice di errore che l'utente riceverà, possiamo includere l'ID registro se esiste come bene in modo che anche il team tecnico possa guardarlo.

Fondamentalmente quello che mi interessa è ridurre il ciclo di analisi-spiegazione-ricerca di supporto e dare ad ogni dipartimento l'accesso alle informazioni a portata di mano che possono farli iniziare più velocemente per i loro rispettivi lavori:

1. L'assistenza clienti può fornire una spiegazione predefinita per questo codice di errore o disporre di passaggi alternativi che l'utente potrebbe seguire.
2. Il team tecnico potrebbe iniziare a risolvere i problemi relativi alla riga di codice o a ciò che l'utente stava facendo e che ha attivato tale riga.

Essenziale ogni codice di errore innesca i passaggi successivi richiesti per ciascun dipartimento e in effetti riduce la fase di ricerca del problema e passa alla fase di soluzione.

Non sono sicuro che quanto sopra sia anche una buona idea. Eventuali suggerimenti sarebbero apprezzati su un buon "modello di progettazione" per tale necessità. O se sarebbe anche una buona strada da guardare.

Grazie in anticipo.

SP

Answer 1

Sembra che tu debba passare un po 'di tempo seriamente a risolvere i tuoi problemi di supporto per alcuni triage di codice. La mia esperienza è stata che puoi quasi sempre creare una "top 10 list" di elementi che causano il 50% + dei problemi di supporto. Dopo aver eliminato i primi 10, riesaminare i registri delle chiamate. I dati sono indispensabili.

Un programma dedicato ad affrontare i problemi di supporto e buttarli fuori dal parco dovrebbe essere in grado di riconoscere abbastanza rapidamente i problemi di codice. Dopodiché, ti verranno lasciati problemi umani / di usabilità che devono essere gestiti con formazione, esperienza o in genere un refactoring del flusso di lavoro / usabilità a lungo termine.

Se vieni sommerso da errori per i quali ritieni di dover sviluppare un elenco di codici / condizioni di errore, sembra che il tuo prodotto abbia bisogno di altri 6 mesi di stabilizzazione. Probabilmente stai non sviluppando un sistema operativo, e per il 99% dei progetti che sviluppano un libro nero di codici di errore IBMesque non è il modello da emulare.

Answer 2

Usa log4j per registrare tutti gli errori e le eccezioni in un logger che ti manda le informazioni via e-mail. Non preoccuparti della messaggistica dell'utente; tutto ciò che devono sapere è che si è verificato un errore e che è stato registrato.