Planificación de Capacidad

Descripción general

La planificación de capacidad responde a dos preguntas que deciden si tu próximo pico de tráfico es un trámite o una caída: cuánta carga aguanta tu infraestructura hoy y cuánta va a necesitar el próximo trimestre. Si te quedas corto tienes saturación, timeouts en cadena y usuarios enfadados; si te pasas, pagas máquinas ociosas — el sobreaprovisionamiento es una de las fuentes más comunes de desperdicio en cloud.

La disciplina en sí es sencilla: mide lo que tienes, pronostica lo que necesitarás, valida bajo carga y guarda margen para lo inesperado. Lo difícil en la práctica es que la demanda casi nunca crece en línea recta — los lanzamientos, la estacionalidad y el crecimiento compuesto deforman la curva. Esta guía recorre el ciclo completo, desde las métricas de base hasta un plan de capacidad documentado que puedes entregar a finanzas. Para un documento listo para rellenar, mira la plantilla de planificación de capacidad; para la hoja de proyecciones, la plantilla de forecast.

Cuándo usarlo

Recurre a una planificación de capacidad estructurada cuando:

• Estás preparando un lanzamiento de producto, una campaña de marketing o un pico estacional de tráfico
• Tu servicio se degrada en horas punta recurrentes y nadie sabe exactamente qué recurso se satura primero
• Quieres recortar costes de cloud sin apostar la fiabilidad — el exceso de capacidad es un problema tanto como la escasez
• Necesitas justificar un presupuesto de infraestructura con proyecciones en lugar de intuición
• Estás migrando de on-premise a cloud y hay que dimensionar instancias en lugar de copiar especificaciones de hardware 1:1

Puedes saltarte el proceso formal cuando el sistema es tan pequeño que un solo dashboard de métricas responde a «¿estamos cerca del límite?» de un vistazo — un proyecto personal en un VPS no necesita un documento de plan de capacidad. El disparador para formalizarlo es cuando la respuesta deja de ser obvia: varios servicios compartiendo bases de datos, o un presupuesto real en juego. Para las prácticas operativas alrededor de esto, la guía de prácticas SRE cubre error budgets y alertas, y la guía de FinOps cubre la parte de costes.

Conceptos clave

Concepto	Descripción
Capacidad actual	Throughput máximo que tu sistema aguanta con los recursos existentes
Margen (headroom)	Colchón sobre el pico de uso para absorber picos inesperados (típicamente 20-30 %)
Punto de saturación	Nivel de utilización donde el rendimiento empieza a degradarse (normalmente >70 % CPU, >80 % memoria)
Tiempo de escalado	Tiempo necesario para aprovisionar y desplegar capacidad adicional
Pronóstico de demanda	Carga futura proyectada a partir de tendencias históricas y eventos de negocio

Dos de estos merecen más atención de la habitual. El margen no es capacidad desperdiciada — es tu seguro contra el pico que llega antes de que reaccione el autoescalado. Y el tiempo de escalado es el número que la mayoría de equipos olvida: si aprovisionar un nodo nuevo tarda 10 minutos, tu plan de capacidad tiene que anticipar la carga 10 minutos hacia el futuro, no solo la del presente.

La matemática detrás de los umbrales

La regla del 70 % de CPU no es arbitraria — viene de la teoría de colas. Dos fórmulas pequeñas hacen la mayor parte del trabajo en planificación de capacidad:

• Ley de utilización: U = X * S donde U es la utilización, X el throughput (peticiones por segundo) y S el tiempo de servicio por petición. Si una petición consume 8 ms de CPU y sirves 1.000 rps, necesitas 1000 * 0,008 = 8 núcleos totalmente ocupados solo para ir al día — al 100 % de utilización y sin colchón.
• Ley de Little: N = X * R donde N es el número de peticiones en el sistema y R el tiempo de respuesta. La trampa: R no es constante — a medida que la utilización se acerca al 100 %, el tiempo de cola crece de forma no lineal. Al 50 % de utilización una cola añade un retardo modesto; al 90 % domina por completo el tiempo de respuesta.

