Plantilla de Pronóstico de Capacidad

Descripción General

El tráfico crece, pero la infraestructura no crece sola. La mayoría de las interrupciones no las causa código malo — las causan sistemas que chocan contra un límite que nadie midió. La planificación de capacidad es la disciplina de mirar hacia adelante: cuánto tráfico tendremos en seis meses, qué recurso se agotará primero y cuánto cuesta mantenerse por delante de la demanda. Un pronóstico de capacidad convierte el escalado por pánico en una operación programada, presupuestada y probada.

Esta plantilla es la parte documental de esa disciplina — un pronóstico rellenable que puedes llevar a tu wiki y revisar trimestralmente. Cubre el ciclo completo: medir la utilización actual, proyectar el crecimiento, identificar el primer cuello de botella, planificar el trabajo de escalado, ponerle precio y programar la próxima revisión. Para la metodología en profundidad, la guía de planificación de capacidad cubre los conceptos.

Cuándo Usar

Usa esta plantilla cuando:

• Entras en una fase de crecimiento (campaña de marketing, lanzamiento de producto, pico estacional)
• Un servicio se acerca al 60-70% de utilización de cualquier recurso crítico
• Necesitas justificar gasto de infraestructura ante finanzas o liderazgo
• Quieres pasar del escalado reactivo al proactivo
• Evalúas una transición de escalado vertical a horizontal

Cuándo no usarla: un servicio nuevo sin histórico de tráfico no se puede pronosticar — ejecuta primero una prueba de carga (la plantilla de plan de pruebas de carga encaja ahí) y vuelve cuando tengas unos meses de datos de referencia. Lo mismo aplica tras un cambio importante de arquitectura: una migración a otra base de datos o un salto a Kubernetes reinicia la línea base, y las tendencias antiguas dejan de significar algo.

Prerequisitos

Antes de crear un pronóstico de capacidad:

• Existen métricas de referencia: CPU, memoria, I/O de disco, throughput de red, tasa de peticiones, latencia
• Hay datos históricos de tráfico de al menos los últimos tres meses
• Las suposiciones de crecimiento están documentadas (planes de marketing, metas de adquisición de usuarios, lanzamientos)
• Los datos de costes están disponibles: facturas del proveedor cloud, precios de instancias reservadas, licencias
• El equipo acuerda qué significa “lleno” (¿80%? ¿90%? ¿100% con margen?)

Esa última casilla es la que los equipos se saltan, y es la que más importa. “Lleno” para una base de datos (70% de CPU antes de que las consultas se degraden) es muy distinto de “lleno” para un nivel web sin estado (90%+ va bien). Anota el umbral por recurso o el pronóstico no tiene línea de disparo.

Solución

# Pronóstico de Capacidad: `<Sistema / Servicio>`

> Autor: ______ | Fecha: ______ | Fecha de revisión: ______
> Propietario del servicio: ______ | Equipo: ______ | Horizonte del pronóstico: ______

## 1. Estado Actual

| Métrica | Actual | Pico (últimos 30d) | Límite | Margen |
|---------|--------|--------------------|--------|--------|
| Peticiones / seg | ______ | ______ | ______ | ______ |
| Utilización CPU (%) | ______ | ______ | ______ | ______ |
| Utilización memoria (%) | ______ | ______ | ______ | ______ |
| I/O disco (MB/s o IOPS) | ______ | ______ | ______ | ______ |
| Throughput red (Gbps) | ______ | ______ | ______ | ______ |
| Conexiones base de datos | ______ | ______ | ______ | ______ |
| Almacenamiento usado (GB) | ______ | ______ | ______ | ______ |
| Profundidad de cola / backlog | ______ | ______ | ______ | ______ |

**Infraestructura actual:**
- ______ instancias de tamaño ______
- ______ bases de datos de tier ______
- ______ nodos de caché
- ______ balanceadores de carga
- Coste mensual estimado: ______

## 2. Suposiciones de Crecimiento

