Vraag Hoe (beleefd?) Te vertellen aan softwareleveranciers dat ze niet weten waar ze het over hebben


Geen technische vraag, maar wel een geldige vraag. Scenario:

HP ProLiant DL380 Gen 8 met 2 x 8-core Xeon E5-2667 CPU's en 256GB RAM met ESXi 5.5. Acht VM's voor het systeem van een bepaalde leverancier. Vier VM's voor testen, vier VM's voor productie. De vier servers in elke omgeving hebben verschillende functies, bijvoorbeeld: webserver, hoofdapp-server, OLAP DB-server en SQL DB-server.

CPU-shares die zijn geconfigureerd om te voorkomen dat de testomgeving invloed heeft op de productie. Alle opslag op SAN.

We hebben wat vragen over de prestaties gehad en de leverancier staat erop dat we het productiesysteem meer geheugen en vCPU's moeten geven. We kunnen echter vanuit vCenter duidelijk zien dat de bestaande toewijzingen niet worden aangeraakt, bijvoorbeeld: een maandelijkse weergave van het CPU-gebruik op de hoofdtoepassingsserver schommelt rond 8%, met een enkele piek tot 30%. De spikes hebben de neiging samen te vallen met de back-upsoftware die binnenkomt.

Een vergelijkbaar verhaal over RAM - het hoogste bezettingspercentage op de servers is ~ 35%.

Dus we zijn wat aan het graven geweest, met behulp van Process Monitor (Microsoft SysInternals) en Wireshark, en onze aanbeveling aan de leverancier is dat ze in eerste instantie wat TNS-tuning doen. Dit is echter naast het punt.

Mijn vraag is: hoe zorgen we ervoor dat ze erkennen dat de VMware-statistieken die we ze hebben gestuurd voldoende bewijs zijn dat meer RAM / vCPU niet zal helpen?

--- UPDATE 12/07/2014 ---

Interessante week. Ons IT-beheer heeft gezegd dat we de wijziging in de VM-toewijzingen moeten aanbrengen en we wachten nu op enige uitvaltijd van zakelijke gebruikers. Vreemd genoeg zeggen de zakelijke gebruikers dat bepaalde aspecten van de app langzaam werken (vergeleken met wat, ik weet het niet), maar ze gaan "ons laten weten" wanneer we het systeem kunnen uitschakelen (mopperen , grommen!).

Even terzijde, het "langzame" aspect van het systeem is blijkbaar niet het HTTP (S) -element, d.w.z. de "dunne app" gebruikt door meest van de gebruikers. Het klinkt alsof het de "fat client" -installaties zijn, die worden gebruikt door de belangrijkste financiële instanties, die blijkbaar "traag" zijn. Dit betekent dat we nu de client en de client-serverinteractie in onze onderzoeken overwegen.

Aangezien het initiële doel van de vraag was om hulp te zoeken bij het zoeken naar de "porren" -route, of gewoon de wijziging aan te brengen, en we zijn nu bezig met de wijziging, zal ik deze sluiten met behulp van lange nekhet antwoord.

Dank u allen voor uw inbreng; Zoals gewoonlijk was serverfault meer dan alleen een forum - het is ook een soort bank van een psycholoog :-)


59
2017-07-08 19:42


oorsprong


LART / Clue-by-four? (catb.org/jargon/html/L/LART.html) (catb.org/jargon/html/C/clue-by-four.html) - Christopher Karel
Dit blijft mijn favoriete LART: laughingsquid.com/cat-5-o-nine-tails-ethernet-cable-whip Het is voor netwerkdiagnostiek. Eerlijk. - Sobrique
Hebt u uit interesse de opslagprestaties gecontroleerd? Het vragen om meer CPU / RAM is misschien een lekenreactie op slechte prestaties, wat gemakkelijk veroorzaakt zou kunnen worden door een hoge schijfrijdiepte. Het lijkt erop dat veel mensen de beste werkwijzen voor SQL-opslag vergaten toen virtualisatie binnenkwam. - Ashigore
mopperen. Dat klopt, de opslag de schuld geven! Maar serieuzer - het is een goed punt. Als er een probleem is en RAM / CPU niet helpt, kan het IO zijn. Vooral als we het over VMWare hebben, omdat het niet ongebruikelijk is dat ... de opslagprestatiekant van een systeem bijna volledig genegeerd wordt - terwijl je vergeet dat je intrinsiek een enorm knelpunt krijgt als je veel VM's voedt met een beperkt aantal aantal HBA's. - Sobrique
Is HP uw leverancier in dit geval? Omdat ik daar werk. Ik kan bevestigen dat het ons niet kan schelen. - Christopher Wirt