Esa no linealidad es la razón por la que los planes de capacidad usan umbrales de saturación en lugar de capacidad bruta. Servir 1.000 rps con exactamente 8 núcleos significa ir al 100 % — la primera ráfaga lo encola todo y la latencia se dispara. Con un techo del 70 % aprovisionas 8 / 0,7 ≈ 11,4 núcleos, es decir doce. Ese 30 % «desperdiciado» es lo que mantiene el p99 plano cuando llega la ráfaga.

La misma matemática aplica a pools de conexiones, thread pools y colas: cualquier recurso usado cerca de su límite convierte pequeñas oscilaciones de tráfico en grandes saltos de latencia. Modela tu techo a partir del cuello de botella que encontraste en el paso 2, no del recurso con más holgura.

Proceso de planificación de capacidad paso a paso

1. Medir la línea base actual

Antes de planificar el crecimiento, captura cómo es tu «normal». Recopila métricas durante un período representativo — 2-4 semanas como mínimo, más si tu tráfico es estacional. Las medias solas engañan: guarda percentiles y valores de pico, porque las decisiones de capacidad se toman contra picos, no contra promedios.

# Recopilar métricas durante un período representativo (2-4 semanas)
# Métricas clave: CPU, memoria, disco I/O, red, latencia de peticiones, tasa de errores

# Ejemplo: consulta Prometheus para utilización de CPU
avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100

Métricas a seguir:

• Métricas de recursos: CPU, memoria, disco, red
• Métricas de aplicación: peticiones por segundo, percentiles de latencia (p50, p95, p99), tasas de error
• Métricas de negocio: usuarios activos, transacciones por minuto, crecimiento del volumen de datos

Prometheus y los equivalentes gestionados (CloudWatch, Azure Monitor, Datadog) te dan estos datos; lo importante es la ventana de retención, no la herramienta.

2. Identificar cuellos de botella

Tu capacidad efectiva la marca el recurso que se satura primero, no el que tiene más margen. Mide el margen por recurso y el más débil es tu techo:

# Ejemplo: analizar qué recurso alcanza antes el límite
from dataclasses import dataclass

@dataclass
class ResourceLimit:
    name: str
    current_usage: float
    max_capacity: float
    saturation_threshold: float

    def headroom(self) -> float:
        return (self.saturation_threshold - self.current_usage) / self.saturation_threshold * 100

# Evaluar margen por recurso
resources = [
    ResourceLimit("CPU", 45, 100, 70),
    ResourceLimit("Memory", 60, 100, 80),
    ResourceLimit("Disk IOPS", 75, 100, 85),
    ResourceLimit("Network", 30, 100, 70),
]

bottleneck = min(resources, key=lambda r: r.headroom())
print(f"Cuello de botella: {bottleneck.name} con {bottleneck.headroom():.1f}% de margen")

Vigila los cuellos de botella ocultos que no aparecen en métricas de SO: pools de conexiones de base de datos, thread pools, descriptores de fichero, límites de rate de APIs y servicios downstream que escalan más lento que tú. Estos viven en las métricas de aplicación — un servicio puede ir al 30 % de CPU mientras su pool de conexiones está al 95 % y las peticiones se encolan detrás. Si tu análisis dice «margen de sobra» pero el p99 no para de subir, el recurso que se satura es uno que aún no estás midiendo.

3. Pronosticar la demanda

Combina tendencias históricas con contexto de negocio — la extrapolación pura se pierde el lanzamiento que marketing ha programado para el mes que viene.

Técnicas:

• Extrapolación de tendencias: extender curvas de crecimiento históricas
• Ajuste estacional: tener en cuenta patrones semanales, mensuales o anuales
• Pronóstico por eventos: factorizar eventos de tráfico conocidos (lanzamientos, campañas)
• Correlación de negocio: vincular capacidad a métricas de negocio (nuevos clientes, ingresos)

