Plantilla de Pronostico de Planificacion de Capacidad

Descripcion General

El trafico crece, pero la infraestructura no crece sola. La mayoria de las interrupciones no son causadas por codigo malo, sino por sistemas que chocan contra un limite que nadie midio. La planificacion de capacidad es la disciplina de mirar hacia adelante: cuanto trafico tendremos en seis meses, que recurso se agotara primero y cuanto costara mantenernos por delante de la demanda. Un pronostico de capacidad convierte el escalado impulsado por el panico en una operacion programada, presupuestada y probada.

Cuando Usar

• For alternatives, see Capacity Planning — Forecast, Scale.

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 utilizacion de cualquier recurso critico
• Necesitas justificar gastos de infraestructura ante finanzas o liderazgo
• Quieres pasar del escalado reactivo al proactivo
• Estas evaluando una transicion de escalado vertical a horizontal

Requisitos Previos

Antes de crear un pronostico de capacidad:

• Existen metricas de referencia: CPU, memoria, disco I/O, throughput de red, tasa de peticiones, latencia
• Hay datos historicos de trafico disponibles de al menos los ultimos tres meses
• Las suposiciones de crecimiento estan documentadas (planes de marketing, metas de adquisicion de usuarios, lanzamientos de funciones)
• Los datos de costos estan disponibles: facturas de proveedores cloud, precios de instancias reservadas, licencias
• El equipo acuerda que significa “lleno” (80%? 90%? 100% con margen?)

Solucion

# Pronostico de Planificacion de Capacidad: `<Sistema / Servicio>`

> Autor: ______ | Fecha: ______ | Fecha de revision: ______
> Propietario del servicio: ______ | Equipo: ______ | Horizonte del pronostico: ______

## 1. Estado Actual

| Metrica | Actual | Pico (ultimos 30d) | Limite | Margen |
|---------|--------|--------------------|--------|--------|
| Peticiones / seg | ______ | ______ | ______ | ______ |
| Utilizacion CPU (%) | ______ | ______ | ______ | ______ |
| Utilizacion 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 tamano ______
- ______ bases de datos de tier ______
- ______ nodos de cache
- ______ balanceadores de carga
- Costo 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 Trafico

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

## 4. Pronostico de Recursos

| Recurso | Actual | +3m | +6m | +12m | Primero en Alcanzar Limite? |
|---------|--------|-----|-----|------|-----------------------------|
| CPU | ______ | ______ | ______ | ______ | Si / No |
| Memoria | ______ | ______ | ______ | ______ | Si / No |
| I/O disco | ______ | ______ | ______ | ______ | Si / No |
| Red | ______ | ______ | ______ | ______ | Si / No |
| Conexiones BD | ______ | ______ | ______ | ______ | Si / No |
| Almacenamiento | ______ | ______ | ______ | ______ | Si / No |

## 5. Plan de Escalado

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

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

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

## 6. Proyeccion de Costos

| Escenario | Costo Mensual | Costo Anual | Notas |
|-----------|---------------|-------------|-------|
| No hacer nada | ______ | ______ | Riesgo de interrupcion |
| Minimo viable | ______ | ______ | Justo por delante de la demanda |
| Margen comodo | ______ | ______ | Buffer del 30-40% |

## 7. Evaluacion de Riesgos

| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Crecimiento excede pronostico | ______ | ______ | ______ |
| Limites del proveedor cloud | ______ | ______ | ______ |
| Escalado toma mas de lo esperado | ______ | ______ | ______ |
| Presupuesto no aprobado | ______ | ______ | ______ |

## 8. Acciones Pendientes

| Tarea | Responsable | Fecha Limite | Estado |
|-------|-------------|--------------|--------|
| ______ | ______ | ______ | ______ |

## 9. Apendice

- Links a dashboards: ______
- Datos historicos de incidentes: ______
- ADRs o documentos de diseno relacionados: ______

Explicacion

La plantilla separa la medicion (estado actual) de la prediccion (suposiciones de crecimiento y proyecciones de trafico) de la decision (plan de escalado y proyeccion de costos). La tabla de pronostico de recursos resalta cual recurso alcanzara su limite primero — este es el cuello de botella que determina tu linea de tiempo de escalado. La proyeccion de costos enmarca el plan tecnico en terminos de negocio, facilitando la obtencion de presupuesto.

