El patrón es tan familiar que aburre. Un cambio sale el día nueve. El doce alguien ve que la gráfica de coste diario tiene una forma rara pero supone que es retraso del informe. El uno del mes siguiente llega la factura con cinco cifras de más, y dos días de forense establecen que un bucle de reintentos en un pipeline de datos lleva tres semanas releyendo los mismos objetos varios millones de veces al día.
Todo eso es evitable, y nada de eso lo evita un presupuesto.
Por qué los presupuestos y las previsiones no bastan
Un presupuesto es un umbral de alerta, no un control. No detiene el gasto, porque detener el gasto en una cuenta de nube significa apagar producción. Merece la pena ponerlos igualmente, a nivel de suscripción, proyecto o cuenta, con una alerta a un porcentaje de la previsión, porque cazan la deriva lenta. No cazan un pico, porque un pico que empieza el día tres no incumple un presupuesto mensual hasta el veinte.
Una alerta de previsión es mejor y sigue llegando tarde, porque la previsión se construye desde una tendencia y un pico tarda días en doblar la tendencia.
Lo que caza un pico es comparar hoy con lo que hoy suele parecer. Comparación con el día anterior y con el mismo día de la semana pasada, por servicio y por cuenta, con un umbral de cambio porcentual y un suelo de cambio absoluto para que no te avisen de un servicio que pasó de dos euros a ocho.
Conoce la latencia de tus datos antes de diseñar la alerta
Es la restricción que da forma a todo lo demás, y los equipos diseñan sobre una suposición equivocada.
Los datos de facturación no son en tiempo real. Según el proveedor y el servicio, los registros de uso pueden tardar horas en aparecer y un día o más en consolidarse, y algunas líneas se reconcilian todavía más tarde. Si tu detección depende de datos de facturación finales, tu tiempo mínimo de detección ya es casi un día.
Así que usa dos señales. Los datos de facturación para la exactitud y para la atribución. Y las métricas operativas como aviso temprano, porque esas sí son en tiempo real: peticiones por segundo en una API, bytes escaneados por un motor de consulta, número de nodos de un clúster, bytes de salida en una pasarela, volumen de ingesta de registro. Un clúster que duplicó su número de nodos a las 14:00 es visible a las 14:01 en Prometheus y el jueves en la factura.
El diseño práctico es una alerta sobre la métrica operativa que predice el coste, y una reconciliación diaria contra los datos de facturación para cazar lo que las métricas no cubrieron.
Los detectores nativos, y lo que se les escapa
Todos los proveedores grandes ofrecen ya detección de anomalías que aprende un patrón de gasto por servicio o cuenta y alerta ante la desviación. Actívala. Es gratis o casi, no requiere ingeniería y caza los eventos grandes y obvios.
Sus límites son consistentes entre proveedores. El modelo necesita historia, así que una cuenta nueva o un servicio nuevo producen falsos positivos durante semanas. La granularidad suele ser por servicio y por cuenta, así que el desbocado de un solo equipo dentro de una cuenta compartida puede perderse en el ruido de una factura grande. Y la detección está acotada por la latencia de facturación de arriba.
Trata el detector nativo como red de seguridad y construye tú las comprobaciones específicas de tus tres o cuatro motores de coste principales. Ahí está el dinero, y conoces su forma mejor que un modelo genérico.
Las formas que toma un pico de verdad
Casi todos los incidentes de coste que hemos investigado son uno de estos, y conocer la lista te permite escribir detección dirigida en vez de alertas genéricas de anomalía.
- Un bucle de reintentos sin espera creciente. Una dependencia que falla y un reintento agresivo convierten una operación en miles. Aparece como número de peticiones, no como algo que parezca un problema de coste.
- Una consulta sin filtro. Un trabajo programado que escanea una tabla entera en vez de una partición, en un sistema con precio por byte escaneado. Es la categoría más cara que vemos, y el mecanismo y los controles están en facturas de BigQuery que se triplican.
- Registro subido y olvidado. Registro de depuración activado durante un incidente y nunca revertido, en una plataforma con precio por gigabyte ingerido. Visto desde el lado estructural en los logs son la línea que crece.
- Un autoescalador con techo alto y mala señal. Una fuga de memoria o una cola atascada llevan el escalado al máximo y lo mantienen ahí.
- Transferencia de datos añadida por un cambio de topología. Un servicio que se movió a otra zona o región, y ahora cada llamada cruza una frontera facturada.
- Almacenamiento sin regla de ciclo de vida. Lento, no es un pico, y el mayor perdedor acumulado. El versionado sin caducidad es la causa concreta habitual.
- Credenciales filtradas usadas para minar. El caso malicioso, que se ve como la aparición súbita de instancias de cómputo grandes en regiones que no usas. Es también un incidente de seguridad, y la alerta de coste suele ser la primera detección.
- Un entorno de no producción que se quedó encendido. Un clúster de prueba de carga de un viernes por la tarde.
Una regla de detección para cada uno de estos, escrita contra la métrica operativa que lo mueve, cazará más que cualquier modelo general.
El bucle de respuesta es la parte que falta
Casi todas las organizaciones que tienen este problema sí tienen algo de alertado. Lo que no tienen es una persona.
La alerta necesita un dueño con nombre, por cuenta o por servicio, derivado de las mismas etiquetas de propiedad que hacen posible atribuir coste. Necesita un canal que alguien vigile y no un buzón. Necesita una pregunta de triaje que se pueda responder en cinco minutos: qué cambió, y podemos revertirlo. Y necesita un camino de escalado para el caso en que la respuesta sea que el gasto es legítimo y hay que actualizar la previsión.
Lleva un registro corto de incidentes de coste con causa y resolución, igual que harías con las caídas. Después de un puñado de entradas el patrón es obvio, y los patrones se repiten entre equipos.
La otra mitad del bucle es la prevención, y vive aguas arriba en el pull request. Una diferencia de coste mostrada en el momento de la revisión detiene una parte de estos antes de que existan, que es el argumento de el coste se decide en el pull request.
La atribución decide si la alerta sirve
Una alerta de anomalía que dice que la cuenta gastó más no te dice nada accionable. Una alerta que dice que un servicio concreto, en un entorno concreto, propiedad de un equipo concreto, gastó más es un ticket.
Eso exige cobertura de etiquetas, que es el mismo requisito previo que todo lo demás en esta área, y el mismo primer paso que en dónde se esconde la factura de AWS y la factura de Azure. Si una parte apreciable del coste cae en "sin etiquetar", tu detección de anomalías se resuelve como "algo, en algún sitio, costó más", y la gente deja de leerla.
Lo que se olvida
- Alerta sobre la tasa, no solo sobre el total. Un servicio que se duplicó es interesante a cualquier nivel absoluto si es un indicador adelantado.
- Silencia lo conocido. Un trabajo por lotes mensual que siempre da un pico debería excluirse, o entrena a todo el mundo a ignorar el canal.
- Los compromisos distorsionan la señal. Cuando caduca una reserva, el coste salta sin ningún cambio de uso. Modélalo para que no parezca un incidente.
- Divisa e impuestos. Los entornos multidivisa ven oscilaciones que no son uso.
- Prueba la alerta. Crea un pico pequeño a propósito en un entorno de pruebas y confirma que la alerta salta y llega a una persona. Casi nunca se prueba el alertado.
Qué hacer esta semana
Saca el coste diario por servicio de los últimos noventa días y grafícalo. Busca los escalones, no la tendencia. Cada escalón es un cambio que hizo alguien, y por cada uno pregunta si alguien se dio cuenta en su momento. El número de escalones que pasaron desapercibidos es el tamaño del hueco, y suele ser la gráfica más persuasiva que puedes poner delante de un equipo de plataforma. Construimos esta vista en la fase de costes de un proyecto cloud.