6.2Problemas recurrentes (playbook)
Lo esencial en 30 segundos
- Primero un síntoma: reproducir y describir el problema antes de tocar el código o los archivos.
- Una causa probable, no una apuesta: el playbook relaciona cada síntoma con causas conocidas y la acción concreta.
- La red antes de la acción: la copia de seguridad y el entorno de pruebas evitan convertir una avería en pérdida de datos.
Hilo Samir — el cuaderno de incidentes
Samir lleva un cuaderno de incidentes para los sitios que mantiene. Cada entrada anota el síntoma que ve el usuario, la causa probable y la acción que resolvió el problema. Con los meses, vuelven las mismas familias: página en blanco tras una actualización, error 500, contenido mixto, formulario mudo, enlaces 404 y pedido bloqueado.
Reflejo: nombrar el síntoma, verificar la causa, aplicar la acción concreta y corregir el fundamento detrás de un incidente que vuelve.
Un incidente, un síntoma
El primer error es corregir al azar. Se empieza por reproducir el incidente y describirlo con precisión: qué página, qué formulario, qué usuario, qué datos. Un síntoma claro ya reduce el tiempo de diagnóstico.
El buen reflejo: la red
Antes de cualquier manipulación arriesgada, se hace copia de seguridad y se trabaja sobre una copia cuando es posible. El objetivo no es evitar todo error, sino poder volver atrás sin perder los contenidos ni los pedidos.
Buscar la causa, no al culpable
Un incidente recurrente suele esconder un fundamento ausente: una extensión abandonada, actualizaciones aplazadas, copias de seguridad nunca probadas. Resolver el síntoma no basta si la causa vuelve al mes siguiente.
| Síntoma | Causas probables | Acciones |
|---|---|---|
| Página en blanco tras una actualización | conflicto de extensión, tema incompatible o memoria PHP insuficiente | restaurar la copia de seguridad, desactivar las extensiones una a una, leer los logs y ampliar la memoria si está justificado (N3.1, N5.1) |
| Error 500 en todo el sitio | error PHP fatal, archivo .htaccess corrupto o límite de memoria alcanzado | consultar los logs del servidor, restaurar el archivo o la copia de seguridad, corregir la extensión culpable (N3.4, N5.1) |
| Contenido mixto tras pasar a HTTPS | URL antiguas en http en la base de datos o en una plantilla | sustituir las URL, forzar HTTPS y verificar los recursos cargados (N3.4, N5.2) |
| Formulario de contacto mudo | envío de correo no configurado, SPF/DKIM ausente o extensión en conflicto | configurar un SMTP, enviar una prueba real y verificar el spam (N3.5) |
| Enlaces 404 tras cambiar los enlaces permanentes | reglas de reescritura no regeneradas o redirecciones ausentes | volver a guardar los enlaces permanentes, verificar .htaccess y añadir las redirecciones necesarias (N1.5, N5.2) |
| Pedido bloqueado o pago rechazado | pasarela en modo de prueba, moneda o país mal configurados, página de pedido rota | verificar los ajustes de WooCommerce, los logs de pago y repetir un pedido de prueba (N4.1) |
Guion listo para decir — calificar un incidente (30 s)
«¿Puede decirme en qué página, qué formulario y qué usuario aparece el problema, y desde cuándo? Lo reproduzco, verifico los logs y corrijo la causa antes de volver a probar.»
Para conservarlo y encuadrar un incidente con un cliente con prisa.
Guion listo para decir — anunciar una vuelta atrás (20 s)
«Restauro la copia de seguridad para poner el sitio en línea de nuevo, y luego busco la causa en una copia. El sitio público permanece estable durante el diagnóstico.»
Tranquilizar: la vuelta atrás no es un fracaso, es una protección.
Modelo para copiar y pegar — ficha de incidente
SÍNTOMA: [página / formulario / mensaje]
USUARIO: [perfil]
DESDE: [fecha / hora]
REPRODUCIDO: sí / no
CAUSA PROBABLE: [extensión / servidor / URL / ajuste]
ACCIÓN: [descripción]
PRUEBA TRAS LA CORRECCIÓN: sí / no
COPIA DE SEGURIDAD / VUELTA ATRÁS: sí / noModelo para copiar y pegar — orden de diagnóstico
1. Describir el síntoma y reproducirlo
2. Hacer copia de seguridad antes de cualquier acción
3. Leer los logs del servidor y de WordPress
4. Aislar: extensión, tema, ajuste, servidor
5. Corregir en una copia si es posible
6. Probar el recorrido completo
7. Documentar la causa y la soluciónWeb de presentación
Los incidentes más frecuentes: formulario, HTTPS, página en blanco tras una actualización.
Tienda
Añadir los pedidos, los pagos y los correos de confirmación al diagnóstico.
Sitio con mucho tráfico
Supervisar caché, servidor y base de datos antes de concluir que hay un problema de WordPress.
Sin entorno de pruebas
Hacer copia de seguridad sistemáticamente e intervenir en horas de baja actividad con un plan de vuelta atrás.
Reto 48 h — aplícalo mañana
Toma tres incidentes reales o simulados, rellena la ficha de incidente y aplica el orden de diagnóstico. Anota la causa y la prueba de no regresión. 30 minutos.
- Describo un síntoma antes de actuar.
- Relaciono el síntoma con una causa probable.
- Hago copia de seguridad y pruebo después de la corrección.
Tras una actualización, el sitio muestra una página en blanco. ¿Cuál es la primera acción útil?
Un incidente que vuelve no es un accidente: es la señal de un fundamento que corregir (extensión abandonada, actualizaciones aplazadas, copia de seguridad no probada).