El cliente es un servicio logístico que procesa decenas de miles de pedidos al día, con picos por la tarde y durante las rebajas, y SLA estrictos con las cadenas comerciales asociadas. La infraestructura había crecido sin planificación: VPS dispersos, configuraciones fijadas «en los servidores» y despliegues manuales siguiendo instrucciones de una wiki. Cada lanzamiento exigía una publicación nocturna con interrupciones; cada pico suponía el riesgo de perder pedidos. El proyecto empezó después de una incidencia en las rebajas previas a Año Nuevo: la plataforma estuvo caída durante cuatro horas y el servicio tuvo que compensar a sus socios.
Migrar la plataforma a una infraestructura gestionada sin detener el negocio:
infraestructura como código, entrega automatizada, contenedores y orquestación, observabilidad y recuperación predecible ante fallos. El fundador definió el éxito así: «desplegar durante el horario laboral, sin tiempo de inactividad y sin una persona con acceso por SSH».
Seguimos una secuencia probada: primero los contenedores y entornos reproducibles, después la automatización de la entrega y solo entonces la orquestación con autoescalado.
- Auditamos la infraestructura: mapa de servicios y dependencias, medición del perfil de carga en horas punta y registro de las operaciones manuales que más a menudo causaban incidencias.
- Contenerizamos los servicios: unificamos las compilaciones, trasladamos la configuración del código a variables de entorno y creamos entornos idénticos de desarrollo, pruebas y producción.
- Describimos la infraestructura en código con Terraform: los entornos se despliegan desde el repositorio y se prohíben los cambios manuales desde la consola del proveedor de nube.
- Creamos un pipeline de GitLab CI: las pruebas y la compilación de imágenes se ejecutan automáticamente; el despliegue a stage es inmediato y a producción se activa con un botón tras la revisión. La reversión se hace con una sola acción.
- Migramos la plataforma a Kubernetes con autoescalado: ante los picos vespertinos y las rebajas, la plataforma añade instancias en vez de exigir intervenciones manuales de emergencia.
- Desplegamos monitorización y alertas con métricas de las señales clave —latencia, errores, tráfico y saturación—, turnos de guardia y un esquema de escalado de incidencias.
- Configuramos copias de seguridad y recuperación ante desastres: establecimos el procedimiento de recuperación e hicimos un simulacro de fallo en stage, midiendo el MTTR real.
Lo más valioso del proyecto no fueron las tecnologías, sino el cambio de responsabilidad: la infraestructura dejó de depender de una «persona con acceso por SSH». Cada despliegue es reproducible, cada entorno se puede reconstruir desde el código y los paneles muestran cualquier fallo antes de que escriba el primer cliente. Así, las interrupciones pasan de ser una catástrofe a una incidencia rutinaria con un procedimiento claro y un tiempo de recuperación medible.
El impacto económico se compone de tres partes: ahorro directo del 32% en infraestructura gracias al autoescalado y a dejar de mantener permanentemente encendida la capacidad para los picos; horas del equipo que ya no se consumen en despliegues nocturnos; y, sobre todo, ingresos preservados durante los picos, que ahora transcurren sin incidentes. Un importante cliente, una cadena de tiendas, renovó su contrato precisamente después de la primera rebaja en la nueva infraestructura.
| Indicador | Resultado |
|---|---|
| Despliegue de versiones | 3–4 horas manualmente → 15 minutos automáticamente |
| Frecuencia de lanzamientos | 2–3 al mes → Casi a diario |
| Disponibilidad de la plataforma | 97,8% → 99,95% |
| Picos de carga | Riesgo de interrupción → Autoescalado sin intervención humana |
Las métricas se han trasladado de los materiales originales del caso. El período se indica cuando está especificado en la fuente.
- despliegue de versiones (antes, 3–4 horas manualmente)
- 15 min
- disponibilidad de la plataforma (antes, 97,8%)
- 99,95%
- recuperación tras una interrupción (antes, 2–4 horas)
- 20–30 min
- coste de infraestructura
- −32%
Se muestran los límites superiores de los intervalos (4 horas, 30 minutos). Tiempo de inactividad = 100% − disponibilidad.
- 01Commit
- 02Pruebas
- 03Compilación de la imagen
- 04Entorno de pruebasinmediatamente
- 05Produccióncon un botón tras la revisión
Áreas para desarrollar la infraestructura en el siguiente ciclo:
- Prácticas FinOps: alertas de anomalías de gasto y visibilidad de costes por equipo.
- Enfoque GitOps: el estado de producción queda descrito en el repositorio y los cambios se realizan solo mediante pull request.
- Multirregión: réplicas de servicios críticos para resistir fallos del proveedor.
Antes, un lanzamiento significaba noche, café y rezar. Ahora son un botón y quince minutos. Toda la empresa celebró la primera rebaja sin incidentes.
— Director técnico del servicio logístico