FinOps y gestión de presupuestos

Resumen breve

1. medimos el valor y el valor unitario (unit-economics),

2. ponemos presupuestos y guardrails,

3. prevemos la demanda y planificamos la capacidad,

4. gestionamos compras/descuentos,

5. cambiamos la arquitectura y los procesos en aras de SLO con un TCO mínimo.

Funciones y responsabilidades

Product/Business: objetivos de ingresos/MAU/LTV, límites presupuestarios.
FinOps: metodología, informes, compras, señales presupuestarias.
Ingeniería/SRE: rightsizing, skaling, caché/arquitectura, palancas operativas.
Datos/Análisis: pronóstico de carga y costos, anomalías.
Seguridad/Cumplimiento: requisitos de almacenamiento/registro/DR que afectan a TCO.

RACI: FinOps mantiene procesos e informes → los ingenieros implementan cambios económicos → el negocio aprueba presupuestos/prioridades.

Métricas y unit-economics

$/1000 RPS (o $/1k eventos/transacciones) es la métrica básica del costo del servicio.
$/ms p95 - cuánto cuesta cambiar la cola de latencia (importante para la conversión).
$/MAU, $/depósito, $/jugador/mes - unidades de negocio.
TCO = compute + storage + network egress + managed-services + licencias + mano de obra.
Costa Coverage Ratio: una fracción del consumo «cerrado» on-demand con planes commit.

Ejemplo: el servicio da 60k RPS a $120/h → $2/1000 RPS· h. Cualquier optimización se compara con esta referencia.

Etiqueta y transparencia

Etiquetas obligatorias: 'env', 'product', 'service', 'owner', 'region', 'tier', 'cost-center'.
Sin etiquetas - los recursos no creamos ni renovamos.

Showback/Chargeback: informes semanales de comandos/productos vinculados a métricas unitarias.
Anomalías: delta diario> X% y recursos «mudos» (0 RPS, hay costo).

Presupuestos, guardrails y alertas

Presupuesto mensual por servicio/producto + soft/hard guardrails.

• día burn-rate> plan de × (días por mes/días restantes),
• egress/logs-ingest> umbral,
• spot-desplazamiento> N% del tiempo,
• crecimiento de los recursos «de nadie».
• Políticas: prohibición de recursos sin etiquetas, auto-TTL de staging, límites por clase de almacenamiento.

Predicción de

1. Conductores: MAU, DAU, RPS a lo largo de las rutas, proporción de caché, estacionalidad/eventos.
2. Modelo: tendencia básica + estacionalidad + escenarios (base/agresivo).
3. Transferencia a dinero: perfiles de consumo por capas (edge/proxy/app/DB/lógica).
4. Establecer pasos: headroom 30% para picos, reserva en planes DR/commit.

Cost_month ≈ Σ (RPS_route × $/1kRPS_route × часы) + egress + storage + managed

Adquisiciones y modelos de consumo

Reserved/Savings/Committed Use (1-3 años) - Cerrar base estable (30-70% de ahorro).
Spot/Preemptible - CI/analítica/asinchron, transportadores de datos.
Mezcla: base - commit, pico - on-demand, fondo/fondo - spot.
Regla 70/20/10: 70% - commit, 20% - on-demand elasticidad, 10% - spot.

Palancas de ahorro de ingeniería (sin pérdida de SLO)

Rightsizing: punto de trabajo CPU 50-70%, recomendaciones de VPA, pequeñas instancias mejor apiladas.
Auto-scaling bajo SLO: HPA/KEDA por latency/lag/RPS, no solo por CPU.
Caché y CDN: clave de caché sin «ruido», escalera TTL, tiered-cache/origin-shield → egress↓, DB↓.
Red: Brotli/gzip, webp/avif, diff-API, keepalive, limitación de retraídas (retry-budget).
Almacenamiento: clases (caliente/caliente/frío), políticas de lifecycle, TTL para datos temporales.
Logs/métricas/tracks: sampling, tail-based, almacenamiento high-res 7-14 días.
Arquitectura: gRPC/protobaf entre servicios, batch/stream en lugar de chats, selección de DB por perfil (KV para lecturas frecuentes).

Costo de confiabilidad y DR

RTO/RPO → valor: activo-activo vs activo-pasivo, backups fríos.
Cálculo: cuánto cuesta un minuto de inactividad vs cuánto cuesta una réplica/región adicional.
Política: «pagamos por la fiabilidad si se paga con el riesgo».

Dashboards FinOps (conjunto mínimo)

