English

Guía · 30 de octubre de 2026

Checklist de incidencias para Black Friday

El Black Friday es el 27 de noviembre y el Cyber Monday, el 30. Las caídas que más duelen esos días rara vez son nuevas: son los puntos débiles que ya conoces, pero con el triple de carga. Aquí tienes 30 comprobaciones para equipos de e-commerce y de plataforma, en el orden en que conviene hacerlas.

A cuatro semanas: conoce tus límites

• Previsión de tráfico pico acordada con marketing, por horas, incluidas las horas de inicio de cada promoción.
• Prueba de carga al 1,5× del pico previsto, contra un entorno equivalente a producción.
• Se sabe cuál es el primer componente que falla bajo carga y su límite está documentado.
• Pools de conexiones a base de datos, tamaños de colas y límites de peticiones revisados frente al pico, no frente a la media.
• Autoescalado probado hasta la capacidad pico, con las cuotas y límites del proveedor cloud ampliados con antelación.
• Inventario de todos los terceros en el flujo de compra: pasarela de pago, antifraude, impuestos, buscador, CDN, email.
• Pasarelas de pago y otros socios críticos informados de los volúmenes esperados.

A tres semanas: detecta los problemas a tiempo

• Un único panel muestra pedidos por minuto, errores en el checkout, tasa de pagos correctos y latencia de página.
• Las alertas saltan con señales de negocio (caída de pedidos, aumento de pagos fallidos), no solo con CPU y memoria.
• Umbrales de alerta ajustados al tráfico pico, para que la carga normal de Black Friday no despierte a nadie.
• Pruebas sintéticas que hacen una compra completa de prueba cada pocos minutos.
• Las páginas de estado y los webhooks de terceros llegan al mismo canal de alertas.
• Alertas ruidosas revisadas y corregidas o silenciadas antes de esa semana.

A dos semanas: planifica la respuesta

• Calendario de guardias del 26 de noviembre al 1 de diciembre publicado, con un responsable de incidencias asignado a cada turno.
• Contactos de escalado de cada proveedor crítico probados, incluidos los teléfonos fuera de horario.
• Runbooks escritos para los cinco fallos más probables: caída de la pasarela de pago, base de datos del checkout saturada, fallo de CDN o caché, un script de terceros que ralentiza las páginas y fallo en la sincronización de stock.
• Cada runbook incluye una opción de «degradar con control», como cambiar de pasarela de pago o desactivar las recomendaciones.
• Feature flags preparados para desactivar funciones pesadas y no esenciales bajo carga.
• Rollback de la última versión probado y cronometrado.
• Está por escrito quién puede decidir un rollback, retirar una promoción o pausar el marketing.

A una semana: congela y ensaya

• La congelación de cambios empieza como muy tarde el 23 de noviembre, con una vía de cambios urgentes que requiere dos aprobadores.
• Un simulacro de 30 minutos: simula la caída de la pasarela de pago y recorre el runbook.
• Plantillas listas para la página de estado y atención al cliente: «checkout lento» e «incidencias con los pagos».
• Atención al cliente sabe cómo llegar al canal de incidencias y qué puede contar a los clientes.
• Copias de seguridad verificadas con una prueba de restauración en los últimos 30 días.

El día D y después

• Se abre un canal de crisis antes de que arranque la primera promoción, con actualizaciones cada 30 minutos durante una incidencia.
• Alguien vigila el panel de negocio a la hora de inicio de cada promoción.
• Cada incidencia queda registrada con hora de inicio, impacto y pedidos perdidos, aunque haya durado minutos.
• Revisión post-pico reservada para la primera semana de diciembre, con todo aún fresco.
• Todo lo que se rompió pasa a ser un registro de problema con un responsable, para que no vuelva a fallar el año que viene.

Preguntas frecuentes