Ejemplo de Dashboard de Forecast de Capacidad

=== Dashboard de Forecast de Capacidad — Q3 2026 ===

ESTADO ACTUAL (al 2026-07-11):
  Utilizacion CPU (prom):    42%
  Utilizacion CPU (pico):    68%
  Utilizacion Memoria (prom): 55%
  Utilizacion Memoria (pico): 78%
  Uso de disco:              3.2 TB / 5 TB (64%)
  Throughput de red (prom):  120 Mbps
  Throughput de red (pico):  450 Mbps
  Conexiones DB (prom):      45 / 100
  Conexiones DB (pico):      82 / 100

SUPUESTOS DE CRECIMIENTO:
  Tasa de crecimiento de usuarios:  8% / mes (basado en ultimos 6 meses)
  Tasa de crecimiento de trafico:   12% / mes (trafico crece mas rapido que usuarios)
  Tasa de crecimiento de datos:     50 GB / mes
  Factor de pico estacional:        2.5x (Black Friday, temporada navidena)

PROYECCION A 6 MESES:
  Mes      | CPU Pico | Mem Pico | Disco   | DB Conn 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!)

BOTTLENECK: Conexiones de DB alcanzan limite en Octubre 2026
ACCION: Aumentar pool de conexiones a 200 para Septiembre 2026

BOTTLENECK: Disco alcanza limite de 5 TB en Noviembre 2026
ACCION: Agregar 3 TB de almacenamiento para Octubre 2026

BOTTLENECK: CPU alcanza 90% en Noviembre 2026 (pico estacional)
ACCION: Agregar 4 instancias al auto-scaling group para Octubre 2026

Variantes

Contexto	Ajustes	Notas
Especifico para bases de datos	Agrega throughput de consultas, crecimiento de indices, lag de replicacion y limites del pool de conexiones	Las bases de datos alcanzan limites de forma diferente al computo
Sistemas con uso intensivo de almacenamiento	Agrega politicas de retencion de datos, planes de compresion y costos de almacenamiento por niveles	El almacenamiento crece predeciblemente pero es costoso
Basados en eventos / colas	Agrega throughput por shard, lag del consumidor y crecimiento de la cola de mensajes muertos	Las colas ocultan la presion hasta que se desbordan
Multi-region	Agrega ancho de banda de replicacion entre regiones y capacidad por region	Cada region puede tener un crecimiento diferente
Serverless	Agrega conteo de invocaciones, limites de concurrencia y frecuencia de cold starts	Los limites serverless son diferentes a los de instancias

Lo que funciona

1. Pronostica mensualmente, revisa trimestralmente — las suposiciones cambian; actualiza el pronostico antes de que se convierta en ficcion
2. Usa percentiles, no promedios — la latencia p99 y el pico de CPU importan mas que los valores medios
3. Incluye un escenario de “no hacer nada” — hace explicito el costo de la inaccion
4. Prueba tu plan de escalado — ejecuta una prueba de carga que simule tu proyeccion a 6 meses antes de necesitarlo
5. Comparte el pronostico ampliamente — producto, finanzas e ingenieria deben ver los mismos numeros

Errores Comunes

1. Planificar basado en promedios — un sistema al 50% de CPU promedio puede estar al 95% durante las horas pico
2. Ignorar la base de datos — el computo escala horizontalmente; las bases de datos a menudo no
3. Olvidar los servicios downstream — escalar tu API no sirve si tu cache o base de datos no pueden seguir
4. Sin niveles de confianza en las suposiciones — las campanas de marketing fracasan; construye escenarios para crecimiento alto, medio y bajo
5. Esperar hasta el 90% de utilizacion — para entonces ya estas en modo emergencia; planifica al 70%

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de capacity-planning y forecasting para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de pronostico de planificacion de capacidad cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Troubleshooting

• Instance is unreachable: check security groups, routes, DNS, and health status in the provider console. Verify that the OS firewall is not blocking the port.
• Provisioning fails consistently: inspect the init script, IAM roles, and image availability. A missing permission is the most common root cause.
• Resource exhaustion alerts: correlate CPU, memory, disk, and network metrics.
• Backup restore does not work: test restores regularly. A backup that cannot be restored is not a backup.
• Configuration drift: Recreate from the canonical definition when in doubt.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.