Plantilla de Planificación de Capacidad

Resumen

La planificación de capacidad responde una pregunta simple: ¿nuestros sistemas manejarán la carga que esperamos en los próximos 12-24 meses? La respuesta requiere datos, no suposiciones. Esta plantilla te ayuda a recolectar esos datos, estimar crecimiento y planificar escalado antes de que los cuellos de botella lleguen a producción — y antes de que una orden de compra de emergencia te caiga encima. Para la metodología detrás de la plantilla (matemática de pronóstico, pruebas de carga, estrategias de escalado), mira la guía de planificación de capacidad.

La plantilla recorre el ciclo completo de planificación:

1. Línea base actual de recursos — qué tienes ahora y cuánto se usa
2. Proyecciones de crecimiento — estimaciones de tráfico, datos y usuarios
3. Análisis de cuellos de botella — qué componente se romperá primero
4. Plan de escalado — qué agregar, cuándo y cuánto cuesta
5. Cronograma de revisión — cuándo revisar y ajustar

Cómo Recolectar la Línea Base

La plantilla vale lo que valen los datos que la alimentan. Extrae al menos 90 días de métricas antes de completar la sección 1 — una foto instantánea miente sobre los picos.

• Compute: kubectl top pods / aws cloudwatch get-metric-statistics por servicio, P95 y máximo, no promedios.
• Base de datos: conteo de conexiones (pg_stat_activity), almacenamiento (pg_database_size), lag de replicación y las queries top por tiempo total desde pg_stat_statements.
• Red: throughput de LB/router y requests por segundo; anotá si los picos correlacionan con deploys o cron jobs.
• Costo: gasto mensual actual por componente — lo vas a necesitar cuando el plan de escalado pida presupuesto.

Registrá de dónde salió cada número. Cuando el plan falle después — y va a fallar — querés saber qué supuesto se desvió, no mirar fijo una tabla vieja.

Una nota sobre proyecciones: nunca presentes un solo número. Modelá tres rangos — bajo (tendencia actual), base (roadmap de producto), alto (lanzamiento o burst de campaña) — y dimensioná para el caso alto en las rutas críticas. Una proyección sin rango es una suposición vestida de spreadsheet.

Plantilla

# Plan de Capacidad: [Nombre del Sistema]

## 1. Línea Base Actual (al [fecha])

### Recursos de Compute

| Servicio | Tipo de instancia | Cantidad | CPU avg | CPU pico | Memoria avg | Memoria pico | Notas |
|----------|-------------------|----------|---------|----------|-------------|--------------|-------|
| Servidores API | c6i.xlarge | 6 | 35% | 72% | 45% | 68% | Auto-scaling 4-10 |
| Workers | c6i.large | 4 | 20% | 55% | 30% | 50% | Batch processing |
| Dashboard | t3.medium | 2 | 15% | 40% | 25% | 45% | Static + SSR |

### Recursos de Base de Datos

| Cluster | Tipo | Storage usado | Storage capacity | Conexiones avg | Conexiones pico | Lag replicación |
|---------|------|---------------|------------------|----------------|-----------------|-----------------|
| Primario | r6i.2xlarge | 340 GB | 500 GB | 80 | 140 | — |
| Réplica 1 | r6i.large | 340 GB | 500 GB | 45 | 90 | < 1s |
| Réplica 2 | r6i.large | 340 GB | 500 GB | 30 | 60 | < 1s |

### Red

| Métrica | Avg actual | Pico actual | Límite | Margen |
|---------|-----------|-------------|--------|--------|
| Ancho de banda in | 120 Mbps | 280 Mbps | 1 Gbps | 72% |
| Ancho de banda out | 200 Mbps | 450 Mbps | 1 Gbps | 55% |
| Requests/seg | 8,000 | 18,000 | 25,000 | 28% |

### Crecimiento de Storage

| Dataset | Tamaño actual | Tasa de crecimiento | Proyectado en 12 meses | Política de retención |
|---------|---------------|---------------------|------------------------|----------------------|
| Datos de usuario | 12 GB | 0.5 GB/mes | 18 GB | Indefinida |
| Pedidos | 45 GB | 3 GB/mes | 81 GB | 7 años (legal) |
| Audit logs | 120 GB | 8 GB/mes | 216 GB | 90 días hot, 1 año cold |
| Media uploads | 800 GB | 40 GB/mes | 1,280 GB | Indefinida |

## 2. Proyecciones de Crecimiento

### Proyecciones de Tráfico