| Impulsor | Cambio Esperado | Plazo | Confianza |
|----------|-----------------|-------|-----------|
| ______ | ______ | ______ | Alta / Media / Baja |
| ______ | ______ | ______ | Alta / Media / Baja |
| ______ | ______ | ______ | Alta / Media / Baja |

**Suposiciones clave:**
- [ ] ______
- [ ] ______

## 3. Proyecciones de Tráfico

| Periodo | RPS Proyectado | MAU Proyectado | Tasa de Crecimiento |
|---------|----------------|----------------|---------------------|
| Actual | ______ | ______ | — |
| +3 meses | ______ | ______ | ______ |
| +6 meses | ______ | ______ | ______ |
| +12 meses | ______ | ______ | ______ |

## 4. Pronóstico de Recursos

| Recurso | Actual | +3m | +6m | +12m | ¿Primero en alcanzar el límite? |
|---------|--------|-----|-----|------|--------------------------------|
| CPU | ______ | ______ | ______ | ______ | Sí / No |
| Memoria | ______ | ______ | ______ | ______ | Sí / No |
| I/O disco | ______ | ______ | ______ | ______ | Sí / No |
| Red | ______ | ______ | ______ | ______ | Sí / No |
| Conexiones BD | ______ | ______ | ______ | ______ | Sí / No |
| Almacenamiento | ______ | ______ | ______ | ______ | Sí / No |

## 5. Plan de Escalado

### Corto Plazo (0-3 meses)
- [ ] ______
- [ ] ______

### Medio Plazo (3-6 meses)
- [ ] ______
- [ ] ______

### Largo Plazo (6-12 meses)
- [ ] ______
- [ ] ______

## 6. Proyección de Costes

| Escenario | Coste Mensual | Coste Anual | Notas |
|-----------|---------------|-------------|-------|
| No hacer nada | ______ | ______ | Riesgo de interrupción |
| Mínimo viable | ______ | ______ | Justo por delante de la demanda |
| Margen cómodo | ______ | ______ | Buffer del 30-40% |

## 7. Evaluación de Riesgos

| Riesgo | Probabilidad | Impacto | Mitigación |
|--------|--------------|---------|------------|
| El crecimiento excede el pronóstico | ______ | ______ | ______ |
| Límites del proveedor cloud | ______ | ______ | ______ |
| El escalado tarda más de lo esperado | ______ | ______ | ______ |
| Presupuesto no aprobado | ______ | ______ | ______ |

## 8. Acciones Pendientes

| Tarea | Responsable | Fecha Límite | Estado |
|-------|-------------|--------------|--------|
| ______ | ______ | ______ | ______ |

## 9. Apéndice

- Enlaces a dashboards: ______
- Datos históricos de incidentes: ______
- ADRs o documentos de diseño relacionados: ______

Cómo Funciona el Pronóstico

Un pronóstico de capacidad responde tres preguntas, y las secciones de la plantilla les corresponden una a una:

1. ¿Dónde estamos ahora? — utilización actual frente a límites (secciones 1–2)
2. ¿Hacia dónde vamos? — proyecciones de tráfico y recursos (secciones 3–4)
3. ¿Qué hacemos al respecto? — plan de escalado, presupuesto, riesgo, acciones (secciones 5–8)

La matemática de fondo es más simple que la disciplina que la rodea. Tres fórmulas hacen la mayor parte del trabajo:

• Tasa de crecimiento: ajusta los últimos 3–6 meses de una métrica a una tendencia — el crecimiento mensual compuesto es (fin / inicio)^(1/meses) - 1. Si el último trimestre muestra RPS pasando de 800 → 900 → 1.000, eso es ~12% de crecimiento mensual, no el 8% que creció tu número de usuarios.
• Runway (recorrido): meses_restantes = (límite - pico_actual) / crecimiento_mensual. Un pool de conexiones a 82/100 creciendo 8 conexiones al mes tiene unos dos meses de recorrido — ese número es la fecha límite desde la que todo lo demás se calcula hacia atrás.
• Objetivo de margen: cuánta capacidad libre mantienes sobre el pico proyectado. Los niveles web sin estado suelen ir bien con un 30% de margen; las bases de datos y todo lo que tiene techo duro (pools de conexiones, disco) merecen 40–50% porque se degradan antes de fallar.