antwoorden:


Ik stel voor dat je de aanpassingen doet die ze hebben aangevraagd. Benchmark vervolgens de prestaties om aan te tonen dat het geen verschil maakte. Je zou zelfs zover kunnen gaan om het te benchmarken met minder geheugen en vCPU om je punt te maken.

Ook: "We betalen u om de software te ondersteunen met echte oplossingen, niet met gissen."


94
2017-07-08 19:58



...wijze woorden. Ik denk dat dit de weg vooruit is, net zo goed als het ons moeite doet om de verandering aan te brengen. Het goede (?) Probleem is dat de wijzigingen opnieuw moeten worden opgestart, en we kunnen aan onze zakelijke gebruikers duidelijk zijn dat dit te wijten is aan het verzoek van de leverancier ... wat bijna zeker zinloos zal blijken. Het lijkt erop dat ik klein wordt, maar we zijn het beu om het schijnbare gebrek aan goede probleemoplossing van de verkoper te zien. - Simon Catlin
Het is niet ongebruikelijk dat leveranciers dit soort stunt spelen. Ik denk dat dit gedeeltelijk te maken heeft met de serviceniveauwaarden - fob off, vraag om meer informatie en stel een (zinloze) oplossing voor, want op zijn minst een deel van de tijd verdwijnt het probleem / wordt het in de tussentijd opgelost. Als u met de leverancier 'trekt', kan een chat met de accountmanager de juiste oplossing zijn. Maar houd je adem niet in. - Sobrique
Had een soortgelijke situatie één keer met een SQL-server voor SCCM (systeemcentrumconfiguratie mgr) 4 CPU 30% gebruik gem. Console vreselijk traag. Gestoten tot 8 CPU nog steeds 30% gebruik, console reageert uiteindelijk op een normale manier. - Clayton
Uitstekende suggestie. Er gaat niets boven gegevens om mensen de mond te snoeren. "We zullen de door u voorgestelde wijziging aanbrengen. Als het de verwachte verbetering niet oplevert, eet u de kosten op." Ik weet niet zeker hoeveel systemen hier worden geraakt, maar uw tijd is voldoende om te bewijzen dat QUICKLY duurder is dan wat extra RAM-geheugen aan te sluiten. - Floris


Als u zeker weet dat u binnen de gegeven systeemspecificaties valt die zij documenteren.

Elke bewering die ze maken met betrekking tot het vereisen van meer RAM of CPU, zouden ze moeten kunnen back-uppen. Als experts in hun systeem houd ik mensen hier rekenschap van.

Vraag hun specifieke informatie.

  • Welke informatie op het systeem geeft aan dat er meer RAM nodig is en hoe heb je dit geïnterpreteerd?

  • Welke informatie op het systeem geeft aan dat er meer CPU nodig is en hoe heb je dit geïnterpreteerd?

  • De gegevens die ik heb - op het eerste gezicht - zijn in tegenspraak met wat u mij vertelt. Kun je me uitleggen waarom ik dit misschien verkeerd interpreteer?

  • Ik interpreteer deze [voor de hand liggende gegevensreeks] als [voor de hand liggende interpretatie]. Kunt u bevestigen dat ik het correct interpreteer met betrekking tot mijn probleem?

Nadat ik in het verleden met ondersteuning heb afgerekend, heb ik dezelfde vragen gesteld. Soms had ik gelijk en richtten ze hun aandacht niet goed op mijn probleem. Andere keren was ik echter fout en ik interpreteerde de gegevens verkeerd, of verzuimde andere gegevens te vermelden die belangrijk waren in mijn analyse.