| Métrica | Actual (mensual) | Q+1 | Q+2 | Q+3 | Q+4 | Fuente |
|---------|-------------------|-----|-----|-----|-----|--------|
| Usuarios activos | 50,000 | 58,000 | 67,000 | 78,000 | 90,000 | Roadmap de producto |
| Requests API | 24M | 28M | 33M | 38M | 44M | 15% MoM growth |
| RPS pico | 18,000 | 21,000 | 24,000 | 28,000 | 32,000 | Load tests |
| Storage agregado | 51 GB | 52 GB | 53 GB | 54 GB | 55 GB | Tendencia lineal |

### Supuestos

- Crecimiento de usuarios: 15% mes-over-mes (basado en últimos 6 meses)
- Requests API por usuario: estable en ~480/mes
- Tráfico pico: 2.5x promedio (basado en datos de load tests)
- Campañas de marketing: lanzamiento Q3 puede causar burst 3x por 2 semanas
- No hay cambios arquitectónicos mayores planificados — si uno aparece a mitad de trimestre, la proyección se resetea

### Factores de riesgo

- **Lanzamiento Q3** — marketing espera burst 3x por 2 semanas. Planificar para 50k RPS pico.
- **Temporada navideña** — histórico 2x tráfico en noviembre-diciembre.
- **Nuevo cliente enterprise** — pipeline de ventas incluye contrato enterprise de 10k usuarios (Q2). Añadiría 20% a la base de usuarios de un día para el otro.

## 3. Análisis de Cuellos de Botella

| Componente | Límite actual | Punto de ruptura proyectado | Cuándo | Mitigación |
|------------|---------------|----------------------------|--------|------------|
| Servidores API (CPU) | 25k RPS | ~28k RPS a eficiencia actual | Q3 | Agregar 2 instancias + optimizar hot paths |
| Conexiones BD | 200 max | ~180 al pico proyectado | Q2 | Agregar réplica + connection pooling |
| Storage BD primaria | 500 GB | ~480 GB en 12 meses | Q4 | Provisionar 1 TB o particionar datos viejos |
| Ancho de banda out | 1 Gbps | ~800 Mbps al pico proyectado | Q3 | Upgrade a 2 Gbps o agregar CDN |
| Storage audit logs | 500 GB asignado | ~480 GB en 12 meses | Q4 | Mover a cold storage (S3 Glacier) |

## 4. Plan de Escalado

### Q1 (trimestre actual)

| Acción | Componente | Costo (mensual) | Justificación |
|--------|-----------|-----------------|---------------|
| Agregar 2 instancias API | Servidores API | $480 | Margen para crecimiento Q2 |
| Habilitar connection pooling | BD | $0 (config change) | Prevenir agotamiento de conexiones |
| Set up CDN para media | Red | $200 | Reducir presión de ancho de banda |

### Q2

| Acción | Componente | Costo (mensual) | Justificación |
|--------|-----------|-----------------|---------------|
| Agregar réplica 3 | BD | $320 | Tráfico de lectura del cliente enterprise |
| Upgrade ancho de banda a 2 Gbps | Red | $150 | Preparación burst de lanzamiento Q3 |
| Implementar archival de audit logs | Storage | $50 (Glacier) | Prevenir agotamiento de storage |

### Q3

| Acción | Componente | Costo (mensual) | Justificación |
|--------|-----------|-----------------|---------------|
| Agregar 4 instancias API (burst pool) | Servidores API | $960 | Lanzamiento de producto 3x tráfico |
| Agregar 2 instancias worker | Workers | $240 | Batch processing para nuevos usuarios |
| Provisionar 1 TB storage BD | BD | $200 | Crecimiento de storage + particionamiento |

### Q4

| Acción | Componente | Costo (mensual) | Justificación |
|--------|-----------|-----------------|---------------|
| Evaluar particionamiento BD | BD | Eng time | Tabla de pedidos creciendo rápido |
| Agregar CDN edge en APAC | Red | $300 | Crecimiento de usuarios en Asia |

### Aumento proyectado de costo total

| Trimestre | Costo mensual adicional |
|-----------|------------------------|
| Q1 | $680 |
| Q2 | $520 |
| Q3 | $1,400 |
| Q4 | $300 |
| **Aumento anual total** | **$2,900/mes promedio** |

## 5. Cronograma de Revisión

| Revisión | Fecha | Owner | Foco |
|----------|-------|-------|------|
| Revisión Q1 | 2026-04-01 | Platform team | Validar acciones Q1, ajustar plan Q2 |
| Revisión Q2 | 2026-07-01 | Platform team | Capacity check post-lanzamiento |
| Revisión Q3 | 2026-10-01 | Platform team | Prep navideña, ajustes Q4 |
| Revisión Q4 | 2027-01-01 | Platform team | Recap anual, plan próximo año |

Del Plan al Presupuesto

Un plan de capacidad que nadie financia es un spreadsheet. La tabla de costos de la sección 4 existe porque las decisiones de escalado compiten con cualquier otra línea del presupuesto de ingeniería — presentalas en el mismo idioma. Sumá el delta mensual por trimestre, mostrá qué se rompe si el gasto se difiere y dale a finanzas el lead time que piden (normalmente un trimestre completo para descuentos de uso comprometido).