Extrae los números de sistemas en los que ya confías: utilización de tu stack de monitoreo, tasas de peticiones de los logs del balanceador o del ingress, crecimiento de almacenamiento de las métricas de disco en lugar del conteo de filas, y coste de la factura real del proveedor en lugar de la calculadora de precios — la factura incluye el egress y todas las líneas que la calculadora olvida. Si una métrica no se mide hoy, instruméntala ahora y marca la sección como “histórico insuficiente” en lugar de adivinar; un hueco honesto es un hallazgo, no un fallo.

Una decisión de modelado importa más que cualquier fórmula: proyecta picos, no medias. Pronostica la hora punta del percentil 95, porque es en esa hora donde ocurre la caída. Si tu monitoreo solo muestra medias diarias, multiplica por tu ratio pico/media observado — en la mayoría de servicios web está entre 1.5x y 3x.

Dos detalles de modelado más separan un pronóstico que funciona de uno que solo parece plausible:

• No todo crece linealmente con el tráfico. El almacenamiento crece con el volumen de datos, no con las peticiones — una función que registra más por petición duplica tu pendiente de almacenamiento sin tocar los RPS. Los pools de conexiones crecen con las sesiones concurrentes. La memoria de caché crece con el tamaño del working set, que sigue al tamaño del catálogo, no al tráfico. Dale a cada recurso su propio impulsor cuando el obvio no aplique.
• Construye tres escenarios, no una línea. Crecimiento esperado, crecimiento alto (la campaña de marketing funciona de verdad) y crecimiento bajo (fracasa). Cada escenario lleva su propia fecha de cuello de botella. El plan base sigue el “esperado”, pero tus disparadores de acción deberían referenciar el “alto” — si el escenario alto deja el disco por encima del límite en octubre, la conversación de compra empieza en agosto, no cuando el disco esté lleno.

También ayuda separar tres tipos de demanda que suelen mezclarse en un único número de crecimiento. La demanda orgánica es la tendencia base — usuarios y uso creciendo de forma sostenida. La demanda por eventos es todo lo que tiene fecha: lanzamientos, campañas, picos estacionales, la incorporación de un cliente grande. La demanda estructural es el crecimiento causado por lo que entregas, no por quién llega — una función nueva que duplica los datos escritos por petición hace crecer tu pronóstico de almacenamiento sin cambiar el tráfico. Modela cada una por separado y súmalas. El fallo clásico de pronóstico es tratar un pico de lanzamiento como crecimiento orgánico (sobre-aprovisionas para siempre) o tratar el crecimiento orgánico como un pico (infra-aprovisionas justo cuando importa).

El overlay estacional merece el mismo tratamiento. Si tu tráfico tiene un multiplicador de 2.5x en festivos, aplícalo sobre la tendencia de crecimiento — una línea de 12% mensual que toca el 80% de CPU en diciembre se convierte en una emergencia real a 2.5x en noviembre. El dashboard de ejemplo de abajo hace exactamente eso: cada fila “¡SOBRE!” de noviembre a enero es el multiplicador estacional cayendo sobre el crecimiento orgánico.

Cómo Rellenarla

Rellena la plantilla en orden — cada sección alimenta a la siguiente.

Sección 1 (Estado Actual) sale directamente de tu monitoreo. Usa los picos de los últimos 30 días, no las medias — un servicio con 40% de CPU media puede estar al 90% a la hora de comer. La columna de margen es la única que requiere juicio: pico actual frente al umbral de “lleno” acordado en los prerequisitos.

Sección 2 (Suposiciones de Crecimiento) es donde los pronósticos mueren en silencio. Cada impulsor lleva un nivel de confianza, y los de confianza baja (una campaña de marketing sin confirmar, una alianza tentativa) pertenecen a un escenario, no a la proyección base. Si producto no puede darte el crecimiento esperado, anota tu propio número y márcalo como confianza baja — una suposición errónea pero registrada gana a una no documentada.