In elk geval waren beide situaties een netto voordeel voor mij leerde ik iets nieuws dat ik nog niet eerder wist - of ik heb hun ondersteuningsteams om harder over mijn probleem na te denken om een ​​fatsoenlijke oorzaak te krijgen.

Als het ondersteuningsteam niet in staat is om u een logische uitbreiding van hun argument te geven op een basis waar u tevreden mee kunt zijn (u moet een open geest hebben om een ​​compromis te sluiten, redelijk zijn om te accepteren dat uw interpretatie van de gegevens onjuist is) dan is het moet erg aanwezig zijn in hun reactie. Zelfs in het ergste geval kun je dit gebruiken als basis om het probleem te laten escaleren.


67
2017-07-09 14:26



+1 voor de erkenning dat menselijke fouten op twee manieren kunnen gaan (en de steun een klein beetje doen kronkelen wanneer ze inderdaad hebben geprobeerd 'af te fluiten'). - Cosmic Ossifrage


Het belangrijkste is om te kunnen bewijzen dat u best practices gebruikt voor uw systeemtoewijzing, met name RAM- en CPU-reserveringen voor uw SQL-server.

Dit gezegd hebbende, is het eenvoudigste om de gevraagde aanpassingen aan te brengen, althans tijdelijk. Als het niets anders is, heeft het de neiging om verkopers over de grond te slepen. Ik kan niet het aantal keren tellen dat ik iets nodig heb dat zo gek is om een ​​tech aan de andere kant van de lijn tevreden te stellen dat het echt hun software is die zich niet gedraagt.


17
2017-07-08 20:01





Voor deze specifiek situatie (waar u VMware- en applicatie-ontwikkelaars hebt of een derde partij die de toewijzing van bronnen niet begrijpt), gebruik ik een week aan metrieken die zijn verkregen van vCenter Operations Manager (vCops - download indien nodig een demo) om de echte beperkingen, knelpunten en dimensioneringsvereisten van de VM's van de toepassing te bepalen.

Soms heb ik de hardnekkigere consumenten kunnen bevredigen door VM-reserveringen aan te passen of prioriteiten te wijzigen om scenario's voor conflicten op te lossen; "Als de RAM | CPU krap is, JOUW VM heeft voorrang!"Slecht-slechte dingen zijn gebeurd wanneer Ik heb toegestaan ​​dat softwareleveranciers hun eisen aan mijn vSphere-clusters dicteren zonder echte analyse.

Maar over het algemeen zouden cijfers en gegevens moeten worden overwonnen.


Een voorbeeld van iets dat ik gebruikte om VM-maatvoering te rechtvaardigen voor de ontwikkelaar van een Tomcat-toepassing:

dev: De VM heeft MOAR cpu nodig!

Me: Welnu, geheugen is je grootste beperking, en hier is een hittekaart van je prestaties versus tijd ... Woensdag om achttien zijn de stressvolste periodes, dus we kunnen speci fi ceren rond die piekperiode. Oh, en hier is een dimensioneringsaanbeveling gebaseerd op de afgelopen 6 weken van productiestatistieken ...

enter image description here 

enter image description here

enter image description here


17
2017-07-09 14:48



Ik moet hieraan toevoegen dat analyse op basis van gemiddelden kan leiden tot verkeerde resultaten. Er zijn omstandigheden waarbij piekprestaties belangrijk zijn, maar u ziet de pieken in laadstatistieken niet wanneer deze aanzienlijk korter zijn dan uw interval voor het verzamelen / berekenen. U hebt dus misschien een leuk kleurrijk "uw totale gebruik is <60%" statistiekengrafiek maar ziet ernstige prestatievermindering in pieken van 1 minuut die 8 keer per uur op hetzelfde moment optreden. - the-wabbit
Misschien heb ik de vraag helemaal verkeerd gelezen, maar is dit niet de tegenover van wat het OP vroeg? Ik dacht dat ze de ontwikkelaar waren, die wist dat ze niet meer cpu nodig hadden, wat de verkoper ze probeerde te verkopen - het klinkt alsof je het inverse beschrijft, waar een ontwikkelaar om meer cpu vraagt ​​die ze niet nodig hebben. - Benubird
Ik gebruik een handig voorbeeld. Ik volg dezelfde aanpak bij leveranciers met rigide vereisten (4 vCPU en 16 GB RAM) en met het identificeren van ondermaatse systemen die middelen nodig hebben. In termen van granulariteitsbewaking, kunt u teruggaan naar de statistieken op hostniveau om pieken te verwerken ... - ewwhite
Bedankt hiervoor. We hebben geen vCops, maar ik denk dat onze vSphere "estate" nu volwassen genoeg is om dit detailniveau te vereisen. Ik zal dit toevoegen aan onze Capex-verlanglijstje voor volgend jaar. - Simon Catlin
@SimonCatlin hoeft u niet te kopen. Je kunt de demo gratis downloaden en deze 60 dagen gebruiken. Het is perfect voor dit soort situaties. - ewwhite


