Comment dire [poliment ?] à un vendeur de logiciels qu'il ne sait pas de quoi il parle ?

Demandez à faire remonter le ticket ou demandez un autre représentant. Selon le fournisseur, l'escalade peut être utile si vous dites que vous estimez que le niveau de support actuel ne répond pas de manière adéquate au problème. S'ils refusent d'escalader le ticket, demander un autre représentant peut être utile car cela demande beaucoup moins de "justification" puisqu'il suffit de ne pas être satisfait du représentant actuel.

S'il s'agit d'un gros fournisseur, il suffit de fermer le ticket et d'en ouvrir un nouveau pour le même problème, car il peut être acheminé vers un autre représentant, mais je vous le déconseille car c'est une mauvaise manière.

Vous pouvez également rester sur vos positions et demander une justification de l'utilité d'une plus grande quantité de RAM/vCPU, ou vous pouvez simplement lui donner plus de RAM/vCPU pour prouver que cela ne sert à rien.

Je vais ajouter mes deux cents. Nous avons eu beaucoup de succès avec cette approche - de bien meilleurs résultats et moins de frustration de la part de chacun. Elle demande beaucoup plus d'efforts que le jeu des reproches et l'ajout aveugle de ressources, mais elle a aussi de meilleures chances de trouver le problème sous-jacent.

Lorsque nous rencontrons de sérieux problèmes avec nos applications sur site qui sont couvertes par des contrats d'assistance des fournisseurs, et que ces derniers commencent leur danse d'esquive (qui semble toujours inclure des demandes farfelues et non fondées sur des données pour plus de CPU ou de RAM), nous avons tendance à faire ces 3 choses :

1. Escaladez la priorité à l'équivalent du système en panne - ils hésitent généralement, mais reviennent en arrière lorsque vous expliquez que le système est effectivement inutilisable même s'il est techniquement "fonctionnel". Traitez-le comme un problème sérieux qu'ils doivent résoudre. Ici, nous appelons cela une équipe de choc, qui se réunit quotidiennement pour obtenir des mises à jour de l'état d'avancement de toutes les parties prenantes. En général, le fournisseur vous demandera de changer des choses. S'il s'agit d'un système de production, c'est problématique, mais si vous voulez qu'il vous aide, vous devrez accepter la responsabilité de l'aider à isoler le problème, ce qui est utile si vous disposez d'un environnement de développement/staging où vous pouvez effectuer des tests.

2. Dites au fournisseur que vous voulez qu'il reproduise votre environnement, afin qu'IL puisse isoler le problème dans son laboratoire. Ils peuvent même héberger le matériel dans un environnement en nuage si nécessaire. Il n'est pas nécessaire qu'il s'agisse d'une copie exacte de votre environnement, même si ce serait l'idéal. Le but est que le VENDEUR essaie activement de reproduire votre problème, afin qu'il puisse tester ses suppositions sur son système plutôt que sur le vôtre. Demandez-lui les diagrammes, les spécifications, etc. de cet environnement répliqué pour vous assurer qu'il le fait.

3. Fournissez-leur (sous couvert d'un accord de confidentialité, bien sûr) votre jeu de données réel afin qu'ils puissent l'exécuter/le reproduire pour de vrai au lieu de deviner. Dans notre cas, la plupart des problèmes liés aux applications fournies par le fournisseur (qu'ils soient passagers ou chroniques) s'avèrent souvent être des problèmes liés aux bases de données fournies par le fournisseur. Je ne compte plus le nombre de fois où nous avons fait cette démarche et où le problème a finalement été attribué à quelque chose d'inattendu dans les données : des artefacts bizarres provenant de mises à jour de l'application il y a deux ans où quelque chose n'a pas été converti proprement ; des enregistrements périmés exposant un problème avec les paramètres GC ; des requêtes ne fonctionnant pas tout à fait correctement parce que NOS valeurs de données brisent une routine transmog dans le code du fournisseur, etc. Des choses que nous ne serions jamais capables d'identifier par nous-mêmes.

Nous l'avons fait avec un certain nombre de fournisseurs au cours des dernières années, et ils sont au départ très réticents à l'idée de procéder comme nous le faisons. Cependant, une fois que cela a fonctionné, c'est toujours un point positif dans les évaluations trimestrielles que nous faisons avec nos fournisseurs. Et cela contribue à cimenter notre relation technique 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 cette suggestion vous aidera. Je sais que ce n'est pas une approche universelle, mais si vous pouvez le faire, je pense que vous trouverez cela intéressant.

La vraie question est : qui est responsable ici ? Si vous ne pouvez pas, de manière réaliste, passer à un autre fournisseur, alors c'est lui qui a le pouvoir, et tout ce que vous pouvez faire, c'est faire ce qu'il dit en espérant que tout ira bien. Ce n'est pas une situation heureuse ! Sinon, je vous suggère de demander un autre représentant (comme d'autres l'ont dit), mais dites clairement que vous n'êtes pas satisfait du service et que vous irez voir ailleurs s'ils ne peuvent pas faire le travail.