El trade-off que vale explicitar: sobreaprovisionar rutas críticas compra confiabilidad por dólar; auto-escalar rutas variables compra eficiencia por dólar. Un plan que elige una sola estrategia para todo es o derrochador o frágil. Ruta crítica primero, elástica después — y decí cuál es cuál en el plan para que quien revisa no tenga que adivinar.

Lo que funciona

• Planifica antes del cuello de botella — La planificación de capacidad es proactiva, no reactiva. Si ya estás al 80% de utilización, llegaste tarde
• Usa datos de pruebas de carga — No adivines; ejecuta load tests para encontrar puntos de ruptura reales
• Incluye un margen de seguridad — Apunta a un margen de al menos 30-40% sobre la carga pico proyectada
• Revisa trimestralmente — Los supuestos de crecimiento cambian; revisa los planes cada trimestre, y siempre después de un lanzamiento, un onboarding grande o un evento burst que rompa una proyección
• Documenta dependencias — Un límite de réplicas de base de datos afecta la capacidad de la aplicación incluso si los servidores de app tienen CPU disponible. Consulta la Plantilla de Diagramas de Sistema para mapear dependencias.
• Modela tráfico burst — Planifica para 2-3x el pico normal durante campañas de marketing o eventos virales. Si el burst duplica tu factura por dos semanas, igual es más barato que mantener esa capacidad ociosa las otras 50 semanas.
• Considera retención de datos — El almacenamiento crece continuamente incluso si el crecimiento de usuarios es plano
• Incluye proyecciones de costo — Las decisiones de capacidad tienen impacto presupuestario; finanzas necesita tiempo y un plan sin columna de costos es una lista de deseos
• Trackea actuals vs proyecciones — Compara crecimiento predicho vs actual cada trimestre. Ajusta tu modelo. Un plan consistentemente desviado más de 20% tiene un problema de modelo, no de capacidad — encontrá qué supuesto (requests por usuario, multiplicador de burst, storage por usuario) se está desviando y corregí la entrada, no el síntoma.

Errores Comunes

• Usar carga promedio en vez de pico para planificar — los promedios ocultan los momentos que causan interrupciones
• Ignorar escalado no lineal — algunos componentes se degradan más rápido después de un umbral (ej: contención de locks en BD)
• No involucrar a finanzas temprano — las aprobaciones de presupuesto sorpresa matan los cronogramas
• Olvidar ambientes no productivos — staging y CI también necesitan capacidad
• Planificar solo compute e ignorar almacenamiento — la capacidad de disco se agota silenciosamente y mata servicios
• Asumir crecimiento lineal indefinidamente — las tasas de crecimiento cambian; revisa supuestos trimestralmente
• Ignorar límites de conexiones — bases de datos y load balancers tienen límites hard de conexiones que se alcanzan antes que CPU o memoria
• No planificar rollback — si escalas y luego el tráfico baja, ¿puedes escalar hacia abajo?

Escenario Detallado: Preparación para Lanzamiento de Producto

Sistema: Plataforma de e-commerce
Evento: Lanzamiento de producto nuevo (Q3)
Tráfico esperado: 3x pico normal durante 2 semanas

Paso 1 - Recopilar datos de línea base:
  $ kubectl top pods -n production --sort-by=cpu
  $ aws cloudwatch get-metric-statistics \
      --namespace AWS/RDS \
      --metric-name DatabaseConnections \
      --start-time 2026-06-01 --end-time 2026-06-30 \
      --period 3600 --statistics Average,Maximum

  Resultados:
  - API servers: 6 instancias, CPU pico 72%, memoria pico 68%
  - BD connections: pico 140 de 200 max (70% utilización)
  - RPS pico: 18,000 de 25,000 límite (28% margen)

Paso 2 - Proyectar carga del lanzamiento:
  - RPS pico esperado: 18,000 * 3 = 54,000
  - Conexiones BD esperadas: 140 * 3 = 420 (excede 200 max)
  - CPU API esperada: 72% * 3 = 216% (excede 100% por instancia)

Paso 3 - Identificar cuellos de botella:
  1. Conexiones BD: se agotan a 200 (crítico)
  2. CPU API: se necesita triplicar instancias o optimizar
  3. Ancho de banda: 450 Mbps * 3 = 1,350 Mbps (excede 1 Gbps)

Paso 4 - Plan de mitigación:
  - BD: agregar 2 réplicas de lectura + connection pooling (pgbouncer)
    Config: pool_mode=transaction, max_client_conn=500
  - API: agregar 12 instancias al burst pool (total 18)
    Auto-scaling: min=6, max=20, target CPU=60%
  - Red: upgrade a 2 Gbps + habilitar CDN para assets estáticos
  - Pre-warm: escalar a 18 instancias 1 hora antes del lanzamiento