Ik werkte in de ondersteuning - en een deel van wat je vraagt klanken zeer rationeel (en waarschijnlijk ook): maar er zijn een paar vragen die je jezelf moet stellen voordat je de "prestatieverbetering" doet die ze vragen

  • ben je aan het rennen tenminste bij de door de leverancier opgegeven minimale systeemvereisten al?
  • als je op z'n minst minimaal sysreqs hebt, ben je dan al in hun "aanbevolen" systeeminstellingen?

Leveranciers zullen 99 keer van de 100 (naar mijn ervaring - zowel aan de supportkant als aan de klant / veldzijde) niet eens te maken krijgen met prestatiegerelateerde problemen totdat / of de systemen overeenkomen met wat hun documentatie vereist. Misschien is het een systeem dat 99,5% van de tijd goed draait met 1 CPU en 512M RAM - maar als de systeemvereisten 4 CPU's en 4G RAM zeggen en je hebt maar 2 CPU's en 1G RAM, dan zijn ze ruim binnen hun rechten om eis dat er meer middelen worden toegewezen*.

Het is waarschijnlijk dat ze je vragen om systeembronnen te vergroten vanwege iets dat ze in het lab / de ontwikkeling hebben gevonden, waarbij een probleem op magische wijze verdwijnt als je een bepaalde drempel overschrijdt; als dit het geval is, ja, het is een voorbeeld van mogelijk slecht debuggen aan hun kant, maar onthoud dat ze geen tijd hebben om te elimineren elk mogelijke bug / probleem die zich voordoet - sommige moeten gewoon worden opgelost, en als dat het geval is, ga er dan gewoon mee akkoord.

Er is ook een niet onbelangrijke kans dat de problemen die u tegenkomt, niet eens deel uitmaken van "hun" software, maar een component waarop zij vertrouwen vanuit een andere bron (leverancier, OSS-bibliotheek, enz.). Ik kwam deze exacte situatie tegen met betrekking tot de swap-grootte, BEA WebLogic en de Sun JRE op een klant een paar jaar geleden.

tl; dr:

Kortom: werk met hun ondersteuningsteam, escaleer waar nodig, totdat u een oplossing vindt - maar wees niet verbaasd wanneer sommige van de suggesties / foutopsporingsstappen / fixes geluidloos of zinloos klinken.


*Als het werkelijk heeft deze extra bronnen niet "nodig", je bent waarschijnlijk op een plaats om een ​​documentin bug / RFE voor toekomstige versies te kunnen indienen - maar duw die weg niet totdat je hebt aangetoond dat dit niet het probleem is dat voorhanden is
^een eBook dat ik je heb geschreven kan nuttig zijn voor het onderwerp: Debugging en ondersteuning van softwaresystemen


10
2017-07-09 14:11



