Как [вежливо?] Сказать продавцу программного обеспечения, что он не знает, о чем говорит

Настоящий вопрос в том, кто здесь главный? Если вы не можете реально переключиться на альтернативного поставщика, то у них есть власть, и все, что вы действительно можете сделать, это согласиться с тем, что они скажут, и надеяться, что все получится. Не самая счастливая ситуация! В противном случае, я предлагаю вам попросить другого представителя (как говорили другие), но ясно дать понять, что вы недовольны сервисом и будете искать в другом месте, если они не смогут выполнить эту работу.

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

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

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

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

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

Для этой специфической ситуации (когда у вас есть VMware и разработчики приложений или третья сторона, которая не понимает распределения ресурсов), я использую метрики, полученные из vCenter Operations Manager (vCops - скачать демо при необходимости), чтобы точно определить реальные ограничения, узкие места и требования к размеру VM(ов) приложения.

Иногда я был в состоянии удовлетворить более упрямых потребителей путем изменения VM оговорки или изменения приоритетов для обработки спорных сценариев; " Если RAM|CPU жесткие, ВАШИ ВМ будет иметь преимущественную силу!". Плохие вещи случились, когда я позволил разработчикам программного обеспечения диктовать свои требования к моим кластерам vSphere без реального анализа.

Но в целом, цифры и данные должны выиграть.

Пример того, что я использовал, чтобы оправдать размер ВМ для разработчика приложения Tomcat:

Dev: ВМ нужна MOAR cpu!

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

Раньше я работал в службе поддержки - и часть того, что вы спрашиваете звучит очень рационально (и, вероятно, так и есть): но есть несколько вопросов, которые вы должны задать себе перед тем, как просто делать "повышение производительности", они просят

• , вы уже работаете по крайней мере в соответствии с заявленными поставщиком минимальными системными требованиями?
• если вы используете хотя бы минимальные sysreqs, вы уже используете их "рекомендуемые" системные настройки?

Поставщики будут 99 раз из 100 (по моему опыту - как со стороны поддержки, так и со стороны клиента/полевой стороны) даже не решать проблемы, связанные с производительностью, пока/не будут ли системы соответствовать тому, к чему призывает их документация. Может быть, это система, которая прекрасно работает 99.5% времени с 1 CPU и 512M RAM - но если системные требования говорят 4 CPU и 4G RAM, а у вас только 2 CPU и 1G RAM, то они вполне в рамках своих прав требовать выделения большего количества ресурсов^*.

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

Есть также немалый шанс, что проблемы, которые вы видите, даже не являются частью "их" программного обеспечения, а компонентом, на который они полагаются из какого-то другого источника (поставщика, библиотеки OSS и т.д.). Я столкнулся именно с этой ситуацией, связанной с размером подкачки, BEA WebLogic и Sun JRE на клиенте несколько лет назад.

tl;dr:

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

^{*_{Если действительно не "нужны" эти дополнительные ресурсы, то, скорее всего, вы сможете подать заявку на ошибку doc / RFE для будущих версий - но не продвигайте этот путь, пока не продемонстрируете, что проблема не в этом}
^_{электронная книга, которую я написал, может оказаться полезной для вас по этой теме: Отладка и поддержка программных систем}}

При условии, что вы уверены, что находитесь в пределах заданных спецификаций системы, которые они документируют.

Тогда любые претензии, которые они выдвигают в связи с потребностью в большем объеме оперативной памяти или процессора, должны быть в состоянии создать резервную копию. Как эксперты в своей системе я привлекаю людей к ответственности за это.

Спросите их об особенностях.

• Какая информация, предоставленная в системе, указывает на то, что требуется больше оперативной памяти, и как вы это интерпретировали?

• Какая информация, предоставленная в системе, указывает на то, что требуется больше CPU, и как вы это интерпретировали?

• Данные, которые у меня есть - на первый взгляд - противоречат тому, о чем вы мне говорите. Не могли бы Вы объяснить мне, почему я интерпретирую это неправильно?

• Я интерпретирую этот [очевидную серию данных] как [очевидную интерпретацию]. Можете ли Вы подтвердить, что я интерпретирую это правильно в отношении моей проблемы?

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

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

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

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

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

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

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

