¿Cómo [educadamente?] Decirle al proveedor de software que no saben de qué están hablando

No es una pregunta técnica, pero sí válida. Guión:

HP ProLiant DL380 Gen 8 con 2 CPU Xeon E5-2667 de 8 núcleos y 256 GB de RAM con ESXi 5.5. Ocho máquinas virtuales para un sistema de proveedor determinado. Cuatro máquinas virtuales para prueba, cuatro máquinas virtuales para producción. Los cuatro servidores en cada entorno realizan diferentes funciones, por ejemplo: servidor web, servidor de aplicaciones principal, servidor OLAP DB y servidor SQL DB.

Los recursos compartidos de la CPU configurados para evitar que el entorno de prueba afecte la producción. Todo el almacenamiento en SAN.

Hemos tenido algunas consultas sobre el rendimiento, y el proveedor insiste en que debemos darle al sistema de producción más memoria y vCPU. Sin embargo, podemos ver claramente desde vCenter que las asignaciones existentes no se están tocando, por ejemplo: una vista mensual de la utilización de la CPU en el servidor de aplicaciones principal oscila alrededor del 8%, con un pico impar de hasta el 30%. Los picos tienden a coincidir con el inicio del software de respaldo.

Historia similar en RAM: la cifra de utilización más alta en los servidores es de ~ 35%.

Por lo tanto, hemos estado cavando un poco, usando Process Monitor (Microsoft SysInternals) y Wireshark, y nuestra recomendación al proveedor es que hagan algunos ajustes de TNS en primera instancia. Sin embargo, esto está fuera del punto.

Mi pregunta es: ¿cómo podemos hacer que reconozcan que las estadísticas de VMware que les hemos enviado son evidencia suficiente de que más RAM / vCPU no ayudará?

--- ACTUALIZACIÓN 07/12/2014 ---

Semana interesante Nuestra administración de TI ha dicho que deberíamos hacer el cambio en las asignaciones de VM, y ahora estamos esperando un tiempo de inactividad de los usuarios comerciales. Curiosamente, los usuarios de negocios son los que dicen que ciertos aspectos de la aplicación se ejecutan lentamente (en comparación con lo que, no sé), pero van a "avisarnos" cuando podamos desactivar el sistema (refunfuñar) , gruñir!)

Además, el aspecto "lento" del sistema aparentemente no es el elemento HTTP (S), es decir, la "aplicación delgada" utilizada por la mayoría de los usuarios. Parece que son las instalaciones del "cliente gordo", utilizadas por los principales organismos financieros, lo que aparentemente es "lento". Esto significa que ahora estamos considerando la interacción del cliente y el cliente-servidor en nuestras investigaciones.

Como el propósito inicial de la pregunta era buscar ayuda sobre si seguir la ruta de "empujarlo", o simplemente hacer el cambio, y ahora estamos haciendo el cambio, lo cerraré usando la respuesta de longneck .

Gracias por su aportación a todos ustedes; como de costumbre, serverfault ha sido más que un simple foro: también es como el sofá de un psicólogo :-)

Le sugiero que haga los ajustes que han solicitado. Luego, evalúe el rendimiento para mostrarles que no hizo ninguna diferencia. Incluso podría ir tan lejos para compararlo con MENOS memoria y vCPU para hacer su punto.

Además, "le estamos pagando para que respalde el software con soluciones reales, no conjeturas".

Siempre que esté seguro de estar dentro de las especificaciones del sistema dadas que documentan.

Luego, cualquier reclamo que estén haciendo con respecto a requerir más RAM o CPU que deberían poder respaldar. Como expertos en su sistema, hago que la gente rinda cuentas sobre esto.

Pregúnteles detalles.

• ¿Qué información proporcionada en el sistema indica que se necesita más RAM y cómo interpretó esto?

• ¿Qué información proporcionada en el sistema indica que se necesita más CPU y cómo interpretó esto?

• Los datos que tengo, a primera vista, contradicen lo que me estás diciendo. ¿Me puede explicar por qué puedo estar interpretando esto incorrectamente?

• Estoy interpretando que esta [serie obvia de datos] significa [interpretación obvia]. ¿Pueden confirmar que lo estoy interpretando correctamente con respecto a mi problema?

Habiendo tratado con el apoyo en el pasado, he hecho las mismas preguntas. A veces tenía razón y no enfocaban su atención en mi problema correctamente. Sin embargo, otras veces me equivoqué y estaba interpretando los datos incorrectamente, o no incluí otros datos que fueron importantes en mi análisis.

En cualquier caso, ambas situaciones fueron un beneficio neto para mí, o aprendí algo nuevo que no sabía antes, o hice que sus equipos de apoyo pensaran más en mi problema para obtener una causa raíz decente.