Alles wat met de prestaties te maken heeft, kost veel tijd en middelen om problemen op te lossen en een diagnose te stellen. Er is tenslotte niets dat is gebroken dus je moet pijnlijk doorlopen. - Sobrique
@Sobrique absoluut - en ze zijn meestal in vrij op afstand verwante (zelfs schijnbaar niet-gerelateerde) segmenten van het product bij de hand - warren
Dat is een goed punt, veel stappen voor foutopsporing kunnen heel contra-intuïtief zijn, hoewel ik het niet onredelijk vind om erop aan te dringen dat ze een reden geven om dit te doen. Als ze niet kunnen zeggen welk voordeel het doen van iets biedt (zelfs als het gewoon "om te zien of het van invloed is op X"), dan werken ze ofwel door een checklist die ze niet begrijpen, of ze hebben geen idee en maken wilde gissingen, of ze verbergen iets - geen van deze zijn zeer bemoedigend. - Benubird
@Benubird - helaas komen sommige van deze dingen neer op darminstinct of "het heeft het ergens anders opgelost ..." :( - warren
"het repareerde het ergens anders" is een vreselijke reden om iets te doen. Het is waar dat er soms geen tijd is om een ​​probleem goed te debuggen, en je moet het doen vanuit een instinctief instinct, maar de gedachte eraan doet me nog steeds huiveren. Ik heb veel bugs gezien die "verschenen" om opgelost te worden door X te doen, alleen om later te ontdekken dat het probleem in iets ogenschijnlijk totaal niet verwant was, dat elders meer problemen veroorzaakte totdat we erachter kwamen. - Benubird


Vraag of je het ticket wilt laten escaleren of vraag om een ​​andere vertegenwoordiger. Afhankelijk van de leverancier kan escalatie helpen als u zegt dat u vindt dat het huidige ondersteuningsniveau het probleem niet adequaat aanpakt. Als ze niet escaleren, kan het helpen om een ​​andere vertegenwoordiger te vragen, omdat dat veel minder "rechtvaardiging" vereist, omdat het alleen maar nodig is om niet blij te zijn met de huidige.

Als het een grote leverancier is, kan het eenvoudig zijn om het ticket te sluiten en een nieuw exemplaar voor hetzelfde probleem te openen omdat het naar een andere vertegenwoordiger kan worden geleid, maar ik zou het afraden omdat het een slechte vorm heeft.

Je zou ook je positie kunnen verdedigen en een reden vragen over hoe meer RAM / vCPU zal helpen, of je zou het gewoon meer RAM / vCPU kunnen geven om te bewijzen dat het niet zal helpen.


8
2017-07-08 20:01





Ik gooi mijn twee cent erin. We zijn behoorlijk succesvol geweest met deze aanpak - veel betere resultaten en minder frustratie van iedereen. Het vergt veel meer inspanning dan het schuldspel en het blindelings toevoegen van middelen, maar het heeft ook betere kansen om het onderliggende probleem te vinden.

Wanneer we serieuze problemen hebben met onze on-premise-apps die worden ondersteund door leveranciersondersteuningscontracten, en de leveranciers beginnen met hun ontwijkende schuifelende dans (die altijd lijkt te wijzen op buitenaardse niet-gegevensgestuurde eisen voor meer CPU of RAM), hebben we de neiging om doe deze 3 dingen:

  1. Escaleer de prioriteit naar systeem-down equivalent - ze hebben meestal een schijnvertoning, maar verdwijnen meestal als je uitlegt dat het effectief onbruikbaar is, zelfs als het technisch "werkt". Behandel het als een serieus probleem dat ze moeten oplossen. Hierom verwijzen we naar dat als een tijgerteam dat dagelijks bijeenkomt om statusupdates te krijgen van alle belanghebbenden. Meestal vraagt ​​de leverancier je om dingen te veranderen. Als het een prod-systeem is, is dat problematisch, maar als je wilt dat ze helpen, moet je de verantwoordelijkheid accepteren om hen te helpen het probleem te isoleren, dus het helpt als je een dev / faseringsomgeving hebt waar je tests kunt uitvoeren.

  2. Vertel de leverancier dat u wilt dat zij uw omgeving repliceren, zodat ZE het probleem in hun lab kunnen isoleren. Ze kunnen zelfs dingen in een bepaalde cloudomgeving hosten als dat nodig is. Het hoeft geen exacte match van uw omgeving te zijn, hoewel dat ideaal zou zijn. Het punt is dat je wilt dat de VENDOR actief probeert je probleem te repliceren, zodat ze hun giswerk kunnen testen op hun systeem in plaats van op het jouwe. Vraag hen naar de diagrammen, specificaties, enz. Van die gerepliceerde omgeving om er zeker van te zijn dat ze het doen.

  3. Geef ze (uiteraard onder NDA) met je feitelijke dataset zodat ze kunnen worden uitgevoerd / opnieuw kunnen worden afgespeeld in plaats van te raden. In ons geval zijn de meeste van onze door de leverancier geleverde app-problemen (zowel van voorbijgaande als chronische aard) vaak problemen met de bijbehorende, door leveranciers geleverde databases. Ik kan het aantal keren dat we dit hebben gedaan niet tellen en uiteindelijk hebben ze het probleem opgezocht tot iets onverwachts in de feitelijke gegevens - rare artefacten van app-upgrades 2 jaar geleden waar iets niet netjes is omgezet; verouderde records die een probleem met de GC-instellingen aan het licht brengen; vragen werken niet helemaal goed, omdat ONZE gegevenswaarden een aantal transmireroutines in de leverancierscode, enz. doorbreken. Dingen die we nooit alleen zouden kunnen identificeren.

We hebben dit de afgelopen jaren gedaan met een flink aantal verkopers, en ze zijn in eerste instantie erg resistent om het op onze manier te doen. Echter, nadat het werkt, komt het altijd als een positief hoogtepunt naar voren in de driemaandelijkse reviews die we bij onze leveranciers houden. En het helpt onze technische relatie met die leveranciers te versterken. Ze willen geen vage problemen. Ze willen specifieke problemen die ze kunnen analyseren om hun producten te verbeteren.

Ik hoop dat de suggestie helpt. Ik weet dat het geen one-size-fits-all benadering is, maar als je het kunt slingeren, denk ik dat je het de moeite waard zult vinden.


4
2017-07-09 16:39





De echte vraag is, wie heeft hier de leiding? Als je niet realistisch kunt overschakelen naar een alternatieve leverancier, dan hebben ze de macht, en alles wat je echt kunt doen is meegaan met wat ze zeggen en hopen dat het goed komt. Geen gelukkige situatie! Anders stel ik voor dat je om een ​​andere vertegenwoordiger vraagt ​​(zoals anderen hebben gezegd), maar maak duidelijk dat je niet tevreden bent met de service en elders zult zoeken of ze de klus niet kunnen klaren.

Maak niet alleen "de aanpassingen die ze suggereerden", als je zeker weet dat ze niet werken, want dat is het opzetten van een patroon voor je relatie dat je op de lange termijn pijn zal doen. Je betaalt ze om je een dienst te verlenen, en ze zouden niet in staat moeten zijn om je acties te dicteren net zo min als iemand die ik huur om mijn huis te schilderen kan dicteren welke kleur het zal zijn.

Dit klinkt misschien drastisch, omdat het klinkt alsof dit geen enorm kritieke kwestie is, maar het feit is dat als ze je op iets kleins knoeien, ze waarschijnlijk hetzelfde zullen doen voor iets groots, en het laatste wat je wilt, is om op een of andere manier een vreselijke charlie-foxtrot tegen het lijf lopen en dan dezelfde problemen met de verkoper hebben.

Zorg ervoor dat de stappen die u nu neemt om het probleem op te lossen, net zo goed werken als u twee dagen na een deadline zit en alles breekt ...


3
2017-07-09 11:42



Ik had gedacht dat het munitie in een tegenargument zou geven - je hebt ons vorige keer gevraagd dit onzinnige te doen; we deden het als een gebaar van goede wil. Deze keer willen we wat meer detail over uw reden waarom dit enig verschil zal maken. - Sobrique
@Sobrique Dat klinkt logisch, en het kan zo uitkomen - ik weet niet genoeg psychologie om het op de een of andere manier te zeggen. Mijn instinct is echter dat als je nu iets hebt gedaan alleen maar omdat ze zeiden - effectief toegeven dat ze meer weten dan jij - ze hetzelfde zullen verwachten in de toekomst. Hoe dan ook, als je met ze moet ruzie maken (munitie of niet), verspil je al tijd die kan worden besteed aan het oplossen van het probleem. - Benubird
"We hebben het je de vorige keer gedaan, je was fout, ben je bereid om te accepteren dat je misschien weer fout zit?" We hebben hier een precedent. " - Sobrique