Planificación de la capacidad

1) ¿Qué es la planificación de la capacidad y por qué se necesita

La planificación de la capacidad (capacity planning) es un proceso sistemático para evaluar y proporcionar los recursos necesarios para alcanzar los SLO objetivo con un costo mínimo. No se trata sólo de CPU/memoria, sino también de ancho de banda de red, almacenamiento, DB/cachés, colas/bus de eventos, proveedores externos (pagos/CUS/antifraude) y recursos humanos (on-call, soporte).

• Realizar SLO/SLA incluso en picos y degradaciones.
• Minimizar el TCO y el capital simple (sobrevisionamiento).
• Reducir el riesgo de incidentes por agotamiento de recursos (saturation → p99/error).
• Garantizar la previsibilidad de lanzamientos y campañas (marketing, torneos, partidos de primer nivel).

2) Entradas y fuentes de la verdad

Observabilidad: RPS/concarrencia, p50/p95/p99, error-rate, saturación (CPU, nat, disk IOPS, red pps/mbps), longitud de cola, rate de límites.
Eventos empresariales: calendarios de campaña, estacionalidad (noches/fines de semana/mega eventos), regiones/jurisdicciones.
Tejdolg/fichi: lanzamientos de roadmap, cambios arquitectónicos (por ejemplo, cifrado, nueva lógica).
Proveedores: cuotas y throughput de pago/CUS/servicios postales/antifraude.
Incidentes del pasado: dónde está el cuello de botella (DB, caché, balanceador L7, bus, CDN, disco).

3) Conceptos y fórmulas básicos

Headroom - stock por capacidad: 'headroom = (max _ sostenible _ RPS − real _ RPS )/max _ sostenible _ RPS'.
Valor objetivo en el pico 20-40% (para subprocesos críticos).
Saturation es la relación entre el recurso ocupado y el disponible (CPU%, memoria/GC, conexiones, descriptores de archivos, IOPS, profundidad de cola).
Throughput constante es la velocidad a la que p99 y error-rate ejecutan SLO durante mucho tiempo (no una sola ráfaga).
Capacity Unit (CU) es una unidad de potencia normalizada para el servicio (por ejemplo, X RPS por pod vCPU = 1, RAM = 2 GiB).
El límite del sistema es max sin degradación: 'N _ pods × CU'. Es importante tener en cuenta las dependencias compartidas (DB/caché/bus).

4) Modelo de demanda: predicción

Series estadísticas: estacionalidad semanal/diaria, vacaciones, finales deportivas, picos regionales.
Cohortes: por país, proveedores de pago, dispositivos, segmentos VIP.
Delta de eventos: impacto de campañas/cañones/lanzamientos/SEO.
«¿Y si» (planificación scenario): + 50% al tráfico a las 19: 00-22: 00; la caída del proveedor A → una redistribución a B (+ 30% a la latencia).
Ajustes en tiempo real: nowcasting por lid métricas (revitalización de sesiones, cola de partidos, canastas).

5) Modelo de propuesta: donde se «rompe» la cadena

La cadena de la interpelación: Edge/CDN → L7-balansirovschik → la aplicación → kesh → BD → exterior API → el turno/neumático → los elaboradores/ETL.

• Capacidad (CU/instance), escalabilidad (horizonte ./vértice.) , límites (connects, pps, IOPS), retrasos.
• Directivas de falla (rate limit, circuit breaker, degradación).
• SLO local y su contribución a la e2e-SLO.

6) Inventario y presupuesto de errores

Vinculamos la sala de cabecera al error budget: menos presupuesto → más stock.
Para los hilos críticos (pago/verificación) - headroom arriba, para los hilos menores - abajo.
Reservas frías/cálidas: activables en caso de pico/accidente.

7) Escala: táctica

HPA (por métricas de carga): RPS, latencia, longitud de cola, SLIs personalizados (mejor que CPU%).
VPA: ajuste de recursos de podam (más cuidadosamente con stateful y p99 GC).
KEDA/adaptadores: escala por fuentes externas (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/calentamiento: instancias preestablecidas para evitar un inicio frío.
El acceso "Load-as-Code": los políticos avtoskeyla/limitov/taymautov/retraev versioniruyutsya pasan review.

8) Colas, backpressure y control de cola

El objetivo es evitar que el p99 crezca en forma de avalancha.
Limitamos el paralelismo y el tamaño de la cola, introducimos ventanas temporales y la idempotencia.
Hedging/Retry-budget: limitar el presupuesto total del tiempo de uso y del sistema.
Degradación Graceful: desactivación de fichas secundarias en caso de sobrecarga.

9) DB, cachés y almacenamiento

DB: límite de connects, registro/FSync, índices, plan de consulta, replica lag, hot-keys/table, max TPS para transacciones.
Cachés: hit-ratio por segmentos, «tormenta de errores» en liberación/discapacidad, distribución de claves.
Storage: IOPS/throughput, latencia, compresión, TTL, limpieza de lotes/snapshots antiguos.
Esquema de migración: expand→migrate→contract sin bloqueos de detención.

10) Flujos de eventos y ETL

Kafka/bus: ancho de banda de lotes, log, ISR, compactación, límites de productores/consumidores.
ETL/batches: ventanas de inicio, presupuestos de tiempo de ejecución, impacto en la puerta de entrada (throttle I/O).
Idempotencia y exactly-once-like para flows críticos (pagos/balances).

11) Red y perímetro

L4/L7 equilibradores: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: ancho de banda, política de caché para reducir la carga de origen.
Límites de red: pps/mbps en VPC/subred, costo de egresos (FinOps).