Sección 3 (Proyecciones de Tráfico) convierte los impulsores en números. Trabaja en la unidad que genera carga — peticiones por segundo, no usuarios — porque el tráfico por usuario deriva. Si no puedes justificar un número, acótalo: un rango bajo/esperado/alto es honesto; una única cifra con aspecto confiado no lo es.

Sección 4 (Pronóstico de Recursos) aplica la tasa de crecimiento del tráfico a cada recurso. Aquí es donde el pronóstico se gana su existencia: el primer recurso en tocar su límite es tu cuello de botella, y su fecha es tu fecha límite de escalado. Todo lo demás es margen. Vigila los recursos que escalan de forma no lineal — los pools de conexiones y el disco se llenan por crecimiento de datos, que suele superar al crecimiento de peticiones.

Sección 5 (Plan de Escalado) aterriza: cada cuello de botella necesita una acción, un responsable y una fecha de inicio que caiga antes de su fecha límite menos el tiempo de entrega. “Añadir capacidad en Q4” no es un plan; “aumentar el pool de conexiones a 200 antes del 15 de septiembre, porque en octubre llegamos a 100” sí lo es.

Sección 6 (Proyección de Costes) traduce el plan técnico a lenguaje de presupuesto. La fila “no hacer nada” no es relleno — es el precio de la inacción, y es lo que consigue que el plan se apruebe. La plantilla de asignación de costes de infraestructura ayuda cuando necesitas desgloses por equipo o servicio.

Secciones 7–8 cierran el bucle: los riesgos llevan probabilidad y mitigación (la respuesta honesta a “¿qué haría fallar este pronóstico?”), y cada pendiente lleva responsable y fecha — las dos columnas que evitan que el documento muera tras la primera semana.

Sección 9 (Apéndice) parece opcional y no lo es. Enlaza los dashboards de donde salieron los números, los incidentes que justifican los márgenes elegidos y los ADRs que acotan el plan de escalado. Dentro de seis meses, cuando alguien pregunte por qué el pronóstico asume un 40% de margen en la base de datos, “ver incidente INC-284 en el apéndice” es mejor respuesta que “elegimos un número”.

Ejemplo de Dashboard de Pronóstico de Capacidad

Así se ve un pronóstico completado como dashboard — la tabla de proyección marca exactamente cuándo cruza cada recurso su límite:

=== Dashboard de Pronóstico de Capacidad — Q3 2026 ===

ESTADO ACTUAL (al 2026-07-11):
  Utilización CPU (media):      42%
  Utilización CPU (pico):       68%
  Utilización memoria (media):  55%
  Utilización memoria (pico):   78%
  Uso de disco:                 3.2 TB / 5 TB (64%)
  Throughput de red (media):    120 Mbps
  Throughput de red (pico):     450 Mbps
  Conexiones BD (media):        45 / 100
  Conexiones BD (pico):         82 / 100

SUPOSICIONES DE CRECIMIENTO:
  Crecimiento de usuarios:      8% / mes (según últimos 6 meses)
  Crecimiento de tráfico:       12% / mes (el tráfico crece más rápido que los usuarios)
  Crecimiento de datos:         50 GB / mes
  Factor de pico estacional:    2.5x (Black Friday, temporada navideña)

PROYECCIÓN A 6 MESES:
  Mes      | CPU Pico | Mem Pico | Disco   | Conn BD Pico
  ---------|----------|----------|---------|-------------
  Ago 2026 | 72%      | 82%      | 3.7 TB  | 88
  Sep 2026 | 78%      | 86%      | 4.2 TB  | 94
  Oct 2026 | 85%      | 91%      | 4.7 TB  | 102 (¡SOBRE!)
  Nov 2026 | 95%      | 96%      | 5.2 TB  | 115 (¡SOBRE!)
  Dic 2026 | 98%      | 98%      | 5.7 TB  | 125 (¡SOBRE!)
  Ene 2027 | 100%+    | 100%+    | 6.2 TB  | 140 (¡SOBRE!)

