Comment [poliment?] Dire au fournisseur de logiciels qu'ils ne savent pas de quoi ils parlent

Pas une question technique, mais néanmoins valable. Scénario:

HP ProLiant DL380 Gen 8 avec 2 processeurs Xeon E5-2667 à 8 cœurs et 256 Go de RAM sous ESXi 5.5. Huit machines virtuelles pour le système d'un fournisseur donné. Quatre machines virtuelles à tester, quatre machines virtuelles à produire. Les quatre serveurs de chaque environnement remplissent différentes fonctions, par exemple: serveur Web, serveur d'applications principal, serveur de base de données OLAP et serveur de base de données SQL.

Partages d'UC configurés pour empêcher l'environnement de test d'avoir un impact sur la production. Tout le stockage sur SAN.

Nous avons posé des questions sur les performances et le fournisseur a insisté sur le fait que nous devions donner au système de production plus de mémoire et de vCPU. Cependant, vCenter montre clairement que les allocations existantes ne sont pas touchées, par exemple: une vue mensuelle de l'utilisation de l'UC sur le serveur d'applications principal oscille autour de 8%, avec une pointe pouvant atteindre 30%. Les pics ont tendance à coïncider avec le démarrage du logiciel de sauvegarde.

Histoire similaire sur RAM: le taux d'utilisation le plus élevé sur les serveurs est d'environ 35%.

Nous avons donc fait des recherches en utilisant Process Monitor (Microsoft SysInternals) et Wireshark, et nous recommandons au fournisseur d’effectuer certains réglages TNS en premier lieu. Cependant, c'est en dehors du point.

Ma question est la suivante: comment pouvons-nous leur faire reconnaître que les statistiques VMware que nous leur avons envoyées sont une preuve suffisante que plus de RAM / vCPU n’aidera pas?

--- MISE À JOUR 12/07/2014 ---

Semaine intéressante. Notre direction informatique a déclaré que nous devrions modifier les allocations des ordinateurs virtuels. Nous attendons maintenant un certain temps d'indisponibilité de la part des utilisateurs professionnels. Étrangement, ce sont les utilisateurs professionnels qui disent que certains aspects de l'application fonctionnent lentement (par rapport à ce que je ne sais pas), mais ils vont "nous le faire savoir" quand nous pourrons mettre le système en panne (grommeler , grogne!).

En passant, l'aspect "lent" du système n'est apparemment pas l'élément HTTP (S), c'est-à-dire "l'application mince" utilisé par la plupart des utilisateurs. On dirait que ce sont les installations du "gros client", utilisées par les principaux organismes financiers, qui sont apparemment "lentes". Cela signifie que nous examinons maintenant les interactions client / serveur dans nos enquêtes.

Comme le but initial de la question était de demander de l’aide afin de déterminer s’il fallait emprunter la voie du «piquer-le» ou simplement apporter le changement, et nous procédons maintenant au changement, je vais le terminer en utilisant la réponse de longneck .

Merci à tous pour votre participation; comme d'habitude, serverfault a été plus qu'un simple forum - c'est un peu comme le canapé d'un psychologue :-)

Je suggère que vous apportiez les ajustements demandés. Ensuite, comparez les performances pour leur montrer que cela ne fait aucune différence. Vous pouvez même aller aussi loin en le comparant avec moins de mémoire et vCPU pour faire valoir votre point de vue.

En outre, "Nous vous payons pour que le logiciel soit pris en charge avec des solutions réelles, et non par approximations."

Pourvu que vous soyez sûr de respecter les spécifications système spécifiées qu’ils documentent.

Ensuite, toute réclamation relative à l'utilisation de plus de RAM ou de CPU devrait être sauvegardée. En tant qu'experts de leur système, je demande des comptes aux gens à ce sujet.

Demandez leur des détails.

• Quelles informations fournies sur le système indiquent qu'il faut plus de RAM et comment l'avez-vous interprétées?

• Quelles informations fournies sur le système indiquent qu'il faut plus de CPU et comment avez-vous interprété cela?

• Les données que j'ai - à première vue - contredisent ce que vous me dites. Pouvez-vous m'expliquer pourquoi je peux interpréter cela de manière incorrecte?

