Diferentes metodologías para resolver errores que solo ocurren en producción

Question

Como alguien relativamente nuevo en todo el entorno de soporte y corrección de errores y un programador joven, nunca me encontré con un error que solo ocurre en el entorno Websphere pero no en el localhost entorno de prueba, hasta el día de hoy. Cuando recibí este informe de error por primera vez, estaba confundido sobre por qué no podía reproducirlo en el entorno de prueba localhost. Decidí probar en el entorno de prueba de Websphere para ver qué sucedería y reproduje correctamente el error. El problema es que no puedo hacer cambios y construir en el entorno de prueba de Websphere. Solo puedo hacer cambios en mi entorno local. Dada esta desventaja, ¿qué metodologías existen para resolver este tipo de errores? ¿O hay incluso alguna metodología en absoluto? ¿Algún consejo o ayuda sobre cómo abordar problemas como este?

Answer 1

• Campaña para obtener acceso completo a un entorno de prueba. Ser capaz de ajustar cosas, volver a desplegar y volver a intentar hace una gran diferencia . Es completamente razonable explicar cómo no tener acceso restringe severamente tu capacidad de hacer tu trabajo.
• Asegúrese de tener suficiente registro y hacerlo configurable. Asegúrese de mantener los registros el tiempo suficiente para rastrear un problema informado por un cliente, incluso si sucedió hace unos días.
• Cuando finalmente diagnostica un problema y por qué solo ocurre en un entorno particular, documentéelo e intente convencer a su sistema local de que se comporte de la misma manera, lo que facilitará el diagnóstico de otro síntoma del mismo problema la próxima vez.

Answer 2

En resumen, la metodología consiste en aislar y comprender las diferencias entre los entornos y cuál de ellos puede estar causando el problema.

1. Revise su compilación local. Asegúrese de que sea la misma versión (código y base de datos) que Test y Prod. Si es así, ¿cuáles son las diferencias ambientales que podrían afectar el problema que está viendo? (Multinúcleo, equilibrio de carga, versión del sistema operativo, versión de la 3ª biblioteca). No ejecute localmente en el depurador, asegúrese de ejecutar una compilación de lanzamiento (si eso es lo que está en Test y Prod) y tal vez incluso realice una implementación local en lugar de compilar desde el origen.

2. Compruebe si se trata de datos particulares que pueden estar causando el problema. Si puede, retire una copia de la base de datos de Test to Local y vea si eso le permite reproducir el problema.

3. Consulte con otros desarrolladores. Ver si pueden repro. el problema en su entorno. Consulte con sus compañeros de control de calidad, piense qué podría estar causando tal problema (muchas veces habrán visto problemas "similares" y podrían darle una pista).

En ese momento, si nada ayuda, generalmente entro en un estado profundo de zen para tratar de entender lo que me estoy perdiendo. Pero, debe haber una diferencia, solo debes encontrarla.

Answer 3

El método científico siempre se aplica-- verifique sus suposiciones primero. Si los sistemas son diferentes, el problema podría residir en que algún tipo de incumplimiento implícito sea diferente o una implementación diferente de alguna función.

En todos los procesos de depuración, la localización es la clave. Primero tienes que aislar el área del problema. Si su sistema operativo, parches, bibliotecas y el software principal en sí son todos idénticos, entonces es probable que sea la configuración del sistema (límites para conectores, descriptores de archivos, etc.). Si sabe que tiene suficientes inodos, espacio y memoria, entonces no es un problema de recursos.Si la computadora apenas responde a su estímulo interactivo, su carga es demasiado alta o tiene algunos procesos desbocados. Recuerde lo que necesita ejecutar cada proceso y asegúrese de que obtuvieron lo que necesitan.

También puede ser código simplemente no puede hacer frente a la carga del sistema de producción. Los mecanismos de bloqueo son una causa muy común de problemas en la producción frente a los sistemas de desarrollo/prueba, simplemente porque no se pueden generar suficientes casos de prueba que se obtienen de forma gratuita durante la producción.

El registro se puede pasar por alto fácilmente, pero también me gusta agregar una gran cantidad de valores de depuración en el código, para facilitar la depuración. Ni siquiera puedo contar cuántas veces alguna variable de entorno, ruta o enlace simbólico roto arruinó mi día, solo para darme cuenta de que sería una solución trivial si miraba los valores de las variables mientras se ejecutaban, no solo mirando el código estático.

Si todo lo demás falla, ltrace y strace son la mejor manera de ver realmente lo que sucede bajo el capó. No son fáciles de leer, pero una vez que te acostumbras a detectar e interpretar los valores de retorno de algunas llamadas de sistema, obtienes una herramienta de depuración muy poderosa.