CUELLO DE BOTELLA: Las conexiones de BD alcanzan el límite en octubre de 2026
ACCIÓN: Aumentar el pool de conexiones a 200 antes de septiembre de 2026

CUELLO DE BOTELLA: El disco llega al límite de 5 TB en noviembre de 2026
ACCIÓN: Añadir 3 TB de almacenamiento antes de octubre de 2026

CUELLO DE BOTELLA: La CPU llega al 90% en noviembre de 2026 (pico estacional)
ACCIÓN: Añadir 4 instancias al grupo de autoescalado antes de octubre de 2026

Léelo de abajo hacia arriba: los cuellos de botella del final son el entregable. Este ejemplo muestra por qué las medias mienten — la CPU está al 42% de media pero al 68% de pico hoy, y el pool de conexiones se agota un mes antes que el disco. Cada cuello de botella lleva una acción con fecha anterior a la fecha de fallo, porque la compra y el despliegue llevan tiempo.

El Bucle del Pronóstico

La planificación de capacidad no es un documento que se escribe una vez — es un bucle. Mide la línea base, proyecta el crecimiento, encuentra el primer cuello de botella, planifica la corrección, presupuéstala, y al trimestre siguiente mide otra vez y compara la realidad con el pronóstico.

El último paso es el que la mayoría de equipos se saltan. Comparar pronóstico con realidad es como se calibra el modelo — si el tráfico creció un 8% pero proyectaste un 12%, la proyección del próximo trimestre se ajusta. Un pronóstico que nunca se contrasta con la realidad sigue siendo ficción.

Revisión del Pronóstico

La revisión trimestral es una reunión de quince minutos, no una auditoría. Tres preguntas la cubren:

1. ¿La realidad coincidió con la proyección? Extrae los picos reales de cada recurso y escríbelos junto a los valores pronosticados. Un fallo sistemático en una dirección significa que el impulsor de crecimiento está mal; fallos aleatorios significan que el horizonte es demasiado largo.
2. ¿Se retrasó alguna acción? Una acción de escalado que perdió su fecha límite es o un problema de recursos o un pronóstico que no reservó tiempo de entrega — corrige la causa, no solo la tarea.
3. ¿Qué cambió desde la última revisión? Funciones nuevas, un cambio de precios, una migración, un cliente grande firmado. Cualquier cosa que invalide una suposición de crecimiento va a la sección 2 de la siguiente versión.

Guarda las versiones antiguas del pronóstico. Una carpeta de pronósticos fechados — cada uno anotado con lo que ocurrió de verdad — es el dataset de precisión de pronósticos más barato que construirás jamás, y es lo que convierte un ejercicio anual de adivinación en un modelo que converge.

La responsabilidad importa aquí igual que en las políticas de monitoreo: un responsable con nombre (normalmente el líder de SRE o plataforma), el documento en control de versiones junto al código de infraestructura que describe, y cambios revisados como cualquier otro artefacto operativo. Un pronóstico que vive en un wiki que nadie mira es indistinguible de no tener pronóstico — salvo que la gente sigue confiando en él.

Variantes

Contexto	Ajustes	Notas
Específico para bases de datos	Añade throughput de consultas, crecimiento de índices, lag de replicación y límites del pool de conexiones	Las bases de datos alcanzan límites de forma distinta al cómputo
Sistemas intensivos en almacenamiento	Añade políticas de retención de datos, planes de compresión y costes de almacenamiento por niveles	El almacenamiento crece predeciblemente pero es caro
Basados en eventos / colas	Añade throughput por shard, lag del consumidor y crecimiento de la dead-letter queue	Las colas ocultan la contrapresión hasta que se desbordan
Multi-región	Añade ancho de banda de replicación entre regiones y capacidad por región	Cada región puede tener un crecimiento distinto
Serverless	Añade conteo de invocaciones, límites de concurrencia y frecuencia de cold starts	Los límites serverless son distintos de los de instancias

