Fornecedor é "trapaceiro", mas não quero revelar como descobri

O que deve fazer é verificar independentemente o que lhe foi dito por este promotor júnior. Para começar, não sabe realmente que o que ele disse é exacto. Pode ter havido um mal-entendido algures, pode ter sido mal-entendido, talvez não tenha o quadro completo do ponto de vista técnico e esteja a transmitir dados incompletos, etc. Como dizem, “trust, mas verifique.”

Por outra razão, verificar o que lhe foi dito protege a sua fonte. Ninguém precisa de saber que ele lhe disse alguma coisa, porque pode reter os dados como prova do que aconteceu, e omitir completamente o facto de ter sido avisado por alguém. Não forneceu detalhes técnicos suficientes para o aconselhar sobre como poderia verificar isto, mas não parece que seja difícil para um administrador de sistemas ou engenheiro de sistemas decente fazê-lo.

Naturalmente, há sempre a opção de simplesmente declarar o que a sua fonte lhe disse, e dizer que para evitar retaliações, prefere não/não pode/não vai nomear a sua fonte. Mas verificar a si mesmo, para que mesmo ter uma fonte esteja fora de questão, é a melhor abordagem.

Embora a sua preocupação com o programador júnior neste caso seja admirável, tenha em mente que esta é uma situação em que a sua obrigação legal é para com o seu cliente. Dito isto …

O meu cliente não iria apresentar uma acção judicial, mas certamente iria despejar esse fornecedor. Somos um dos seus clientes mais importantes.

Uma vez que o seu cliente despejaria o fornecedor e uma vez que o fornecedor está a ser desonesto, por que razão faria outra coisa que não recomendar o despejo do fornecedor?

Argumivelmente, não precisa de divulgar a sua fonte. Na verdade, você poderia simplesmente dizer ao seu cliente que como o desempenho do fornecedor não correspondeu ao que ele está pagando, então é hora de ir embora. Se for pressionado, pode dizer que como o prestador de serviços sabia antecipadamente do teste que suspeita ter atribuído recursos extra para o teste que não está a fornecer normalmente.

Se você realmente quer proteger o programador júnior e tem uma vaga que ele pode preencher, você mesmo pode contratá-lo, ou o seu cliente pode contratá-lo. Desta forma, ele evita de certeza ser despedido pelo prestador de serviços. Além disso, caso o prestador de serviços tente processar o seu cliente por quebra de contrato, você tem a certeza de o ter por perto como testemunha.

Um pouco a este

Pelo que sabe o fornecedor adicionou servidores à quinta durante os testes. Se o seu cliente pagou uma quantia enorme pelo benchmark então deveria ter esperado que a empresa contratada para realizar o benchmark tivesse pegado nele.

O flat do benchmark excede a produção teórica da fazenda? Pode mostrar que os resultados não são realistas?

Pode, de alguma forma, executar alguns benchmarks independentes que ponham em causa o parâmetro de referência dotored?

O fornecedor não tem algum acompanhamento em tempo real de métricas básicas de desempenho como CPU, IO, largura de banda …? Deve ter executado algumas delas durante o benchmark divulgado. Eu sei que a retrospectiva é 20/20 mas mesmo assim.

Não está à procura do problema. Conhece o problema e agora só precisa de o provar. A sua fonte fez-lhe um grande serviço ao expor o problema. Consegue provar o problema sem expor a fonte?

Talvez apenas vá com:

Estes valores de referência não estão a corresponder ao desempenho da aplicação. Ou a aplicação está a colocar uma carga maior do que eu esperava, os servidores não estão a colocar esse desempenho, ou apenas me está a faltar algo. Aqui estão itens a explorar… E na lista de itens a explorar tem um benchmark de surpresa.

A saída da pessoa que forneceu a informação é difícil. Ele provavelmente seria despedido. E provavelmente seria despedido de uma forma muito má, tão difícil de encontrar outro emprego. Eu procuraria muito para encontrar uma maneira de expor isto sem expor a pessoa. Pessoalmente, não os denunciaria. Sem uma verificação independente, provavelmente não se aguentaria de qualquer forma.

Se o desempenho na vida real não corresponder ao desempenho durante o teste (e tem os dados para o provar), a solução deve ser fácil: notificar o fornecedor, e se o desempenho não melhorar, cancelar o contrato.

Não precisa de dizer como descobriu que o teste foi manipulado, apenas que ** o desempenho diário não corresponde ao benchmark do teste** (pode até perguntar “inocentemente”: alguma configuração de hardware/software mudou desde o benchmark?). Mas os seus advogados podem estar interessados em falar com a empresa que pagou pelo caro benchmark - foi o mesmo que o fornecedor do serviço, ou diferente?