12) Multirregión, DR y jurisdicciones

Estrategias: active-active (GSLB/Anycast), active-passive (DR caliente/caliente/frío).
N + 1 por región: soportar la pérdida de AZ/región mientras se mantienen los flujos de núcleo SLO.
Localización legal: separación de tráfico/datos por país, diferentes límites y SLO en proveedores.
Pruebas DR: días de juego regulares con transferencia de carga real.

13) Proveedores externos: cuotas y rutas

Pagos/KYC/antifraude/correo/SMS: cuotas TPS, burst, límites diarios.
Multi-proveedor: enrutamiento por latencia/éxito, proveedor de SLO per, auto-failover.
Contratos SLA: cumplimiento de e2e-SLO, canales de escalamiento, status-webhooks.

14) FinOps: costo y eficiencia

TCO: compute + storage + network egress + licencias/proveedores + servicio.
Unit Economics: costo de 1k solicitudes/1 operación de depósito/1 KYC.
Optimización: right-sizing, spot/prefijos descuentos, cache-hit, dedup logs/tracks, niveles de almacenamiento en frío.
Transferencia de carga en el tiempo: batches no críticos a ventanas «nocturnas» y regiones baratas.

15) Dashboards e informes (conjunto mínimo)

• Carga actual vs constante a través de los enlaces.
• Headroom por servicios y regiones; pronóstico de 24/72 horas.
• KPI FinOps: $/1k solicitudes, $/depósito.

• Los principales cuellos de botella (p99, saturation, lag), stock por DR.

• Éxito/latencia y límites de proveedores; una proporción del tráfico a lo largo de las rutas.

• Plan de upgrades/índices/optimizaciones, ahorros/aumentos de capacidad esperados.

16) Procesos y roles

RACI: Plataforma (infra/clúster/balanceadores), DAB/Datos (índices, replicaciones), Comandos de servicio (perfiles/caché), SRE (SLO, alertas), Sec/Compliance (cripto/revistas), Finanzas (presupuesto).
Ritmo: semanal capacity-review (hoja de ruta, pronóstico, riesgos), resúmenes mensuales de FinOps, pruebas trimestrales de DR.
Gestión de cambios: grandes campañas/lanzamientos pasan por capacity-gate (lista de verificación abajo).

17) Lista de verificación de liberación y campañas (capacity-gate)

• Pronóstico de carga pico y «+ x% cola de emergencia».
• headroom disponible para flujos de núcleo (pagos/CUS/inicio de sesión).
• Se han confirmado cuotas a los proveedores; rutas alternativas están activas.
• Los umbrales HPA/KEDA y warm-pool están configurados.
• Colas/límites y degradaciones verificadas (listas de reproducción listas).
• Se incluyen las acciones canarias y el auto-retroceso.
• Se verifican los dashboards/alertas (burn-rate, saturation, p99).
• El plan de DR y los contactos de escalamiento son relevantes.

18) Anti-patrones

«CPU <70% - todo está bien»: ignorar los límites de dependencia (connects BD, IOPS, colas).
Una «caja negra» centralizada sin métricas por enlace es imposible entender dónde está el límite.
Falta de estrategia de caché: los errores de lanzamiento matan al origin.
El hardcod de los límites de retrayas sin presupuestos es una tormenta de peticiones.
«Un proveedor de pagos» - punto de falla en el pico.
Ignorar las reservas cálidas es un comienzo frío como causa de incidentes.
No hay pruebas periódicas de RD: el plan no funciona cuando se necesita.

19) Mini-cálculos (ejemplo)

Servicio X: constante 350 RPS por pod (vCPU = 1, RAM = 2 GiB). El objetivo es 5.000 RPS, un 25% de sala de cabecera.
La potencia deseada = '5000/0. 75 = 6667 RPS`.
Podov = 'ceil (6667/350) = 20'. Además de warm-pool 15% → otros 3 pod.
BD: límite de 12k TPS, crédito actual 9k TPS, pronóstico pico 10. 5k TPS → stock 1. 5k (14%). Requiere: índices/sharding/réplicas o almacenamiento en caché para reducir a 8. 5k.
Proveedor A (KYC): cuota 120 rps, pico 95 rps, campaña + 40% → 133 rps> cuotas → enrutamiento 70% A/30% B.

20) Plantilla de implementación de planificación de capacidad

1. Describir la ruta e2e y los cuellos de botella.
2. Introduzca CU y mida el throughput estable de cada capa.
3. Configurar métricas de saturación y p99 en todos los eslabones.
4. Generar un calendario de eventos/campañas/lanzamientos.
5. Construir una predicción para las cohortes y el escenario «que si».
6. Anclar el headroom per-stream y per-region (ajuste a error budget).
7. Configurar HPA/VPA/KEDA + warm-pools, límites/retrés/colas.
8. Compruebe las cuotas de los proveedores, habilite las rutas múltiples.
9. Recoge los dashboards y el ritmo semanal capacity-review.
10. Trimestralmente - Ejercicios de RD y revisión del modelo.

21) Resultado

La planificación de la capacidad es un conjunto manejable de predicciones, limitaciones arquitectónicas y costos, en lugar de «agregar CPU». Cuando cada capa de la ruta e2e tiene una capacidad medida y las estrategias de headroom y degradación están relacionadas con SLO y error budget, entonces las cargas máximas, campañas y accidentes dejan de ser una sorpresa. Este enfoque reduce el riesgo de incidentes, estabiliza las métricas del negocio y optimiza los costos.