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


Не технический вопрос, а действительный, тем не менее. Сценарий:

HP ProLiant DL380 Gen 8 с 2 x 8-ядерными процессорами Xeon E5-2667 и 256 ГБ оперативной памяти ESXi 5.5. Восемь виртуальных машин для данной системы поставщика. Четыре виртуальных машины для тестирования, четыре виртуальных машины для производства. Четыре сервера в каждой среде выполняют разные функции, например: веб-сервер, сервер основных приложений, сервер OLAP DB и сервер SQL DB.

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

У нас были некоторые вопросы относительно производительности, и поставщик настаивает на том, что нам нужно предоставить производственной системе больше памяти и vCPU. Тем не менее, из vCenter ясно видно, что существующие ассигнования не затрагиваются, например: ежемесячный обзор использования ЦП на главном сервере приложений колеблется около 8%, а нечетный всплеск до 30%. Шипы, как правило, совпадают с программным обеспечением резервного копирования.

Аналогичная история по ОЗУ - самый высокий показатель использования серверов - ~ 35%.

Таким образом, мы проводим некоторые операции, используя Process Monitor (Microsoft SysInternals) и Wireshark, и наша рекомендация поставщику заключается в том, что они выполняют некоторую настройку TNS в первом экземпляре. Однако, это не относится к делу.

Мой вопрос: как мы можем заставить их признать, что статистика VMware, которую мы отправили, является достаточным доказательством того, что больше RAM / vCPU не поможет?

--- ОБНОВЛЕНИЕ 12/07/2014 ---

Интересная неделя. Наш ИТ-менеджмент сказал, что мы должны внести изменения в распределения VM, и теперь мы ждем некоторого времени простоя от бизнес-пользователей. Как ни странно, бизнес-пользователи говорят, что некоторые аспекты приложения работают медленно (по сравнению с тем, что я не знаю), но они собираются «сообщать нам», когда мы можем взять систему вниз (ворчать , ворчать!).

В стороне, «медленный» аспект системы, по-видимому, не является элементом HTTP (S), то есть «тонким приложением», используемым большинство пользователей. Похоже, что это «толстый клиент» устанавливает, используется основными финансами, что, по-видимому, «медленное». Это означает, что мы сейчас рассматриваем взаимодействие с клиентом и сервером в наших исследованиях.

Поскольку первоначальная цель вопроса заключалась в том, чтобы обратиться за помощью к вопросу о том, следует ли идти по маршруту «вытащить его» или просто внести изменения, и теперь мы вносим изменения, я закрою его, используя длинная шеяответ.

Спасибо всем за ваш вклад; как обычно, serverfault - это больше, чем просто форум - это похоже на диван психолога :-)


59
2017-07-08 19:42


Источник


LART / Clue-by-four? (catb.org/jargon/html/L/LART.html) (catb.org/jargon/html/C/clue-by-four.html) - Christopher Karel
Это остается моим предпочтительным LART: laughingsquid.com/cat-5-o-nine-tails-ethernet-cable-whip Это для диагностики сети. Честный. - Sobrique
Из интереса вы проверили производительность хранилища? Требование большего количества CPU / RAM может быть просто ответом непрофессионала на низкую производительность, что может быть вызвано большой глубиной очереди дисков. Похоже, многие люди забыли о лучших методах хранения SQL, когда появилась виртуализация. - Ashigore
ворчать, Правильно, храните память! Но более серьезно - это хороший момент. Если есть проблема, и RAM / CPU не помогает, тогда это может быть IO. Особенно, если мы говорим о VMWare, потому что это не редкость для ... ну, сторона производительности системы хранения почти полностью игнорируется - забывая при этом, что вы внутренне получаете массивное узкое место, если вы кормите много виртуальных машин на ограниченном количество HBA. - Sobrique
Является ли HP вашим продавцом в этом случае? Потому что я там работаю. Я могу подтвердить, что нам все равно. - Christopher Wirt


Ответы:


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

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


94
2017-07-08 19:58