Si el equipo de soporte no puede proporcionarle una expansión lógica de su argumento a una base con la que pueda estar satisfecho (debe tener una mente abierta para comprometerse, sea razonable aceptar que su interpretación de los datos es incorrecta) debería estar muy presente en su respuesta. Incluso en el peor de los casos, puede usar esto como base para escalar el problema.

Lo importante es poder demostrar que está utilizando las mejores prácticas para la asignación de su sistema, especialmente las reservas de RAM y CPU para su servidor SQL.

Dicho todo esto, lo más fácil es hacer los ajustes solicitados, al menos temporalmente. Si nada más, tiende a hacer que los vendedores se arrastren. No puedo contar la cantidad de veces que he necesitado hacer algo loco como esto para satisfacer a un técnico en el otro extremo de la línea que realmente no está comportando su software.

Para esta situación específica (donde tiene VMware y desarrolladores de aplicaciones o un tercero que no comprende la asignación de recursos), utilizo una semana de métricas obtenidas de vCenter Operations Manager (vCops - descargue una demostración si es necesario ) para identificar las restricciones reales , cuellos de botella y requisitos de tamaño de las máquinas virtuales de la aplicación.

A veces, he podido satisfacer a los consumidores más obstinados modificando las reservas de VM o cambiando las prioridades para manejar escenarios de contención; " Si RAM | CPU están ajustados, ¡ SU VM tendrá prioridad! ". Han pasado cosas malas y malas cuando he permitido que los proveedores de software dicten sus requisitos en mis clústeres de vSphere sin un análisis real .

Pero en general, los números y los datos deberían ganar.

Un ejemplo de algo que utilicé para justificar el tamaño de VM al desarrollador de una aplicación Tomcat:

Dev : ¡ La VM necesita una CPU MOAR!

Yo : Bueno, la memoria es su mayor limitación, y aquí hay un mapa de calor de su desempeño en función del tiempo ... Los miércoles a las 6 p.m. son los períodos más estresantes, por lo que podemos especificar alrededor de ese período pico. Ah, y aquí hay una recomendación de tamaño basada en las últimas 6 semanas de métricas de producción ...

Solía ​​trabajar en apoyo, y parte de lo que estás preguntando parece muy racional (y probablemente lo sea): pero hay algunas preguntas que debes hacerte antes de hacer la "mejora del rendimiento" que están solicitando.

• ¿ya está ejecutando al menos los requisitos mínimos del sistema establecidos por el proveedor?
• si tiene al menos un sysreqs mínimo, ¿ya está en la configuración del sistema "recomendada"?

Los proveedores 99 veces de cada 100 (en mi experiencia, tanto en el lado del soporte como en el lado del cliente / campo) ni siquiera se ocuparán de los problemas relacionados con el rendimiento hasta / a menos que los sistemas coincidan con lo que exige su documentación. Tal vez es un sistema que funciona bien el 99.5% de las veces con 1 CPU y 512M de RAM, pero si los requisitos del sistema dicen 4 CPU y 4G RAM y solo tienes 2 CPU y 1G RAM, tienen derecho a exigir que se asignen más recursos ^* .

Es probable que le pidan que aumente los recursos del sistema debido a algo que encontraron en el laboratorio / desarrollo en el que un problema desaparece mágicamente si cruza un umbral específico; Si este es el caso, sí, es un ejemplo de depuración potencialmente pobre por su parte, pero tenga en cuenta que no tienen tiempo para eliminar todos los posibles errores / problemas que surjan; algunos solo necesitan ser solucionados, y si ese es el caso aquí, solo hazlo.

También existe una posibilidad no insignificante de que los problemas que está viendo no sean ni siquiera parte de "su" software, sino un componente del que dependen de alguna otra fuente (proveedor, biblioteca OSS, etc.). Me encontré con esta situación exacta relacionada con el tamaño de intercambio, BEA WebLogic y Sun JRE en un cliente hace unos años.

tl; dr:

En resumen, trabaje con su equipo de soporte, escalando según sea necesario, hasta que encuentre una resolución, pero no se sorprenda cuando algunas de las sugerencias / pasos de depuración / arreglos suenen descabellados o no tengan sentido.

^{* _{Si realmente no "necesita" esos recursos adicionales, es probable que esté en un lugar para poder presentar un error de documento / RFE para futuras versiones, pero no empuje esa ruta hasta que haya demostrado que no es el problema en cuestión}
^ _{un eBook que escribí puede serle útil en el tema: Depuración y soporte de sistemas de software}}

