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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dev: ВМ нужен ЦП MOAR!

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

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

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

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

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

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

tl; dr:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я собираюсь выложить взгляд со стороны продавца.

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

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

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

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

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

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

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

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

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

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

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

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

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