• J'interprète cette [série évidente de données] comme signifiant [interprétation évidente]. Pouvez-vous confirmer que je l’interprète correctement en ce qui concerne mon problème?

Ayant traité avec le soutien dans le passé, j'ai posé les mêmes questions. Parfois, j'avais raison et ils ne concentraient pas leur attention sur mon problème correctement. D’autres fois, j’ai eu tort et j’ai mal interprété les données ou omis d’inclure d’autres données importantes pour mon analyse.

Dans tous les cas, ces deux situations ont été un avantage net pour moi: soit j'ai appris quelque chose de nouveau que je ne connaissais pas auparavant, soit j'ai demandé à leurs équipes de soutien de réfléchir plus sérieusement à mon problème pour trouver une cause fondamentale décente.

Si l'équipe de support n'est pas en mesure de vous fournir une extension logique de leurs arguments, vous pouvez en être satisfait (vous devez être ouvert d'esprit pour vous compromettre, être raisonnable d'accepter que votre interprétation des données soit erronée). devrait devenir très présent dans leur réponse. Même dans le pire des cas, vous pouvez vous en servir comme base pour l'escalade du problème.

L’essentiel est de pouvoir prouver que vous utilisez les meilleures pratiques pour l’allocation de votre système, notamment les réservations de RAM et de CPU pour votre serveur SQL.

Tout ceci étant dit, le plus simple est d’effectuer les ajustements demandés, au moins temporairement. Si rien d’autre, les vendeurs ont tendance à se laisser aller. Je ne peux pas compter le nombre de fois où j'ai eu besoin de faire quelque chose de fou pour satisfaire un technicien à l'autre bout de la ligne que ce soit vraiment leur logiciel qui ne se comporte pas.

Pour cette situation spécifique (où vous avez des développeurs d'applications et VMware ou un tiers qui ne comprend pas l'allocation de ressources), j'utilise une métrique d'une semaine obtenue à partir de vCenter Operations Manager (vCops - téléchargez une démonstration si nécessaire ) pour identifier les contraintes réelles. , goulots d'étranglement et exigences de dimensionnement des ordinateurs virtuels de l'application.

Parfois, j'ai pu satisfaire les consommateurs les plus obstinés en modifiant les réservations de machines virtuelles ou en modifiant les priorités pour gérer les scénarios de conflit. " Si RAM | CPU sont serrés, VOTRE VM sera prioritaire! ". De mauvaises choses se sont produites lorsque j'ai permis aux éditeurs de logiciels de dicter leurs exigences sur mes clusters vSphere sans analyse réelle .

Mais en général, les chiffres et les données devraient être gagnants.

Un exemple de quelque chose que j'ai utilisé pour justifier le dimensionnement d'une machine virtuelle au développeur d'une application Tomcat:

Dev : La VM a besoin du processeur MOAR!

Moi : Eh bien, la mémoire est votre plus grande contrainte, et voici une carte thermique de votre performance en fonction du temps ... Les mercredis à 18h sont les périodes les plus stressantes, nous pouvons donc spécifier cette période de pointe. Oh, et voici une recommandation de dimensionnement basée sur les mesures de production des 6 dernières semaines ...

J'avais l'habitude de travailler dans l'assistance - et une partie de ce que vous demandez semble très rationnelle (et l'est probablement): mais il y a quelques questions à vous poser avant de simplement faire "l'amélioration de la performance" qu'ils demandent.

• exécutez-vous déjà au moins la configuration système minimale indiquée par le fournisseur?
• si vous êtes au moins au minimum sur sysreqs, êtes-vous déjà à leurs paramètres système "recommandés"?

99 fournisseurs sur 100 (selon mon expérience - du côté du support et du côté client / du site) ne traitent même pas les problèmes liés aux performances tant que les systèmes ne correspondent pas aux exigences de leur documentation. C’est peut-être un système qui fonctionne très bien 99,5% du temps avec 1 processeur et 512 Mo de RAM - mais si la configuration système requise indique 4 processeurs et 4G de RAM et que vous n’avez que 2 processeurs et 1G de RAM, ils sont bien dans leurs droits demander que plus de ressources soient allouées ^* .