...мудрые слова. Я считаю, что это может быть путь вперед, так как это мешает нам внести изменения. Хорошая (?) Вещь заключается в том, что изменения потребуют перезагрузки, и мы можем быть понятны нашим бизнес-пользователям, что это связано с запросом поставщика ... что почти наверняка окажется бессмысленным. Похоже, я становлюсь мелочным, но мы устали от очевидного отсутствия у поставщика надлежащего устранения неполадок. - Simon Catlin
Для продавцов нет ничего необычного в том, чтобы играть в этот трюк. Я думаю, что отчасти это касается показателей уровня обслуживания - отбросьте, попросите дополнительную информацию и предложите (бессмысленное) обходное решение, потому что по крайней мере некоторое время проблема уходит / фиксируется в то же время. Если вы «тянете» с продавцом, общение с менеджером учетной записи может сделать трюк. Но не задерживайте дыхание. - Sobrique
Имел подобную ситуацию один раз с SQL-сервером для SCCM (системный конфигуратор конфигурации mgr) 4 CPU 30% использовать avg. Консоль ужасно медленная. Сбитый до 8 CPU все еще на 30%, консоль, наконец, отвечает обычным образом. - Clayton
Отличное предложение. Нет ничего похожего на данные, чтобы закрывать людей. «Мы сделаем изменения, которые вы предлагаете. Если это не даст прогнозируемого улучшения, вы едите стоимость». Не знаете, сколько систем влияет на вас, но ваше время доказывает их неправильность. QUICKLY становится дороже, чем подключать дополнительную RAM. - Floris


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

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

Спросите их специфика.

  • Какая информация, предоставленная в системе, указывает на необходимость большего объема ОЗУ и как вы это понимаете?

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

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

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

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

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

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


67
2017-07-09 14:26



+1 для признания того, что человеческая ошибка может идти двумя путями (и немного опоздать, когда они действительно пытались «отбросить»). - Cosmic Ossifrage


Главное - доказать, что вы используете лучшие методы для распределения вашей системы, в частности, резервирование ОЗУ и ЦП для вашего SQL-сервера.

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


17
2017-07-08 20:01





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

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

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


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

Dev: VM требует процессор MOAR!

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

enter image description here 

enter image description here

enter image description here


17
2017-07-09 14:48



Я должен добавить, что анализ, основанный на средних показателях, может привести к неправильным результатам. Существуют условия, при которых максимальная производительность важна, но вы не видите пиков статистики загрузки, когда они значительно короче, чем ваш интервал сбора / усреднения. Таким образом, у вас может быть красивый красочный «общий коэффициент использования <60%», но см. Серьезную деградацию производительности в 1-минутных пиках, происходящих 8 раз в час одновременно. - the-wabbit
Возможно, я полностью неправильно понял вопрос, но разве это не напротив о чем спрашивал ОП? Я думал, что они были разработчиком, который знал, что им не нужно больше процессоров, которые поставщик пытается их продать - похоже, вы описываете инверсию, где разработчик просит больше процессора, что им не нужно. - Benubird
Я использую удобный пример. Я придерживаюсь такого же подхода с поставщиками, которые имеют жесткие требования (4 vCPU и 16 ГБ оперативной памяти), а также для определения недоразвитых систем, которым нужны ресурсы. Что касается степени детализации мониторинга, вы можете вернуться к статистике уровня хоста, чтобы справиться с пиками ... - ewwhite
Спасибо за это. У нас нет vCops, но я считаю, что наше поместье vSphere теперь достаточно зрелое, чтобы требовать такого уровня детализации. Я добавлю это в наш список желаний Capex на следующий год. - Simon Catlin
@SimonCatlin вам не нужно покупать его. Вы можете бесплатно скачать демо и использовать его в течение 60 дней. Это идеально подходит для такого типа ситуаций. - ewwhite


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

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

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

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

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

ТЛ; др:

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


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


10
2017-07-09 14:11



