Técnicas de resolución de problemas

El primer paso de un buen análisis de problemas es describir el problema por completo. Sin una descripción del problema, no sabrá por dónde empezar a investigar la causa de éste.

Este paso incluye preguntas básicas como:

  • ¿Cuáles son los síntomas?
  • ¿Dónde ocurre el problema?
  • ¿Cuándo ocurre el problema?
  • ¿Bajo qué circunstancias ocurre el problema?
  • ¿Se puede reproducir el problema?

Responder estas y otras preguntas le llevará a realizar una descripción correcta para la mayoría de los problemas y, es la mejor forma de comenzar a resolver el problema.

¿Cuáles son los síntomas?

Cuando empieza a describir el problema, la pregunta más obvia es "¿Cuál es el problema?" Esto puede parecer una pregunta sencilla, sin embargo, se puede desglosar en varias preguntas para tener una idea más descriptiva del problema. Dichas preguntas pueden ser:
  • ¿Quién o qué está informando del problema?
  • ¿Cuáles son los códigos y mensajes de error?
  • ¿Cómo falla? Por ejemplo: bucle, bloqueo, detención, degradación del rendimiento, resultado incorrecto.
  • ¿Cuál es el efecto en los negocios?

¿Dónde ocurre el problema?

No siempre es fácil determinar dónde se origina el problema, pero es uno de los pasos más importantes a la hora de solucionar un problema. Puede que existan muchas capas de tecnología entre los componentes que informan y los que sufren las anomalías. Las redes, los discos y los controladores son solamente algunos de los componentes que se deben tener en cuenta al examinar los problemas.
  • ¿Es el problema específico para una plataforma o se puede reproducir en varias plataformas?
  • ¿Se soporta el entorno y la configuración actuales?
  • ¿Se está ejecutando la aplicación de forma local en el servidor de base de datos o en un servidor remoto?
  • ¿Hay alguna pasarela de por medio?
  • ¿Está la base de datos almacenada en discos individuales, o en una matriz de discos RAID?

Este tipo de preguntas le ayudarán a aislar la capa del problema y son necesarias para determinar el origen de éste. Tenga en cuenta que si una capa informa de un problema, no quiere decir que la raíz del problema esté en esa capa.

Una parte de la identificación de dónde ocurre un problema, es entender el entorno en el que existe. Debe siempre tomarse algún tiempo para describir completamente el entorno del problema, incluyendo el sistema operativo, la versión, todo lo correspondiente a software y versiones, e información de hardware. Confirme que el entorno en el que está trabajando tiene una configuración con soporte; muchos problemas se pueden explicar descubriendo niveles de software que no pueden funcionar juntos o que no se han probado totalmente funcionando juntos.

¿Cuándo ocurre el problema?

El desarrollo de una línea de tiempo detallada de los sucesos que conducen a una anomalía es otro paso necesario en el análisis de problemas, especialmente para los casos que son ocurrencias únicas. Puede hacerlo con más facilidad trabajando hacia atrás; es decir, empezar en el momento en que se ha informado de un error (lo más exacto posible, incluso en milisegundos), y trabajar hacia atrás a través de los registros y la información disponibles. Por lo general, solo tiene que llegar hasta el primer evento sospechoso que encuentre en cualquier registro de diagnóstico, sin embargo, esto no es siempre fácil de hacer y solo se conseguirá con la práctica. Saber cuándo parar es especialmente difícil cuando existen varias capas de tecnología, cada una con su propia información de diagnóstico.
  • ¿Ocurre el problema siempre a una misma hora del día o de la noche?
  • ¿Con qué frecuencia ocurre?
  • ¿Cuál es la secuencia de sucesos que conducen a la hora en que se informa del problema?
  • ¿Ocurre el problema en un cambio de entorno, como una actualización o una instalación de software o hardware nuevo?

Responder a preguntas como estas, le ayudará a crear una línea temporal de sucesos detallada y, le proporcionará un marco de referencia en el que investigar.

¿Bajo qué circunstancias ocurre el problema?

Saber qué más se estaba ejecutando en el momento del problema es importante para una descripción completa del problema. Que un problema ocurra en un entorno determinado o bajo ciertas condiciones, puede ser un indicador clave de la causa del problema.
  • ¿Siempre ocurre el mismo problema realizando la misma tarea?
  • ¿Tiene que producirse una secuencia de sucesos determinada para que aparezca el problema?
  • ¿Fallan otras aplicaciones al mismo tiempo?

Responder a este tipo de preguntas le ayudará a explicar el entorno en el que el problema se produce y a correlacionar cualquier dependencia. Tenga en cuenta, que el hecho de que varios problemas hayan ocurrido al mismo tiempo, no quiere decir necesariamente que estén siempre relacionados entre ellos.

¿Se puede reproducir el problema?

Desde el punto de vista de la descripción del problema y de la investigación, el problema "ideal" es uno que se puede reproducir. Con problemas que se pueden reproducir, casi siempre tendrá un gran número de herramientas o procedimientos disponibles para usarlos como ayuda en su investigación. Por consiguiente, los problemas que se pueden reproducir son normalmente más fáciles de depurar y resolver.

Sin embargo, los problemas reproducibles pueden tener una desventaja: si el problema tiene un impacto empresarial significativo, no desea que sea recurrente. En este caso y si fuera posible, es preferible reproducir el problema en un entorno de prueba o desarrollo.

  • ¿Se puede reproducir el problema en un sistema de prueba?
  • ¿Se encuentran con el mismo tipo de problema varios usuarios o aplicaciones?
  • ¿Se puede volver a crear el problema ejecutando un único mandato, un conjunto de mandatos, una aplicación existente concreta o una aplicación de prueba creada deliberadamente?
  • ¿Puede recrearse el problema ejecutando el comando/consulta equivalente con el Db2® procesador de línea de comandos?

Es preferible reproducir un único problema en un entorno de prueba o desarrollo, ya que existe normalmente, mucha más flexibilidad y control para investigar.