Solicite escalar el ticket o solicite un representante diferente. Dependiendo de qué proveedor es la escalada puede ayudar si dice que siente que el nivel actual de soporte no aborda adecuadamente el problema. Si no van a escalar, pedir un representante diferente puede ayudar porque eso requiere mucha menos "justificación" ya que todo lo que necesita es no estar contento con el actual.

Si se trata de un gran vendedor, simplemente cerrar el boleto y abrir uno nuevo sobre el mismo problema puede funcionar, ya que puede enrutarse a un representante diferente, pero desaconsejaría porque es deficiente.

También podría mantener su posición y solicitar una justificación de cómo ayudará más RAM / vCPU, o simplemente podría darle más RAM / vCPU para demostrar que no ayudará.

Voy a tirar mis dos centavos. Hemos tenido bastante éxito con este enfoque: resultados mucho mejores y menos frustración por parte de todos. Requiere mucho más esfuerzo que el juego de la culpa y agregar recursos a ciegas, pero también tiene mejores posibilidades de encontrar el problema subyacente.

Cuando tenemos serios problemas con nuestras aplicaciones locales que están respaldadas por contratos de soporte de proveedores, y los proveedores comienzan su evasión de baile (que siempre parece incluir demandas extrañas no basadas en datos para más CPU o RAM), tendemos a haz estas 3 cosas:

1. Escale la prioridad al equivalente del sistema inactivo: por lo general, se resisten, pero generalmente retroceden cuando explica que es efectivamente inutilizable incluso si técnicamente está "funcionando". Trátelo como un problema serio para que lo resuelvan. Por aquí nos referimos a eso como un equipo de tigres, que se reúne diariamente para obtener actualizaciones de estado de todos los interesados. Por lo general, el vendedor le pedirá que cambie las cosas. Si se trata de un sistema de producción, eso es problemático, pero si desea que lo ayuden, deberá aceptar la responsabilidad de ayudarlos a aislar el problema, por lo que es útil si tiene un entorno de desarrollo / preparación donde puede ejecutar pruebas.

2. Dígale al vendedor que desea que repliquen su entorno, para que ELLOS puedan aislar el problema en su laboratorio. Incluso pueden alojar cosas en algún entorno de nube si es necesario. No tiene que ser una coincidencia exacta de su entorno, aunque eso sería ideal. El punto es que desea que el VENDEDOR intente activamente replicar su problema, para que pueda probar sus conjeturas en su sistema en lugar del suyo. Pídales los diagramas, especificaciones, etc. de ese entorno replicado para asegurarse de que lo estén haciendo.

3. Proporcione (bajo NDA, por supuesto) su conjunto de datos real para que puedan ejecutarlo / reproducirlo de verdad en lugar de adivinar. En nuestro caso, la mayoría de los problemas de nuestras aplicaciones proporcionadas por el proveedor (tanto transitorios como crónicos) con frecuencia resultan ser problemas con las bases de datos proporcionadas por el proveedor. No puedo contar la cantidad de veces que hemos hecho esto y finalmente han identificado el problema en algo inesperado en los datos reales: artefactos extraños de actualizaciones de aplicaciones hace 2 años donde algo no se convirtió limpiamente; registros obsoletos que exponen un problema con la configuración del GC; las consultas no funcionan del todo bien porque NUESTROS valores de datos rompen alguna rutina de transfiguración en el código del proveedor, etc. Cosas que nunca podríamos identificar por nuestra cuenta.

Lo hemos hecho con bastantes proveedores en los últimos años, y al principio son muy resistentes a hacerlo a nuestra manera. Sin embargo, después de que funciona, siempre aparece como un punto culminante positivo en las revisiones trimestrales que tenemos con nuestros proveedores. Y ayuda a consolidar nuestra relación técnica con esos proveedores. No quieren problemas vagos. Quieren problemas específicos que puedan analizar para mejorar sus productos.

Espero que la sugerencia ayude. Sé que no es un enfoque único para todos, pero si puedes cambiarlo, creo que valdrá la pena.

La verdadera pregunta es, ¿quién está a cargo aquí? Si no puede cambiarse de manera realista a un proveedor alternativo, entonces ellos tienen el poder, y todo lo que realmente puede hacer es aceptar lo que digan y esperar que funcione. ¡No es una situación feliz! De lo contrario, le sugiero que solicite otro representante (como han dicho otros), pero deje en claro que no está satisfecho con el servicio y buscará en otro lado si no pueden hacer el trabajo.

No solo "haga los ajustes que sugirieron" si está seguro de que no funcionarán, ya que eso es establecer un patrón para su relación que lo lastimará a la larga. Usted les está pagando para que le brinden un servicio, y no deberían poder dictar sus acciones como tampoco alguien que contrate para pintar mi casa puede determinar de qué color será.

