Il fornitore sta "imbrogliando", ma non voglio rivelare come ho scoperto

Quello che dovreste fare è verificare in modo indipendente ciò che vi è stato detto da questo sviluppatore junior. Per prima cosa, in realtà non si sa se quello che ha detto è accurato. Potrebbe esserci stato un errore di comunicazione da qualche parte, potrebbe esserci stato un malinteso, forse non ha il quadro completo dal punto di vista tecnico e sta trasmettendo dati incompleti, ecc. Come si dice, “fiducia, ma verifica.”

Per un altro motivo, verificare ciò che ti è stato detto protegge la tua fonte. Nessuno deve sapere che vi ha detto qualcosa, perché potete trattenere i dati come prova di ciò che è successo, e omettere completamente il fatto che siete stati avvisati da qualcuno. Non avete fornito abbastanza dettagli tecnici per consigliarvi su come potreste verificarlo, ma non sembra che sarebbe affatto difficile per un sysadmin o un ingegnere di sistemi decente farlo.

Naturalmente, c'è sempre la possibilità di dichiarare semplicemente ciò che la vostra fonte vi ha detto, e dire che per evitare ritorsioni, preferireste non/può/non vuole nominare la vostra fonte. Ma verificare se stessi, in modo che anche avere una fonte non sia un problema, è l'approccio migliore.

Anche se la vostra preoccupazione per il programmatore junior in questo caso è ammirevole, tenete presente che si tratta di una situazione in cui il vostro obbligo legale è nei confronti del vostro cliente. Detto questo …

Il mio cliente non intenterebbe una causa, ma certamente scaricherebbe quel fornitore. Siamo uno dei loro clienti più importanti.

Poiché il vostro cliente scaricherebbe il fornitore e poiché il fornitore è disonesto, perché non dovreste fare altro che raccomandare di scaricare il fornitore?

Senza dubbio, non è necessario divulgare la vostra fonte. Infatti, potreste semplicemente dire al vostro cliente che, dato che le prestazioni del provider non hanno raggiunto il livello per il quale sta pagando, allora è il momento di andarsene. Se si preme, si può dire che, poiché il fornitore di servizi sapeva in anticipo del test, si sospetta che abbia assegnato risorse extra per il test che non stanno fornendo normalmente.

Se volete davvero proteggere il programmatore junior e avete un posto che potrebbe occupare, potreste assumerlo voi stessi, o il vostro cliente potrebbe assumerlo. In questo modo è sicuro di evitare di essere licenziato dal fornitore di servizi. Inoltre, nel caso in cui il fornitore di servizi cerchi di citare in giudizio il vostro cliente per violazione del contratto, siete sicuri di averlo come testimone.

Un po ‘a questo

Da quello che sai il provider ha aggiunto i server alla fattoria durante il test. Se il vostro cliente ha pagato una somma enorme per il benchmark, allora avreste dovuto sperare che l'azienda assunta per eseguire il benchmark l'avrebbe rilevato.

Il benchmark flat supera la produzione teorica della farm? Potete mostrare che i risultati sono semplicemente non realistici?

Potete in qualche modo eseguire alcuni benchmark indipendenti che mettono in discussione il benchmark doctored?

Il fornitore non dispone di un monitoraggio in tempo reale delle metriche di base delle prestazioni come CPU, IO, larghezza di banda …? Avreste dovuto eseguire alcuni di questi durante il benchmark divulgato. So che il senno di poi è 20/20 ma comunque.

Non state cercando il problema. Conosci il problema e ora devi solo provarlo. La vostra fonte vi ha reso un grande servizio esponendo il problema. Può provare il problema senza esporre la fonte?

Forse basta andare con:

Questi parametri di riferimento non corrispondono alle prestazioni dell'applicazione. O l'applicazione sta scaricando un carico maggiore di quello che mi aspetto, i server non stanno scaricando queste prestazioni, oppure mi manca semplicemente qualcosa. Ecco alcuni elementi da esplorare… E nella lista degli articoli da esplorare c'è un punto di riferimento a sorpresa.

L'uscita della persona che ha fornito le informazioni è difficile. Probabilmente verrebbe licenziato. E probabilmente verrebbe licenziato in un modo molto brutto in quanto è difficile trovare un altro lavoro. Cercherei con difficoltà di trovare un modo per smascherarlo senza smascherare la persona. Personalmente non lo rivelerei. Senza una verifica indipendente non reggerebbe comunque.

Se la performance nella vita reale non corrisponde alla performance durante il test (e avete i dati per dimostrarlo), la soluzione dovrebbe essere semplice: notificate il provider, e se la performance non migliora, annullate il contratto.

Non dovete dire come avete scoperto che il test è stato truccato, solo che la performance giornaliera non corrisponde al benchmark del test (potete anche chiedere “innocentemente”: è cambiata qualche configurazione hardware/software dal benchmark?) Ma i vostri avvocati potrebbero essere interessati a parlare con l'azienda che avete pagato per il costoso benchmark - era lo stesso fornitore di servizi, o diverso?

