FinOps es uno de esos términos que significan cosas muy distintas según el tamaño de la empresa. Para una Fortune 500, es una práctica de 30 personas con un CFO como patrocinador, un presupuesto de herramientas mayor que tu nómina, y comités directivos trimestrales. Para tu SaaS de 30 personas, se reduce más o menos a: "¿por qué la factura de AWS es un 27 % más alta que el trimestre pasado, y de quién es el trabajo de averiguarlo?" Este artículo es para el segundo grupo.

Primero, la buena noticia: el desperdicio cloud es aburrido. La inmensa mayoría proviene de los mismos cinco patrones, en cualquier empresa, a cualquier escala. Cómputo inactivo que nadie apagó. Instancias sobredimensionadas aprovisionadas para un pico que nunca volvió a repetirse. Recursos sin etiquetar que nadie puede atribuir, así que nadie se siente responsable. Entornos de desarrollo y staging olvidados, funcionando las 24 horas para un software que se despliega dos veces al mes. Y almacenamiento en niveles premium años después de que alguien lo leyera por última vez. Ninguno de estos problemas requiere una certificación de la FinOps Foundation para solucionarse. Todos requieren que alguien realmente se ponga a mirar.

El patrón que vemos con más frecuencia merece su propio párrafo. Un desarrollador levanta una c5.4xlarge para una prueba de carga el jueves. La prueba termina el viernes a las 16:00. La instancia sigue funcionando todo el fin de semana, porque apagarla es un paso manual en una consola que nadie abre en sábado. Para el standup del lunes, el equipo ha quemado 180 € en una máquina inactiva - no por incompetencia, sino porque el comportamiento por defecto del sistema es "seguir facturando". Multiplícalo por cada equipo, cada fin de semana, cada experimento olvidado, y tienes un porcentaje significativo de tu presupuesto de infraestructura haciendo exactamente nada.

¿Por qué los dashboards no arreglan esto? Porque la visibilidad nunca fue el cuello de botella - tu proveedor cloud ya tiene un cost explorer, y tú ya no lo abres. Un dashboard te dice lo que pasó después de que el dinero haya volado, en un sitio que tienes que acordarte de visitar, en un formato que exige veinte minutos de filtrado antes de decir algo accionable. Entre "el dato existe" y "alguien actuó en consecuencia" se encuentra toda la disciplina real de FinOps, y es exactamente la parte para la que un equipo pequeño no tiene capacidad de sobra.

También hay un problema estructural que los dashboards no pueden resolver: la fragmentación multi-cloud. En el momento en que ejecutas AWS para el producto, Hetzner para cargas de trabajo por lotes, y un proyecto suelto de DigitalOcean que alguien empezó en 2024, "cuánto gastamos" deja de tener una única respuesta. Cada proveedor exporta los costes en su propio formato, en su propio calendario, con su propia idea de lo que es un proyecto. La mayoría de los equipos pequeños responden vigilando de cerca la factura grande y dejando que las pequeñas se les vayan de las manos - así es como una fuga de 400 €/mes sobrevive dos años.

Entonces, ¿qué aspecto tiene realmente FinOps para un equipo sin equipo de FinOps? Según nuestra experiencia, cuatro hábitos cubren la mayor parte del valor. Uno: una única fuente de verdad para el gasto en todos los proveedores, desglosada por servicio, proyecto y entorno - no porque los dashboards arreglen las cosas, sino porque las discusiones sobre atribución mueren cuando todo el mundo ve las mismas cifras. Dos: detección de anomalías más inteligente que un umbral fijo - las facturas cloud son ruidosas por naturaleza, y un "avísame si supera X €" estático o salta constantemente o nunca salta; señalar desviaciones genuinas respecto a tu propia línea base es trabajo para ML, no para un cron job y la esperanza. Tres: recomendaciones de right-sizing con periodicidad - una lista mensual de "estas doce instancias están sobredimensionadas, este es el tamaño más pequeño seguro, este es el ahorro" que alguien revisa en quince minutos. Cuatro: alertas de presupuesto que escalan - un aviso discreto al ingeniero al 80 %, uno más ruidoso al líder de equipo al 100 %, porque un presupuesto del que nadie es responsable es solo un deseo.

Fíjate en lo que tienen en común los cuatro: acortan el ciclo entre la percepción y la acción. Ese es todo el juego. No más datos - menos distancia entre "el sistema lo detectó" y "una persona decidió". Un equipo pequeño no necesita una práctica de FinOps; necesita los veinte minutos a la semana en los que las decisiones de coste están bien preparadas, priorizadas de antemano, y en un solo lugar.

Eso es lo que hemos construido en Sencai: gasto por servicio, proyecto y entorno en todos los proveedores conectados; anomalías de coste señaladas por ML; recomendaciones de right-sizing programadas; alertas de presupuesto que escalan. El ciclo de percepción a acción, comprimido para caber dentro de un standup. Y el siguiente paso en la hoja de ruta - Autopilot - consiste en cerrar ese ciclo por completo para los casos aburridos: detener automáticamente según calendario los recursos de desarrollo etiquetados, ejecutar el right-sizing aprobado durante ventanas de mantenimiento. El criterio sigue siendo tuyo; pulsar el botón no debería tener que serlo.

Si quieres saber dónde estás hoy, aquí tienes un ejercicio de quince minutos: descarga la factura del mes pasado de cada proveedor que uses - incluidos los que habías olvidado. Ordénala por servicio. Marca todo lo que no puedas atribuir a una funcionalidad de producto en producción en menos de diez segundos. En la mayoría de las empresas, eso marcado es el 25-35 % del total. Eso no es un problema de presupuestación. Es simplemente entropía - y la entropía es muy, muy solucionable.