Paso 5 - Pruebas de carga:
  $ k6 run --vus 500 --duration 10m launch_test.js
  $ locust -f locustfile.py --host https://staging.example.com \
      --users 1000 --spawn-rate 50

  Criterios de aceptación:
  - P99 latency < 500ms a 50k RPS
  - Error rate < 0.1%
  - BD connections < 180 con pooling
  - CPU < 70% en todas las instancias

Paso 6 - Rollback plan:
  - Si error rate > 1%: habilitar modo degradado (rate limiting)
  - Si BD connections > 190: activar circuit breaker en reads
  - Si CPU > 85% por 5 min: escalar manualmente a 24 instancias

¿Cómo calculo el margen de seguridad necesario?

Regla general: 30-40% sobre el pico proyectado. Para sistemas críticos (pagos, autenticación), apunta a 50%. El margen cubre imprevistos: picos más altos de lo esperado, degradación de performance bajo carga, y tiempo de reacción del auto-scaling. Si tu margen es menor a 20%, estás operando al límite.

¿Qué métricas debo trackear para detectar cuellos de botella temprano?

Trackea: CPU por servicio, memoria por servicio, conexiones de BD, latencia P99 por endpoint, tasa de errores, profundidad de cola de mensajes, y utilización de disco. Configura alertas en el 70% de cada límite. Si una métrica toca el 80%, ya estás en zona de riesgo.

Las menos obvias importan más: tiempo de espera del pool de conexiones, antigüedad del backlog de cola (no solo profundidad), y tasa de crecimiento de disco versus el calendario de retención. Las métricas de saturación — cuán cerca está cada recurso de su límite — predicen problemas antes que la latencia, porque la latencia solo se mueve cuando ya estás saturado.

Variantes

Cloud-native (auto-scaling)

En entornos cloud con auto-scaling, la planificación de capacidad se enfoca en setear umbrales y límites de escalado correctos en vez de pre-provisionar. Trackea: min/max de instancias, cooldown periods de escalado, y tiempo de warm-up de instancias. El riesgo es el lag de escalado — auto-scaling reacciona después de que la carga aumenta, así que igual necesitas margen.

On-premise (capacidad fija)

On-premise requiere mayores lead times para procurement de hardware (4-8 semanas). Planifica con 6 meses de anticipación. Mantén un inventario de hardware con edad y fechas de reemplazo esperadas. Las decisiones de capacidad son más difíciles de revertir — por eso el margen de sobreaprovisionamiento on-premise es más alto que en cloud (40-50% vs 30-40%) y por eso los refrescos de hardware pertenecen al plan de capacidad, no a un spreadsheet aparte.

Serverless (pay-per-use)

Serverless reduce la planificación de capacidad para compute pero introduce nuevas restricciones: latencia de cold start, límites de ejecución concurrente, y timeouts por función. Planifica para concurrencia pico (que puede tocar la quota a nivel cuenta, no la función), asignación de memoria por invocación, y costo total al volumen proyectado — serverless escala con gracia pero factura linealmente, así que la pregunta de “capacidad” se vuelve más una pregunta de pronóstico de costos que de dimensionamiento.

Híbrido

Rutas críticas on-premise por compliance o latencia, cargas elásticas en cloud. La parte difícil es la visibilidad: necesitas un solo lugar donde aparezca la utilización de ambos lados, de lo contrario cada mitad se planifica aislada y el cuello de botella cae en el enlace entre ellas.

Troubleshooting

• Las proyecciones quedan cortas siempre: las estimaciones de un punto casi siempre subestiman. Modela tres rangos (bajo/base/alto) y planifica contra el alto — la diferencia suele ser el burst de marketing que no presupuestaste.
• El auto-scaling nunca alcanza el pico: el lag de escalado es real — las instancias tardan minutos en bootear y calentar mientras el tráfico llega en segundos. Mantén el mínimo lo bastante alto para el ramp rápido y pre-calienta antes de eventos planificados.
• Un límite oculto golpea antes que el CPU: pools de conexiones, file descriptors y límites de load balancer se agotan antes que el compute. Lista cada límite duro por componente en la tabla de cuellos de botella, no solo CPU/memoria.
• El storage se llena más rápido que el forecast: los datos crecen aunque el tráfico sea plano — políticas de retención, audit logs y releases de features agregan storage por usuario. Revisa la tasa real de crecimiento mensualmente, no en la revisión anual.
• Staging colapsa bajo el load test: si staging tiene la mitad de la capacidad de producción, tus números de punto de ruptura son ficción. Iguala el dimensionamiento del path crítico o anota qué números son extrapolados.