Resolución de problemas de tecnología de la información: los 6 principios de la resolución de problemas científicos

Este artículo explicará un enfoque científico para la resolución de problemas. Aunque está escrito para abordar problemas relacionados con la tecnología de la información, los conceptos también pueden ser aplicables en otras disciplinas. Los métodos, conceptos y técnicas descritos aquí no son nada nuevo, pero es sorprendente ver cuántos “solucionadores de problemas” no los utilizan. Entre tanto, incluiré algunos ejemplos de la vida real.

¿Por qué los solucionadores de problemas adivinan en lugar de seguir un enfoque científico para la resolución de problemas? ¿Quizás porque se siente más rápido? ¿Quizás falta de experiencia en la resolución eficiente de problemas? ¿O tal vez porque se siente como un trabajo duro hacerlo científicamente? ¿Quizás mientras sigues adivinando y no resolviendo realmente, generas más ingresos y agregas algo de seguridad laboral? O tal vez porque viola el primer principio de resolución de problemas: comprender el problema.

Principio # 1. Comprende el problema * real *.

¿No es obvio que antes de poder resolver, es necesario comprender el problema? Quizás. Pero, la mayoría de las veces, el solucionador comenzará a resolver sin conocer el problema real. Lo que el cliente o usuario describe como “El problema” es normalmente sólo el síntoma. “Mi computadora no quiere encenderse” es el síntoma. El verdadero problema podría ser que todo el edificio no tenga electricidad. “Cada vez que intento agregar un nuevo producto, aparece un mensaje de error” es el síntoma. Aquí el problema real podría ser “Solo los últimos 2 productos que intenté agregar dieron un error de ‘El producto ya existe'”. Otro ejemplo clásico: “Nada funciona” …

Empiece su investigación definiendo el “problema real”. Esto implicará hacer preguntas (y en ocasiones verificarlas) y realizar algunas pruebas básicas. Pregúntele al usuario preguntas como “¿cuándo fue la última vez que funcionó correctamente?”, “¿Cuánto tiempo ha estado usando el sistema?”, “¿Funciona en otra PC u otro usuario?”, “¿Cuál es el mensaje de error exacto?”. ” etc. Solicite una serigrafía del error si es posible. Su prueba básica será asegurarse de que el equipo de un extremo a otro esté en funcionamiento. Compruebe la PC del usuario, la red, el servidor web, los cortafuegos, el servidor de archivos, el back-end de la base de datos, etc. En el mejor de los casos, ya podrá señalar el problema. En el peor de los casos, puede eliminar muchas áreas de la causa del problema.

Un ejemplo de la vida real. El síntoma según el usuario: “El sistema se cuelga en momentos aleatorios cuando hago pedidos”. El entorno: el usuario ingresa los detalles del pedido en un formulario en una aplicación de mainframe. Cuando se completen todos los detalles, el usuario saldrá del formulario. Luego, el mainframe envía este detalle a través del software de comunicación a un sistema Oracle Client / Server en la planta. El sistema Oracle realizará la planificación de la capacidad y devolverá un error o una fecha de pedido esperada al sistema mainframe. Este problema es bastante grave, porque puede perder clientes si intentan realizar pedidos y el sistema no los acepta. Para intentar resolver este problema, la gente comenzó investigando: 1) La carga y capacidad del hardware del mainframe 2) Monitoreando la carga de la red entre el mainframe y el sistema Oracle 3) Contratando consultores para depurar el software de comunicación 4) Depurar la capacidad de Oracle sistema de planificación Después de pasar un par de meses no pudieron resolver el problema.

Se llamó al “Solucionador de Problemas Científicos”. ¡Tomó menos de un día y el problema se resolvió! ¿Cómo? El solucionador pasa el día en el usuario para ver cuál era el “problema real”. Se encontró que el problema solo ocurre con los pedidos de exportación. Al investigar la pantalla de captura y las acciones del usuario, se encontró que con los pedidos de exportación, el último campo del formulario siempre se deja en blanco y el usuario no salta de este campo. El sistema no se colgaba, esperaba que el usuario presionara “tabulador” en otro momento. Problema resuelto. Cabe señalar que el “Scientific Problem Solver” tenía un conocimiento muy limitado del mainframe, del sistema de captura de pedidos, del software de comunicación y del sistema de planificación de capacidad de Oracle. Y esto nos lleva al Principio # 2.

Principio # 2. No tenga miedo de iniciar el proceso de resolución, incluso si no comprende el sistema.

