Провайдер "обманывает", но я не хочу раскрывать, как я узнал

Что вы должны сделать, так это самостоятельно проверить, что вам сказал этот младший разработчик. Во-первых, вы на самом деле не знаете, что то, что он сказал, верно. Может быть, где-то произошло недопонимание, может быть, у него нет полной картины с технической точки зрения и он передает неполные данные и т.д. Как говорится, “trust, but verify.”

По другой причине, проверка того, что вам сказали, защищает ваш источник. Никто не должен знать, что он вам что-то сказал, потому что вы можете держать данные в качестве доказательства того, что произошло, и полностью опустить тот факт, что вам кто-то сообщил. Вы не предоставили достаточно технических деталей, чтобы посоветовать, как вы сможете это проверить, но, похоже, приличному сисадмину или системному инженеру будет совсем не трудно это сделать.

Конечно, всегда есть возможность просто указать то, что сказал вам ваш источник, и сказать, что для предотвращения возмездия, вы предпочитаете/не можете/не хотите называть ваш источник. Но проверка себя, так что даже наличие источника не имеет смысла, является лучшим подходом.

Хотя ваша забота о младшем программисте в этом случае достойна восхищения, имейте в виду, что это ситуация, когда ваше законное обязательство перед вашим клиентом. При этом…

Мой клиент не стал бы подавать в суд, но, безусловно, бросил бы этого провайдера. Мы являемся одним из их самых важных клиентов.

Поскольку ваш клиент бросит провайдера, и поскольку провайдер нечестен, зачем вам что-либо делать, кроме как рекомендовать бросить провайдера?

Вероятно, вам не нужно разглашать свой источник. На самом деле, вы можете просто сказать своему клиенту, что раз производительность провайдера не соответствует тому, за что он платит, то пришло время уйти. Если нажать на кнопку, то можно сказать, что раз поставщик услуг заранее знал о тестировании, то вы подозреваете, что они выделили дополнительные ресурсы на тест, который они не предоставляют нормально.

Если вы really хотите защитить младшего программиста и у вас есть слот, который он может заполнить, вы можете нанять его самостоятельно, или ваш клиент может нанять его. Таким образом, он наверняка избежит увольнения со стороны поставщика услуг. Кроме того, в случае, если поставщик услуг попытается подать в суд на вашего клиента за нарушение договора, вы уверены, что он будет рядом в качестве свидетеля.

Немного к этому

Из того, что вы знаете, провайдер добавил серверы в ферму во время тестирования. Если ваш клиент заплатил огромную сумму за бенчмарк, то вы должны были надеяться, что компания, нанятая для выполнения бенчмарка, подхватила бы его.

Плоскостной ли бенчмарк превышает теоретическую производительность фермы? Можете ли вы показать, что результаты просто не реалистичны?

Можете ли вы каким-то образом запустить некоторые независимые тесты, которые ставят под сомнение doctored эталон?

У провайдера нет некоторого мониторинга в реальном времени основных показателей производительности, таких как CPU, IO, пропускная способность …? Вы должны были запустить некоторые из них во время раскрытого бенчмарка. Я знаю, ретроспектива 20/20, но все же.

Вы не ищете проблему. Ты знаешь проблему и теперь тебе просто нужно доказать это. Ваш источник оказал вам большую услугу, разоблачив проблему. Можете ли вы доказать проблему, не разоблачая источник?

Может быть, стоит просто согласиться с:

Эти эталоны просто не соответствуют производительности приложения. Либо приложение выпускает большую нагрузку, чем я ожидал, серверы не выпускают, что производительность, или я просто пропустил что-то. Вот пункты, чтобы исследовать… И в списке пунктов для изучения есть сюрприз эталона.

Outing человек, который предоставил информацию является жестким. Скорее всего, его уволят. И, скорее всего, его уволят в очень плохом смысле, чтобы найти другую работу. Я бы усердно искал способ разоблачить это, не разоблачая человека. Лично я бы не стал их разоблачать. Без независимой проверки он вряд ли бы не выдержал.

Если производительность в реальной жизни не соответствует производительности во время теста (и у вас есть данные, чтобы доказать это), решение должно быть простым: уведомить провайдера, и если производительность не улучшается, расторгнуть контракт.

Вам не нужно говорить, как вы обнаружили, что тест был сфальсифицирован, только то, что daily производительность не соответствует тестовому эталону (вы даже можете “невинно” спросить: изменились ли некоторые аппаратные/программные конфигурации с момента эталона?). Но вашим юристам может быть интересно поговорить с компанией, которой вы заплатили за дорогой бенчмарк - он был таким же, как у провайдера услуг, или другим?

