FinOps para equipos chicos: el proceso que sobrevive a un martes

El FinOps de la nota anterior asume algo que un equipo chico no tiene: alguien con tiempo para mirar dashboards. Un equipo de cinco personas no va a correr queries de Athena los viernes a la tarde. Lo va a hacer una vez cuando llega la factura sorpresa, va a encontrar la fuga, la va a apagar y no va a volver a mirar nada por cuatro meses. Hasta la próxima sorpresa.

Ese ciclo es el problema real de un equipo chico: no les falta visibilidad, les falta ritmo. Y el ritmo no se consigue con disciplina ni con recordatorios. Se consigue con una decisión que casi nadie toma en empresas chicas: poner a alguien a cargo del número, aunque sea compartido.

Este artículo es esa versión mínima: qué papel escribir, qué automatizar esta semana y qué no hacer nunca. Está escrito para equipos de 2 a 15 personas con factura de cientos a pocos miles de dólares — donde FinOps de empresa es matar una mosca con un cañón, pero no mirar nada cuesta reintegros de cuatro dígitos.

01 · El rol que en realidad es una línea de texto

El error más común en equipos chicos no es técnico: es que el gasto de nube no tiene dueño. La factura llega al mail del que registró la cuenta hace tres años, nadie la abre, y cuando alguien pregunta «¿cuánto gastamos?» la respuesta es abrir tres consolas.

La corrección es mínima y cabe en el README del equipo:

Quién paga: [nombre]. Su trabajo mensual: abrir la factura, comparar contra el mes anterior por servicio y marcar cualquier línea que creció más del 20% sin que se sepa por qué. No optimiza. Pregunta.

Dos detalles que importan más de lo que parece:

• El dueño pregunta, no arregla. La tentación en un equipo chico es que la misma persona optimice — y a las tres semanas es trabajo de nadie. El dueño solo tiene que detectar y preguntarle al responsable del servicio: «¿esto creció de propósito?». La corrección la hace el dueño del recurso, que es el que sabe.
• Se rota cada seis meses. No por cansancio: porque cada rotación deja a una persona más que entiende la factura. En un equipo de cinco, tener a dos que leen el costo de la infraestructura cambia decisiones de arquitectura antes de que lleguen a producción.

En teams de una sola persona (freelance, proyectos propios), el rol existe igual: el dueño sos vos y la revisión es un evento del calendario de 15 minutos, primer lunes de mes. No es idealismo: es la diferencia entre detectar una fuga a los 30 días o a los 120.

02 · Un script que pregunta por vos

El dashboard de costos tiene un problema de física: hay que abrirlo. En un equipo chico, lo que funciona es lo inverso — el costo te busca a vos.

La versión más barata de esto es un script que corre una vez por semana y publica un mensaje corto donde el equipo ya vive (Slack, Discord). Preguntas que vale la pena automatizar:

1. Total del mes proyectado y comparación contra el mes anterior, por servicio.
2. Cualquier línea que creció más del 20% semana a semana.
3. Recursos sin etiqueta desde hace más de 7 días.
4. Los tres servicios que más crecieron y los tres que más cayeron (los que cayeron son fugas apagadas o algo que se rompió — ambas cosas valen mirar).

Ejemplo de salida — el formato importa más que la técnica. Un team no lee una tabla de 40 líneas; lee cinco:

📊 Nube, semana 42 · proyectado $1.840 (mes anterior: $1.610) ⚠️ RDS creció 24% ($340 → $422) — snapshot por las dudas? preguntó @juán ✅ Etiquetas: 100% 📉 Fugas apagadas: 2 ($38/mes recuperados) Última revisión: hace 6 días · dueño: @maría

Ese mensaje, una vez por semana, es el 80% del FinOps de un equipo chico. Las alertas nativas cubren el resto (anomalías fuera del patrón, presupuestos).

03 · Alertas que valen (y las que no)

Las alertas nativas de cada nube son gratis y casi nadie las configura bien. Para un equipo chico hay exactamente tres que valen:

1. Presupuesto mensual con aviso al 80% y al 110%. Es la única alerta que dice «esto se va de madre» sin juicio. Monto = factura del mes estable + 20%, no el de tus deseos: una alerta que siempre dispara deja de leerse en la tercera semana.
2. Detección de anomalías (AWS lo tiene como servicio; en GCP/DO es la comparación del script). Avisa lo que ningún presupuesto anticipa — el export accidental a otra región, el disco que llenó un log.
3. Etiquetas faltantes, como parte del reporte semanal, no como alerta en el momento. Un recurso sin etiqueta es información, no emergencia.

Y las que no valen: alertas por servicio individual con umbral arbitrario. Un equipo chico termina con 15 alertas de presupuesto que nadie lee. Menos es más — el objetivo es que cada aviso produzca una pregunta, no silencio.

04 · La regla del gasto pre-aprobado

Un equipo de cinco con «consultalo antes de lanzar algo» termina en dos lugares: o la infra se congela (nadie pide nada), o la regla se ignora (todos piden todo). Lo que funciona es un número claro:

Podés lanzar cualquier cosa que sume menos de $[X]/mes sin preguntar. De $X a $[Y], preguntá en el canal de infra. Más que $[Y], se decide en planning.