Per quanto riguarda il vostro leaker: Non rivelate il suo nome, che lo getterebbe sotto un autobus senza un buon motivo e senza alcun beneficio per la vostra azienda. Ma potreste voler rimanere in contatto ed eventualmente restituire il favore: avvertirlo della necessità di cercare un lavoro diverso prima del crash (quando la cancellazione del contratto è un'informazione pubblica, non prima). Capisco il dilemma di non potergli fornire una buona referenza (o forse si può - dicendo che è stato utile e che avrebbe fatto il miglio in più per comunicare con il cliente).

Il modo più semplice per restituire il favore sarebbe quello di porlo a prendere un caffè qualche volta (fuori dai locali di entrambe le aziende, e dirgli che l'incontro è strettamente ufficioso ). Potrebbe essere poco dopo che la cancellazione del progetto è diventata pubblica, non prima, e spiegategli in che tipo di politica aziendale si è impigliato, e quale complicato dilemma etico è lì libero per la presa (per entrambi). Così sarà in grado di affrontarlo meglio la prossima volta. Sembra essere un ragazzo onesto e disponibile, possibilmente non ancora informato sulle complessità della vita - e voi avete un'ottima possibilità di aiutarlo a farlo, aiutarlo a imparare la lezione senza danneggiare la sua carriera.

Non siete sicuri di come reagirà la prossima volta: non dirvelo, o non imbrogliare i clienti? :-)

Le altre risposte sono davvero buone, ma non ho visto questo esplicitamente dichiarato in nessuna di esse -

Perché la sua raccomandazione non dovrebbe essere solo che il loro fornitore esterno di benchmarking effettui un altro test, dato che il loro metodo di test era difettoso? Se sapete che le informazioni sono state pubblicate e i servizi sono stati disattivati, sono sicuro che potete trovare una norma NIST o ISO che indichi la procedura corretta per questo tipo di test. Potreste anche cercare informazioni sulle migliori pratiche presso ISACA.

Non importa quello che sapete, basta che pubblicando il tempo e l'ambiente che viene alterato, non è un test valido. Anche allora, potrei andare all'azienda di test esterna e chiedere loro cosa ne pensano.

Sembra che sia l'azienda di benchmarking che il fornitore siano stati coinvolti nel creare una situazione per risultati non accurati e che IMO sia almeno negligente e al massimo * collusiva **.

Ancora una volta, non so per quale lavoro siete stati assunti, ma se qualcosa di tutto ciò rientra nel campo di applicazione, è un buon modo per evitare di divulgare qualsiasi informazione riservata.

Rivelate tutto al vostro cliente e ditegli le informazioni che avete. Avete l'obbligo professionale di fornirgli il miglior servizio possibile e non avete alcun obbligo professionale nei confronti dello sviluppatore junior del centro dati. Il vostro cliente vi ha letteralmente pagato per scoprire cose come questa.

Dopo che avete divulgato le informazioni che avete acquisito (per le quali il vostro cliente vi paga). Discutete la verifica di ciò che ha detto lo sviluppatore junior.

In caso di verifica - sicuramente lavorate con un altro fornitore.

Come persone, cerchiamo di essere gentili e corretti e questo è ammirevole. Come professionisti avete l'obbligo di fornire il miglior servizio possibile al vostro cliente.

Il semplice fatto che l'applicazione reale abbia “prestazioni software orribili”, mentre nei test “i risultati sono andati bene” dovrebbe suonare un campanello d'allarme per chiunque e può essere usato come punto di partenza per discutere, o sfidare i test. Si potrebbe/devete sollevare sospetti sulla fattoria dei test con il cliente su questa discrepanza, specialmente se si è “responsabili per loro”.

Inoltre, la questione originale a portata di mano rimane irrisolta e aperta ad ulteriori analisi, con o senza il coinvolgimento dell'azienda esterna, enormemente pagata. Per molte tecnologie sono disponibili strumenti per monitorare le prestazioni di produzione senza avere un impatto reale su di essa; potreste volerli utilizzare per quantificare “orribile”. Aggiungendo alla risposta di HopelessN00b , questo sarebbe un altro modo per verificare.

La vostra fonte è uno “sviluppatore junior impiegato dall'host del server, che ha blaterato a riguardo”. In altre parole, per quanto vi riguarda, non avete fatto assolutamente nulla di sbagliato nell'ottenere quelle informazioni.

Il vostro dovere non è verso l'ISP, o lo sviluppatore junior presso l'ISP, ma verso il vostro cliente. Quindi credo che dovreste informare il vostro cliente. Potreste menzionare il tipo di fonte di cui disponete senza menzionare la fonte effettiva. Cosa accadrà: Il vostro cliente smetterà di usare un ISP che sta imbrogliando, l'ISP perderà il cliente che sta imbrogliando, e lo sviluppatore junior, si spera, non parlerà più di questo sono in pericolo.