Preparar sitio para pico de tráfico

Los sitios fallan en picos de tráfico por cuellos de botella en infraestructura, base de datos o servicios terceros, y por falta de pruebas reales. No prepararse puede costar ventas, reputación y tiempo de recuperación en momentos críticos. Esta guía ofrece un checklist técnico priorizado y un plan de pruebas para que emprendedores y pymes coordinen al equipo técnico y ejecuten un ensayo efectivo antes del día D.

Checklist técnico priorizado

Mínimo (imprescindible)

• Revisa capacidad de hosting y límites: conexiones máximas, procesos PHP/worker, límites de pipelines. Si no estás seguro, consulta a tu proveedor o revisa la documentación del servicio.
• Cache en el servidor y navegador: habilita caching de páginas y recursos estáticos (cabeceras Cache-Control) con caducidades razonables.
• CDN: configura un CDN para assets (imágenes, CSS, JS) y prueba su entrega.
• Backups recientes y plan de rollback documentado.
• Monitoreo básico y alertas por latencia alta y errores 5xx.

Medio (rendimiento y resiliencia)

• Autoscaling o reglas para escalar instancias y/o procesos en picos; define límites seguros y costes previstos.
• Optimización de assets: minificación, compresión (gzip/brotli), tamaños de imagen adaptativos y carga diferida cuando aplique.
• Índices en consultas críticas de la base de datos; revisa queries lentas y añade caché de consultas cuando sea posible.
• Colas y procesamiento asíncrono para tareas pesadas (emails, generación de PDFs, integraciones externas).
• Timeouts razonables y circuit breakers para llamadas a APIs de terceros.

Avanzado (escalado y tolerancia a fallos)

• Réplicas de lectura para la base de datos o separación lectura/escritura.
• Cache distribuida (Redis/Memcached) con políticas de expiración claras.
• Pruebas de “chaos” básicas para validar degradación controlada y circuit breakers.
• Revisión de arquitectura: balanceo de carga, health checks y despliegues canary/blue-green.
• Políticas de rate limiting para proteger endpoints críticos.

Plan de pruebas paso a paso

Objetivo: simular condiciones reales del día D para detectar cuellos de botella y validar respuestas del equipo. Herramientas recomendadas: k6 (scripting y métricas), ApacheBench (pruebas simples), Loader.io (pruebas rápidas desde la nube).

1. Define escenarios reales: número de usuarios concurrentes, acciones por usuario (visitar home, búsqueda, checkout), y origen del tráfico (CDN, país, picos horario).
2. Prueba de smoke: carga pequeña para verificar que el sitio responde y que logs/alertas funcionan.
3. Ramp-up gradual: sube concurrencia en etapas (por ejemplo, 10% cada 2–5 minutos) hasta la carga esperada. Observa latencia P95/P99, errores 5xx, uso CPU/mem y conexiones DB.
4. Concurrencia sostenida: mantén la carga esperada durante 10–30 minutos para comprobar estabilidad y fugas de memoria o límites de conexión.
5. Picos cortos: inyecta ráfagas breves (10–30% sobre lo esperado) para validar autoscaling y comportamiento de circuit breakers.
6. Itera: corrige cuellos detectados y repite pruebas. Documenta cambios y resultados.

Métricas clave a medir:

• Latencia P95 y P99 por endpoint.
• Tasa de errores 5xx y errores de timeouts.
• Tiempo hasta el primer byte (TTFB).
• Uso de CPU y memoria en servidores, número de procesos/threads, y conexiones activas a la base de datos.
• Tiempos de respuesta de servicios externos.

Ejemplo básico de script k6 para un escenario de compra (simplificado):

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
  stages: [
    { duration: '2m', target: 50 }, // ramp-up
    { duration: '10m', target: 50 }, // sostenida
    { duration: '2m', target: 0 }, // ramp-down
  ],
};

export default function () {
  http.get('https://tusitio.com/');
  http.get('https://tusitio.com/producto/123');
  http.post('https://tusitio.com/checkout', { /* payload */ });
  sleep(1);
}

Checklist pre-lanzamiento (24–72 horas) y procedimientos del día D

• 24–72 h: ejecutar pruebas de carga controladas y validar rollback; revisar errores y recursos.
• 48 h: asegurar backups completos y notificar al equipo y proveedor de hosting sobre ventana de tráfico alto.
• 24 h: programar escalado anticipado si es posible (instancias, workers, CDN purge/precarga).
• 12 h: preparar canales de comunicación (Slack/Telegram/llamadas) y lista de contactos de soporte técnico y proveedor.
• Día D: realizar calentamiento de cache (requests automáticos a páginas críticas), activar reglas de escalado programadas y monitorizar en tiempo real las métricas clave; mantener un feed único de incidentes y decisiones.

Runbook de contingencia (pasos concretos)

1. Si errores 5xx suben de forma sostenida: reducir funcionalidades no críticas (promociones, widgets externos) y aumentar caché.
2. Si la base de datos alcanza conexiones máximas: activar réplica o read-only para cargas no críticas y degradar funcionalidades que escriben intensivamente.
3. Rollback: desplegar la versión estable previa si un cambio reciente coincide temporalmente con el fallo; documentar el motivo y hora de rollback.
4. Si el hosting no escala: activar página de mantenimiento escalable (servida desde CDN) con información mínima y formulario para capturar leads/órdenes offline.
5. Post-mortem inmediato: registrar timeline, métricas y decisiones; planear correcciones antes de la próxima campaña.

Si necesitas orientación sobre elección de hosting o verificación de límites de tu proveedor, consulta recursos sobre qué hosting necesitas y qué debe incluir un buen hosting empresarial para empresas: Qué hosting necesitas para tu sitio web? y Qué debe incluir un buen hosting empresarial.