Identificación y definición del problema

Identificar el problema es el primer paso y posiblemente el más importante. Identificarlo de forma incorrecta desvía todos los pasos posteriores. El objetivo aquí es obtener una descripción del problema clara, específica y verificada. El tiempo dedicado a comprender el problema con precisión rara vez se desperdicia, porque concentra todo el esfuerzo posterior en el síntoma real y no en una suposición.

Comience recopilando datos. Hable con los usuarios afectados, consulte los paneles de supervisión y los registros, y realice usted mismo pruebas rápidas. Intente conocer el alcance (un usuario, una planta o todo el sitio), el momento (cuándo comenzó) y los síntomas (lentitud, intermitencia o caída total). Cuanto más concreta sea la información, más precisa será su teoría.

Una pregunta muy útil es "¿qué cambió?" La mayoría de los problemas comienza justo después de un cambio: hardware nuevo, una modificación de configuración, una actualización de software o un incidente eléctrico. Pregunte a los usuarios y consulte los registros de cambios. Si un servicio funcionaba ayer y hoy falla, algo es diferente, y encontrar esa diferencia suele conducir directamente a la causa. Los cambios recientes son los principales sospechosos.

Los usuarios describen los síntomas con sus propias palabras, así que entrevístelos con atención y amabilidad. Haga preguntas abiertas: "¿Qué estaba haciendo cuando falló?" y "¿Ha cambiado algo más?" Evite las preguntas tendenciosas que sugieren una respuesta falsa. Tenga en cuenta que los usuarios pueden omitir detalles o describir efectos en lugar de causas. La paciencia y las buenas preguntas convierten una queja vaga en datos útiles.

Determinar el alcance reduce considerablemente la búsqueda. Si solo hay un PC afectado, examine ese dispositivo o su cable. Si toda una VLAN está caída, sospeche del switch o de la puerta de enlace. Si todo el sitio no tiene Internet, céntrese en el enlace WAN o en el ISP. Adaptar el tamaño del problema al tamaño de la causa probable ahorra muchísimo tiempo.

Cuando pueda, reproduzca el problema usted mismo. Reproducir el fallo confirma que es real, revela las condiciones exactas y le proporciona una prueba que puede repetir después de aplicar una solución. Si un sitio web falla para el usuario, intente acceder a él desde su propio equipo en la misma red. Los problemas intermitentes son más difíciles de reproducir, pero hacerlo resulta muy valioso para confirmar que se han solucionado.

CompTIA indica explícitamente que se debe cuestionar lo obvio. Muchas interrupciones tienen causas comunes: un cable desconectado, un dispositivo apagado, una contraseña caducada o el bloqueo de mayúsculas activado durante el inicio de sesión. Comprobar primero estos aspectos lleva unos segundos y a menudo resuelve el problema. Omitir las comprobaciones sencillas porque "no puede ser eso" es una forma clásica de perder horas con un fallo trivial.

Los dispositivos suelen anunciar sus propios problemas. Lea los registros para buscar mensajes de error, observe las luces de enlace de las interfaces y revise las alertas de supervisión. Una luz roja en un puerto del switch, un evento registrado de "interfaz inactiva" o un mensaje de error de DHCP pueden señalar directamente el fallo. Dejar que el equipo indique lo que detecta complementa la información proporcionada por el usuario.

Considere si se enfrenta a un problema o a varios. A veces aparecen simultáneamente dos fallos no relacionados y parecen un único síntoma extraño. Si las pistas no encajan con una sola causa, pregúntese si se superponen dos problemas. Separar los problemas entrelazados evita la confusión de intentar explicarlo todo con una única teoría forzada.

Combine sus hallazgos en una descripción del problema precisa: quién está afectado, qué falla, cuándo comenzó y qué patrón presenta. "Desde el reinicio del switch a las 9:00, ningún teléfono de la VLAN 20 puede registrarse" es mucho más útil que "los teléfonos están averiados". Una buena descripción es la base sobre la que se construye el resto de la metodología.

Una definición sólida del problema orienta naturalmente hacia las teorías sobre la causa. Si el problema comenzó después de un cambio de configuración en un switch y solo afecta a los usuarios de ese switch, la primera teoría surge por sí sola. Dedicar un esfuerzo real a la identificación hace que elaborar teorías, probarlas y corregir el problema sea mucho más rápido y preciso. Defina bien el problema y el resto de la resolución fluirá.

Compruebe su comprensión de la identificación de problemas.

Ha aprendido a identificar y definir problemas. Puntos clave:

• Recopile el alcance, el momento y los síntomas a partir de los usuarios, los registros y las pruebas.
• Pregunte siempre "¿qué cambió?"
• Determine el alcance para estimar el tamaño de la causa probable; reproduzca el problema cuando sea posible.
• Cuestione lo obvio primero.
• Redacte una descripción precisa del problema que oriente cada paso posterior.