如何[礼貌地告诉软件供应商他们不知道他们在说什么

我build议你做他们已经要求的调整。 然后以performance为基准，向他们表明它没有任何区别。 甚至可以使用LESS内存和vCPU进行基准testing以expression您的观点。

而且，“我们付钱给你用实际的解决scheme支持软件，而不是猜测”。

如果您确信自己在所logging的给定系统规格范围内。

然后，他们要求更多的内存或CPU，他们应该能够备份的索赔。 作为他们系统的专家，我要求人们对此作出说明。

询问他们的具体情况。

• 系统上提供的信息表明需要更多的RAM，您是如何解释的？

• 系统上提供的信息表明需要更多的CPU，您是如何解释的？

• 我乍看之下的数据与你告诉我的相矛盾。 你能向我解释为什么我会错误地解释这个吗？

• 我正在解释这一[明显的一系列数据]的含义是[明显的解释]。 你能证实我正在解释我的问题吗？

过去我已经处理了支持，我也提出了同样的问题。 有时我是对的，他们没有把注意力集中在我的问题上。 但其他时候，我错了 ，我错误地解释了数据，或者没有包括其他在我的分析中很重要的数据。

无论如何，这两种情况对我来说都是一种净利益 ，要么我学到了一些我以前不知道的新东西 – 要么就是我的支持团队更加努力地思考我的问题，从而得到一个体面的根源。

如果支持团队无法为您提供一个合理的逻辑扩展，那么您可以满意（您需要有一个开放的态度来妥协自己，理性地接受您对数据的解释是错误的），那么它应该在他们的回应中变得非常现时。 即使在最坏的情况下，您也可以将其作为升级问题的基础。

最重要的是要能够certificate您正在使用最佳实践来进行系统分配，特别是SQL服务器的RAM和CPU预留。

所有这一切都被说成最简单的事情就是做出所要求的调整，至less是暂时的。 如果没有别的东西，它往往会让供应商拖延。 我不能指望我需要做这样疯狂的事情，以满足技术的另一端，它确实是他们的软件不行为。

对于这种特定情况（如果您有VMware和应用程序开发人员或不了解资源分配的第三方），我使用从vCenter Operations Manager获得的一周指标（vCops – 如果需要，下载演示 ）来查明实际限制，应用程序虚拟机的瓶颈和大小要求。

有时，我可以通过修改虚拟机保留或改变优先级来处理争用情况，以满足更顽固的用户; “ 如果RAM | CPU很紧， 你的 VM将优先！ ”。 当我允许软件供应商在没有真正的分析的情况下在我的vSphere群集上指定他们的需求时，糟糕的事情就发生了。

但总的来说，数字和数据应该是胜出的。

一个我用来certificateVM调整到Tomcat应用程序的开发者的例子：

Dev ： VM需要MOAR cpu！

我 ： 记忆是你最大的约束，这里是你的performance与时间的热点图。星期三下午6点是压力最大的时期，所以我们可以在高峰时段左右。 哦，这里是根据过去6周的生产指标来确定尺寸的build议…

我曾经在支持方面工作 – 而且你所要求的一部分听起来非常合理（可能是）：但是在做他们要求的“性能增强”之前，有几个问题要问自己

• 您是否至less按照供应商规定的最低系统要求运行？
• 如果你至less在sysreqs，你是否已经在他们的“推荐”系统设置？

在我的经验中（无论是在支持方面，还是在客户/领域方面），供应商都将达到99次（除非系统符合他们的文档要求），甚至不涉及与性能有关的问题。 也许这是一个99.5％的系统运行良好的时间，1个CPU和512M内存 – 但如果系统要求说4个CPU和4G内存，而你只有2个CPU和1G内存，他们是在他们的权利要求分配更多的资源^* 。

他们可能会要求你增加系统资源，因为他们在实验室/开发中发现的东西，如果你跨过一个特定的门槛，一个问题会奇迹般地消失; 如果是这种情况，是的，这是一个潜在的穷人debugging的例子，但要记住，他们没有时间来消除每一个可能出现的错误/问题 – 有些只是需要解决，如果就是这样的情况，就这样吧。

你所看到的问题甚至不是“他们的”软件的一部分，而是来自其他来源（供应商，OSS库等）的组件。 几年前，我遇到了与交换大小，BEA WebLogic和Sun JRE相关的确切情况。

TL;博士：

简而言之，与他们的支持团队一起工作，根据需要升级，直到find解决scheme – 但是当一些build议/debugging步骤/修复听起来不错或毫无意义时，不要感到惊讶。

^{* _{如果它真的不需要这些额外的资源，那么你很可能会在某个地方为未来的版本提交一个doc bug / RFE，但是在你展示它不是这个问题在手边}
^ _{我写了一本电子书可能会在以下主题上find帮助： debugging和支持软件系统}}

要么要求升级票或要求不同的代表。 如果您认为目前的支持水平没有充分解决问题，则取决于哪个供应商是升级可能会有所帮助。 如果他们不升级，那么寻求不同的代表可能会有所帮助，因为这需要更less的“理由”，因为所需要的只是对现有的不满意。

如果它是一个大的供应商，那么简单地closures票据，并在同一问题上打开一个新的可能会工作，因为它可能被路由到不同的代表，但我build议反对它，因为它是可怜的forms。

你也可以站在你的立场，并要求有更多的RAM / vCPU将有助于理由，或者你可以给它更多的内存/ vCPU来certificate它不会帮助。

我会投入我的两分钱。 我们用这种方法取得了相当大的成功 – 对每个人来说，都会有更好的结果和更less的挫折感。 它需要比责备游戏更多的努力和盲目增加资源，但是它也有更好的机会find潜在的问题。

当我们的厂商支持合同支持的内部应用程序存在严重问题时，供应商开始他们的闪避洗牌舞（总是似乎包含了更多的CPU或RAM的非数据驱动需求），我们倾向于做这3件事情：

1. 升级系统相当于优先级 – 他们通常是不愿意的，但是当你解释它是有效的，即使它在技术上“工作”时通常也会退缩。 把它当作是他们解决的一个严重问题。 在这里，我们把这个作为一个老虎队，每天聚会，以获得所有利益相关者的状态更新。 通常供应商会要求你改变东西。 如果它是一个prod系统，这是有问题的，但是如果你想让他们帮忙，你将需要接受帮助他们隔离问题的责任，所以如果你有一个可以运行testing的开发/分期环境，这将有所帮助。

2. 告诉供应商您希望他们复制您的环境，以便他们能够在实验室中隔离问题。 如果需要的话，他们甚至可以在一些云环境中托pipe东西。 它不一定是你的环境完全匹配，虽然这将是理想的。 问题的关键在于你想让卖主积极地尝试复制你的问题，以便他们可以在他们的系统上testing他们的猜测而不是你的猜测。 询问他们的复制环境的图表，规格等，以确保他们正在做。

3. 提供他们（当然NDA下）与您的实际数据集，以便他们可以运行/重播真实而不是猜测。 就我们而言，我们大多数供应商提供的应用程序问题（包括瞬态和慢性问题）通常都是随供应商提供的数据库问题。 我无法计算我们已经完成的次数，并且他们最终把问题归结为实际数据中出乎意料的问题 – 2年前应用程序升级时出现的奇怪的工件，其中某些东西没有完全转换; 陈旧的logging暴露了GC设置的问题; 查询不太正常，因为我们的数据值在供应商代码中打破了一些transmog例程，等等。我们永远无法自己识别的东西。

过去几年里，我们已经和很多供应商一起做了这个工作，而且他们最初很难按照我们的方式做。 然而，在它的工作之后，在我们与供应商进行的季度评估中，它总是成为一个积极的亮点。 这有助于巩固我们与这些供应商的技术关系。 他们不想要模糊的问题。 他们确实希望能够分析他们改进产品的具体问题。

希望这个build议有帮助。 我知道这不是一种万能的方法，但是如果你能摆动它，我认为你会发现它是值得的。

真正的问题是，谁在这里负责？ 如果你不能切实地转向另一个供应商，那么他们就有权力，而你所能做的就是随意行事，并希望能够实现。 不是一个快乐的情况！ 否则，我build议你要求另一位代表（正如其他人所说的），但要明确表示你对这项服务不满意，如果他们不能做这项工作，他们会到别的地方看看。

如果你确定他们不会工作，那么不要只是“做出他们所build议的调整”，因为这是build立你的关系的模式，从长远来看将会伤害你。 你正在付钱给你提供服务，他们不应该能够指定你的行为，而不是我雇用的那个人来画我的房子就可以决定它的颜色。

这可能听起来很激烈，因为听起来这不是一个非常关键的问题，但事实是，如果他们在一些小事上搞乱了你，他们可能会做同样的事情，而最后一件事是你在六个月的时间里遇到了一些可怕的查理福克斯特，并与供应商有同样的麻烦。

确保你现在解决这个问题的任何步骤，在距离截止date两天的时间内都能正常工作，一切都会中断。

我打算从供应商那边发表看法。

我们有这个客户有这个反复出现的问题，软件的性能会每隔几个小时左右下降到一些真正糟糕的速度，然后在几个小时后回来。

系统中的bulitin分析器显示系统CPU（或可能是内存）的速度令人厌恶，比如100MHZ，而不是预期的2GHZ。 将VM提供的CPU加倍并不会改变症状，他们认为我们浪费了。

由于他们无法获得更快的CPU（更多的CPU不会帮助），我们尝试交换TEST和PROD虚拟机。 然后在第二天的testing中出现问题。 然后，我们尝试将其中一个客户端升级为独立（无服务器）的实例。 服务器窒息时，该工作站没有问题。

他们从VM主机发出报告，指出没有性能问题，并再次声称这是一个应用程序问题。

最后，我是一名工程师（我没有专门从事支持职位的人的支持）专门询问了一个物理盒子。 客户尖叫血腥的谋杀，但没有人有任何其他潜在的解决scheme，他们做到了。 你怎么知道，这个问题神奇地消失了。

我们从来没有发现问题是什么。 所有基准程序都显示正常，但应用程序分析器告诉我们计算资源根本不够用。 现在我们在探查器中寻找一种特定的签名。 如果我们看到它，我们知道在我们进一步讨论虚拟机的交互问题之前，这个问题在当时是不为人知的。

他们当然认为我充满了。 我没有。 我没有select。

编辑，从几年后更新：

随着越来越多的客户希望在虚拟机上运行，​​愿意不惜一切代价来解决问题的pipe理，我们获得了良好的虚拟机硬件。 我能够构build一个专用的虚拟机刻录程序，在两个带有512MB RAM的单核虚拟机上运行在用户空间（并且不需要特权），能够从另一个单核虚拟机中耗用1/3内存性能，只有4个在虚拟机主机上使用的16个核心中的16个仍然是免费的。 程序没有发出警报，除了内存访问速度慢以外，在虚拟机主机上也没有显示任何exception情况。

现在我们可以告诉客户我们知道虚拟机存在问题，而不是我们的软件。 对于虚拟机兼容的软件，我们仍然会收到客户的要求。 我想知道为什么pipe理层不让支持告诉他们，我们能够开发一种软​​件来减缓同一主机上的其他虚拟机。

可怕的是，涉及的技术是涉及无锁同步的着名编程技术的简单变换。 数以百计的软件供应商可能会将这个虚拟机从他们的软件中排除，而不知道它。 获得激烈竞争的primefaces指令锁应该是罕见的，但不是不可能的。 这一切的有趣的一部分是我正在争夺ACROSS虚拟机的锁。

我想build议一个截然不同的方法到目前为止提到的。 在与供应商争论之前，为什么不仔细观察报告的问题，看看有什么告诉你。

报告的实际问题是什么？用户的期望是什么？ 如果用户说的话“花太长时间”，请问他们究竟是什么（所以你可以重现），他们认为应该花多长时间，以及他们为什么认为应该花这么长时间。 如果他们的期望是合理的，那么衡量他们正在尝试做的事情的实际performance和系统影响。 您的系统在一个月内显示30％的峰值的事实并不意味着当用户尝试查询时它不会以> 100％运行。 如果您可以向您的供应商certificatecpu和内存不会由于有问题的任务而紧张，那么您可以要求供应商certificate推荐将会花费您的钱。