1. Resumen del costo: por productos/servicios/regiones, tendencias, pronóstico antes de fin de mes.
2. Unit-economics: $/1k RPS, $/ms p95, $/MAU (por semana).
3. Egress/Storage: egress GB/$, distribución de clases de almacenamiento.
4. Logging/Observability: ingest por fuentes,% de registros útiles, costo de «colas» p99.
5. Cobertura de Commit: proporción de consumo cerrado, riesgo de subutilización.
6. Anomalies: top spikes y recursos «mudos».

Procesos y rituales

Fin de semanaOps: top 10 fugas, owner → acción → ETA.
Monthly Cost Review: hecho vs presupuesto, eficiencia de compras, revisión de commits.
Revisión previa al evento: plan de picos (min-réplicas, grupos warm, caché, límites PSP).
Blameless post-mar por incidentes de precios (fugas de registros, runaway autoscale).

Lista de comprobación de implementación

• El etiquetado es estricto, showback/chargeback por equipos.
• Las métricas unitarias están definidas ($/1k RPS, $/ms p95, $/MAU).
• Los presupuestos/guardrails/alertas están configurados.
• La previsión de costos está relacionada con la previsión de tráfico y SLO.
• Los planes comunes y la cartera spot/on-demand están equilibrados.
• Rightsizing y SLO Skaling están incluidos (HPA/KEDA/VPA/CA).
• Caché/CDN/egress optimizados, lifecycle en almacenamiento.
• Logs/métricas/tracks - sampling y TTL.
• Se fija la política de RTO/RPO y su costo.
• Las revisiones semanales y mensuales funcionan.

Errores

No unit-economics → discutimos «sobre las sensaciones».
Recursos sin etiquetas, ambientes «de nadie» viven durante meses.
Almacenar todo en una clase caliente sin lifecycle.
Los registros como «agujero negro» son 100% ingest, 5% lecturas.
Commite a «todos seguidos» → subutilización y multas.
Auto skale por CPU sin tener en cuenta latency/lag → sobrepago o rotura de SLO.
Re-lanzamiento de DR sin justificación comercial.

Minibuses

1) Auditoría rápida «de tres días» de FinOps

1. Corte de los 10 mejores servicios y egresos. 2) Incluir lifecycle en objetos «antiguos».
2. Cortar registros ruidosos/habilitar tail-based. 4) Introduzca TTL/preview.
3. Fijar $/1k RPS y objetivos en el −15 %/mes.

2) −25% egress en una semana

1. Tiered-cache + origin-shield. 2) Traducción de imágenes a webp/avif.
2. Diff-API y Brotli. 4) Reducir la tasa de retry y activar el collapsing request.

3) Ataque «runaway autoscale»

1. Aumentar la estabilidad/cooldown, minReplicas en su punto máximo.
2. Transfiera parte de los fondos a las ventanas spot y batch.
3. Calentar las imágenes (image pre-pull) y TLS/connects.

4) Uso insuficiente de commits

1. Volver a recoger el maletín, transferir la parte on-demand al commit.
2. Migrar worcloads adecuados a ARM/otro tipo.
3. Habilitar auto-parking en horas no laborables.

Ejemplos de artefactos

sql
SELECT product, service, date_trunc('week', usage_date) AS wk,
SUM(cost_usd) AS cost, SUM(rps) AS rps,
ROUND(SUM(cost_usd) / NULLIF(SUM(rps)/1000,0), 3) AS usd_per_1k_rps
FROM finops_daily
GROUP BY 1,2,3
ORDER BY 3 DESC;

rego package finops deny[msg] {
input. resource. tags. owner == ""
msg:= "resource without owner tag"
}
deny[msg] {
input. resource. env == "dev"
input. resource. ttl == ""
msg:= "dev resource without TTL"
}

Características específicas para iGaming/Fintech

Picas (partidos/torneos): elevar minReplicas/minNodes de antemano, calentar CDN/TLS/caches, rutas grises para bots; headroom puntualmente en los puntos calientes (lobby/catálogos/match fides).
Pagos/PSP: contabilización de cuotas/valor por proveedor, pool egress separado e idempotencia → menos tomas.
Antifraude/AML: comprobación de varias etapas (cheque gris barato en el borde → puntuación costosa sólo si es necesario).
Proveedores de contenido: caché CDN, límites de frecuencia de actualización, renegociación de contratos para grandes eventos.

Resultado

Un FinOps eficiente no es «reducir costos», sino controlarlos en conjunto con la velocidad del producto y el SLO.
Mantenga un costo unitario transparente, construya presupuestos y guardrails, combine compras con palancas de ingeniería, automatice ahorros y realice revisiones de costos con regularidad. Así que la plataforma seguirá siendo rápida, sostenible y rentable, incluso en picos de crecimiento.