Aquí debe aislar un error mediante una prueba, comparar el resultado esperado con el real y elegir la siguiente acción. El método puede aplicarse a un programa, un contenedor o un servicio de red. Necesita una interacción conocida del usuario que debería haber funcionado y acceso para investigar la solución correspondiente.

Comience con los siete pasos y “Prueba lo esperado contra lo real”, y úselos en la Tarea 1. La secuencia de red es apoyo cuando el error involucra redes. La tabla de Linux/Proxmox es un ejemplo, no comandos que deba ejecutar para todos los errores. La autoprueba es un ejercicio opcional.

Si desea ver el método aplicado a un error específico, siga resolución de problemas modelada de una aplicación. Ahí justifica su próxima prueba antes de abrir la sugerencia de respuesta.

Los siete pasos

1. Mapea las circunstancias. ¿Qué sucedió y cuándo comenzó?
2. Replica el error cuando sea seguro hacerlo de nuevo.
3. Localiza y acota posibles fuentes de error; ¿qué capa o qué componente podría ser la causa?
4. Recopila información: registros, mensajes de error, resultados de comandos.
5. Determina soluciones posibles en función de lo que sabes ahora.
6. Prueba una solución o hipótesis a la vez. Si cambias varias cosas al mismo tiempo, no sabrás cuál fue la que realmente resolvió el problema.
7. Documenta el error y su solución para que tú (u otras personas) puedan reconocerlo la próxima vez.

Orden de depuración para redes y servicios

Cuando no se sabe dónde se encuentra un error de red, este orden proporciona un punto de partida. Si ya se cuenta con un resultado de prueba relevante, se utiliza para elegir dónde continuar la investigación. No es necesario ejecutar todas las pruebas de red para un error de código.

flowchart TD
    A[Conexión física] --> B[Interfaz de red]
    B --> C[Configuración IP]
    C --> D[Red local]
    D --> E[Puerta de enlace y enrutamiento]
    E --> F[DNS]
    F --> G[Servicio]

Vídeo: Cómo probar la conexión de red con ping

El vídeo muestra cómo se puede utilizar ping para comprobar si un dispositivo está disponible a través de la red.

Para cada punto debes poder:

• explicar qué comprueba realmente el punto de control
• encontrar los valores relevantes con el comando correcto (consulta [[Protocoles Nivel 1 - Protocolos de red|🌐 Protocolos de red]] para ping, nslookup, etc.)
• distinguir una observación de una suposición
• elegir el siguiente punto de control según el resultado del anterior, no por intuición

Comandos por capa en una VM de Linux en Proxmox

Esta es una aplicación del método cuando una VM de Linux no alcanza un servicio. Ejecuta los comandos relevantes en la Consola de la VM, no en el Shell del host de Proxmox. Consulta 🧭 Navegar en Proxmox VE si es necesario. Elige las pruebas para lo que estés investigando; la tabla no es un requisito previo para la Tarea 1.

Si falta la ruta predeterminada, investiga cómo debe alcanzar la VM los destinos fuera de su propia red; algunos destinos pueden tener rutas propias. Algunas redes bloquean ping, por lo que la ausencia de respuestas no demuestra por sí sola que la conexión esté interrumpida. Si el resolución de nombres y las fuentes de paquetes funcionan, tienes resultados concretos para continuar. 🌐 IP, subredes y gateway estándar explica la dirección, el prefijo y la ruta.

Prueba de lo esperado frente a lo real

Una prueba de dep solo es útil si sabes qué esperas antes de ejecutarla. Anota:

Requisito:        ¿Qué debe poder hacer el usuario?
Objetivo:          ¿Qué dirección/servicio estás probando?
Esperado:         ¿Qué debería pasar si todo funciona?
Real:              ¿Qué pasó?
Demuestra:         ¿Qué demuestra este resultado?
No demuestra solo: ¿Qué NO demuestra este resultado?

Tarea 1 - Aplicar el método a un problema real

Toma un problema con el que hayas encontrado en otra materia de Soporte Operativo o Desarrollo (un contenedor que no arranca, un servicio al que no puedes conectarte, un script que falla):

1. Recorre los siete pasos anteriores, uno por uno.
2. Escribe «esperado frente a lo observado» para cada prueba que ejecutes.
3. Anota qué componente o capa limita la prueba. Utiliza el orden de red solo cuando se ajuste al problema.
4. Prueba una corrección justificada en un entorno de pruebas donde tengas permiso para hacer cambios. Repite la acción original del usuario y verifica que la corrección funcione realmente. Mantén una vía de retorno a la configuración anterior.

Si no tienes errores disponibles, puedes analizar este ejemplo: Una aplicación devuelve la página esperada en /, pero HTTP 404 en /status. ¿Qué muestran las dos respuestas y qué investigarías primero? Ambas solicitudes recibieron respuesta HTTP; la primera verificación es si /status existe efectivamente en la aplicación y si el cliente utiliza la ruta correcta. El ejercicio es de análisis, no evidencia de que hayas corregido una solución propia.

Punto de control: El error está acotado y bajo control

Muestra el registro de pruebas y explica qué observación respaldó la siguiente prueba o corrección. Tras la corrección, la acción original debe producir el resultado esperado. Puedes explicarlo oralmente o por escrito con los comandos y resultados frente a ti. Si el error sigue abierto, indica lo que se ha probado, lo que aún es incierto y una próxima prueba precisa. No escribas una causa supuesta como confirmada.

Pruébate a ti mismo

Autoevaluación opcional con retroalimentación. Las respuestas no se envían al profesor. Utilice su propio registro de pruebas para demostrar la depuración real; el autoexamen no sustituye la verificación práctica.

Resumen

• La depuración de errores es un método, no una suposición: siete pasos fijos desde el mapeo hasta la documentación
• El método de bisección puede delimitar una cadena cuando conoces los elementos que utiliza la prueba
• Para redes: usa las capas para elegir la siguiente prueba relevante según lo observado
• Anota siempre lo esperado frente a lo real antes de probar y recuerda que una sola prueba rara vez demuestra todo