Il est probable qu'ils vous demandent d'augmenter les ressources système à cause de quelque chose qu'ils ont trouvé dans le laboratoire / développement et dans lequel un problème disparaît comme par magie si vous dépassez un seuil spécifique. si c'est le cas, oui, c'est un exemple de débogage potentiellement médiocre de leur côté, mais gardez à l'esprit qu'ils n'ont pas le temps d'éliminer tous les bogues / problèmes possibles - certains doivent simplement être résolus, et si c'est le cas ici, allez-y avec ça.

Il y a également une chance non négligeable que les problèmes que vous rencontrez ne fassent même pas partie de "leur" logiciel, mais qu'ils utilisent un composant d'une autre source (fournisseur, bibliothèque OSS, etc.). J'ai rencontré cette situation exacte liée à la taille de l'échange, BEA WebLogic et Sun JRE chez un client il y a quelques années.

tl; dr:

En bref, travaillez avec leur équipe de support, en augmentant si nécessaire, jusqu'à ce que vous trouviez une résolution - mais ne soyez pas surpris lorsque certaines des suggestions / étapes de débogage / corrections semblent tout à fait originales ou inutiles.

^{* _{S'il n'a vraiment pas "besoin" de ces ressources supplémentaires, vous êtes probablement en mesure de pouvoir déposer un doc / document bug / RFE pour les versions futures - mais ne poussez pas cette route avant d'avoir démontré que ce n'est pas le cas. problème en cours}
^ _{un eBook que j'ai écrit pourrait vous être utile sur le sujet: Débogage et prise en charge de systèmes logiciels}}

Soit demander à faire monter le billet ou demander un représentant différent. En fonction du fournisseur concerné, l'escalade peut vous aider si vous dites que le niveau de support actuel ne résout pas le problème de manière adéquate. S'ils ne veulent pas escalader, alors demander un représentant différent peut aider car cela nécessite beaucoup moins de "justification" car tout ce dont il a besoin est de ne pas être heureux avec l'actuelle.

S'il s'agit d'un gros fournisseur, fermer simplement le ticket et en ouvrir un nouveau sur le même problème peut fonctionner, car il peut être acheminé vers un autre représentant, mais je le déconseille car il s'agit d'un format médiocre.

Vous pouvez également rester ferme et demander une explication sur la manière dont davantage de RAM / vCPU aidera, ou vous pouvez simplement lui donner plus de RAM / vCPU pour prouver que cela ne vous aidera pas.

Je vais jeter mes deux cents. Cette approche a très bien réussi: résultats bien meilleurs et moins de frustration de la part de tous. Cela demande beaucoup plus d'efforts que le jeu du blâme et l'ajout aveugle de ressources, mais il a également de meilleures chances de trouver le problème sous-jacent.

Lorsque nous rencontrons de graves problèmes avec nos applications sur site, qui sont soutenues par des contrats de support des fournisseurs, et que les fournisseurs entament leur danse de dodge shuffling (qui semble toujours inclure des demandes farfelues ne nécessitant pas davantage de ressources processeur ou RAM), nous avons tendance à: faire ces 3 choses:

1. Transférer la priorité en système équivalent - ils rechignent généralement, mais reviennent généralement lorsque vous leur expliquez que c'est effectivement inutilisable, même si cela fonctionne techniquement. Traitez-le comme un problème grave à résoudre. Ici, nous appelons cela une équipe de tigres, qui se réunit tous les jours pour obtenir des mises à jour de statut de toutes les parties prenantes. Habituellement, le fournisseur vous demandera de changer des choses. Si c'est un système de prod, c'est problématique, mais si vous voulez qu'ils vous aident, vous devrez accepter la responsabilité de les aider à isoler le problème. Cela vous aidera si vous disposez d'un environnement de développement / de développement où vous pouvez exécuter des tests.

2. Indiquez au fournisseur que vous souhaitez qu'il réplique votre environnement, afin qu'il puisse isoler le problème dans son laboratoire. Ils peuvent même héberger des contenus dans un environnement cloud si nécessaire. Cela ne doit pas nécessairement correspondre exactement à votre environnement, même si ce serait idéal. Le but est que vous souhaitiez que le VENDEUR tente activement de reproduire votre problème, afin qu’il puisse tester ses incertitudes sur son système plutôt que sur le vôtre. Demandez-leur les diagrammes, les spécifications, etc. de cet environnement répliqué pour s'assurer qu'ils le font.

3. Fournissez-leur (sous NDA bien sûr) votre jeu de données réel afin qu'ils puissent l'exécuter / le rejouer pour de vrai, au lieu de le deviner. Dans notre cas, la plupart des problèmes liés aux applications fournies par les fournisseurs (transitoires et chroniques) sont souvent liés aux bases de données fournies par les fournisseurs. Je ne peux pas compter le nombre de fois où nous l'avons fait et ils ont finalement identifié le problème à quelque chose d'inattendu dans les données réelles - d'étranges artefacts de mises à niveau d'applications il y a 2 ans où quelque chose ne s'est pas converti proprement; enregistrements obsolètes révélant un problème avec les paramètres du CPG; les requêtes ne fonctionnent pas correctement parce que nos valeurs de données brisent certaines routines de transmog dans le code du vendeur, etc. Des informations que nous ne pourrions jamais identifier nous-mêmes.

Nous avons fait cela avec un certain nombre de fournisseurs au cours des dernières années, et ils sont d’abord très réticents à le faire à notre façon. Cependant, une fois que cela fonctionne, cela apparaît toujours comme un élément positif dans les examens trimestriels que nous effectuons avec nos fournisseurs. Et cela contribue à cimenter nos relations techniques avec ces fournisseurs. Ils ne veulent pas de problèmes vagues. Ils veulent des problèmes spécifiques qu'ils peuvent analyser pour améliorer leurs produits.

J'espère que la suggestion aide. Je sais que ce n'est pas une approche unique, mais si vous pouvez vous en servir, je pense que vous le trouverez intéressant.

La vraie question est de savoir qui est responsable ici? Si vous ne pouvez pas vous adresser de manière réaliste à un autre fournisseur, ils ont le pouvoir. Tout ce que vous pouvez vraiment faire, c'est accepter ce qu'ils disent et espérons que cela fonctionnera. Pas une situation heureuse! Autrement, je vous suggère de demander à un autre représentant (comme d'autres l'ont déjà dit), mais précisez que vous n'êtes pas satisfait du service et que vous chercherez ailleurs s'il ne peut pas faire le travail.

Ne vous contentez pas de "faire les ajustements suggérés" si vous êtes certain que cela ne marchera pas, car il s’agit d’établir un modèle pour votre relation qui vous fera mal à long terme. Vous les payez pour vous fournir un service, et ils ne devraient pas être en mesure de dicter vos actions, pas plus qu'une personne que j'engage pour peindre ma maison ne peut dicter de quelle couleur elle sera.

Cela peut sembler drastique, car il semble que ce n’est pas un problème extrêmement important, mais le fait est que s’ils vous dérangent sur quelque chose de mineur, ils feront probablement de même pour quelque chose de grand, et la dernière chose que vous voulez est de rencontrez une sorte d'horrible charlie foxtrot six mois plus tard et rencontrez le même problème avec le vendeur à ce moment-là.

Assurez-vous que les mesures que vous prenez pour résoudre le problème maintenant fonctionneront aussi bien deux jours à compter de la date limite et que tout se passe bien ...

Je vais poster une vue du côté du vendeur.

Nous avons eu ce client qui a eu ce problème récurrent où la performance du logiciel chutait toutes les quelques heures à peu près à un taux vraiment abyssal puis revenait quelques heures plus tard.

Le profileur de bulitin dans le système a indiqué que la vitesse du processeur du système (ou éventuellement de la mémoire) était démesurément lente, quelque chose comme 100MHZ au lieu des 2GHZ attendus. Doubler le processeur fourni par la machine virtuelle ne changeait pas le symptôme et pensait que nous gaspillions.

Comme ils ne pouvaient pas obtenir un processeur plus rapide (plus de processeurs n'allaient pas aider), nous avons ensuite essayé d'échanger les machines virtuelles TEST et PROD. Le problème est apparu le lendemain sur TEST. Nous avons ensuite essayé de promouvoir l’un des clients en une instance autonome (sans serveur). Aucun problème sur ce poste de travail alors que le serveur était en train de s'étouffer.

Ils ont produit des rapports à partir de l'hôte VM indiquant l'absence de problème de performances et ont à nouveau affirmé qu'il s'agissait d'un problème d'application.

Enfin, j'ai [un ingénieur] (je n'avais aucune assistance de ceux qui occupaient des rôles d'assistance dédiés) et j'ai spécifiquement demandé une boîte physique. Le client a crié au meurtre, mais personne ne pouvant le faire, il l'a fait. Que savez-vous, le problème a disparu comme par magie.

Nous n'avons jamais découvert quel était le problème. Tous les programmes de référence ont montré des résultats normaux, mais le profileur d’application nous disait que les ressources informatiques n’étaient tout simplement pas adéquates. Nous recherchons maintenant une sorte de signature spécifique dans le profileur. Si nous le voyons, nous savons qu'avant d'aller plus loin, le problème est l'interaction de la machine virtuelle, mais le problème n'était pas connu à l'époque.

Ils pensaient bien que j'en étais plein. Je n'étais pas. J'étais à court d'options.

EDIT, Mise à jour des années plus tard:

Avec de plus en plus de clients souhaitant utiliser des ordinateurs virtuels et une gestion disposée à tenter de résoudre le problème à tout prix, nous avons obtenu un bon matériel d'ordinateur virtuel. J'ai pu construire un programme de gravure de machine virtuelle spécialisé s'exécutant en espace utilisateur (sans aucun privilège) sur deux machines virtuelles monocœur avec 512 Mo de RAM, capable de drainer 1/3 des performances de la mémoire d'une autre machine virtuelle monocœur avec seulement 4 nombre total de cœurs sur 16 utilisés sur l'hôte de la machine virtuelle et la plupart de ses béliers sont encore libres. Le programme n'a déclenché aucune alarme et ne montre rien d'extraordinaire sur l'hôte de la machine virtuelle ni sur aucun des invités, à l'exception de la lenteur de l'accès à la mémoire.

Nous pouvons maintenant dire aux clients que nous savons qu'il existe un problème avec les ordinateurs virtuels et que ce n'est pas notre logiciel. Nous recevons encore de temps à autre les demandes de nos clients pour des logiciels compatibles avec les machines virtuelles. Je me demande pourquoi la direction ne laisse pas le support technique leur dire que nous avons pu développer un logiciel qui ralentit toutes les autres VM sur le même hôte.

Ce qui est effrayant, c’est que la technique impliquée est une simple transformation de la technique de programmation bien connue impliquant une synchronisation sans verrouillage. Des centaines de fournisseurs de logiciels pourraient avoir cet égouttoir de VM dans leur logiciel sans le savoir. Obtenir un verrou d’instruction atomique très disputé devrait être rare mais pas impossible. Ce qui est amusant, c’est que j’ai eu le verrou pour pouvoir contester ACROSS VM.

Je suggérerais une approche très différente de celles mentionnées jusqu'à présent. Avant de vous disputer avec le fournisseur, pourquoi ne pas regarder de plus près le problème signalé et voir ce que cela vous dit.

Quels sont les problèmes réels signalés et quelles sont les attentes des utilisateurs. Si un utilisateur dit quelque chose "prend trop de temps", demandez-lui exactement ce que c'est (pour que vous puissiez le reproduire), combien de temps il pense que cela devrait prendre et pourquoi il pense que cela devrait prendre si longtemps. Si leurs attentes sont raisonnables, mesurez les performances réelles et l'impact système de ce qu'ils tentent de faire. Le fait que votre système affiche une hausse de 30% sur un mois ne signifie pas qu'il ne fonctionne pas à plus de 100% lorsque l'utilisateur essaie leur requête. Si vous pouvez démontrer à votre fournisseur que la tâche problématique ne sollicite pas le processeur et la mémoire, vous pouvez lui demander de justifier les recommandations qui vous coûteront de l'argent.