Относительно вашего утечки: ** не раскрывайте его имя,** которое будет бросать его под автобус без уважительной причины и без пользы для вашей собственной компании. Но, возможно, вы захотите остаться на связи и, возможно, вернуть услугу: предупредить его о необходимости поиска другой работы перед аварией (когда расторжение договора является публичной информацией, а не до этого). Я понимаю дилемму, что вы не можете предоставить ему хорошую рекомендацию (или, может быть, вы можете - говоря, что он был полезен и пойдет лишняя миля, чтобы общаться с клиентом).

Самый простой способ вернуть услугу было бы принять его за кофе иногда (за пределами помещений обеих компаний, и сказать ему, что Совета строго не для записи ). Это может произойти вскоре после того, как проект будет отменен, а не до того, как он станет публичным, и объяснить ему, в какую корпоративную политику он ввязался, и какая сложная этическая дилемма является бесплатной для взятия (для вас обоих). Так что в следующий раз ему будет легче с этим справиться. Он кажется честным и полезным парнем, возможно, еще не разобравшимся в тонкостях жизни - и у вас есть отличный шанс помочь ему разобраться; помочь ему усвоить урок без ущерба для его карьеры.

Не уверен, как он отреагирует в следующий раз: не расскажет или не обманывает клиентов? :-)

Остальные ответы действительно хороши, но я не видел, чтобы это было явно указано ни в одном из них -

Почему бы вам просто не порекомендовать своему внешнему поставщику провести еще один тест, так как их метод тестирования был ошибочным. Если вы знаете, что информация была опубликована и службы были отключены, я уверен, что вы можете найти NIST или ISO стандарт, указывающий правильную процедуру для такого типа тестирования. Вы даже можете обратиться за информацией о лучших методиках к ISACA.

Неважно, что вы знаете, просто публикация времени и изменяемой среды не является корректным тестом. Даже тогда, я мог бы пойти во внешнюю тестовую компанию и спросить их, о чем они думали.

Звучит так, как будто и компания стендовой разметки, и провайдер были вовлечены в создание ситуации за неточные результаты и были IMO по крайней мере negligent и по крайней мере * сговор **.

Опять же, я не знаю, на какую работу вы были наняты, но если что-то из этого входит в сферу действия, это хороший способ избежать разглашения любой конфиденциальной информации.

Раскройте все своему клиенту и расскажите ему о том, что у вас есть. У вас есть профессиональное обязательство предоставлять ему наилучшее обслуживание, и у вас нет профессионального обязательства перед младшим разработчиком дата-центра. Ваш клиент буквально заплатил вам за то, чтобы вы открыли для себя подобные вещи.

После того, как вы раскрыли полученную вами информацию (за которую ваш клиент платит вам). Обсудите, что сказал младший разработчик.

Если это подтвердится - обязательно работайте с другим провайдером.

Как люди, мы стараемся быть добрыми и справедливыми, и это достойно восхищения. Как профессионал вы обязаны обеспечить наилучший сервис для вашего клиента.

Простой факт, что фактическое приложение имеет “ужасную производительность программного обеспечения”, в то время как в тестах “результаты были в порядке” должен звонить в колокол для любого и может быть использован в качестве отправной точки для обсуждения, или оспорить тесты. Вы можете/должны вызвать подозрения на тестовой ферме у клиента по поводу этого несоответствия, особенно учитывая, что вы “несете за них ответственность”.

Кроме того, исходный вопрос остается нерешенным и открытым для дальнейшего анализа, с привлечением или без привлечения к участию в тестировании чрезвычайно высокооплачиваемой внешней компании. Инструменты доступны для многих технологий, чтобы контролировать производительность без реального влияния на нее; вы можете использовать это для количественного определения “ужасного”. Добавив к Ответ HopelessN00b , это будет еще один способ проверки.

Ваш источник - это “младший разработчик, нанятый хостом сервера, который о нем болтал”. Другими словами, что касается вас, вы не сделали абсолютно ничего плохого, получив эту информацию.

Ваша обязанность не перед ISP, или младшим разработчиком у ISP, а перед вашим клиентом. Поэтому я считаю, что вы должны проинформировать своего клиента. Вы можете упомянуть, какой источник у вас был, не упоминая фактический. Что случится: Ваш клиент перестанет использовать ISP, который жульничает, ISP потеряет клиента, которого жульничает, а младший разработчик, надеюсь, больше не будет об этом говорить, будет в опасности.