Em relação ao seu leaker: Não revele o seu nome, que o atiraria para debaixo de um autocarro sem uma boa razão e sem qualquer benefício para a sua própria empresa. Mas pode querer manter-se em contacto e possivelmente retribuir o favor: avise-o da necessidade de procurar um emprego diferente antes do acidente (quando o cancelamento do contrato é informação pública, não antes). Compreendo o dilema de não lhe poder fornecer uma boa referência (ou talvez possa - dizendo que ele foi útil e que faria a milha extra para comunicar com o cliente).

A forma mais fácil de lhe retribuir o favor seria tomá-lo para um café algum dia (fora das instalações de ambas as empresas, e dizer-lhe que a reunião é estritamente fora do registo* ). Poderia ser pouco depois do cancelamento do projecto se tornar público, e não antes, e ** explicar-lhe que tipo de política empresarial** em que se enredou, e que dilema ético complicado está lá livre para a tomada (para ambos). Por isso, da próxima vez, ele estará mais apto a lidar com isso. Ele parece ser um tipo honesto e prestativo, possivelmente ainda não está a par dos meandros da vida - e você tem uma excelente oportunidade de o ajudar a dar-lhe uma pista; ajudá-lo a aprender a lição sem prejudicar a sua carreira.

Não sei como reagirá da próxima vez: não lhe dizer, ou não enganar os clientes? :-)

As outras respostas são realmente boas, mas não vi isto explicitamente declarado em nenhuma delas -

Por que razão não seria a vossa recomendação apenas que o seu fornecedor externo de benchmarking realizasse outro teste, uma vez que o seu método de teste apresentava falhas. Se sabe que a informação foi publicada e que os serviços foram desligados, tenho a certeza que pode encontrar um NIST ou uma norma ISO que indique o procedimento adequado para este tipo de testes. Pode mesmo procurar informação sobre melhores práticas no ISACA.

Não importa o que sabe, apenas que ao publicar o tempo e o ambiente que está a ser alterado, não é um teste válido. Mesmo assim, poderia ir à empresa de testes externa e perguntar-lhes o que estavam a pensar.

Parece que tanto a empresa de testes como o fornecedor estavam envolvidos na criação de uma situação por resultados incorrectos e que a IMO era pelo menos negligente e no máximo * colusivo ***.

Mais uma vez, não sei para que trabalho foi contratado, mas se algum destes trabalhos está no âmbito, é uma boa forma de evitar a divulgação de qualquer informação confidencial.

Divulgue tudo ao seu cliente e informe-o sobre as informações que tem. Tem a obrigação profissional de lhe prestar o melhor serviço possível e não tem qualquer obrigação profissional para com o programador júnior do centro de dados. O seu cliente pagou-lhe literalmente para descobrir coisas como esta.

Depois de ter revelado a informação que adquiriu (que o seu cliente lhe está a pagar). Discuta a verificação do que o programador júnior disse.

Se verificar - definitivamente trabalhar com outro fornecedor.

Como pessoas, tentamos ser simpáticos e justos e isso é admirável. Como profissional, tem a obrigação de prestar o melhor serviço possível ao seu cliente.

O simples facto de a verdadeira aplicação ter um “péssimo desempenho do software”, enquanto nos testes “os resultados foram bons” deve soar a qualquer um e pode ser usado como ponto de partida para discussão, ou para desafiar os testes. Pode/ deve levantar suspeitas na quinta de testes junto do cliente sobre esta discrepância, especialmente dado que é “responsável por eles”.

Adicionalmente, a questão original em questão permanece por resolver e aberta para análise posterior, com ou sem o envolvimento da empresa externa altamente remunerada. Estão disponíveis ferramentas para muitas tecnologias para monitorizar o desempenho da produção sem realmente o afectar; poderá querer usar isso para quantificar o “horrível”. Acrescentando à resposta da HopelessN00b , esta seria outra forma de verificação.

A sua fonte é um “desenvolvedor júnior empregado pelo anfitrião do servidor, que se queixou sobre isso”. Por outras palavras, no que lhe diz respeito, não fez absolutamente nada de mal em obter essa informação.

O seu dever não é para com o ISP, ou o programador júnior do ISP, mas sim para com o seu cliente. Por isso acredito que deve informar o seu cliente. Pode mencionar que tipo de fonte teve sem mencionar a fonte real. O que vai acontecer: O seu cliente vai deixar de usar um ISP que está a fazer batota, o ISP vai perder o cliente que está a fazer batota, e o desenvolvedor júnior esperançosamente não vai falar mais sobre isso vai estar em perigo.