El proveedor está "engañando", pero no quiero revelar cómo me enteré

Lo que debes hacer es verificar independientemente lo que te ha dicho este desarrollador junior. Por un lado, no sabes si lo que te ha dicho es correcto. Podría haber habido un malentendido en algún lugar, podría ser un malentendido, tal vez no tiene todo el panorama desde un punto de vista técnico y está pasando datos incompletos, etc. Como se dice, “confía, pero verifica.”

Por otra razón, verificar lo que se le dijo protege su fuente. Nadie necesita saber que te dijo algo, porque puedes sostener los datos como evidencia de lo que pasó, y omitir completamente el hecho de que fuiste avisado por alguien. No has proporcionado suficientes detalles técnicos para aconsejar sobre cómo podrías verificar esto, pero no parece que sea difícil para un administrador de sistemas o un ingeniero de sistemas decente hacerlo.

Por supuesto, siempre existe la opción de simplemente decir lo que tu fuente te dijo, y decir que para evitar represalias, prefieres no/puedes/no nombrar tu fuente. Pero verificarte a ti mismo, para que incluso tener una fuente no tenga importancia, es el mejor enfoque.

Aunque su preocupación por el programador junior en esta instancia es admirable, por favor tenga en cuenta que esta es una situación en la que su obligación legal es con su cliente. Dicho esto…

Mi cliente no presentaría una demanda, pero ciertamente dejaría a ese proveedor. Somos uno de sus clientes más importantes.

Dado que su cliente dejaría al proveedor y dado que el proveedor está siendo deshonesto, ¿por qué haría algo más que recomendar el abandono del proveedor?

Podría decirse que no necesita divulgar su fuente. De hecho, podrías decirle a tu cliente que como el desempeño del proveedor no ha cumplido con lo que está pagando, entonces es hora de irse. Si se le presiona, puede decir que ya que el proveedor de servicios sabía de antemano sobre la prueba, usted sospecha que asignaron recursos adicionales para la prueba que no están proporcionando normalmente.

Si usted realmente quiere proteger al programador junior y tiene un hueco que podría llenar, podría contratarlo usted mismo, o su cliente podría contratarlo. De esta manera él está seguro de evitar ser despedido por el proveedor de servicios. Además, en caso de que el proveedor de servicios intente demandar a su cliente por incumplimiento de contrato, está seguro de tenerlo como testigo.

Un poco de esto

Por lo que sabes el proveedor añadió servidores a la granja durante las pruebas. Si su cliente pagó una gran cantidad por el benchmark, entonces debería haber esperado que la compañía contratada para realizar el benchmark lo hubiera recogido.

¿El benchmark plano excede el rendimiento teórico de la granja? ¿Puede mostrar que los resultados son simplemente no realistas?

¿Puede de alguna manera ejecutar algunos benchmarks independientes que pongan en duda el benchmark doctorado?

¿No tiene el proveedor alguna supervisión en tiempo real de las métricas básicas de rendimiento como CPU, IO, ancho de banda…? Debería haber ejecutado algunas de ellas durante el benchmark revelado. Sé que en retrospectiva es 20/20 pero aún así.

No estás buscando el problema. Conoces el problema y ahora sólo necesitas probarlo. Tu fuente te hizo un gran servicio al exponer el problema. ¿Puedes probar el problema sin exponer la fuente?

Tal vez sólo vaya con:

Estos puntos de referencia no coinciden con el rendimiento de la aplicación. O bien la aplicación está sacando una carga más grande de lo que espero, los servidores no están sacando ese rendimiento, o simplemente me falta algo. Aquí hay elementos para explorar… Y en la lista de elementos a explorar hay un punto de referencia sorpresa.

Sacar a la persona que proporcionó la información es difícil. Es probable que sea despedido. Y probablemente despedido de una manera muy mala en ese difícil de encontrar otro trabajo. Yo buscaría con fuerza la manera de exponer esto sin exponer a la persona. Personalmente, no los expondría. Sin una verificación independiente, no es probable que no se sostenga de todos modos.

Si el rendimiento en la vida real no coincide con el rendimiento durante la prueba (y usted tiene los datos para probarlo), la solución debe ser fácil: notifique al proveedor, y si el rendimiento no mejora, cancele el contrato.

No tiene que decir cómo encontró que la prueba estaba amañada, sólo que el rendimiento diario no coincide con el punto de referencia de la prueba (puede incluso preguntar “inocentemente”: ¿cambió alguna configuración de hardware/software desde el punto de referencia?) Pero sus abogados podrían estar interesados en hablar con la compañía que pagó por el costoso benchmark - ¿fue la misma que el proveedor de servicios, o diferente?