Elige la variante preguntando qué recurso se agota primero — esa es la fila de la tabla que dirige tu horizonte de pronóstico. Un servicio centrado en base de datos planifica alrededor del pool de conexiones y el lag de replicación; un sistema de colas planifica alrededor del lag del consumidor; serverless planifica alrededor de cuotas que solo se pueden elevar abriendo un ticket de soporte con semanas de antelación.

Lo Que Funciona

1. Pronostica mensualmente, revisa trimestralmente — las suposiciones cambian; actualiza el pronóstico antes de que se convierta en ficción
2. Usa percentiles, no medias — la latencia p99 y el pico de CPU importan más que los valores medios
3. Incluye un escenario de “no hacer nada” — hace explícito el coste de la inacción
4. Prueba tu plan de escalado — ejecuta una prueba de carga que simule tu proyección a 6 meses antes de necesitarla
5. Comparte el pronóstico ampliamente — producto, finanzas e ingeniería deben ver los mismos números
6. Define disparadores de escalado, no solo fechas — “añade capacidad cuando el pico de CPU sostenga 70% durante dos semanas” sobrevive mejor a un mal pronóstico que una fecha de calendario
7. Registra la precisión del pronóstico — anota proyectado vs real cada trimestre para que el modelo converja en lugar de derivar

Errores Comunes

1. Planificar en base a medias — un sistema al 50% de CPU media puede estar al 95% en horas punta
2. Ignorar la base de datos — el cómputo escala horizontalmente; las bases de datos a menudo no
3. Olvidar los servicios downstream — escalar tu API no sirve si tu caché o tu base de datos no pueden seguir el ritmo
4. Sin niveles de confianza en las suposiciones — las campañas de marketing fracasan; construye escenarios para crecimiento alto, medio y bajo
5. Esperar hasta el 90% de utilización — para entonces ya estás en modo emergencia; planifica al 70%
6. Pronosticar cómputo pero no coste — la línea de presupuesto es lo que lee la dirección; un pronóstico técnicamente perfecto que no se aprueba sigue siendo un plan fallido

Solución de Problemas

• El pronóstico falla estrepitosamente cada trimestre: el impulsor de crecimiento está mal, no las matemáticas. Comprueba si el tráfico sigue realmente al impulsor que elegiste (registros ≠ peticiones; una campaña de marketing puede doblar registros mientras el tráfico de lectura se mantiene plano).
• La utilización sube pero el dashboard se ve bien: estás mirando medias. Cambia las métricas de referencia a picos p95/p99 — las medias ocultan el muro hasta que chocas con él.
• Los costes proyectados quedaron muy por debajo de la factura: revisa transferencia de datos, NAT gateway y crecimiento de almacenamiento — el egress y el almacenamiento suelen crecer más rápido que el pronóstico de cómputo.
• Una acción de escalado perdió la fecha límite del cuello de botella: la suposición de tiempo de entrega era optimista. Registra los tiempos reales de compra/despliegue en el apéndice e incorpóralos a las fechas de acción del próximo pronóstico.
• La prueba de carga dice que la capacidad sobra pero producción discrepa: el tráfico de la prueba no tenía la forma del real. El tráfico real tiene ráfagas, reintentos y claves calientes desiguales — reproduce tráfico de producción o usa la plantilla de plan de pruebas de carga para construir un perfil realista.
• Nadie actualizó el pronóstico tras el lanzamiento: asigna un responsable al documento y pon la revisión trimestral en el calendario; un pronóstico sin mantenimiento es peor que ninguno porque la gente confía en él.

Lecturas Adicionales

• Google SRE Workbook — The Lego Approach to Capacity Planning
• AWS Well-Architected — pilar de eficiencia de rendimiento
• Gestión de recursos en Kubernetes para requests y límites de CPU/memoria en contenedores
• Relacionado en este sitio: la guía de planificación de capacidad y la plantilla de política de monitoreo y alertas para alertar sobre los umbrales que define este pronóstico.