題:
提供者在“作弊”,但我不想透露自己的發現
Sergey
2016-03-01 23:46:03 UTC
view on stackexchange narkive permalink

我是一位經驗豐富的IT開發人員,最近改用了IT諮詢。我當前的項目涉及在我的客戶租用的服務器場中對抗可怕的軟件性能。

我的客戶最近為該租用的服務器場的外部基準測試支付了巨額費用,結果很好。今天,我發現服務器場的主機知道了測試的確切時間,並且他們 Volkswagened (即在測試過程中更改了設置,以產生比實際使用情況更好的結果)通過向服務器場臨時添加其他資源。

事實證明,我的客戶端實際上將測試時間發佈到了主機。測試是在晚上進行的,以免干擾實時用戶,但是主機需要關閉一些夜間自動執行的任務-否則,長時間運行的同步將改變結果,而白天不會發生這種情況。

我應該敲響警鐘,讓我的客戶知道,因為我對此負責。不幸的是,我是通過服務器主機僱用的一名初級開發人員獲得的信息的,他對此developer之以鼻(可能不知道這些額外的資源是秘密的)。在過去的幾周里,他一直非常樂於助人-實際上,我在該項目中最值得信賴和最寶貴的聯繫-我不想花掉他的工作。

即使他不知道,關於機密性,他給我打電話給他,有點違背了使用票務系統的常規規定。這為我實現目標提供了很大幫助-並帶來了困境。

我願意接受任何建議,無論是道德的還是務實的。

如果有問題,我的客戶不會提起訴訟,但肯定會放棄該提供商,而我的客戶是他們最重要的客戶之一。

