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

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

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

Общие ресурсы ЦП настроены так, чтобы среда тестирования не влияла на производительность. Все хранилище по SAN.

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

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

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

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

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

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

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

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

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

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

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

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

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

Спросите их конкретику.

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

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

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

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

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

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

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

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

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

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

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

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

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

Dev : VM нуждается в процессоре MOAR!

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

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

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

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

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

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

ТЛ; др:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ, обновление от лет спустя:

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

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

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

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

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