Tu tienda online se ha caído: plan de continuidad para saber qué hacer

Todas las tiendas se caen alguna vez. El servidor se queda sin disco, una actualización automática del hosting cambia la versión de PHP, un módulo falla después de un cambio, el dominio caduca o un ataque deja la web inservible. Lo que distingue una caída de una hora de una de un día no suele ser la gravedad del fallo, sino lo preparado que estaba el equipo: si sabía cómo enterarse, a quién llamar y qué hacer.

Un plan de continuidad no tiene por qué ser un documento de cien páginas. Para una tienda online basta con una o dos hojas que respondan a unas cuantas preguntas antes de que haga falta.

1. Cómo te enteras

La peor forma de enterarte es por un cliente, y la segunda peor, al día siguiente. Necesitas al menos:

• Una vigilancia externa que pida la portada y alguna página clave cada pocos minutos desde fuera de tu servidor, y avise si no responde o responde con error. Tiene que estar fuera: si el servidor cae, un vigilante dentro de él cae con él.
• Avisos de errores desde dentro de la tienda, para los fallos que no tiran la portada pero rompen algo: el checkout, el retorno de una pasarela, una página concreta.
• Avisos de caducidad del dominio y del certificado SSL. Son caídas totalmente evitables.

Y decide quién recibe los avisos. Un aviso que llega a un buzón que nadie lee por la noche no sirve de nada.

2. Qué tipo de caída es

Los primeros minutos sirven para clasificar, porque cada tipo tiene su responsable:

• No responde nada (ni la tienda ni otras webs del mismo servidor): servidor, red o DNS. Es cosa del hosting o del proveedor del dominio.
• Responde con error 500 o pantalla en blanco: casi siempre un fallo de PHP en la tienda. Un cambio reciente, un módulo, la versión de PHP, el disco lleno o la base de datos.
• Error de base de datos: el servidor de base de datos está caído, saturado o las credenciales han cambiado.
• Funciona pero algo está mal: no se puede pagar, no se añaden productos al carrito, la tienda muestra contenido extraño. Puede ser un fallo de un módulo o, en el peor caso, una intrusión.
• Funciona pero muy lenta: picos de tráfico, bots, una tarea pesada o falta de recursos.

3. A quién llamas

Escribe una lista con nombre, forma de contacto y horario para:

• El hosting: número de cliente, cómo abrir una incidencia urgente y qué cubre su soporte.
• El proveedor del dominio y del DNS, si no es el mismo que el hosting.
• Quien mantiene la tienda: tu desarrollador o la empresa que te da soporte.
• Las pasarelas de pago, por si el problema está en ellas o necesitas revisar cobros.
• Quien dentro de tu equipo decide: si se restaura una copia, si se pone la tienda en mantenimiento, qué se comunica.

Guarda esta lista fuera de la tienda y del correo del dominio. Si el servidor cae y tu correo está en él, no podrás consultarla.

4. Accesos y copias, comprobados antes

En plena caída no es momento de descubrir que nadie tiene la contraseña del panel del hosting o que la última copia es de hace un mes. Comprueba de antemano:

• Que las personas que deben actuar tienen acceso al panel del hosting, al FTP o SSH, a la base de datos y al back-office.
• Que existen copias de ficheros y de base de datos recientes, guardadas fuera del servidor de la tienda.
• Que alguien ha restaurado una copia alguna vez y sabe cuánto tarda. Una copia que nunca se ha probado es una esperanza, no un plan.
• Qué pasa con los pedidos entrados entre la última copia y la caída si hay que restaurar: dónde consultarlos (pasarela, correos de confirmación, ERP) y cómo recuperarlos.

5. Qué haces mientras se arregla

Mantenimiento con aviso

Si la tienda responde pero falla, a menudo es mejor ponerla en mantenimiento con un mensaje claro que dejar que los clientes se encuentren errores o, peor, que paguen y no se cree el pedido.

Pagos

Revisa en la pasarela los cobros del periodo afectado y compáralos con los pedidos. Los cobros sin pedido hay que atenderlos uno a uno: crear el pedido o devolver el dinero.

Comunicación

• A los clientes: un mensaje breve en redes o en el propio aviso de mantenimiento, sin prometer horas que no puedes cumplir.
• A los clientes con pedido en curso, si la caída afecta a envíos o plazos.
• Al equipo de atención, con qué responder si llaman.

Si hay indicios de que han entrado en la tienda y pueden haberse visto afectados datos personales, la situación cambia: hay que valorar las obligaciones de notificación del RGPD con quien te asesore en protección de datos, y no restaurar una copia sin antes cerrar la vía de entrada.

6. Después: qué apuntar

Cuando la tienda vuelve, el trabajo no ha terminado. Apunta:

• Cuándo empezó, cuándo te enteraste y cuándo se resolvió. La diferencia entre las dos primeras horas mide tu vigilancia.
• Qué lo causó y qué se hizo.
• Qué faltó: un acceso, una copia, un teléfono.
• Qué cambias para que no se repita: una actualización pendiente, más disco, un módulo que retirar, una vigilancia que añadir.

Muchas caídas se repiten porque nadie apunta la causa. Y muchas se evitan con lo de siempre: tienda, PHP y módulos al día, probados en una copia antes de cambiarlos en producción.

Cómo resolverlo en PrestaShop

RKR Sentinel vigila la tienda desde dentro y te avisa por Telegram de errores de PHP, excepciones, fatales, memoria agotada, tiempos agotados y respuestas 500, con el mensaje, el fichero y la línea, la URL y las versiones; también captura los errores de JavaScript del checkout y vigila los pagos que no acaban en pedido o cuyo importe no cuadra. Agrupa las repeticiones para no llenarte el móvil y enmascara tarjetas, IBAN, tokens y contraseñas antes de enviar nada. Recuerda que necesita que la tienda responda: para las caídas completas del servidor, combínalo con una vigilancia externa. Y si buscas un alojamiento pensado para PrestaShop, el Hosting plan profesional de Rekire es nuestra propuesta para tiendas que quieren despreocuparse del servidor.