Когда у нас возникают серьезные проблемы с нашими локальными приложениями, которые поддерживаются контрактами на поддержку от поставщиков, и поставщики начинают свой танец уклонения (который всегда, кажется, включает в себя странные, не связанные с данными требования к большему количеству CPU или оперативной памяти), мы обычно делаем эти 3 вещи:

1. Эскалация приоритета до системного эквивалента - они обычно препятствуют, но обычно отступают, когда вы объясняете, что это фактически непригодно, даже если это технически "работает". Считайте это серьезной проблемой, которую они должны решить. Здесь мы называем это "тигровой командой", которая собирается ежедневно для получения обновлений статуса от всех заинтересованных сторон. Обычно поставщик просит вас что-то менять. Если это prod-система, то это проблематично, но если вы хотите, чтобы они помогли, вам нужно будет взять на себя ответственность за изоляцию проблемы, так что это поможет, если у вас есть среда разработки/запуска, в которой вы можете запустить тесты.

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

3. Предоставьте им (конечно же, под NDA) ваш реальный набор данных, чтобы они могли запускать/воспроизвести его по-настоящему, вместо того, чтобы угадывать. В нашем случае большинство проблем с приложениями, предоставляемыми поставщиком (как кратковременные, так и хронические), часто оказываются проблемами с сопровождающими их базами данных, предоставляемыми поставщиком. Я не могу сосчитать количество раз, когда мы это делали, и они, наконец, определили проблему до чего-то неожиданного в реальных данных; странные артефакты от апгрейдов приложений 2 года назад, где что-то не конвертировалось чисто; черствые записи, обнажающие проблему с настройками GC; запросы, работающие не совсем корректно, потому что значения наших данных ломают какую-то трансмоговую рутину в коде производителя, и т.д. Вещи, которые мы никогда не смогли бы определить самостоятельно.

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

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

Я собираюсь высказать свое мнение со стороны производителя.

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

Профилировщик булитина в системе показал, что скорость процессора (или, возможно, памяти) системы была отвратительно медленной, что-то вроде 100 МГц, а не ожидаемых 2 ГГц. Удвоение процессора, предоставляемого ВМ, не изменило симптома, и они подумали, что мы расточительны.

Так как они не могли получить более быстрый процессор (большее количество процессоров не помогло бы), мы затем попробовали поменять местами ВМ TEST и PROD. Затем проблема появилась на TEST на следующий день. Затем мы попытались продвинуть одного из клиентов на отдельный (безсерверный) экземпляр. На этой рабочей станции не было проблем во время удушья сервера.

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

Наконец, я [инженер] (у меня не было поддержки от тех, кто занимался выделенными ролями поддержки) попросил специально физический ящик. Клиент кричал, что это кровавое убийство, но ни у кого не было другого потенциального решения. Что вы знаете, проблема волшебным образом исчезла.

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

Они наверняка подумали, что я был полон этого. А я и не был. У меня не было выбора.

EDIT, Update from years later:

With more more customers wanting to run on VMs and management willing to try to solve the problem at all cost, we got good VM hardware. Я смог построить специализированную программу для записи ВМ, которая работала в пользовательском пространстве (и не требовала никаких привилегий) на двух одноядерных ВМ с 512 Мб оперативной памяти, которая была способна истощать 1/3 производительности памяти из другой одноядерной ВМ, при этом всего 4 ядра из 16 использовалось на ВМ-хосте, и большая часть ее тарана все еще свободна. Программа не подавала никаких сигналов тревоги и ничего необычного не показала ни на ВМ-хосте, ни на гостях, за исключением того, что доступ к памяти был медленным.

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

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

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

Каковы реальные проблемы, о которых сообщается, и каковы ожидания пользователей. Если пользователь говорит что-то "слишком долго", спросите его, что именно "это" (чтобы вы могли это воспроизвести), как долго, по его мнению, это должно занять, и почему он думает, что это должно занять столько времени. Если их ожидания разумны, измерьте фактическую производительность и системное воздействие того, что они пытаются сделать. Тот факт, что ваша система показывает 30%-ный всплеск в течение месяца, не означает, что она не работает на уровне >100%, когда пользователь пытается выполнить свой запрос. Если вы можете продемонстрировать поставщику, что процессор и память не перегружены проблемной задачей, то вы можете попросить поставщика обосновать рекомендации, которые обойдутся вам в копеечку.