Respecto a su fuga: no revele su nombre, eso sería arrojarlo debajo de un autobús sin ninguna buena razón y sin beneficio para su propia compañía. Pero puede que quiera mantenerse en contacto y posiblemente devolverle el favor: adviértale de la necesidad de buscar otro trabajo antes del accidente (cuando la cancelación del contrato es información pública, no antes). Entiendo el dilema de que no puedes darle una buena referencia (o tal vez puedas - diciendo que fue útil y que haría el esfuerzo extra para comunicarse con el cliente).

La forma más fácil de devolver el favor sería llevarlo a tomar un café en algún momento (fuera de las instalaciones de ambas compañías, y decirle que la reunión es estrictamente extraoficial). Podría ser poco después de que la cancelación del proyecto se hiciera pública, no antes, y explicarle en qué tipo de política corporativa se enredó, y qué complicado dilema ético hay libre para tomar (para ambos). Así que será más capaz de lidiar con ello la próxima vez. Parece ser un tipo honesto y servicial, posiblemente aún no se ha dado cuenta de las complejidades de la vida - y usted tiene una excelente oportunidad de ayudarlo a comprenderlo; ayúdelo a aprender la lección sin dañar su carrera.

No estoy seguro de cómo reaccionará la próxima vez: ¿no se lo dirá, o no engañará a los clientes? :-)

Las otras respuestas son muy buenas, pero no vi esto explícitamente en ninguna de ellas -

¿Por qué no sería su recomendación sólo que su proveedor externo de benchmarking realice otra prueba ya que su método de prueba era defectuoso. Si usted sabe que la información fue publicada y los servicios fueron desactivados, estoy seguro de que usted puede encontrar una norma NIST o ISO que establece el procedimiento adecuado para este tipo de pruebas. Incluso podría buscar información sobre las mejores prácticas en ISACA.

No importa lo que sepa, sólo que al publicar el tiempo y el entorno que se altera, no es una prueba válida. Incluso entonces, podría ir a la compañía de pruebas externa y preguntarles qué estaban pensando.

Suena como que tanto la compañía de pruebas como el proveedor estuvieron involucrados en crear una situación para obtener resultados inexactos y fueron IMO siendo por lo menos negligentes y a lo sumo colusorio*.

Nuevamente, no sé para qué trabajo fue contratado, pero si algo de esto está dentro del alcance, es una buena manera de evitar la divulgación de cualquier información confidencial.

Revela todo a tu cliente y cuéntale la información que tienes. Tienes la obligación profesional de darle el mejor servicio posible y no tienes ninguna obligación profesional con el desarrollador junior del centro de datos. Tu cliente te pagó literalmente para descubrir cosas como esta.

Después de que hayas revelado la información que has adquirido (por la que tu cliente te está pagando). Discuta la verificación de lo que el desarrollador junior ha dicho.

Si se verifica - definitivamente trabaje con otro proveedor.

Como personas, tratamos de ser amables y justos y eso es admirable. Como profesional tienes la obligación de proporcionar el mejor servicio posible a tu cliente.

El simple hecho de que la aplicación real tenga un “horrible rendimiento del software”, mientras que en las pruebas “los resultados fueron buenos” debería hacer sonar una campana para cualquiera y puede ser usado como punto de partida para la discusión, o para desafiar las pruebas. Podría/debería levantar sospechas en la granja de pruebas con el cliente sobre esta discrepancia, especialmente dado que usted es “responsable de ellas”.

Adicionalmente, el asunto original en cuestión permanece sin resolver y abierto a más análisis, con o sin la participación de la enormemente pagada compañía externa. Hay herramientas disponibles para muchas tecnologías para monitorear el desempeño de la producción sin impactarla realmente; tal vez quieras usar eso para cuantificar lo “horrible”. Añadiendo a HopelessN00b’s reply , esta sería otra forma de verificar.

Tu fuente es un “desarrollador junior empleado por el anfitrión del servidor, que parloteó sobre ello”. En otras palabras, en lo que a ti respecta, no hiciste absolutamente nada malo para conseguir esa información.

Tu deber no es con el ISP, o el desarrollador junior del ISP, sino con tu cliente. Así que creo que deberías informar a tu cliente. Podrías mencionar qué tipo de fuente tenías sin mencionar la fuente real. Lo que sucederá: Tu cliente dejará de usar un ISP que está haciendo trampas, el ISP perderá al cliente que está haciendo trampas, y el desarrollador junior esperará no hablar más sobre esto, porque estará en peligro.