Benchmarks de servidores en la nube: identifica especificaciones infladas con pruebas forenses
Desenmascara las especificaciones infladas con benchmarks forenses y calcula la verdadera relación calidad-precio
Los benchmarks no son solo números: cruza Steal Time y tasa de prima para negarte a pagar por especificaciones infladas.
Benchmark forense: Steal Time y generaciones de CPU
Lo que más se teme al comprar un servidor en la nube no es una puntuación baja, sino una «puntuación inflada»: la ficha técnica indica EPYC 9006, pero en realidad se asigna un núcleo de generación anterior; la caché de disco muestra 1,2 GB/s, pero al hacer una prueba de esfuerzo cae a 200 MB/s. Eso es especificación inflada. Mi método: primero ejecutar un benchmark forense de 30 minutos y luego contrastar los números con la factura.
El primer corte va al Steal Time. En top, si %steal supera el 5% hay que estar alerta; por encima del 15% prácticamente significa que un vecino está devorando tu CPU. Usa vmstat 1 para muestrear de forma continua; si el steal fluctúa mucho y va acompañado de una carga alta, indica sobresuscripción grave. Estas máquinas, por muy alto que sea su benchmark, se quedan cortas en cuanto llega la carga de trabajo.
El segundo corte va a la generación de la CPU. No te fíes solo de lscpu; mira los flags avx512, sse4_2, y compara si el modelo real coincide con el declarado. Un Xeon antiguo también tiene 8 núcleos, pero su IPC está tres generaciones por detrás; la prima sobre la misma configuración debería ser al menos un 30% menor. Combinando con la tasa de sobreprecio de FinOps, pongo «puntuación declarada ÷ precio real de alquiler» en una tabla; cuánta agua de sobresuscripción contiene el precio unitario se ve de un vistazo.
Los comandos concretos están en la lista de benchmarks de CloudWorth, que puede generar un paquete de evidencias válido para presentar un ticket.
Auditoría de prima: calcula la relación calidad-precio real
Las puntuaciones de referencia son solo el comienzo; lo que realmente hay que calcular es la prima — es decir, cuánta potencia efectiva obtienes por cada yuan. No importa lo alta que sea la puntuación del servidor en la nube; si el Steal Time supera el 10% durante todo el año, significa que los vecinos están acaparando la CPU y hay una alta sospecha de sobresuscripción. Este tipo de configuración inflada es más engañosa que la falsificación de parámetros.
Mi fórmula de auditoría personal es simple:
- Potencia efectiva = puntuación de un solo núcleo × proporción de tiempo de CPU que se puede ocupar de forma estable (1 - porcentaje de steal)
- Prima = potencia efectiva ÷ precio real de renovación, no el precio promocional del primer pedido
Nota: compara el precio de renovación con el de la nube pública. Para un mismo EPYC, una generación anterior debería ser un 20% más barata que la nueva; si el modelo nuevo se vende al precio del viejo, significa que la prima tiene un problema.
En la práctica, primero haz una prueba de estrés de 30 minutos para capturar el steal:
vmstat 1 300 | awk 'NR>1{sum+=$16;n++} END{print "avg steal %:", sum/n}'Si el promedio de steal supera el 5%, empaqueta los resultados de la puntuación y las capturas de pantalla del ticket en un PDF; esto se convertirá en la cadena de evidencia para reclamaciones y reembolsos posteriores. Solo pide después de calcular la prima; así estarás pagando por la verdadera relación calidad-precio, no pagando la factura por configuraciones infladas.
Ciclo de cierre de reclamaciones: cadena de evidencia y compensación por downgrade
Si el benchmark revela problemas, no te apresures a desinstalar y reinstalar. Primero ejecuta una serie de comandos de recopilación de evidencias con marca de tiempo, como vmstat 1 30 para capturar los picos de Steal Time, luego dd repetido para medir el desplome de la caché del disco, y finalmente lscpu para registrar la generación real de la CPU. Guarda estas salidas en un PDF, con la fecha y el ID de la instancia anotados: esa es la cadena de evidencia que puedes poner delante del servicio al cliente.
Al enviar el ticket, no digas «va lento»; escribe directamente: «Steal Time superior al 30% de forma sostenida, prima de la misma configuración superior al 40% respecto al mercado, se sospecha sobreventa o reducción de especificaciones». La mayoría de los proveedores te pasarán un script de prueba para que repitas la medición. En ese caso, ejecútalo sin cambiar nada y haz una captura con los dos resultados lado a lado. Si se confirma la especificación inflada, prioriza negociar una compensación por downgrade: o un reembolso de la diferencia basado en el rendimiento real, o una actualización gratuita a una CPU de la misma generación. El caso más rentable que he visto fue cambiar los datos de Steal Time por una exención de las tarifas de tráfico durante tres años; la condición es que también cuantificaras la prima para el departamento de finanzas. La metodología FinOps es más convincente que los términos técnicos en este punto.
Conserva todos los números de ticket. Cuando la compensación se haya acreditado, vuelve a medir para confirmar que las cifras coinciden con la factura. Reclamar no es discutir, es intercambiar evidencia por una compensación equivalente.
FAQ
¿Cómo identificar especificaciones infladas en servidores en la nube?
Cruza Steal Time y la tasa de prima: no te fíes solo de las cifras de benchmarks; se necesitan pruebas forenses.
¿Qué hago si un servidor en la nube tiene benchmarks altos pero rendimiento real deficiente?
Verifica si el Steal Time es demasiado alto y compara el precio con la media de configuraciones similares; si la tasa de prima supera el 20%, desconfía de especificaciones infladas.