Cómo calibrar los números: $X = lo que cuesta un entorno de desarrollo completo de tu servicio más pequeño (nada de lo que hacés día a día debería frenarse), $Y = lo que cuesta tu servicio de producción más grande (eso sí cambia el negocio). En la mayoría de los equipos chicos: $X entre $20 y $80, $Y entre $500 y $2.000/mes.

El punto de la regla no es ahorrar. Es que la velocidad de desarrollo no sea negociable mientras el número total sigue teniendosueño. Un equipo que puede lanzar un prototipo de $40/mes sin llamar a nadie es un equipo que explora; uno que tiene que pedir permiso para un RDS de pruebas es uno que no explora.

05 · Lo que un equipo chico puede recortar (y lo que puede recortar mal)

Casi todo lo que decía el artículo anterior sobre fugas vale acá, con una diferencia de escala: en un equipo chico, la peor fuga no es un recurso encendido — es tomar una decisión de arquitectura por miedo a la factura. Ejemplos que ves todo el tiempo:

• Elegir una base de datos más lenta pero «gratis» — y encima los dos años que el equipo tarda en migrar.
• Autogestionar Redis/Postgres en una EC2 cuando el managed cuesta $30/mes más y el tiempo del DevOps que se lo lleva es infinitamente más caro.
• No activar autoscaling porque «puede traer una sorpresa» — y pagar sobredimensionado 24/7 por miedo.

Con un dueño del número + reporte semanal, ese tipo de decisión se puede tomar con data: «sumamos $30 pero liberamos 6 horas de on-call» es un trade-off que se defiende. Sin visibilidad, la factura manda por miedo y el equipo opera más lento para siempre.

La línea que separa el buen recorte del malo: recortar desuso (entornos muertos, snapshots sobrantes, capacidad ociosa) es casi siempre gratis. Recortar redundancia (backups, réplicas, multi-AZ) en un sistema con clientes de pago es casi siempre una deuda a futuro. Un equipo chico se puede recortar en lo primero con confianza; en lo segundo, solo con un plan de contingencia escrito.

06 · Qué NO hacer con un equipo chico

• No implementes una herramienta de FinOps de empresa. Kubecost, Vantage, CloudZero: todas resuelven problemas de equipos con 50+ servicios y contadores dedicados. Con 15 servicios, un script + las alertas nativas sobra. Si en algún momento el reporte semanal deja de alcanzar, recién ahí mirá herramientas.
• No asignes el 100% del rol a una sola persona por siempre. El día que se va de vacaciones, el proceso muere. Rotá y dejá el checklist escrito.
• No intentes alojar costos por feature. En un equipo chico, la correlación feature/linea de factura es demasiado indirecta; el equipo que la necesita es el que tiene productos separados por cliente. Lo que sí funciona: costo por servicio y por entorno.
• No confundas bajar la factura con éxito. El KPI real es que ninguna línea de la factura sea una sorpresa para alguien del equipo. Una factura estable y conocida con 5% de desperdicio es más sana que una factura un 12% más baja que nadie entiende.

07 · Checklist de la primera semana

1. Elegí un dueño provisional del número (puede ser temporal, dos semanas).
2. Configurá las dos alertas: presupuesto con 80/110% y detección de anomalías. 30 minutos.
3. Escribí el script de las 4 preguntas (o la vista programada en GCP). Con la data cruda del artículo anterior, es una tarde. Sin ella, activá el export primero.
4. Escribí los números de la regla pre-aprobada ($X y $Y) y publicalos en el README.
5. Mandá el primer reporte aunque sea imperfecto — el formato mejora con uso, y el punto es empezar a tener ritmo.

El FinOps de un equipo grande es un sistema. El de un equipo chico es un hábitat: un dueño que pregunta, un script que habla una vez por semana y una regla que respeta la velocidad del equipo. Todo lo demás es decoración hasta que la factura crece.

08 · Cómo aprender FinOps sin curso

No hay carrera de FinOps y la certificación (FinOps Certified Practitioner) le apunta a quien la implementa en empresas grandes. Para alguien de un equipo chico, el aprendizaje útil tiene tres etapas y ninguna requiere pagar nada:

Etapa 1 · Los principios (una tarde). Leer los principios y las fases del FinOps Foundation — Inform, Optimize, Operate. Es el vocabulario común de toda la industria y alcanza con la introducción. Cualquier otra lectura antes de tocar una factura real es teoría sin anclaje.

Etapa 2 · Tu propia factura (2-3 semanas). Con la cuenta de la empresa (o una cuenta personal de AWS/GCP con factura mínima), activar el export de datos crudos — CUR en AWS, export a BigQuery en GCP — y responder preguntas propias en SQL: ¿cuánto costó el staging este mes? ¿qué servicio creció más? Cuando podés responder sin abrir la consola, ya sabés más que la mayoría de los equipos. DigitalOcean, con su factura de precio fijo por recurso, es el lugar más fácil para empezar: el inventario por API es el modelo de costos completo.

Etapa 3 · El proceso corre solo (mes 2+). Implementar el checklist de la sección 07 en un entorno real. A partir de ahí, los temas avanzados se cruzan cuando hacen falta, no antes: OpenCost cuando aparece Kubernetes, Infracost cuando el equipo empieza a usar infra como código, y las herramientas comerciales solo cuando el reporte semanal deja de alcanzar.

La señal de que estás avanzando no es cuánto sabés de la nube: es que las preguntas de costo que antes tomaban una tarde, ahora las respondés en una query.

Referencias