プロバイダは「不正行為」だが、どうやってそれを知ったのかは公表したくない

あなたがすべきことは、このジュニア開発者に言われたことを独自に検証することです。一つには、彼の言ったことが正確なのかどうか、実際にはわからないということです。どこかで誤解があったのかもしれませんし、技術的な観点から全体像を把握しておらず、不完全なデータを伝えているのかもしれません。彼らが言うように、 “trust, but verify.”

別の理由で、あなたが言われたことを検証することは、あなたのソースを保護します。誰も彼があなたに何かを言ったことを知る必要はありません、あなたは何が起こったかの証拠としてデータを保持することができますので、あなたが誰かによって密告されたという事実を完全に省略します。あなたはどのようにしてこれを検証するのか、技術的な詳細を提供していませんが、まともなシス テム管理者やシステムエンジニアが検証するのは難しいことではなさそうです。

もちろん、あなたの情報源があなたに言ったことを単に述べ、報復を防ぐために情報源を名乗らない/名乗らない/名乗らないという選択肢もあります。しかし、自分自身を確認することは、ソースを持つことさえもポイントの横にあるように、より良いアプローチです。

この場合のジュニアプログラマーへのあなたの心配は立派ですが、これはあなたの法的義務があなたのクライアントへの状況であることを心に留めておいてください。そうは言っても…

私の顧客は訴訟を起こさないでしょうが、確かにそのプロバイダを捨てるでしょう。私たちは彼らの最も重要な顧客の一人です。

あなたのクライアントはプロバイダを捨てるでしょうし、プロバイダが不正をしているので、なぜあなたはプロバイダを捨てることを勧める以外に何もしないのでしょうか？

有利なことに、あなたはあなたのソースを漏らす必要はありません。実際には、あなただけのプロバイダのパフォーマンスは、彼らが支払っているものを満たしていないので、それは離れて歩くための時間だということをあなたのクライアントに伝えることができます。もし、サービス提供者が事前にテストのことを知っていたので、通常は提供していないテストのために余分なリソースを割り当てたのではないかと疑っていると言えばいいでしょう。そうすれば、サービス提供者に解雇されることは確実に避けられます。また、サービス提供者が契約違反であなたのクライアントを訴えようとした場合には、証人として彼が周りにいることを確認しています。

これに少しだけ

あなたが知っている限りでは、プロバイダはテスト中にサーバーをファームに追加しています。あなたの顧客がベンチマークのために莫大な金額を支払った場合、あなたはベンチマークを実行するために雇われた会社がそれを拾っていることを期待していたはずです。

ベンチマークはファームの理論的な出力を超えていますか？ベンチマークの結果が現実的でないことを示すことができますか？

どうにかして、doctoredベンチマークを疑問に持ってくるいくつかの独立したベンチマークを実行することができますか？

プロバイダは、CPU、IO、帯域幅などの基本的なパフォーマンス指標をリアルタイムで監視していないのですか？開示されたベンチマークの間にそれらのいくつかを実行する必要があります。私は後悔は20/20であることを知っていますが、それでも。

あなたは問題を探していません。あなたは問題を知っているし、今、あなたはちょうどそれを証明する必要があります。あなたのソースは、問題を公開することによって、あなたに素晴らしいサービスをしました。

多分、次のようにしてください:

これらのベンチマークは、アプリケーションのパフォーマンスと一致していません。アプリが思ったよりも大きな負荷をかけているか、サーバーがそのパフォーマンスを発揮していないか、何かが欠けているだけです。ここに探索すべき項目があります… 探索すべき項目のリストには、意外なベンチマークがあります。彼はおそらくクビになるだろう。そして、おそらく別の仕事を見つけるために、そのハードで非常に悪い方法で解雇された。私は人を公開せずにこれを公開する方法を見つけるために懸命に見るだろう。個人的には、私はそれらをアウトにしないだろう。独立した検証がなければ、それはおそらくとにかく持ちこたえられないだろう。

