Come [educatamente?] Dire al venditore di software che non sanno di cosa stanno parlando

Non una domanda tecnica, ma comunque valida. Scenario:

HP ProLiant DL380 Gen 8 con 2 CPU Xeon E5-2667 x 8 core e 256 GB di RAM con ESXi 5.5. Otto VM per il sistema di un determinato fornitore. Quattro VM per test, quattro VM per produzione. I quattro server in ciascun ambiente svolgono funzioni diverse, ad esempio: server Web, server delle app principale, server DB OLAP e server SQL DB.

Condivisioni CPU configurate per impedire all'ambiente di test di influire sulla produzione. Tutto l'archiviazione su SAN.

Abbiamo avuto alcune domande in merito alle prestazioni e il fornitore insiste sulla necessità di dare più memoria e vCPU al sistema di produzione. Tuttavia, da vCenter possiamo vedere chiaramente che le allocazioni esistenti non vengono toccate, ad esempio: una visualizzazione mensile dell'utilizzo della CPU sul server delle applicazioni principale si aggira intorno all'8%, con il picco dispari fino al 30%. I picchi tendono a coincidere con l'avvio del software di backup.

Storia simile sulla RAM: la percentuale di utilizzo più elevata tra i server è del 35% circa.

Quindi, abbiamo fatto qualche scavo, usando Process Monitor (Microsoft SysInternals) e Wireshark, e la nostra raccomandazione al venditore è che facciano un po 'di tuning TNS in prima istanza. Tuttavia, questo è oltre il punto.

La mia domanda è: come possiamo farli riconoscere che le statistiche VMware che abbiamo inviato loro sono prove sufficienti che più RAM / vCPU non aiuterà?

--- AGGIORNAMENTO 12/07/2014 ---

Settimana interessante. La nostra gestione IT ha affermato che dovremmo apportare la modifica alle allocazioni delle macchine virtuali e ora stiamo aspettando dei tempi di inattività da parte degli utenti aziendali. Stranamente, gli utenti aziendali sono quelli che dicono che alcuni aspetti dell'app stanno funzionando lentamente (rispetto a cosa, non lo so), ma ci faranno "farci sapere" quando potremo smontare il sistema (brontolare , brontoli!).

A parte questo, l'aspetto "lento" del sistema non è apparentemente l'elemento HTTP (S), ovvero: la "sottile app" utilizzata dalla maggior parte degli utenti. Sembra che siano le installazioni "fat client", utilizzate dai principali centri finanziari, a essere apparentemente "lente". Ciò significa che ora stiamo prendendo in considerazione l'interazione client e client-server nelle nostre indagini.

Poiché lo scopo iniziale della domanda era di chiedere assistenza per decidere se percorrere la strada "poke it", o semplicemente apportare la modifica, e ora stiamo apportando la modifica, la chiuderò usando la risposta di longneck .

Grazie a tutti per il vostro contributo; come al solito, serverfault è stato più di un semplice forum - è un po 'come il divano di uno psicologo :-)

Ti suggerisco di apportare le modifiche che hanno richiesto. Quindi confrontare le prestazioni per mostrare loro che non ha fatto alcuna differenza. Potresti anche andare così lontano per confrontarlo con MENO memoria e vCPU per esprimere il tuo punto.

Inoltre, "Ti stiamo pagando per supportare il software con soluzioni reali, non congetture."

Fornendo la certezza di essere all'interno delle specifiche di sistema fornite che documentano.

Quindi, qualsiasi richiesta stiano facendo riguardo al richiedere più RAM o CPU di cui dovrebbero essere in grado di eseguire il backup. Come esperti nel loro sistema, tengo le persone a spiegarlo.

Chiedi loro dettagli.

• Quali informazioni fornite sul sistema indicano che è necessaria più RAM e come è stata interpretata?

• Quali informazioni fornite sul sistema indicano che è necessaria più CPU e come è stata interpretata?

