Asignación de recursos

1) Tarea y principios

La asignación de recursos es una forma sistémica de combinar la demanda (carga, proyectos, incidentes) con la oferta (CPU/RAM/IO/red, licencias, personas, presupuestos) bajo SLOs de destino y restricciones de FinOps.

• SLO-first: el recurso tiene un objetivo de calidad; selección - herramienta para soportarlo.
• Fairness + Priority: una participación justa para todos, pero prioritaria - garantías.
• Isolation: limitamos el blast-radius a cargas «voraces».
• Elasticidad: expansión/compresión automática bajo demanda real.
• Costo-aware: cada recurso adicional debe tener un efecto comprensible en los SLO/ingresos.
• Evidence-based: soluciones validadas por telemetría y experimentos.

2) Taxonomía de los recursos

Cálculos: CPU/Memoria/GPU, grupos de contenedores, cuotas sin servidor.
Almacenamiento: IOPS/ancho de banda, capas calientes/cálidas/frías, caché.
Red: egress/ingress, CDN, canales privados, grupos IP.
Datos: ranuras/recursos de ventanas en DWH/streaming, ventanas de fondo.
Personas: ranuras on-call, IC/Release, tiempo SRE/Dev (reloj/sprint).
Vendedores: límites de proveedores (PSP/KYC/CDN), rate-limits y connects.

3) Modelo de priorización (cartera)

Tier-0: flow vital (inicio de sesión, pagos). Recursos garantizados, grupos separados.
Tier-1: crítico con el negocio (producto Core, informes D-1). Cuotas preferidas.
Tier-2/3: apoyo/investigación. Burstable, límites presupuestarios.
Proyectos: Evaluación de Impact × Urgency × Confidence × Costo → rango; Armonización en el SAV/cartera.

4) Políticas de distribución (garantías, cuotas, límites)

Guaranteed (dedicado): fracción de fix/reserva; para Tier-0/1.
Burstable: cuota básica + derecho a ocupar libre hasta el límite.
Mejor efecto: sin garantías, se puede desplazar.
Quota/Limit-as-Code: todas las cuotas y límites se describen declarativamente (repositorio de políticas).
Preemption/Pod Disruption Budget: a quién se puede desplazar y a qué velocidad.
Cuotas de red: egress/tenant, límites de conexiones a proveedores.

5) Multiotenancia y aislamiento

Namespace/Account per tenant: límites individuales, presupuesto, auditoría.
Vecinos ruidosos: cgroups/requests/limits/IO-throttling; nodos individuales para tareas «pesadas».
Aislamiento P95: SLO se calcula por percentilo, no por medio; burst no debe romper p95 vecinos.
Datos tenancy: grupos separados de capas de almacenamiento y caché para VIP/regiones.

6) Auto-escalabilidad y elasticidad

HPA/VPA/Cluster-autoscaler: escala por proxy SLI/SLI (latency p95, queue depth), no sólo CPU.
Escala Scheduled: de antemano debajo de las ventanas/eventos pico.
Warm pools: nodos/conexiones calientes para skalaps rápidos.
Red/CDN: reequilibrio automático por carga RUM/Anycast/POP.

7) Colas, clases de servicios y SLA

Clases: 'gold/silver/bronze' con tiempo de espera objetivo y presupuesto de error.
Colas/bus: priorización, lotes individuales para Tier-0, DLQ.
Backpressure: las disciplinas drop/shape/slow para proteger el núcleo.
Temporizadores adaptativos/retraídos: bajo la clase de servicio y el estado actual.

8) Recursos humanos

Turnos y cobertura: coincidencia de tráfico (follow-the-sun), toma de P1 + P2 en su punto máximo.
Enfoque SRE/Dev: porcentaje de tiempo por reactivo/activo (por ejemplo, 50/50) con KPI.
Solicitud de recursos: plantillas RFC por reloj/sprint, cola de prioridad transparente.

9) Modelo financiero (FinOps)

Unit-economy: $/1k solicitudes, $/pago exitoso, $/GiB registros.
Presupuestos y alertas: cuotas por cuentas/tenantes, advertencias de sobrecostos.
Optimización: almacenamiento caliente/caliente/frío, registro-sampling, pools spot para no-critical.
Showback/Chargeback: los informes de costos por equipo/tenant motivan la eficiencia.

10) Gestión de proveedores

Límites y ventanas: TPS contractuales y colas en PSP/KYC/CDN; ventanas programadas en el calendario.
Perfiles falleros: pesos y enrutamiento entre múltiples proveedores.
Métricas de pulso: tiempo de respuesta, tolerancia a fallas, costo/operación exitosa.