Esto puede sonar drástico, ya que parece que este no es un tema muy crítico, pero el hecho es que si te están molestando en algo menor, probablemente harán lo mismo por algo grande, y lo último que quieres es toparse con una especie de charlie foxtrot horrible seis meses después y tener el mismo problema con el vendedor entonces.

Asegúrese de que, independientemente de los pasos que tome para resolver el problema ahora, funcionará igual de bien cuando falten dos días para la fecha límite y todo se rompa ...

Voy a publicar una vista desde el lado del vendedor.

Tuvimos un cliente que tenía este problema recurrente en el que el rendimiento del software se reducía cada pocas horas a un ritmo realmente abismal y luego regresaba unas horas más tarde.

El generador de perfiles de bulitina en el sistema indicó que la velocidad de la CPU del sistema (o posiblemente la memoria) era asquerosamente lenta, algo así como 100MHZ en lugar de los 2GHZ esperados. Duplicar la CPU proporcionada por la VM no cambió el síntoma y pensaron que estábamos siendo un desperdicio.

Como no podían obtener una CPU más rápida (más CPU no iban a ayudar), intentamos intercambiar las máquinas virtuales TEST y PROD. El problema apareció en TEST al día siguiente. Luego intentamos promocionar a uno de los clientes a una instancia independiente (sin servidor). No hay problema en esa estación de trabajo mientras el servidor se estaba ahogando.

Produjeron informes del host VM que indicaban que no había problemas de rendimiento e intentaron nuevamente afirmar que se trataba de un problema de aplicación.

Finalmente, [un ingeniero] (tenía cero apoyo de aquellos en roles de soporte dedicados) pedí específicamente una caja física. El cliente gritó asesinato sangriento, pero como nadie tenía otra solución potencial, lo hicieron. ¿Qué sabes? El problema desapareció mágicamente.

Nunca descubrimos cuál era el problema. Todos los programas de referencia mostraron normalidad, pero el generador de perfiles de aplicaciones nos decía que los recursos informáticos simplemente no eran adecuados. Hay una especie de firma específica que buscamos en el generador de perfiles ahora. Si lo vemos, sabemos antes de avanzar, el problema es la interacción de VM, pero en ese momento no se conocía.

Seguramente pensaron que estaba lleno de eso. Yo no estaba Estaba sin opciones.

EDITAR, actualización de años más tarde:

Con cada vez más clientes que desean ejecutarse en máquinas virtuales y gestión dispuestos a intentar resolver el problema a toda costa, obtuvimos un buen hardware de máquina virtual. Pude construir un programa especializado de grabación de VM que se ejecutó en el espacio de usuario (y no requirió privilegios) en dos máquinas virtuales de un solo núcleo con 512 MB de RAM, que fue capaz de drenar 1/3 del rendimiento de la memoria de otra máquina virtual de un solo núcleo con solo 4 total de núcleos de 16 en uso en el host VM y la mayoría de sus ram aún libres. El programa no generó alarmas y no mostró nada fuera de lo común en el host VM ni en ninguno de los invitados, excepto que el acceso a la memoria fue lento.

Ahora podemos decirles a los clientes que sabemos que hay un problema con las máquinas virtuales y que no es nuestro software. Todavía recibimos solicitudes de clientes de vez en cuando para software compatible con VM. Me pregunto por qué la administración no deja que el soporte les diga que pudimos desarrollar un software que ralentiza cada VM en el mismo host.

Lo que da miedo es que la técnica involucrada es una simple transformación de una técnica de programación conocida que involucra sincronización sin bloqueo. Cientos de proveedores de software podrían tener este drenador de VM en su software y no saberlo. Conseguir un bloqueo de instrucciones atómicas que sea muy disputado debería ser raro pero no imposible. La parte divertida de todo es que estaba obteniendo el bloqueo para impugnar máquinas virtuales ACROSS.

Sugeriría un enfoque muy diferente a los mencionados hasta ahora. Antes de discutir con el vendedor, por qué no mirar más de cerca el problema reportado y ver qué le dice eso.

¿Cuáles son los problemas reales que se informan y cuáles son las expectativas de los usuarios? Si un usuario dice algo "toma demasiado tiempo", pregúntele exactamente qué es (para que pueda reproducirlo), cuánto tiempo cree que debería tomar y por qué cree que debería tomar tanto tiempo. Si sus expectativas son razonables, mida el rendimiento real y el impacto del sistema de lo que están tratando de hacer. El hecho de que su sistema muestre un pico de 30% durante un mes no significa que no se esté ejecutando a> 100% cuando el usuario está intentando realizar su consulta. Si puede demostrarle a su proveedor que la CPU y la memoria no están siendo forzadas por la tarea problemática, entonces puede pedirle al proveedor que justifique las recomendaciones que le costarán dinero.