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

Не технічне питання, але все-таки дійсне. Сценарій:

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

Частини CPU налаштовані так, щоб тест-середовище не впливало на виробництво. Усі сховища в SAN.

У нас були запити щодо продуктивності, і виробник наполягає на тому, що нам потрібно надати виробничій системі більше пам’яті та vCPU. Однак із vCenter ми чітко бачимо, що існуючі асигнування не торкаються, наприклад: щомісячний перегляд використання процесора на головному сервері додатків коливається близько 8%, а непарний стрибок - до 30%. Шипи, як правило, збігаються із запуском резервного програмного забезпечення.

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

Таким чином, ми виконували копання, використовуючи Монітор процесів (Microsoft SysInternals) та Wireshark, і наша рекомендація постачальнику полягає в тому, що вони виконують деяку настройку TNS в першу чергу. Однак це крім пункту.

Моє запитання: як ми змусимо їх визнати, що статистика VMware, яку ми їм надіслали, є достатньою доказами того, що більше оперативної пам’яті / vCPU не допоможе?

--- ОНОВЛЕННЯ 07.12.2014 ---

Цікавий тиждень. Наше управління інформаційних технологій сказало, що ми повинні внести зміни до розподілу VM, і тепер ми чекаємо певного простою від ділових користувачів. Дивно, що ділові користувачі говорять про те, що певні аспекти програми працюють повільно (порівняно з тим, що я не знаю), але вони "дадуть нам знати", коли ми можемо зняти систему (бурчить , бурчить!).

З іншого боку, "повільний" аспект системи, мабуть, не є елементом HTTP (S), тобто: "тонким додатком", який використовується більшістю користувачів. Здається, це встановлення "товстого клієнта", яке використовується основними фінансовими органами, що, мабуть, "повільно". Це означає, що зараз ми розглядаємо взаємодію клієнта та клієнта-сервера під час наших досліджень.

Оскільки початковою метою питання було звернутися за допомогою до того, чи слід їхати по маршруту "сунути його" або просто внести зміни, і ми зараз вносимо зміни, я закрию її, використовуючи відповідь longneck .

Дякую всім за ваш внесок; як завжди, сервер за замовчуванням був більше, ніж просто форум - це на зразок дивана психолога :-)

Я пропоную внести внесені ними зміни. Потім порівняйте ефективність, щоб показати їм, що це не мало значення. Ви можете навіть зайти так далеко, щоб порівняти його з меншою пам'яттю та vCPU, щоб зробити свою думку.

Також "Ми платимо вам за те, щоб підтримувати програмне забезпечення актуальними рішеннями, а не здогадами".

За умови, що ви впевнені, що ви знаходитесь в даних системних специфікаціях, які вони документують.

Тоді будь-які вимоги, які вони пред'являють щодо того, щоб вимагати більше оперативної пам’яті або процесора, вони повинні мати можливість резервного копіювання. Як експерти в їхній системі, я залучаю людей до цього.

Запитайте їх специфіку.

• Яка інформація, що надається в системі, вказує, що потрібно більше оперативної пам’яті і як ви це інтерпретували?

• Яка інформація, що надається в системі, вказує на те, що потрібно більше процесора та як ви це трактували?

• Дані, які я маю - на перший погляд - суперечать тому, що ви мені говорите. Чи можете ви пояснити мені, чому я, можливо, трактую це неправильно?

• Я інтерпретую це [очевидний ряд даних], щоб означати [очевидне тлумачення]. Чи можете ви підтвердити, що я правильно його інтерпретую щодо своєї проблеми?

Займаючись підтримкою в минулому, я задавав ті ж запитання. Іноді я мав рацію, і вони не зосередили належну увагу на моїй проблемі. В іншому випадку я помилявся, і інтерпретував дані неправильно, або не міг включити інші дані, які були важливими в моєму аналізі.

У будь-якому випадку, обидві ці ситуації були для мене чистою вигодою , або я дізнався щось нове, про що раніше не знав, - або у мене є їхні групи підтримки, щоб думати важче про свою проблему, щоб отримати гідну першопричину.

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

Найголовніше - це вміти довести, що ви використовуєте кращі практики розподілу системи, зокрема резервування оперативної пам’яті та процесора для свого SQL-сервера.

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

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

Іноді мені вдалося задовольнити більш впертих споживачів, змінивши застереження VM або змінивши пріоритети для обробки сценаріїв суперечок; " Якщо оперативна пам'ять | CPU є щільною, ваш VM буде мати перевагу! ". Погані погані речі траплялися, коли я дозволяв постачальникам програмного забезпечення диктувати свої вимоги на моїх кластерах vSphere без реального аналізу .

Але загалом цифри та дані повинні вигравати.

Приклад чогось я використовував для виправдання розміру VM для розробника програми Tomcat:

Dev : В.М. потрібен процесор MOAR!

Я : Ну, пам’ять - це найбільше обмеження, і ось основна карта вашої роботи порівняно з часом ... Середа о 18:00 - найбільш напружений період, тому ми можемо проаналізувати цей пік. О, і ось рекомендація щодо визначення розміру на основі останніх 6 тижнів виробничих показників ...

Я працював у підтримці - і частина того, що ви запитуєте, звучить дуже раціонально (і, мабуть, є): але є кілька питань, які слід задати собі перед тим, як просто зробити "підвищення продуктивності", про яке вони запитують.

• Ви вже працюєте принаймні за вказаними мінімальними системними вимогами продавця?
• якщо ви принаймні як мінімум sysreqs, ви вже користуєтесь їх рекомендованими системними налаштуваннями?

Постачальники 99 разів із 100 (за моїм досвідом - як з боку підтримки, так і з боку клієнта / поля) навіть не вирішуватимуть проблеми, пов'язані з ефективністю, поки / доки системи не відповідають тому, що вимагає їх документація. Можливо, це система, яка працює нормально 99,5% часу з 1 процесором і 512М оперативної пам’яті - але якщо системні вимоги говорять про 4 процесора та 4G оперативної пам’яті, а у вас є лише 2 процесора та 1G оперативної пам’яті, вони повністю входять у свої права на вимагати більше ресурсів ^* .

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

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

tl; dr:

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

^{* _{Якщо вам справді не потрібні ці додаткові ресурси, ви, ймовірно, зможете подати документ-помилку / RFE для майбутніх версій - але не натискайте на цей маршрут, поки ви не продемонструєте, що це не Проблема під рукою}
^ _{Електронна книга, яку я написав, вам може бути корисною на тему: Налагодження та підтримка програмних систем}}

Або попросіть ескалацію квитка або попросіть іншого представника. Залежно від того, для якого постачальника це ескалація, може допомогти, якщо ви скажете, що вважаєте, що поточний рівень підтримки недостатньо вирішує проблему. Якщо вони не наростатимуть, то прохання про отримання іншого представника може допомогти, оскільки для цього потрібно набагато менше "обгрунтування", оскільки все, що потрібно, - це не бути задоволеним поточним.

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

Ви також можете висловити свою думку і попросити обґрунтування того, як більше RAM / vCPU допоможе, або ви можете просто дати їй більше оперативної пам’яті / vCPU, щоб довести, що це не допоможе.

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

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

1. Визначте пріоритет до системного еквівалента - вони зазвичай обмежуються, але, як правило, відступають, коли ви пояснюєте, що це практично непридатно, навіть якщо це технічно "працює". Ставтесь до них як до серйозної проблеми, яку вони мають вирішити. Тут ми називаємо це тигровою командою, яка збирається щодня, щоб отримувати оновлення статусу від усіх зацікавлених сторін. Зазвичай постачальник просить вас змінити речі. Якщо це система prod, це проблематично, але якщо ви хочете, щоб вони допомогли, вам потрібно буде взяти на себе відповідальність, щоб допомогти їм вирішити проблему, і це допоможе, якщо у вас є середовище розробки / постановки, де ви можете запускати тести.

2. Скажіть продавцю, що ви хочете, щоб вони копіювали ваше оточення, щоб вони могли ізолювати проблему у своїй лабораторії. Вони можуть навіть розміщувати речі в якомусь хмарному середовищі, якщо це потрібно. Це не повинно відповідати вашому оточенню, хоча це було б ідеально. Справа в тому, що ви хочете, щоб ВІДПРИЄМНИК активно намагався повторити свою проблему, щоб вони могли перевірити свої здогадки на своїй системі замість вашої. Запитайте їх щодо діаграм, специфікацій тощо цього реплікаційного середовища, щоб переконатися, що вони це роблять.

3. Забезпечте їх (під NDA, звичайно) своїм фактичним набором даних, щоб вони могли запустити / відтворити його реально, а не здогадуватися. У нашому випадку більшість проблем із додатками, що надаються постачальниками (як перехідні, так і хронічні), часто виявляються проблемами з супровідними базами даних постачальника. Я не можу порахувати, скільки разів ми це зробили, і вони, нарешті, визначили проблему до чогось несподіваного у фактичних даних - дивних артефактів від оновлення додатків 2 роки тому, де щось не було перетворено чисто; несвіжі записи, що виявляють проблему з налаштуваннями GC; запити працюють не дуже правильно, оскільки НАШІ значення даних порушують деяку трансмогранічну процедуру в коді постачальника тощо.