もし、実生活でのパフォーマンスがテスト中のパフォーマンスと一致しない場合（そして、それを証明するデータがある場合）、解決策は簡単です。しかし、あなたの弁護士は、あなたが高価なベンチマークのために支払った会社に話をすることに興味があるかもしれません - それはサービスプロバイダと同じだったか、または異なっていましたか？

あなたのリークについて。**彼の名前を公表しないでください。しかし、あなたは連絡先に滞在し、おそらく好意を返すためにしたい場合があります：クラッシュの前に別の仕事を探すために必要性について彼に警告する（契約のキャンセルは、前ではなく、公開情報である場合）。私は、あなたが彼に良い参考資料を提供できないというジレンマを理解しています（または、あなたができるかもしれません - 彼は親切だったと言って、顧客とのコミュニケーションのために余分なマイルを行くだろう）。

恩返しの最も簡単な方法は、いつかコーヒーのために彼を連れて行くことでしょう（両方の会社の敷地外で、会議は厳密にオフレコであることを彼に伝える）。それは、プロジェクトの中止が公になってからではなく、プロジェクトの中止が公になった直後でも構いませんし、彼がどのような企業政治**に巻き込まれてしまったのか、また、どのような複雑な倫理的ジレンマがあるのかを説明してください。そうすれば、彼は次回、より良い対処ができるようになるでしょう。彼は正直で親切な人のようですが、おそらく人生の複雑さについてはまだ何もわかっていないようです。)

他の回答は本当に良いものですが、私はその中でこのことが明示的に述べられているのを見ませんでした -

なぜあなたの推奨は、外部のベンチマークベンダーがテスト方法に欠陥があったので、別のテストを実行することだけではないでしょうか。情報が公開され、サービスがオフになっていたことを知っていれば、私はあなたがテストのこのタイプのための適切な手順を述べているNISTまたはISO標準を見つけることができると確信しています。ISACAのベストプラクティス情報を求めることもできます。

知っていることは関係ありませんが、時間と環境が変更されていることを公開することで、有効なテストではないということだけです。ベンチマーキングの会社とプロバイダの両方が、不正確な結果のために状況を作成することに関与していたように聞こえますが、IMOは少なくとも過失**、せいぜい 談合**のように聞こえます。

あなたのクライアントに everything を開示して、あなたが得た情報を彼に伝えてください。あなたには可能な限り最高のサービスをクライアントに提供するプロとしての義務があり、データセンターの後輩開発者に対してはプロとしての義務はありません。あなたのクライアントは文字通り、このようなことを発見するためにあなたにお金を払っているのです。

ジュニア開発者が言ったことを確認することを話し合ってください。プロとして、あなたはクライアントに可能な限り最高のサービスを提供する義務があります。

テストでは「結果は問題なかった」のですが、実際のアプリケーションは「恐ろしいソフトウェア性能」を持ってい るという単純な事実は、誰にとってもベルを鳴らすべきであり、議論やテストに挑戦するための出発点として使われることができます。あなたは、この矛盾についてクライアントとのテストファーム上で疑惑を提起することができます。ツールは、実際に影響を与えずに生産パフォーマンスを監視するための多くの技術のために利用可能である;あなたはそれを使用して「恐ろしい」を定量化するためにしたいかもしれません。HopelessN00b さんの回答 ](https://workplace.stackexchange.com/a/62897/) に補足すると、これは検証のもう一つの方法になります。

あなたの情報源は、「サーバホストに雇われていて、それについて口うるさく言っていた下級開発者」です。

あなたの義務は、ISPやISPの開発者ではなく、あなたのクライアントにあるのです。ですから、あなたはクライアントに知らせるべきだと思います。実際のソースには触れずに、どのようなソースがあったのかに言及するかもしれません。そうするとどうなるでしょうか。クライアントは不正を行っている ISP を利用しなくなり、ISP は不正を行っているクライアントを失い、後輩開発者はこれ以上このことを口にしないようにしてほしいと願っていますが、危険な状態になります。