• I dati che ho - a prima vista - contraddicono quello che mi stai dicendo. Puoi spiegarmi perché potrei interpretarlo in modo errato?

• Sto interpretando questa [ovvia serie di dati] nel senso di [ovvia interpretazione]. Potete confermare che lo sto interpretando correttamente riguardo al mio problema?

Avendo avuto a che fare con il supporto in passato, ho posto le stesse domande. A volte avevo ragione e non stavano focalizzando la loro attenzione sul mio problema correttamente. Altre volte, però, mi sbagliavo e interpretavo i dati in modo errato o non includevo altri dati che erano importanti nella mia analisi.

In ogni caso, entrambe queste situazioni sono state un vantaggio per me, o ho imparato qualcosa di nuovo che non sapevo prima - o ho avuto i loro team di supporto a pensare più duramente al mio problema per ottenere una causa decente.

Se il team di supporto non è in grado di fornirti un'espansione logica delle sue argomentazioni su una base di cui puoi essere soddisfatto (devi avere una mente aperta per scendere a compromessi, essere ragionevole accettare che la tua interpretazione dei dati sia sbagliata), allora dovrebbe diventare molto presente nella loro risposta. Anche nel peggiore dei casi è possibile utilizzare questo come base per l'escalation del problema.

La cosa importante è essere in grado di dimostrare che stai usando le migliori pratiche per l'allocazione del tuo sistema, in particolare le prenotazioni di RAM e CPU per il tuo server SQL.

Detto questo, la cosa più semplice è effettuare le modifiche richieste, almeno temporaneamente. Se non altro tende a trascinare i venditori oltre i piedi. Non riesco a contare il numero di volte in cui ho dovuto fare qualcosa di folle come questo per soddisfare una tecnologia dall'altra parte della linea che è davvero il loro software che non si comporta.