您不能*沒有*告訴提供者嗎?這樣便有了數據,而不是推論。
評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/36533/discussion-on-question-by-sergey-provider-is-cheating-but-i-dont-want-to- dis)。
關於“添加其他資源”的含義是否有一定的澄清可能性?什麼是“資源”?
您是否可以從測試中看到任何指標,從而獨立於您的聯繫人指出這一點?測試是否顯示正在運行的節點數,可用的RAM和MIPS等等?
可能是[我的雇主強迫其僱員欺騙客戶,我該如何處理這種情況?](http://workplace.stackexchange.com/questions/62686/my-employer-is-forcing-its-employees-欺騙客戶我該如何處理)
@user2284570在基準測試中,很可能是重罪帳單欺詐,很可能是非犯罪性欺詐,這是完全不同的事情。
@HopelessN00b這是一個自動註釋,這意味著mod驗證了我的標誌。
@user2284570不,這是一個自動註釋,表示您已投票或標記為要重複。它並不表示其他人都同意它。。。由於我有足夠的代表可以看到親密的票數,因此我可以驗證對此問題沒有實際的親密的票數,並且到目前為止,兩個評論此標記的人都不同意用它。
八 答案:
HopelessN00b
2016-03-02 03:25:20 UTC
view on stackexchange narkive permalink

您應該做的是獨立驗證此初級開發人員告訴您的內容。首先,您實際上並不知道他說的是正確的。在某處可能存在溝通不暢,他可能會誤解,也許他沒有從技術角度了解整體情況,並且正在傳遞不完整的數據,等等。正如他們所說,“ 信任,但要驗證。” em>“

由於另一個原因,驗證您的提示可以保護您的信息來源。沒有人需要知道他告訴過您任何事情,因為您可以保留數據作為發生情況的證據,而完全忽略您遭到任何人欺騙的事實。您尚未提供足夠的技術詳細信息來建議如何進行驗證,但聽起來像這樣的系統管理員或系統工程師根本很難做到這一點。

HTTPS://恩.Wikipedia.org/wiki/parallel_construction
@GrzegorzOledzki是的,無論如何都不是一個新主意,但在OP的情況下,它的好處是實際上是合法的,而不是偽造,非法竊聽和嚴重違憲的遺跡,這使美國開國元勳在墳墓中旋轉。 :/
考慮到對舉報人的普遍不佳對待,指出您自己有消息來源可能是其他人開始挖掘並弄清楚您的消息來源的充分理由。最好不要提及它。
第一段絕對是要走的路。
GreenMatt
2016-03-02 00:13:31 UTC
view on stackexchange narkive permalink

儘管在這種情況下您對初級程序員的關心令人欽佩,但請記住,在這種情況下,您對客戶負有法律義務。就是說...

我的客戶不會提起訴訟,但肯定會丟棄該提供商。我們是他們最重要的客戶之一。

由於您的客戶會丟棄該提供程序,並且由於該提供程序是不誠實的,因此您除了建議轉儲該提供程序之外,還需要做什麼?

可以說,您無需透露您的來源。實際上,您可以告訴您的客戶,由於提供商的績效無法滿足他們所支付的費用,因此該該走了。如果按下該按鈕,您可以說,由於服務提供商已提前了解測試,因此您懷疑他們為正常無法提供的測試分配了額外的資源。

如果您真的是 希望保護初級程序員並有一個可以填補的空缺,您可以自己僱用他,或者您的客戶可以僱用他。這樣,他一定可以避免被服務提供商解僱。另外,如果服務提供商試圖起訴您的客戶違反合同,您一定會邀請他為證人。

我建議放棄最後一段。儘管有免責聲明,但它肯定是作為法律建議而來的,根據OP提供的信息,它似乎並不實用。我認為沒有它你的答案就很好。
在偽造之痛下,初中生有法律義務向法院訴說真相,全部真相,只有真相。如果您要提供法律建議,請保持準確,否則請忽略它。
-1
我喜歡這個答案,因為它是基於動作的。操作是您的客戶轉儲提供程序。因此,您只需要向客戶說明情況。
@user1717828:好的,最後一段已經過修改。更好?
建議在測試後走開表明沒有問題可能無法正常工作。客戶可能會(正確地)問,如果測試(貌似)表明提供方方面沒有問題,為什麼。因此,首先收集證據(HopelessN00b的答案)似乎更好。
paparazzo
2016-03-02 00:38:17 UTC
view on stackexchange narkive permalink

對此有一點了解

據了解,提供商在測試期間將服務器添加到服務器場中。如果您的客戶為基準測試支付了巨額費用,那麼您應該希望僱用執行基準測試的公司能夠提高這一基準。

基准單位是否超出農場的理論產量?您能證明結果只是普通的,不現實的嗎?

您能以某種方式運行一些獨立的基準測試來質疑醫生基準測試嗎?

提供程序是否沒有對CPU,IO,帶寬等基本性能指標的實時監控?您應該在公開的基準測試中運行其中一些程序。我知道事後的看法是20/20,但仍然如此。

您不是在尋找問題。您知道問題所在,現在只需證明一下即可。您的消息來源通過揭示問題為您提供了出色的服務。可以在不暴露源代碼的情況下證明問題嗎?

也許可以隨便使用:

這些基準測試與應用程序的性能不匹配。應用程序正在承擔比我預期更大的負載,服務器沒有在發揮這種性能,或者我只是簡單地缺少一些東西。這是要探索的項目...在要探索的項目列表中,有一個令人驚訝的基準。

淘汰提供信息的人員是一項艱鉅的任務。他可能會被解僱。而且很可能以一種非常糟糕的方式解僱,以致於很難找到另一份工作。我很難找到一種方法來揭露這一點而不暴露他人。我個人不會。沒有獨立的驗證,它就不會阻止。

Peter M. - stands for Monica
2016-03-02 03:30:22 UTC
view on stackexchange narkive permalink

如果現實生活中的性能與測試期間的性能不匹配(並且您有數據證明這一事實),則解決方案應該很簡單:通知提供商,如果性能沒有提高,則取消合同。 / p>

您不必告訴您如何發現測試已被操縱,只需每日性能與測試基準不匹配(您甚至可以“天真地”問:做了一些自基準測試以來硬件/軟件配置發生了變化?)。但是您的律師可能會對與您為昂貴的基準付費的公司進行交流感興趣-是與服務提供商相同還是不同?

關於您的洩密者:請勿透露其姓名, ,這會無緣無故地把他扔在公車上,對您自己的公司沒有好處。但是您可能希望保持聯繫並可能得到幫助:警告他有關在墜機事故發生之前需要尋找其他工作的警告(當取消合同是公共信息時,而不是之前)。我了解您無法為他提供良好參考的困境(或者也許您可以-說他很有幫助,並且會竭盡全力與客戶溝通)。

最簡單的回報方式是在某個時間(在兩家公司的辦公場所外,並嚴格地開會)帶他去喝咖啡。記錄)。可能要在取消項目後不久才公開,而不是在不久之前,然後向他解釋他陷入了什麼樣的公司政治,以及有什麼複雜的道德困境可供自由選擇(對於兩者而言)你的)。因此,他下次將可以更好地應對它。他似乎是一個誠實和樂於助人的人,可能還不了解生活的複雜性-而且您有極好的機會幫助他找尋線索。幫助他學習課程而不會損害他的職業。