Ne vous contentez pas de "faire les ajustements qu'ils ont suggérés" si vous êtes sûr qu'ils ne fonctionneront pas, car cela crée un modèle de relation qui vous nuira à long terme. Vous les payez pour qu'ils vous fournissent un service, et ils ne devraient pas pouvoir vous dicter vos actions, pas plus qu'une personne que j'engage pour peindre ma maison ne peut me dicter la couleur qu'elle prendra.

Cela peut sembler radical, car il semble que ce n'est pas un problème extrêmement critique, mais le fait est que s'ils vous embêtent pour quelque chose de mineur, ils feront probablement de même pour quelque chose de plus important, et la dernière chose que vous voulez est de tomber sur une sorte d'horrible charlie foxtrot six mois plus tard et d'avoir alors les mêmes problèmes avec le fournisseur.

Assurez-vous que toutes les mesures que vous prenez pour résoudre le problème maintenant fonctionneront aussi bien lorsque vous serez à deux jours d'une échéance et que tout se cassera...

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

Nous avions ce client qui avait ce problème récurrent où les performances du logiciel chutaient toutes les quelques heures environ à un taux vraiment abyssal, puis revenaient quelques heures plus tard.

Le profileur bulitin du système indiquait que la vitesse du processeur du système (ou peut-être de la mémoire) était dégoûtante, quelque chose comme 100MHZ au lieu des 2GHZ attendus. Doubler le CPU fourni par la VM n'a pas changé le symptôme et ils ont pensé que nous étions gaspilleurs.

Comme ils ne pouvaient pas obtenir un CPU plus rapide (plus de CPU n'allait pas aider), nous avons alors essayé de permuter les VM TEST et PROD. Le problème est alors apparu sur TEST le jour suivant. Nous avons ensuite essayé de promouvoir l'un des clients vers une instance autonome (sans serveur). Aucun problème sur cette station de travail alors que le serveur s'étouffait.

Ils ont produit des rapports de l'hôte VM n'indiquant aucun problème de performance et ont essayé à nouveau de prétendre qu'il s'agissait d'un problème d'application.

Finalement, j'ai [un ingénieur] (je n'ai eu aucun soutien de la part de ceux qui ont un rôle de support dédié) demandé spécifiquement une boîte physique. Le client a crié au meurtre, mais comme personne n'avait d'autre solution potentielle, ils l'ont fait. Et le problème a disparu comme par magie.

Nous n'avons jamais trouvé quel était le problème. Tous les programmes de référence étaient normaux, mais le profileur d'application nous indiquait que les ressources informatiques n'étaient tout simplement pas suffisantes. Il y a une sorte de signature spécifique que nous recherchons dans le profileur maintenant. Si nous la voyons, nous savons avant d'aller plus loin que le problème vient de l'interaction avec la VM, mais nous ne le savions pas à l'époque.

Ils ont sûrement pensé que j'étais pleine d'espoir. Je ne l'étais pas. J'étais à court d'options.

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

Avec de plus en plus de clients souhaitant fonctionner sur des VM et une direction désireuse de résoudre le problème à tout prix, nous avons obtenu un bon matériel VM. J'ai pu construire un programme spécialisé de gravure de VM qui s'exécutait dans l'espace utilisateur (et ne nécessitait aucun privilège) sur deux VM à un seul cœur avec 512 mb de RAM, qui était capable de drainer 1/3 des performances de mémoire d'une autre VM à un seul cœur avec seulement 4 cœurs au total sur les 16 utilisés sur l'hôte VM et la plupart de sa RAM encore libre. Le programme n'a pas déclenché d'alarme et n'a rien montré d'anormal sur l'hôte de la VM ni sur aucun des invités, si ce n'est que l'accès à la mémoire était lent.

Maintenant, nous pouvons dire aux clients que nous savons qu'il y a un problème avec les VM, et que ce n'est pas notre logiciel. Nous recevons encore de temps en temps des demandes de clients pour des logiciels compatibles avec les VM. 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 utilisée est une simple transformation d'une technique de programmation bien connue impliquant une synchronisation sans verrou. Des centaines de vendeurs de logiciels pourraient avoir ce draineur de VM dans leurs logiciels sans le savoir. Obtenir un verrou d'instruction atomique aussi disputé devrait être rare mais pas impossible. Le plus amusant dans tout ça, c'est que j'ai obtenu que le verrou soit contesté DANS TOUTES les VM.

Je suggère une approche très différente de celles mentionnées jusqu'à présent. Avant d'argumenter avec le vendeur, pourquoi ne pas examiner 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 que quelque chose "prend trop de temps", demandez-lui exactement ce que c'est (pour pouvoir le reproduire), combien de temps il pense que cela devrait prendre, et pourquoi il pense que cela devrait prendre autant de temps. Si leurs attentes sont raisonnables, mesurez les performances réelles et l'impact sur le système de ce qu'ils essaient de faire. Le fait que votre système affiche un pic de 30 % sur un mois ne signifie pas qu'il ne fonctionne pas à plus de 100 % lorsque l'utilisateur effectue sa requête. Si vous pouvez démontrer à votre fournisseur que le processeur et la mémoire ne sont pas sollicités par la tâche problématique, vous pouvez alors lui demander de justifier des recommandations qui vous coûteront de l'argent.