Per questa situazione specifica (in cui hai sviluppatori VMware e applicativi o una terza parte che non capisce l'allocazione delle risorse), utilizzo una metrica di una settimana di metriche ottenute da vCenter Operations Manager (vCops - scarica una demo se necessario ) per individuare i vincoli reali , colli di bottiglia e requisiti di dimensionamento delle macchine virtuali dell'applicazione.

A volte, sono stato in grado di soddisfare i consumatori più testardi modificando le prenotazioni delle VM o cambiando le priorità per gestire gli scenari di contesa; " Se la RAM | CPU sono stretti, IL TUO VM avrà la precedenza! ". Cose brutte sono successe quando ho permesso ai produttori di software di dettare i loro requisiti sui miei cluster vSphere senza una vera analisi .

Ma in generale, numeri e dati dovrebbero vincere.

Un esempio di qualcosa che ho usato per giustificare il dimensionamento della VM allo sviluppatore di un'applicazione Tomcat:

Dev : la VM ha bisogno di CPU MOAR!

Io : beh, la memoria è il tuo più grande vincolo, ed ecco una mappa di calore della tua performance rispetto al tempo ... Mercoledì alle 18:00 sono i periodi più stressanti, quindi possiamo speculare su quel periodo di punta. Oh, ed ecco una raccomandazione di dimensionamento basata sulle ultime 6 settimane di metriche di produzione ...

Lavoravo in supporto - e parte di ciò che stai chiedendo sembra molto razionale (e probabilmente lo è): ma ci sono alcune domande da porsi prima di fare semplicemente il "miglioramento delle prestazioni" che stanno richiedendo

• stai già eseguendo almeno i requisiti minimi di sistema indicati dal fornitore?
• se hai almeno un minimo di sysreqs, hai già le impostazioni di sistema "consigliate"?

I fornitori saranno 99 volte su 100 (secondo la mia esperienza, sia sul lato dell'assistenza che sul lato cliente / sul campo), non si occuperanno nemmeno di problemi relativi alle prestazioni fino a quando i sistemi non corrisponderanno a quanto richiesto dalla loro documentazione. Forse è un sistema che funziona bene il 99,5% delle volte con 1 CPU e 512 MB di RAM, ma se i requisiti di sistema indicano 4 CPU e 4 GB di RAM e hai solo 2 CPU e 1 GB di RAM, rientrano pienamente nei loro diritti di richiedere l'assegnazione di più risorse ^* .

È probabile che ti chiedano di aumentare le risorse di sistema a causa di qualcosa che hanno trovato in laboratorio / sviluppo in cui un problema scompare magicamente se si attraversa una soglia specifica; in questo caso, sì, è un esempio di debug potenzialmente scadente da parte loro, ma tieni presente che non hanno tempo per eliminare ogni possibile bug / problema che si presenta - alcuni devono solo essere aggirati, e se questo è il caso qui, basta andare con esso.

C'è anche una possibilità non insignificante che i problemi che stai vedendo non fanno nemmeno parte del "loro" software, ma un componente su cui fanno affidamento da qualche altra fonte (fornitore, libreria OSS, ecc.). Mi sono imbattuto in questa situazione esatta legata alla dimensione dello swap, BEA WebLogic e Sun JRE presso un cliente alcuni anni fa.

tl; dr:

In breve, lavora con il loro team di supporto, intensificando secondo necessità, fino a quando non trovi una soluzione, ma non essere sorpreso quando alcuni dei suggerimenti / passaggi di debug / correzioni sembrano off-the-wall o inutili.

^{* _{Se davvero non "ha bisogno" di quelle risorse extra, è probabile che tu sia in grado di archiviare un bug doc / RFE per le versioni future - ma non spingere quel percorso fino a quando non hai dimostrato che non è il problema a portata di mano}
^ _{un eBook che ho scritto potresti trovare utile sull'argomento: Debug e supporto dei sistemi software}}

O chiedere di intensificare il biglietto o chiedere un rappresentante diverso. A seconda del fornitore, l'escalation può essere utile se si afferma che l'attuale livello di supporto non risolve adeguatamente il problema. Se non si intensificheranno, potrebbe essere utile chiedere un rappresentante diverso perché ciò richiede molta meno "giustificazione" poiché tutto ciò di cui ha bisogno è non essere soddisfatto di quello attuale.

Se si tratta di un fornitore di grandi dimensioni, chiudere semplicemente il ticket e aprirne uno nuovo sullo stesso problema potrebbe funzionare in quanto potrebbe essere indirizzato a un rappresentante diverso, ma lo sconsiglio perché è in forma scadente.

Potresti anche mantenere la tua posizione e chiedere una logica su come aiuterà più RAM / vCPU, oppure potresti semplicemente dargli più RAM / vCPU per dimostrare che non aiuterà.

Aggiungerò i miei due centesimi. Abbiamo avuto abbastanza successo con questo approccio: risultati molto migliori e meno frustrazione da parte di tutti. Richiede molto più sforzo del gioco della colpa e aggiunge ciecamente risorse, ma ha anche maggiori possibilità di trovare il problema di fondo.

Quando abbiamo seri problemi con le nostre app on-premise che sono supportate da contratti di supporto del fornitore e i venditori iniziano la loro dodge shuffling dance (che sembra sempre includere richieste stravaganti non basate su dati per più CPU o RAM), tendiamo a fai queste 3 cose:

1. Aumenta la priorità all'equivalente di sistema - di solito si oppongono, ma di solito si abbassano quando spieghi che è effettivamente inutilizzabile anche se tecnicamente "funziona". Consideralo come un problema serio da risolvere. Da queste parti ci riferiamo a ciò come una squadra di tigri, che si riunisce quotidianamente per ottenere aggiornamenti sullo stato da tutte le parti interessate. Di solito il venditore ti chiederà di cambiare roba. Se si tratta di un sistema prod, questo è problematico, ma se vuoi che ti aiutino, dovrai assumerti la responsabilità di aiutarli a isolare il problema, quindi aiuta se hai un ambiente di sviluppo / stadiazione in cui puoi eseguire i test.

2. Di 'al fornitore che vuoi che replicino il tuo ambiente, in modo che possano isolare il problema nel loro laboratorio. Possono anche ospitare cose in un ambiente cloud, se necessario. Non deve corrispondere esattamente al tuo ambiente, anche se sarebbe l'ideale. Il punto è che vuoi che VENDOR stia provando attivamente a replicare il tuo problema, in modo che possano testare le loro congetture sul proprio sistema anziché sul tuo. Chiedere loro i diagrammi, le specifiche, ecc. Di quell'ambiente replicato per assicurarsi che lo stiano facendo.

3. Fornisci loro (ovviamente sotto NDA) il tuo set di dati reale in modo che possano eseguirlo / riprodurlo per davvero invece di indovinare. Nel nostro caso, la maggior parte dei problemi relativi alle app forniti dal fornitore (sia temporanei che cronici) si rivelano spesso problemi con i database forniti dal fornitore. Non riesco a contare il numero di volte che lo abbiamo fatto e hanno finalmente individuato il problema in qualcosa di inaspettato nei dati reali: strani manufatti dagli aggiornamenti delle app 2 anni fa in cui qualcosa non è stato convertito in modo pulito; record non aggiornati che espongono un problema con le impostazioni del GC; le query non funzionano correttamente perché i NOSTRI valori dei dati interrompono alcune routine di trasmissione nel codice fornitore, ecc. Roba che non saremmo mai in grado di identificare da soli.

Abbiamo fatto questo con parecchi fornitori negli ultimi anni e inizialmente sono molto resistenti a fare a modo nostro. Tuttavia, dopo che funziona, si presenta sempre come un punto culminante positivo nelle recensioni trimestrali che teniamo con i nostri fornitori. E aiuta a cementare il nostro rapporto tecnico con quei fornitori. Non vogliono problemi vaghi. Vogliono problemi specifici che possono analizzare per migliorare i loro prodotti.

Spero che il suggerimento sia d'aiuto. So che non è un approccio adatto a tutti, ma se riesci a farlo oscillare penso che lo troverai utile.

La vera domanda è: chi è responsabile qui? Se non riesci a passare realisticamente a un fornitore alternativo, allora hanno il potere e tutto ciò che puoi fare è andare avanti con tutto ciò che dicono e sperare che funzioni. Non è una situazione felice! Altrimenti, ti suggerisco di chiedere un altro rappresentante (come altri hanno già detto), ma chiarisci che non sei soddisfatto del servizio e cercherai altrove se non possono fare il lavoro.

Non limitarti a "apportare le modifiche che hanno suggerito" se sei sicuro che non funzioneranno, poiché questo sta creando uno schema per la tua relazione che ti farà del male a lungo termine. Li stai pagando per fornirti un servizio e non dovrebbero essere in grado di dettare le tue azioni più di quanto qualcuno che assumo per dipingere la mia casa possa dettare di che colore sarà.

Questo può sembrare drastico, in quanto sembra che questo non sia un problema estremamente critico, ma il fatto è che se ti stanno scherzando su qualcosa di minore, probabilmente faranno lo stesso per qualcosa di grosso, e l'ultima cosa che vuoi è imbattersi in una sorta di orribile charlie foxtrot sei mesi lungo la linea e avere gli stessi problemi con il venditore.

Assicurati che qualunque cosa tu faccia per risolvere il problema ora, funzionerà ugualmente bene quando mancano due giorni a una scadenza e tutto si rompe ...

Pubblicherò una vista dal lato del venditore.

Abbiamo avuto questo cliente che aveva questo problema ricorrente in cui le prestazioni del software sarebbero diminuite ogni poche ore o giù di lì a un tasso davvero spaventoso per poi tornare dopo poche ore.

Il profiler bulitino nel sistema indicava che la velocità della CPU del sistema (o forse della memoria) era disgustosamente lenta, qualcosa come 100MHZ piuttosto che i 2GHZ previsti. Raddoppiare la CPU fornita dalla VM non ha modificato il sintomo e hanno pensato che fossimo sprecati.

Dato che non potevano ottenere una CPU più veloce (più CPU non avrebbero aiutato), abbiamo quindi provato a scambiare macchine virtuali TEST e PROD. Il problema si è quindi manifestato su TEST il giorno successivo. Quindi abbiamo provato a promuovere uno dei client in un'istanza autonoma (senza server). Nessun problema su quella workstation mentre il server stava soffocando.

Hanno prodotto report dall'host di macchine virtuali che non indicavano problemi di prestazioni e hanno tentato nuovamente di affermare che si trattava di un problema dell'applicazione.

Alla fine io [un ingegnere] (non avevo supporto da parte di quelli con ruoli di supporto dedicati) ho chiesto specificamente una scatola fisica. Il cliente ha urlato un sanguinoso omicidio, ma nessuno ha avuto altre potenziali soluzioni. Cosa sai, il problema è magicamente scomparso.

Non abbiamo mai scoperto quale fosse il problema. Tutti i programmi di benchmark sono risultati normali, ma il profiler dell'applicazione ci stava dicendo che le risorse informatiche semplicemente non erano adeguate. C'è una specie di firma specifica che cerchiamo ora nel profiler. Se lo vediamo, sappiamo prima di andare oltre il problema è l'interazione della VM, ma al momento non era noto.

Pensavano sicuramente che ne fossi pieno. Non lo ero. Ero senza opzioni.

EDIT, aggiornamento da anni dopo:

Con un numero sempre maggiore di clienti che desiderano eseguire VM e management disposti a tentare di risolvere il problema a tutti i costi, abbiamo ottenuto un buon hardware VM. Sono stato in grado di costruire un programma di masterizzazione di VM specializzato che funzionava nello spazio utente (e non richiedeva privilegi) su due VM single-core con 512 MB di RAM, in grado di drenare prestazioni di memoria 1/3 da un'altra VM single-core con solo 4 core totali su 16 in uso sull'host di macchine virtuali e la maggior parte dei suoi ram sono ancora liberi. Il programma non ha generato allarmi e non ha mostrato nulla di straordinario sull'host di macchine virtuali né su nessuno degli ospiti, ad eccezione dell'accesso alla memoria lento.

Ora possiamo dire ai clienti che sappiamo che c'è un problema con le VM e non è il nostro software. Di tanto in tanto riceviamo richieste dei clienti per software compatibile con VM. Mi chiedo perché la gestione non permetta al supporto di dire loro che siamo stati in grado di sviluppare un software che rallenta ogni altra macchina virtuale sullo stesso host.

La cosa spaventosa è che la tecnica in questione è una semplice trasformazione della nota tecnica di programmazione che prevede la sincronizzazione senza blocco. Centinaia di fornitori di software potrebbero avere questo drainer VM nel loro software e non saperlo. Ottenere un blocco di istruzioni atomiche che ha fortemente contestato dovrebbe essere raro ma non impossibile. La parte divertente di tutto questo è che stavo ottenendo il blocco per contestare le VM ACROSS.

Suggerirei un approccio molto diverso da quelli menzionati finora. Prima di discutere con il fornitore, perché non guardare più da vicino il problema segnalato e vedere cosa ti dice.

Quali sono i problemi reali segnalati e quali sono le aspettative degli utenti. Se un utente sta dicendo qualcosa "impiega troppo tempo", chiedi esattamente che cos'è (in modo da poterlo riprodurre), quanto pensano che dovrebbe impiegare e perché pensano che dovrebbe impiegare così tanto tempo. Se le loro aspettative sono ragionevoli, misurare le prestazioni effettive e l'impatto del sistema su ciò che stanno cercando di fare. Il fatto che il sistema mostri un picco del 30% nell'arco di un mese non significa che non stia funzionando a> 100% quando l'utente sta provando la sua query. Se riesci a dimostrare al tuo fornitore che CPU e memoria non sono stressati dall'attività problematica, puoi chiedere al venditore di giustificare raccomandazioni che ti costeranno denaro.