¿Cuántas veces ha escuchado “No puedo tocar ese código, porque fue desarrollado por otra persona”, o “No puedo ayudar porque soy un consultor de recursos humanos y eso es un problema de finanzas”? Si su lavadora no quiere encenderse, no necesita ser un ingeniero eléctrico, un especialista en reparación de lavadoras, un técnico o cualquier otro especialista para realizar una búsqueda básica de fallas. Asegúrese de que el enchufe funcione. Compruebe el interruptor de disparo, etc. “Nunca he visto este error antes” no debería impedirle intentar solucionarlo. Con el mensaje de error y un motor de búsqueda de Internet, puede obtener muchos puntos de partida.

En cada sistema complejo hay un par de principios básicos de funcionamiento. El sistema A que lee datos del sistema B puede ser terriblemente complejo (tal vez un espectrómetro de laboratorio que lee datos de una computadora lógica programable a través de un puerto RS-232). Pero, algunos conceptos básicos para probar: ¿Ambos sistemas tienen energía? ¿Hay un mensaje de error en el registro de eventos de uno de estos sistemas? ¿Puede “hacer ping” o rastrear un paquete de red de un sistema al otro? Pruebe con un cable de comunicación diferente. Busque en Internet el mensaje de error.

Una vez que haya establecido cuál es el problema, debe comenzar a resolverlo. A veces, la investigación inicial le indicará directamente la solución (encienda la unidad, reemplace el cable defectuoso, etc.). Pero, a veces, el problema real es complejo en sí mismo, por lo que el siguiente principio es resolverlo de manera simple.

Principio # 3. Conquístelo de forma simple.

Comencemos esta sección con un ejemplo de la vida real. En determinadas condiciones, un procedimiento almacenado se bloqueará. Normalmente, el procedimiento almacenado tarda aproximadamente una hora en ejecutarse (cuando no se bloquea). Entonces, el desarrollador intentó depurar. Realice algunos cambios y luego espere una hora más o menos para ver si se resuelve el problema. Después de algunos días, el desarrollador se rindió y el “solucionador de problemas” se hizo cargo. El “solucionador de problemas” tenía a su disposición el conocimiento bajo las condiciones en que el procedimiento almacenado colgaría. Entonces, fue un ejercicio simple hacer una copia del procedimiento, y luego con esta copia eliminar todo el código innecesario. Todos los parámetros se cambiaron con valores codificados. Los bits de código se ejecutaron a la vez y los conjuntos de resultados se codificaron nuevamente en la copia del procedimiento. En 3 horas se resolvió el problema. Se descubrió un bucle infinito.

Lo que hizo el “solucionador de problemas” fue replicar el problema y, al mismo tiempo, intentó aislar el código que causaba el problema. Al hacerlo, el procedimiento almacenado complejo (y lento) se convirtió en algo rápido y simple.

Si el problema está dentro de una aplicación, cree una nueva aplicación e intente simular el problema dentro de la nueva aplicación lo más simple posible. Si el problema ocurre cuando se llama a un método determinado para un control determinado, intente incluir solo este control en la aplicación vacía y llame a ese método con valores codificados. Si el problema es con SQL incorporado dentro de una aplicación C #, intente simular el SQL dentro de una herramienta de consulta de base de datos (como SQL * Plus para Oracle, Query Analyzer para SQL Server, o use el código en MS Excel a través de ODBC en la base de datos ).

En el momento en que puedas replicar el problema de una manera simple, estás más del 80% en camino de resolverlo.

Si no sabe en qué parte del programa está el problema, utilice DEBUG.

Principio # 4. Depurar.

La mayoría de las herramientas de desarrollo de aplicaciones vienen de serie con un depurador. Si es Macromedia Flash, Microsoft Dot Net, Delphi o cualquier entorno de desarrollo, habrá algún tipo de depurador. Si la herramienta no viene de serie con un depurador, puede simular uno.

Lo primero que desea hacer con el depurador es determinar dónde está el problema. Para ello, agregue puntos de interrupción en áreas clave. Luego, ejecuta el programa en modo de depuración y sabrá entre qué puntos de interrupción ocurrió el problema. Profundiza y encontrarás el lugar. Ahora que sabe dónde está el problema, puede “conquistarlo de forma sencilla”

Otra característica interesante de la mayoría de los depuradores incluye la posibilidad de observar variables, valores, parámetros, etc. a medida que avanza por el programa. Con estos valores conocidos en ciertos pasos, puede codificarlos en su “versión simplificada” del programa.

