6.2 · Problemas recurrentes (playbook)

Nivel 6 · En la práctica

6.2Problemas recurrentes (playbook)

Objetivo: disponer de un playbook «síntoma → causas → acciones» para los incidentes habituales.
Tiempo estimado: 12 min · Si solo tienes 5 min: lee «Lo esencial en 30s» + el esquema.

Lo esencial en 30 segundos

  • Diagnosticar: un síntoma = unas causas probables = una secuencia de acciones — no se corrige al azar.
  • Orden: de lo simple a lo complejo (físico, IP, DNS), un solo cambio a la vez, o ya no se sabe qué corrigió qué.
  • Raíz: un ticket que vuelve sin cesar no son ocho incidentes, es UN problema de fondo que tratar de raíz.

Hilo Sofiane — la tabla pegada junto a la pantalla

Sofiane guarda este playbook junto a su pantalla en el soporte, en Argel. Balance tras un trimestre: tres líneas fueron las que más le sirvieron — «ya no tengo Internet», la impresora no encontrada y la cuenta bloqueada. Para cada una, acabó aplicando la secuencia (síntoma, causas, acciones) en lugar de probar correcciones al azar.

Síntoma observado, causas verificadas, acciones en orden: el reflejo cabe en tres tiempos.

Un reflejo por síntoma

La mayoría de los tickets son grandes clásicos. Relacionar cada síntoma con sus causas probables y con una secuencia de acciones ahorra un tiempo precioso, sobre todo en soporte N1.

De lo simple a lo complejo

Se prueba primero la capa más simple (cable, alimentación, IP) y luego se sube (puerta de enlace, DNS, servicio). Un solo cambio a la vez, o ya no se sabe qué corrigió qué.

Tratar la raíz

Un mismo ticket que vuelve no es una fatalidad: es un problema de fondo (un router saturado, un rango DHCP mal encuadrado, una sala mal cubierta) que tratar de raíz.

SíntomaCausas probablesAcciones
«Ya no tengo Internet»169.254 (sin DHCP), puerta de enlace caída, cable/puerto, o DNSipconfig → ping puerta de enlace → ping 8.8.8.8 → ping un nombre → tracert
«El sitio no abre» (otros sí)DNS, caché caducada, o el sitio realmente caídoprobar por IP; cambiar/vaciar el DNS; probar desde otra red
«Impresora no encontrada»apagada/fuera de red, IP cambiada, recurso/controladorrevisar alim/red; reserva DHCP; reinstalar el controlador
«Unidad de red desconectada»servidor/recurso no disponible, permisos, sesiónping al servidor; revisar recurso + permisos (grupo); reconectar
«Va lento»RAM insuficiente, disco HDD, red saturada, softwareadministrador de tareas; RAM/SSD; probar la velocidad; aislar la app
«Cuenta bloqueada / contraseña olvidada»olvido, bloqueo, MFA perdidarestablecer; desbloquear; volver a inscribir el MFA
Error frecuente de interpretación: «la tabla sustituye al diagnóstico». No. El playbook da causas probables, no un veredicto: observa el síntoma, verifica la causa (DHCP, puerta de enlace, DNS, recurso, recursos) y luego aplica la acción concreta.
Versión en texto del esquema (SEO / lectores de pantalla / traducción): 1) Nombrar el síntoma observado («sin Internet», sitio inaccesible, impresora no encontrada, unidad desconectada, lentitud, cuenta bloqueada). 2) Retener las causas probables de la tabla sin concluir solo (DHCP, puerta de enlace, DNS, IP, recurso, permisos, recursos). 3) Aplicar las acciones en orden, de lo simple a lo complejo (ping puerta de enlace → ping 8.8.8.8 → ping un nombre → tracert). 4) Corregir de raíz (un ticket que vuelve = un problema de fondo: reservar las IP, encuadrar el rango DHCP, cubrir la sala). Lección: un error que vuelve pide un ajuste, no correcciones al azar.

Guion listo para decir — diagnosticar sin improvisar (30 s)

«Mi síntoma: [sin Internet / impresora no encontrada / lento]. Verifico la causa probable del playbook (DHCP, puerta de enlace, DNS, recursos), aplico la acción concreta y lo confirmo con una prueba.»

El reflejo cabe en tres tiempos: síntoma, causa, acción.

Guion listo para decir — separar red y DNS (30 s)

«Hago ping a la puerta de enlace, luego a 8.8.8.8 y luego a un nombre. Si la IP pasa y el nombre no, es un problema de DNS; si no pasa nada, subo hacia el enlace o el DHCP.»

Probar siempre la IP antes que el nombre.

Modelo copiar-pegar — secuencia de red

ipconfig /all            -- ¿IP? 169.254 = sin DHCP
ping   -- ¿enlace local OK?
ping 8.8.8.8             -- ¿Internet OK?
ping www.example.com     -- ¿DNS OK?
tracert www.example.com  -- ¿dónde se bloquea?

Modelo copiar-pegar — ficha de ticket exprés

Síntoma  : [lo que ve el usuario]
Causa    : [verificada, no supuesta]
Acción   : [un cambio a la vez]
Prueba   : [lo que he vuelto a probar]
¿Raíz?   : [ticket aislado o problema de fondo]

Pyme muy pequeña / bajo presupuesto

Sin tabla formal: un síntoma, la causa probable, la acción y la prueba, anotados en una ficha.

Pyme Argelia

Integrar las realidades locales en el diagnóstico: un solo enlace a Internet, cortes, hardware heterogéneo, contenidos en francés.

Remoto / híbrido

Añadir una captura al diagnóstico: a distancia, un síntoma y una prueba escritos evitan idas y venidas.

Intercultural

Explicitar las comprobaciones por escrito: lo que parece obvio (qué servicio, qué formato) no lo es para todos.

Prudencia: Recordatorio genérico: un mismo error que vuelve no son diez incidentes — corrige el diseño de raíz (DHCP, reservas, cobertura) y guarda una instantánea del puesto antes de cualquier reparación en masa.

Reto 48 h — aplícalo mañana

Detecta 1 síntoma actual (sin Internet, impresora no encontrada, lentitud, cuenta bloqueada), aplica la línea del playbook (síntoma nombrado + causa verificada + acción concreta) y pruébalo.

Lista de salida de la sección
  • Sé relacionar un síntoma con sus causas probables.
  • Verifico de lo simple a lo complejo, un cambio a la vez.
  • Distingo un ticket aislado de un problema de fondo.
Autoevaluación 1-5: ¿diagnóstico antes de corregir?¿prueba sistemática después de corregir?
Comprueba tu comprensión

Sofiane ve un puesto en 169.254 y «ya no tengo Internet». ¿Qué reflejo aplica el playbook?

💡

Reflejo: nombrar el síntoma, verificar la causa, aplicar la acción concreta — y detectar el problema de fondo detrás de un ticket que vuelve.