Все, что связано с производительностью, требует много времени и ресурсов для устранения неполадок и диагностики. В конце концов, нет ничего, что сломанный поэтому вам нужно проследить сквозь боль. - Sobrique
@Sobrique абсолютно - и они обычно находятся в довольно отдаленных (даже, по-видимому, не связанных) сегментах продукта под рукой - warren
Это хороший момент, многие шаги отладки могут быть очень противоречивыми, хотя я не думаю, что было бы необоснованно настаивать на том, что они дают причину для этого. Если они не могут сказать, какая польза от чего-то даст (даже если это просто «увидеть, влияет ли это на X»), то либо они работают через контрольный список, который они не понимают, либо они не имеют представления и делают дикие догадки, или они что-то скрывают - ничто из этого не очень обнадеживает. - Benubird
@Benubird - к ​​сожалению, некоторые из этих вещей сводятся к инстинкту кишки или «это исправлено в другом месте ...» :( - warren
«он исправил это где-то еще» - это страшная причина что-то сделать. Правда, иногда нет времени правильно отлаживать проблему, и вам нужно идти инстинктом кишки, но мысль об этом по-прежнему заставляет меня дрожать. Я видел множество ошибок, которые «оказались» исправлены, сделав X, только чтобы потом обнаружить, что проблема была на самом деле в чем-то, казалось бы, совершенно не связанным, что вызвало больше проблем в других местах, пока мы не выяснили это. - Benubird


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

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

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


8
2017-07-08 20:01





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

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

  1. Повысьте приоритет до эквивалента системы - они обычно перестают работать, но обычно отступают, когда вы объясняете, что это эффективно непригодно, даже если оно технически «работает». Рассматривайте это как серьезную проблему для их решения. Вокруг здесь мы говорим о том, что в качестве команды тигра, которая собирается ежедневно, чтобы получать обновления статуса от всех заинтересованных сторон. Обычно продавец попросит вас изменить материал. Если это система prod, это проблематично, но если вы хотите, чтобы они помогли, вам нужно будет принять ответственность за то, чтобы помочь им изолировать проблему, поэтому она помогает, если у вас есть среда разработки, где вы можете запускать тесты.

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

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

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

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


4
2017-07-09 16:39





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

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

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

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


3
2017-07-09 11:42



Я бы подумал, что это даст боеприпасы в контраргументе - вы попросили нас сделать это бессмысленно в прошлый раз; мы сделали это как жест доброй воли. На этот раз мы хотим получить более подробную информацию о ваших рассуждениях, почему это будет иметь значение. - Sobrique
@Sobrique Это имеет смысл, и это может сработать именно так - я не знаю достаточно психологии, чтобы сказать так или иначе. Мой инстинкт, однако, заключается в том, что если вы сделали что-то сейчас, просто потому, что сказали, что они эффективно признают, что знают больше, чем вы, они ожидают того же в будущем. В любом случае, если вам приходится спорить с ними (боеприпасы или нет), вы уже теряете время, которое можно потратить на решение проблемы. - Benubird
«В прошлый раз мы сделали это по-твоему. Ты ошибался. Готовы ли вы принять, что вы снова ошибаетесь? У нас есть прецедент здесь». - Sobrique


Я собираюсь опубликовать представление со стороны поставщика.

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

Профилировщик bulitin в системе показал, что системный CPU (или, возможно, память) был отвратительно медленным, примерно 100MHZ, а не ожидаемым 2GHZ. Удвоение ЦП, предоставляемое ВМ, не изменило симптом, и они думали, что мы расточительны.

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

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

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

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

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

EDIT, обновление от лет спустя:

Поскольку все больше и больше клиентов, желающих работать на виртуальных машинах и в управлении, готовы попытаться решить проблему любой ценой, мы получили хорошее аппаратное обеспечение VM. Я смог создать специализированную программу для записи на VM, которая выполнялась в пользовательском пространстве (и не требовала никаких привилегий) на двух одноядерных виртуальных машинах с 512 МБ ОЗУ, которая смогла вывести производительность 1/3 памяти из другой одноядерной виртуальной машины только с 4 всего ядра из 16, используемых на хосте VM, и большая часть его бара все еще свободна. Программа не вызвала никаких аварийных сигналов и не показала ничего необычного на хосте VM, и ни один из гостей, за исключением доступа к памяти, был медленным.

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

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


3
2017-07-11 20:23