Si una herramienta de desarrollo no admite la depuración, puede simularla. Ponga los pasos en el programa que genera valores de variables y mensajes de “Hola, estoy aquí” en la pantalla, en un archivo de registro o en una tabla de la base de datos. Recuerde eliminarlos cuando se resuelva el problema … ¡no quiere que su sistema de archivos esté desordenado o lleno de archivos de registro!

Principio # 5. Existe una gran cantidad de información en el back-end de la base de datos que ayudará a resolver un problema.

El “solucionador de problemas” fue llamado para ayudar a resolver un problema muy complicado. Un proyecto consistía en migrar un sistema de un mainframe a una tecnología cliente-servidor. Todo salió bien durante las pruebas, pero cuando los sistemas se activaron, de repente hubo bastantes y bastante aleatorias “Fallos de protección general”. (El error GPF era la trampa de error general en Windows 95 y 98). Se intentó simplificar el código, se intentó depurar, pero fue imposible replicar. ¡En el entorno de LAB, el problema no se produciría! La depuración de mensajes de seguimiento en archivos de registro indicó que el problema se produjo de forma muy aleatoria. Algunos usuarios lo experimentaron más que otros, ¡pero eventualmente todos los usuarios los obtendrán! Interesante problema.

El “solucionador de problemas” resolvió esto después de que comenzó a analizar el back-end de la base de datos. No estoy seguro de si fue por casualidad o porque se movió sistemáticamente en la dirección correcta debido a un enfoque científico. Al rastrear lo que está sucediendo en el nivel de back-end, se encontró que todas estas aplicaciones estaban creando cada vez más conexiones a la base de datos. Cada vez que un usuario inicia una nueva transacción, se establece otra conexión a la base de datos. La suma total de las conexiones solo se publicó cuando se cerró la aplicación. A medida que el usuario navega a nuevas ventanas dentro de la misma aplicación, se abren más y más conexiones, y después de un número específico de conexiones, la aplicación tendrá suficiente y luego se bloqueará. Esta fue una falla de programación en una plantilla que fue utilizada por todos los desarrolladores. La solución fue probar primero si un cursor a la base de datos ya estaba abierto, antes de volver a abrirlo.

¿Cómo rastrea en la base de datos back-end lo que está sucediendo? Los principales proveedores de bases de datos tienen herramientas GUI que le ayudan a rastrear o analizar qué consultas se disparan contra la base de datos. También le mostrará cuándo las personas se conectan, desconectan o no pueden conectarse debido a violaciones de seguridad. La mayoría de las bases de datos también incluyen algunas tablas de diccionario del sistema que se pueden consultar para obtener esta información. Estos rastros a veces pueden contar una historia completa de por qué algo está fallando. El código de consulta que recupera del seguimiento puede ayudar a “simplificar la búsqueda”. Puede ver en el seguimiento si el programa establece un contacto exitoso con la base de datos. Puede ver cuánto tarda en ejecutarse una consulta.

Para agregar al Principio # 2 (no tenga miedo de comenzar …); puede analizar esta información de seguimiento, aunque es posible que no sepa nada sobre los detalles de la aplicación.

Sin embargo, recuerde que estos rastreos de back-end pueden ejercer presión sobre los recursos de back-end. No los deje funcionando durante un tiempo innecesario.

Principio # 6. Usa ojos frescos.

Este es el último principio. No dedique demasiado tiempo al problema antes de pedir ayuda. La asistencia no tiene que ser de alguien de más edad que usted. El principio es que necesitas un par de ojos frescos para tener una nueva perspectiva y, a veces, un poco de aire fresco para tomar un descanso. La otra persona mirará y luego hará una pregunta o dos. A veces es algo muy obvio que se pasó por alto. A veces, el solo hecho de responder la pregunta te hace pensar en nuevas direcciones. Además, si pasa horas mirando el mismo código, es muy fácil empezar a revisar un error tonto. Muchos problemas de equilibrio financiero se resuelven con una cerveza. Podría ser un cambio de escenario y / o la atmósfera relajada que hará surgir la solución. Tal vez sea el oxígeno fresco que llegó al cerebro mientras caminaba hacia el pub. Tal vez sea porque el problema se discutió con otra persona.

Conclusión

Después de leer este artículo, el autor espera que los pruebe la próxima vez que encuentre un problema que resolver. Es de esperar que al aplicar estos seis principios se dé cuenta de las ventajas que aportan, en lugar de “adivinar” el camino hacia una solución.

#Resolución #problemas #tecnología #información #los #principios #resolución #problemas #científicos

Leave a Comment