11) Métricas de la madurez de la distribución

SLO Adherence por clase:% de cumplimiento en oro/plata/bronce.
Eficacia de recursos: eliminación de CPU/RAM/IO (mediana/p95), fracción idle.
Costo per SLO-point: cambios en los costos de retención del objetivo de SLO.
Throttling/Preemption rate: cuán a menudo y a quién expulsamos.
Hotspot MTTA: tiempo de respuesta al sobrecalentamiento de las piscinas/tenantes.
Índice Fairness: dispersión de retardos/cuotas entre los tenantes (gini/variación).

12) Hojas de cheques

Antes de cambiar la distribución

• Se definen los objetivos de SLO y la clase de servicio.
• Hay telemetría por carga (p95/p99, crecimiento, estacionalidad).
• Las cuotas/límites se describen en Git y han pasado el rugido.
• Se han comprobado los efectos en los vecinos (pruebas de aislamiento).
• El plan de reversión y guardrails están listos.

Operativa semanal

• Heatmap eliminación de agrupaciones y el informe hotspot.
• Informe FinOps: $/ed., sobrecostos, anomalías.
• Se cumplen los límites de proveedores y SLA.
• Colas: retraso dentro de las clases, sin ayuno.
• CAPA sobre los estrechos de trabajo identificados.

13) Plantillas (ideas)

13. 1 Política de cuotas (YAML)

yaml tenant: vip-eu class: gold compute:
cpu:
request: "8000m"
limit: "12000m"
memory:
request: "16Gi"
limit: "24Gi"
storage:
tier: hot iops_min: 8000 network:
egress_mbps_cap: 500 slo:
latency_p95_ms: 250 preemption:
protected: true burst:
allowed: true max_factor: 1.5

13. 2 Perfil de escala automática (fragmento)

yaml autoscaling:
metric: "queue_depth"   # или biz_sli.payment_latency_p95 target: 200 min_replicas: 6 max_replicas: 60 warm_pool: 4 cooldown_sec: 120

13. 3 Clase de servicio y cola

yaml class: gold sla:
wait_p95_ms: 150 queue:
partition: "gold-eu"
retry_policy:
attempts: 2 backoff_ms: 200 backpressure: "shape" # иначе drop/slow

13. 4 Solicitud de recursos (personas)

RFC: RES-OPS-2025-11
Цель: усилить on-call P2 на пике ноябрьских промо (EU)
Период: 2025-11-25..2025-12-05
Обоснование: прогноз трафика +30%, прошлогодний p95 MTTA ↑
Запрос: +1 P2 слот/сутки, +IC в prime-time

14) Procedimientos y automatización

Planner-bot: cálculo de cuotas a partir del historial de tráfico y los objetivos de SLO, PR al repositorio de políticas.
Guardrails-bot: señal de parada a los deployas cuando hay escasez de cuota/oversubscription.
Comms-bot: notificaciones a los equipos de sobrecostos/desplazamientos/cambios de clase.
Anotaciones: las versiones/ventanas de mantenimiento cambian los pesos/cuotas por el tiempo de trabajo (suppression suppression después).

15) Anti-patrones

Destacar «por sensaciones», sin SLO y telemetría.
Una gran piscina para todos sin aislar a los «vecinos ruidosos».
Un burst incontrolable sin límite superior → el «soplo» de los vecinos.
Sin backpressure/colas → bola de nieve de temporizadores.
Ignorar el costo de los registros/egresos es una fuga de presupuesto «silenciosa».
Cuotas fijas sin estacionalidad/picos → inaccesibilidad o sobrecostos.

16) Hoja de ruta para la implementación (4-8 semanas)

1. Ned. 1-2: inventario de recursos y servicios; asignación de clases (oro/plata/bronce); cuotas primarias; SLO básicos.
2. Ned. 3-4: habilitar la escalación automática por proxy SLI; configurar colas y backpressure; aislar Tier-0 grupos.
3. Ned. 5-6: Informes de FinOps ($/ed., cuotas, alertas del presupuesto); warm-pools y patines pintados durante los días pico.
4. Ned. 7-8: automatización de Planner/Guardrails, gabinete de tenant (visibilidad de cuotas/valor), review trimestral fairness & hotspots.

17) Resultado

La asignación de recursos no es una configuración única, sino un proceso en vivo integrado en SLO, telemetría y FinOps. Cuando se formalizan las prioridades, las cuotas y los límites -como el código, el aislamiento y la elasticidad- por defecto, y las soluciones se confirman con métricas y costes, el sistema sobrevive a picos estables, protege flows críticos y no «quita» el presupuesto.