不確定他下次會如何反應:不告訴您,還是不欺騙客戶? :-)

“ *取消合同的時間是公開信息,而不是之前*”出於好奇,為什麼不能提前警告他?
@QPaysTaxes我不知道Peter Masiar的理由是什麼,但我建議,如果這不是公眾知識,那麼OP可能在法律上有義務對他和他的客戶之間的事情保持沉默,並且不要透露任何非公開的信息。 。如果OP之前要告訴開發人員,那麼他將與開發人員處於相似的位置。由於開發人員將此信息洩漏給了OP,因此他可能會無意間從OP洩漏了該信息。
@QPaysTaxes-pedro_sland正確了
Raystafarian
2016-03-02 16:06:21 UTC
view on stackexchange narkive permalink

其他答案確實很好,但是我在任何一個答案中都沒有明確指出-

為什麼您不建議僅由其外部基準測試供應商執行另一項測試作為其測試方法有缺陷。如果您知道信息已發布且服務已關閉,那麼我確定您可以找到NIST或ISO標準,其中闡明了此類測試的正確程序。您甚至可以從ISACA中尋求最佳實踐信息。

您所知道的都無所謂,只是通過發佈時間和更改的環境,這不是有效的測試。即使那樣,我還是可以去外部測試公司,問他們在想什麼。

基準測試公司和提供者之類的聲音都參與了創建不准確結果的情況,並且 IMO 至少是過失和最多 collusive

同樣,我不知道您的工作是什麼,但是如果其中任何一項在範圍內,這是避免洩露任何機密信息的好方法。

測試有缺陷-這就是* I *的想法。
當問題表明他的客戶是洩露測試時間的客戶時,我看不到如何將責任歸咎於外部基準測試小組。
@pydsigner是的,您是對的,我讀錯了。我想這將排除串通的可能性,但仍然可能出現過失。我去找客戶,問他們到底在想什麼,而不是外部小組。
Benjamin Gruenbaum
2016-03-02 17:53:24 UTC
view on stackexchange narkive permalink

向您的客戶披露一切,並告訴他您所獲得的信息。您有專業的義務為他提供最好的服務,而您對數據中心的初級開發人員也沒有專業的義務。您的客戶實際上是付錢給您發掘這樣的事情。

在您披露所獲得的信息之後(客戶正在為您付款)。討論驗證初級開發人員的意見。

如果可以退房-一定要與其他提供者合作。

作為人們,我們努力做到友善公正,這令人欽佩。作為專業人員,您有義務為您的客戶提供最佳服務。

如果不先執行HopelessNoob所說的話,這似乎是一個糟糕的主意。
不論是否專業,您都可能對初級開發人員負有道義上的義務,他們冒著生活中面臨巨大問題的風險,充其量只能是當一名好的舉報人(並且履行*他**的專業義務!),或者最糟糕的是發表無辜的評論。
當然,您確實有義務為您的客戶提供最好的服務,但是我看不出初級開發人員如何使該服務明顯更好。您當然不希望被別人認識,因為一個人不會冒著工作的危險就無法進行真誠的交談。
Ram
2016-03-04 04:09:36 UTC
view on stackexchange narkive permalink

一個顯而易見的事實,即實際應用程序具有“可怕的軟件性能”,而在測試中“結果很好”,應該讓任何人振作起來,並且可以用作討論或挑戰測試的起點。您可能/應該與客戶就此差異在測試場上產生懷疑,特別是考慮到您“對他們負責”。

此外,當前的原始問題仍未解決,可以進行進一步分析,不論是否涉及高薪的外部公司。許多技術都可以使用工具來監視生產性能,而不會真正影響生產性能。您可能想用它來量化“可怕”。加上 HopelessN00b的回复,這將是另一種驗證方式。

gnasher729
2017-07-10 23:43:30 UTC
view on stackexchange narkive permalink

您的消息來源是“服務器主機僱用的初級開發人員,對此who之以鼻”。換句話說,就您而言,獲取該信息絕對沒有錯。

您的職責不是對ISP或ISP的初級開發人員,而是對您的客戶。因此,我認為您應該通知您的客戶。您可能會提到您擁有哪種來源,而沒有提及實際來源。將會發生什麼:您的客戶端將停止使用正在作弊的ISP,ISP將失去他們在作弊的客戶端,而初級開發人員將希望不再談論此事,否則將有危險。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...