# Ejemplo: pronóstico de demanda con margen
peak_qps_current: 5000
weekly_growth_rate: 0.05  # 5 % por semana
headroom_percent: 0.30    # 30 % de colchón

# Pronóstico a 3 meses (13 semanas)
peak_qps_forecast: 5000 * (1.05 ** 13) ≈ 9440
required_capacity: 9440 * 1.30 ≈ 12272 QPS

Cuidado con el efecto compuesto: un 5 % semanal no suena a mucho hasta que te das cuenta de que duplica la demanda cada ~14 semanas. Modela siempre el escenario optimista, el esperado y el pesimista — el plan tiene que sobrevivir a equivocarse por un factor de dos en cualquier dirección.

La estacionalidad merece su propia línea en el modelo. Un servicio de e-commerce con una base de 5.000 rps que ve un multiplicador de 4x durante las rebajas necesita capacidad para 20.000 rps más el margen — unos 26.000 rps aprovisionados con un colchón del 30 % — no una línea de tendencia suavemente creciente. Separa el pronóstico en «crecimiento orgánico» y «eventos conocidos» para que los revisores puedan cuestionar cada parte de forma independiente.

4. Validar con pruebas de carga

Los pronósticos son hipótesis; las pruebas de carga son como se comprueban. Prueba a 2-3 veces tu pico esperado para ver los modos de fallo antes de que los vea producción.

