Guía para la obtención de pruebas de sobreventa y la redacción de tickets en servidores en la nube
Fija la evidencia de sobreventa en 3 pasos; así es como se escribe un ticket efectivo
Fija la evidencia con registros a nivel de sistema + marcas de tiempo + notarización de terceros; el ticket apunta directamente a la violación del SLA.
Cómo medir la sobreventa
No te apresures a sacar conclusiones sobre el proveedor usando software de benchmark: si el proveedor te responde con un "el método de prueba no es estándar", por muy buenas que sean tus capturas, no servirán de nada. La sobreventa consiste en una asignación excesiva de recursos físicos, pero los signos se esconden en dos lugares poco llamativos: el Steal Time de la CPU y la caída brusca de la caché del disco.
Primero, haz una prueba de referencia en un momento de baja carga: usa top -d 5 para registrar el valor de steal durante 10 minutos. En un servidor en la nube normal, debería estar por debajo del 1%; si supera el 5% de forma sostenida, significa que las máquinas virtuales vecinas están ocupando tus vCPU. Para el IO de disco, no te limites a mirar los picos con fio: observa la curva de rendimiento al escribir 10 GB de forma continua. Cuando la caché del host sobrevendido se agota, los IOPS caen en picado, y esto no lo puede cambiar ningún "método de prueba".
Ejecuta la misma prueba en tres momentos diferentes (por ejemplo, fuera de las horas pico, en la hora pico nocturna y al amanecer), haz una ronda en cada uno y guarda las salidas originales. Si ni siquiera entiendes el Steal Time, puedes seguir los puntos que hemos preparado para recorrer el proceso, o ver ejemplos de diagnóstico automático en /app. Recuerda: no se trata de medir "si es lento", sino "si los recursos te los están robando los vecinos".
Cómo fijar las pruebas
El objetivo de la recopilación de pruebas no es demostrar que el rendimiento es malo, sino demostrar que los recursos comprometidos no coinciden con el SLA. Por lo tanto, cada prueba debe incluir cuatro elementos: marca de tiempo, nombre del comando o herramienta, salida original y entorno de ejecución.
Combine date -u +%FT%TZ con el comando de prueba para que el registro lleve la hora UTC; luego use script -a session.log para registrar toda la sesión de terminal y evitar sospechas de fabricación posterior. Las capturas de pantalla deben conservar la barra de título y la hora del sistema. Se recomienda grabar la pantalla con un teléfono y leer en voz alta la hora actual al inicio de la grabación: este es el ancla de tiempo de terceros más original. Para las capturas de la caída abrupta de la caché de disco, acompáñelas con el registro continuo de iostat -dx 5 y guárdelo como CSV, que es más convincente que una sola imagen.
No olvide la "validación cruzada": las dos rondas de pruebas deben estar separadas por más de 6 horas, idealmente cruzando el "ciclo de renovación" o el "pico de actividad de los inquilinos vecinos". Si solo prueba una vez, la otra parte puede negarlo; pero si obtiene resultados repetidos en diferentes fechas y bajo diferentes cargas, la cadena de evidencia queda cerrada.
Las personas más astutas extraen de la misma evidencia una curva de relación costo-rendimiento: al mismo precio, ¿su cuota asignable de CPU es un 30 % inferior a la referencia de la nube pública? Aunque esto no demuestra directamente la sobresuscripción, puede elevar la "disputa técnica" a "pérdida por prima de FinOps", transformando el ticket de "usted miente" a "yo pierdo".
Cómo escribir un ticket de soporte
La regla de oro del ticket es escribir solo hechos, sin calificaciones. No digas "hacen sobreventa", sino "se observó un steal de CPU promedio del 12 % y 4 caídas abruptas de caché de disco"; no digas "el rendimiento no es aceptable", sino "según el compromiso de rendimiento de CPU de su SLA, el comportamiento actual se ha desviado de la línea base".
Estructura recomendada:
- Descripción del entorno: configuración de la instancia, sistema operativo, rango de fechas/horas.
- Método de prueba: adjunte los comandos de reproducción (use comandos genéricos, no herramientas de terceros ni de panel de control).
- Datos originales: tres conjuntos de registros de
steal, CSV de disco, capturas de pantalla con marca de tiempo, empaquetados como adjuntos. - Impacto: describa cómo se ve afectado el negocio (p. ej., la respuesta de la API pasó de 80 ms a 2 s).
- Solicitud: pida al proveedor que revise el estado de carga del host físico y explique la asignación de recursos.
La plantilla puede comenzar así:
“Nuestra instancia ejecutó la misma prueba tres veces el 2025-06-01 a las 02:00, 08:00 y 20:00; las muestras se adjuntan. El steal de CPU superó el 8 % en las tres ocasiones, y después de que la caché de disco se desplomara, las IOPS cayeron a menos del 20 % de lo especificado. Dado que su acuerdo de nivel de servicio promete rendimiento de CPU e IO de referencia, le pedimos al equipo técnico que revise la proporción de asignación actual del host físico y la carga de los vecinos.”
Nota: no incluya palabras como “queja”, “sobreventa” o “fraude” en el cuerpo del ticket — esas se dejan para después, cuando escalen a atención al cliente. El valor del ticket es que la otra parte no pueda refutar con “la herramienta no es precisa”; por lo tanto, cada dato debe corresponder a una línea de registro completa. Si le responden “use nuestra herramienta de prueba”, puede contestar: “Ya se repitió la prueba según el método de su documentación; ver el conjunto de datos n.º 3 del adjunto.” Así, usted devuelve la pelota a su tejado.
¿Qué hacer si el proveedor no lo reconoce?
Cuando la otra parte responda "el método de prueba tiene problemas" o "la carga del host es normal", no te apresures a discutir. Primero exige que proporcionen los registros de monitoreo del host del mismo período de tiempo — normalmente no pueden presentarlos o solo entregan una versión reducida. Para entonces ya tienes dos conjuntos de pruebas sólidas: los registros línea por línea con CPU steal superior al 8% y la curva donde las IOPS caen al 20% del valor nominal después de que la caché del disco se agote por completo. Convierte estos dos conjuntos de datos en una tabla comparativa alineada en el tiempo y señala: si la caída abrupta de la caché del disco coincide exactamente con el pico de steal, demuestra que la CPU y los recursos de almacenamiento del host están siendo ocupados simultáneamente por los vecinos; no es una fluctuación de una única prueba, sino el patrón típico de sobresuscripción del pool de recursos.
Si la otra parte insiste en que "la herramienta no es precisa", puedes responder: "Por favor, proporcionen el script y los parámetros de prueba recomendados oficialmente por su empresa. Repetiré la prueba siguiendo su documentación, y un tercero imparcial registrará el proceso." El valor de este paso es trasladar la carga de la prueba de vuelta al proveedor de servicios. Al mismo tiempo, realiza dos pruebas independientes adicionales en fechas diferentes (por ejemplo, de madrugada y durante el pico de la tarde), para obtener una verificación cruzada. Si las tres muestras señalan la misma conclusión, la otra parte no podrá usar "algo aislado" como excusa. Recuerda conservar los registros originales de cada prueba, la hora del sistema, los registros de sincronización NTP y las marcas de tiempo de las capturas de pantalla; estos son materiales para apelar posteriormente a canales de nivel superior.
Reclamaciones y reembolsos escalados
Si el servicio de atención al cliente directo se niega a escalar el problema, inicie una escalada de canal: primero, envíe un correo electrónico al buzón de abuso/reclamaciones publicado en el sitio web oficial del proveedor, con el asunto indicando "Número de anexo de evidencia de incumplimiento de SLA"; segundo, presente los materiales ante la autoridad reguladora de telecomunicaciones de la jurisdicción donde se encuentra el proveedor de nube o ante el 12321 Centro de Recepción de Denuncias sobre Contenido Nocivo y Spam en Internet. Al presentar, no repita las conclusiones de las pruebas; simplemente enumere una lista de hechos: en qué día y en qué instancia, qué pruebas se ejecutaron, cuáles fueron los valores de los resultados y qué cláusula del SLA corresponde.
La solicitud de reembolso debe hacerse en dos pasos. Primero, solicite un "reembolso por tiempo no utilizado" según las reglas de reembolso del proveedor, e indique que las pérdidas comerciales se debieron a que los recursos no alcanzaron el nivel esperado, solicitando una compensación adicional; aquí puede usar la perspectiva de FinOps para hacer un cálculo: pagó una prima por la supuesta configuración de 8 núcleos y 16 GB, pero la potencia informática real disponible equivale a solo 3 núcleos, por lo que la relación costo-rendimiento ya está desequilibrada. Si la otra parte solo está dispuesta a reembolsar una parte del costo, insista en que proporcionen una "explicación de la asignación de recursos" que especifique si esta instancia comparte el servidor host con VPS económicos de alta densidad. La mayoría de los proveedores temen que use esta explicación para denunciar la venta excesiva (overselling), por lo que ofrecerán una solución intermedia.
Recordatorio final: todas las comunicaciones deben realizarse a través de tickets o correos electrónicos, y conserve capturas de pantalla. Si solicita un reembolso, recuerde exportar los datos del disco antes de eliminar la instancia; después del reembolso, la instancia se borrará, y sus registros de evidencia deben conservarse durante al menos 180 días para un posible arbitraje o litigio posterior. Incluso si el reembolso tiene éxito, se recomienda aplicar este método de recopilación de evidencia al próximo proveedor; verifique antes de pagar para evitar caer en la misma trampa.
FAQ
¿Cómo probar y obtener evidencia de sobreventa en un servidor en la nube?
Usa fio para pruebas continuas de estrés del disco, registra IOPS y latencia, y captura las marcas de tiempo de los registros del sistema; realiza pruebas en múltiples períodos consecutivos y guarda capturas de pantalla.
¿Cómo redactar el ticket para que el proveedor lo reconozca?
Apunta directamente a la violación del SLA, adjunta marcas de tiempo y el informe de pruebas en PDF, exige una compensación según el contrato y no te detengas en comparaciones de rendimiento.
¿Qué hacer si el proveedor no reconoce los resultados de las pruebas?
Solicita una notarización de terceros o un informe de una plataforma de pruebas en la nube, eleva la queja a los organismos reguladores o a los superiores del proveedor, y conserva todas las evidencias del proceso.