Ми робили це з досить багатьма постачальниками протягом останніх кількох років, і вони спочатку дуже стійкі до цього. Однак після того, як вона працює, вона завжди виступає як позитивна родзинка у щоквартальних оглядах, які ми проводимо у наших постачальників. І це допомагає зав'язати наші технічні стосунки з тими постачальниками. Вони не хочуть неясних проблем. Вони хочуть конкретних проблем, які вони можуть проаналізувати, щоб покращити свою продукцію.

Сподіваюся, пропозиція допомагає. Я знаю, що це не єдиний підхід для всіх, але якщо ви зможете розмахувати, я думаю, що ви вважаєте це вартим.

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

Не просто "вносьте запропоновані вами корективи", якщо ви впевнені, що вони не спрацюють, оскільки це налаштування схеми для ваших відносин, яка завдасть вам шкоди в довгостроковій перспективі. Ви платите їм за надання вам послуги, і вони не повинні мати можливість диктувати ваші дії більше, ніж хтось, кого я наймаю, щоб пофарбувати свій будинок, може диктувати, якого кольору він буде.

Це може здатися драстичним, адже це здається, що це не є надзвичайно критичною проблемою, але факт полягає в тому, що якщо вони зроблять вас з чимось незначним, вони, ймовірно, зроблять те саме для чогось великого, і останнє, що ви хочете - це наткнутися на якийсь жахливий фокстрот Чарлі через півроку і мати ті ж проблеми з продавцем.

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

Я збираюся розмістити погляд з боку продавця.

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

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

Оскільки вони не змогли отримати більш швидкий процесор (більше процесорів не допомогло), ми спробували змінити TEST і PROD VM. Потім проблема з’явилася на TEST наступного дня. Тоді ми спробували просувати одного з клієнтів до самостійного (без сервера) екземпляра. На цій робочій станції жодних проблем не було, коли сервер захлинався.

Вони підготували звіти від хоста VM, вказуючи на відсутність проблем у роботі та спробували знову заявити, що це проблема програми.

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

Ми ніколи не з’ясували, в чому проблема. Усі тестові програми показали нормальне значення, але програма-програміст говорила нам, що обчислювальні ресурси просто не були адекватними. Зараз у профілера ми шукаємо певний підпис. Якщо ми бачимо це, ми знаємо, перш ніж дістати будь-яку проблему, це проблема взаємодії з ВМ, але тоді вона просто не була відома.

Вони впевнені, думали, що я сповнений цього. Я не був. Мені не вистачало варіантів.

EDIT, оновлення через роки:

Оскільки все більше і більше клієнтів, які бажають працювати на віртуальних машинах та керівництві, готові спробувати вирішити проблему за будь-яку ціну, ми отримали гарне обладнання для VM. Мені вдалося побудувати спеціалізовану програму запису VM, яка працювала в просторі користувачів (і не вимагала привілеїв) на двох одноядерних VM з 512 Мб оперативної пам’яті, що змогло витягти 1/3 продуктивності пам’яті з іншого одноядерного VM лише 4 загальна кількість ядер із 16, що використовуються на хості VM, і більшість його оперативної пам'яті все ще безкоштовні. Програма не викликала тривоги і нічого не показала нічого звичайного на хості VM, ані комусь із гостей, крім доступу до пам'яті було повільним.

Тепер ми можемо сказати клієнтам, що ми знаємо, що з VM є проблеми, і це не наше програмне забезпечення. Ми все ще час від часу отримуємо запити клієнтів на програмне забезпечення, сумісне з VM. Цікаво, чому керівництво не дозволяє підтримці сказати їм, що ми змогли розробити програмне забезпечення, яке сповільнює всі інші VM на тому ж хості.

Страшна річ у тому, що ця техніка - це проста трансформація відомої техніки програмування, яка передбачає безблокову синхронізацію. Сотні постачальників програмного забезпечення могли мати цей стікач VM у своєму програмному забезпеченні і не знати цього. Отримати атомну блокування інструкцій, яка гаряче оспорюється, має бути рідкісним, але не неможливим. Цікавою частиною всього цього є те, що я отримував замок на змагання з ACROSS VM.

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

Які фактичні проблеми повідомляються та які очікування користувачів. Якщо користувач каже щось "зайняти занадто довго", запитайте їх, що саме "це" (щоб ви могли його відтворити), скільки часу вони думають, що це повинно пройти, і чому вони думають, що це повинно зайняти так довго. Якщо їхні очікування є розумними, виміряйте фактичну ефективність та вплив системи на те, що вони намагаються зробити. Той факт, що ваша система демонструє 30-відсотковий сплеск протягом місяця, не означає, що він не працює на рівні 100%, коли користувач намагається виконати запит. Якщо ви можете продемонструвати своєму постачальнику, що процесор і пам'ять не обтяжуються проблематичним завданням, тоді ви можете попросити постачальника виправдати рекомендації, які коштуватимуть вам грошей.