// capacity-test.js — prueba de carga con k6
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '5m', target: 100 },   // Subida gradual
    { duration: '10m', target: 100 },  // Estado estable
    { duration: '5m', target: 200 },   // Prueba de estrés
    { duration: '5m', target: 0 },     // Bajada gradual
  ],
  thresholds: {
    http_req_duration: ['p(95)<200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/health');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

k6, Gatling y JMeter sirven para esto. Lo importante es probar el stack completo — una prueba de carga que solo golpea el frontend sin estado no demuestra nada sobre la base de datos que hay detrás.

Dos formas de prueba responden a preguntas distintas: una prueba de pico (salto repentino de 3-5x) te dice si tu tiempo de escalado puede absorber ráfagas reales, mientras que una prueba de resistencia (el pico esperado sostenido durante horas) saca a la luz fugas lentas — crecimiento de memoria, agotamiento del pool de conexiones, disco llenándose — a las que las pruebas cortas nunca llegan.

• Código companion: el repo companion de capacity-planning-guide empaqueta el script k6 y el analizador de cuellos de botella como archivos ejecutables.

5. Elegir la estrategia de escalado

Estrategia	Cuándo usarla	Ventajas	Contras
Escalado vertical	Crecimiento predecible y estable; cargas de base de datos	Simple, sin cambios de código	Límite duro, riesgo de caída, caro
Escalado horizontal	Tráfico variable con picos; servicios sin estado	Elástico, tolerante a fallos	Más complejidad, consistencia de datos
Auto-escalado	Demanda impredecible o cíclica	Eficiente en coste, sin intervención	Latencia de arranque en frío, complejidad de configuración
Capacidad reservada	Carga base predecible	Ahorro de costes importante	Menos flexible, compromiso por adelantado

En la práctica, la mayoría de sistemas en producción mezclan estrategias: instancias reservadas o descuentos por uso continuado cubren la base, y el auto-escalado absorbe la parte variable. En Kubernetes, el Horizontal Pod Autoscaler escala pods según métricas; en VMs de cloud, los grupos de Auto Scaling de AWS hacen lo equivalente para instancias. Ajusta la herramienta al tiempo de escalado — un auto-escalado que tarda 10 minutos en añadir un nodo no puede absorber un pico que llega en 30 segundos, por bien configurado que esté.

6. Planificar el margen

Dimensionar el colchón es una decisión de riesgo, no una regla fija:

• Margen mínimo: 20 % sobre el pico esperado
• Servicios críticos: 30-40 % de margen
• Entornos con coste limitado: 15 % con disparadores de escalado más rápidos
• Negocios estacionales: planifica el margen alrededor de las temporadas de pico conocidas

Cuanto más barato sea tu tiempo de reacción al escalar, menos margen necesitas. Si puedes aprovisionar capacidad en segundos (serverless, autoescalado rápido), un 15-20 % es defendible; si tarda horas (pedidos de hardware, aprovisionamiento manual), necesitas el rango superior más un calendario de compras.

7. Documentar y revisar

Un plan de capacidad que solo vive en la cabeza de alguien se degrada rápido. Deja por escrito:

• Métricas de base y cuellos de botella actuales
• Pronóstico de demanda con sus supuestos (para que los revisores puedan cuestionarlos)
• Estrategia de escalado y disparadores
• Proyecciones de coste
• Calendario de revisión — mensual para servicios que crecen rápido, trimestral en el resto

La plantilla de planificación de capacidad cubre esta estructura; la reunión de revisión es donde los pronósticos se corrigen, así que mantén el pronóstico anterior visible junto a los datos reales — así es como tus estimaciones mejoran con el tiempo. Lleva a esa revisión a SRE, al responsable del servicio y a alguien de finanzas: cada uno ve un modo de fallo distinto del plan.

Lo que funciona

• Empieza con datos, no con suposiciones. Recopila al menos 2 semanas de métricas de producción antes de pronosticar.
• Prueba a escala. Haz pruebas de carga a 2-3 veces el pico esperado para entender los modos de fallo.
• Dimensiona de forma continua. Revisa tipos de instancia y capacidad reservada cada trimestre — los precios de cloud y tu propio uso se mueven.
• Correlaciona con eventos de negocio. Vincula la capacidad a lanzamientos, marketing y estacionalidad.
• Automatiza la monitorización. Configura alertas cuando la utilización cruza umbrales de revisión (p. ej., 60 % sostenido), no solo cuando algo se rompe.
• Planifica la degradación. Define qué se descarta primero (feature flags, límites de rate, calidad reducida) cuando se supera la capacidad — el patrón de degradación elegante cubre la mecánica.

Errores comunes

• Planificar para promedios en lugar de picos. La carga media oculta el comportamiento en ráfagas; las decisiones de capacidad son decisiones de pico.
• Ignorar el tiempo de escalado. Si escalar tarda 10 minutos, planifica para el tráfico 10 minutos antes.
• Sobreaprovisionar “por si acaso”. El exceso de capacidad es dinero tirado; usa auto-escalado para cargas variables y capacidad reservada para la base.
• Olvidar las dependencias downstream. Escalar el frontend sin escalar la base de datos solo mueve el cuello de botella — y lo hace fallar más fuerte con más tráfico.
• No re-probar después de cambios. Los cambios de arquitectura invalidan las suposiciones de capacidad anteriores; repite la prueba de carga tras cambios relevantes.
• Tratar el pronóstico como una promesa. Es una estimación con margen de error; revísala contra los datos reales en un calendario o se convierte en ficción.

Variantes

• Planificación de capacidad cloud-native: usa auto-escalado gestionado, instancias spot y serverless para cargas elásticas. Los tiempos de escalado bajan a segundos, así que el margen puede ser más ajustado — pero el precio por petición mueve el riesgo de coste.
• Planificación de capacidad on-premise: céntrate en ciclos de compra de hardware, densidad de virtualización y restricciones de energía y refrigeración. Los plazos se estiran a meses, así que los pronósticos tienen que llegar más lejos y el margen ser más amplio.
• Planificación de capacidad de bases de datos: monitoriza el rendimiento de consultas, límites de conexiones, crecimiento de almacenamiento y lag de replicación. Las bases de datos escalan verticalmente mucho más que los servidores de aplicación, así que sus puntos de saturación merecen su propio plan.
• Serverless y servicios gestionados: la capacidad se mide en límites de concurrencia, throughput aprovisionado y precio por petición en lugar de máquinas. Las cuotas de concurrencia de AWS Lambda y los presupuestos de IOPS de base de datos son el equivalente a los umbrales de saturación de arriba — planifícalos de la misma forma.

Ejemplo práctico: plan de capacidad para un SaaS en crecimiento

Un escenario realista muestra cómo encajan las piezas. Producto SaaS, 10K usuarios activos, crecimiento del 15 % mensual, planificando a seis meses:

Métrica	Actual	Crecimiento	Proyección a 6 meses
Usuarios activos	10K	15 %/mes	~23K
Peticiones/min	50K	15 %/mes	~115K
CPU media	45 %	15 %/mes	~85 %
Memoria	60 %	10 %/mes	~95 %
Almacenamiento	500 GB	20 %/mes	~1,5 TB
Ancho de banda	200 GB/mes	15 %/mes	~460 GB/mes

Cruza las proyecciones con la capacidad aprovisionada para obtener un plan de acción:

Recurso	Aprovisionado	Uso actual	Proyectado	Acción
CPU (8 núcleos)	8 núcleos	3,6 núcleos	6,8 núcleos	Añadir 4 núcleos, mes 4
Memoria (32 GB)	32 GB	19,2 GB	30,4 GB	Añadir 16 GB, mes 3
Almacenamiento (1 TB)	1 TB	500 GB	1,5 TB	Añadir 2 TB, mes 2
Ancho de banda	1 TB/mes	200 GB	460 GB	OK hasta mes 6
Conexiones de BD	200	80	184	Ampliar pool, mes 5

Mes	Acción	Coste estimado
1-2	Almacenamiento +2 TB	$100/mes
3	Memoria +16 GB	$80/mes
4	CPU +4 núcleos	$150/mes
5	Pool de BD +100 conexiones	$0 (config)
6	Evaluar ampliación del clúster	$500/mes

Las lecciones que ilustra este escenario, y que los planes reales no paran de repetir:

• Planifica con datos, no con suposiciones.
• El crecimiento compuesto engaña — un 15 % mensual es 2,3x en seis meses.
• El almacenamiento suele crecer más rápido que la CPU y la memoria.
• El auto-escalado absorbe picos, no crecimiento sostenido; el crecimiento sostenido necesita aprovisionamiento.
• Revisa el plan mensualmente, no semestralmente.

Umbrales de monitorización que dispararían acción en este escenario:

Señal	Umbral	Acción
Utilización de CPU	> 70 % durante 10 min	Escalar / ampliar
Utilización de memoria	> 80 %	Escalar / ampliar
Uso de disco	> 75 %	Ampliar volumen
Pool de conexiones de BD	> 80 % usado	Aumentar pool o añadir réplicas
Tiempo de respuesta p99	> 500 ms	Investigar el cuello de botella

La fórmula de crecimiento compuesto usada arriba: F = P * (1 + r)^n donde P es el valor actual, r la tasa de crecimiento del período y n el número de períodos. Para 10K usuarios al 15 % mensual durante 6 meses: 10000 * 1,15^6 ≈ 23.133. Redondea hacia arriba y añade tu margen encima.

Checklist de planificación de capacidad

• 2-4 semanas de métricas de base capturadas (picos y percentiles, no promedios)
• Cuello de botella identificado por recurso, incluidos pools y dependencias downstream
• Pronóstico cubre escenarios optimista, esperado y pesimista
• Prueba de carga ejecutada a 2-3 veces el pico esperado contra el stack completo
• Estrategia de escalado ajustada al tiempo de escalado
• Margen dimensionado según riesgo y velocidad de reacción (15-40 %)
• Plan documentado con supuestos y cadencia de revisión
• Umbrales de alerta fijados por debajo del punto de saturación, con responsables