[丁寧に]どうやって話しているのかわからないソフトウェアベンダーに伝える方法

技術的な質問ではなく、有効な質問です。シナリオ：

ESXi 5.5を実行する2 x 8コアXeon E5-2667 CPUと256GB RAMを搭載したHP ProLiant DL380 Gen 8。特定のベンダーのシステム用の8つのVM。テスト用の4つのVM、実稼働用の4つのVM。各環境の4つのサーバーは、Webサーバー、メインアプリサーバー、OLAP DBサーバー、SQL DBサーバーなどの異なる機能を実行します。

テスト環境が実稼働に影響を与えないように構成されたCPU共有。SAN上のすべてのストレージ。

パフォーマンスに関するいくつかの質問がありましたが、ベンダーは、実稼働システムにより多くのメモリとvCPUを提供する必要があると主張しています。ただし、vCenterから既存の割り当てが変更されていないことを明確に確認できます。たとえば、メインアプリケーションサーバーのCPU使用率の月間ビューは約8％で、奇数のスパイクは最大30％です。スパイクは、バックアップソフトウェアの起動と一致する傾向があります。

RAMについても同様の話があります-サーバー全体の最高使用率は約35％です。

そのため、Process Monitor（Microsoft SysInternals）とWiresharkを使用して掘り下げを行ってきましたが、最初のインスタンスでTNSチューニングを行うことをベンダーに推奨しています。ただし、これは重要な点です。

私の質問は、送信したVMwareの統計情報が、RAM / vCPUを追加しても役に立たない十分な証拠であることをどのように認めさせるかです。

--- 2014/12/07更新---

興味深い週。IT管​​理者は、VMの割り当てを変更する必要があると言っており、現在、ビジネスユーザーからのダウンタイムを待っています。不思議なことに、ビジネスユーザーは、アプリの特定の側面の動作が遅いと言います（私は知りません）が、システムをダウンさせることができると「知らせて」くれます（不平を言う） 、不平を言う！）。

余談ですが、システムの「遅い」側面は、明らかにHTTP（S）要素ではありません。つまり、ほとんどのユーザーが使用する「シンアプリ」です。メインの金融機関が使用する「ファットクライアント」インストールであるように見えますが、明らかに「遅い」です。これは、調査でクライアントとクライアント/サーバーの相互作用を検討していることを意味します。

質問の最初の目的は、「突く」ルートをたどるか、単に変更を加えるかについて支援を求めることであり、現在変更を行っているので、ロングネックの答えを使用して閉じます。

ご意見ありがとうございます。いつものように、serverfaultは単なるフォーラム以上のものです-心理学者のソファのようなものでもあります:-)

彼らが要求した調整を行うことをお勧めします。次に、パフォーマンスをベンチマークして、違いがないことを示します。これまでのところ、LESSメモリとvCPUを使用してベンチマークを行って、ポイントを示すこともできます。

また、「当て推量ではなく、実際のソリューションでソフトウェアをサポートするためにあなたに支払いをしています。」

文書化された特定のシステム仕様の範囲内にいると確信している場合。

次に、バックアップ可能なRAMまたはCPUをさらに必要とすることに関して彼らが行っている主張。彼らのシステムの専門家として、私はこれを説明する人々を抱えています。

それらに詳細を尋ねてください。

• システムで提供されるどのような情報が、より多くのRAMが必要であることを示し、どのようにこれを解釈しましたか？

• システム上で提供されるどのような情報が、より多くのCPUが必要であることを示し、どのようにこれを解釈しましたか

• 私が持っているデータは、一見、あなたが私に言っていることと矛盾しています。これを間違って解釈している理由を説明してもらえますか？

• 私はこの[明白な一連のデータ]を[明白な解釈]を意味すると解釈しています。私の問題に関して正しく解釈していることを確認できますか？

過去にサポートを扱ってきたので、同じ質問をしました。時々私は正しかったのですが、彼らは私の問題に適切に注意を向けていませんでした。他の回は、しかし、私がいた間違ったと私は間違ってデータを解釈する、あるいは私の分析で重要だった他のデータを含めることができませんでした。

いずれにせよ、これらの状況はどちらも私にとって最終的な利点でした。以前は知らなかった新しいことを学んだか、サポートチームに問題をより深く考えさせて適切な根本原因を見つけました。

サポートチームが満足のいく根拠に論理的拡張を提供できない場合（自分自身を妥協するために心を開く必要があり、データの解釈が間違っていることを受け入れるのが合理的である）彼らの応答に非常に存在する必要があります。最悪の場合でも、これを問題のエスカレーションの基礎として使用できます。

重要なことは、システム割り当てのベストプラクティス、特にSQLサーバーのRAMとCPUの予約を使用していることを証明できることです。

これはすべて、少なくとも一時的に要求された調整を行うことです。それ以外の場合は、ベンダーが足を引きずってドラッグする傾向があります。ラインの反対側の技術が実際にソフトウェアが動作していないことを満足させるために、このようなクレイジーなことをする必要がある回数を数えることはできません。

この特定の状況（VMwareとアプリケーション開発者、またはリソース割り当てを理解していないサードパーティがいる場合）では、vCenter Operations Manager（vCops- 必要に応じてデモをダウンロード）から取得した1週間分のメトリックを使用して、実際の制約を特定します、ボトルネック、アプリケーションのVMのサイズ設定要件。

競合シナリオを処理するためにVM予約を変更したり、優先順位を変更したりすることで、より頑固な消費者を満足させることができました。「RAM場合| CPUが締まっている、あなたの VMが優先されます！」。ソフトウェアベンダーが実際の分析なしでvSphereクラスターの要件を指定できるようにしたときに、悪いことが起こりました。

しかし、一般的には、数字とデータが勝つはずです。

Tomcatアプリケーションの開発者に対してVMのサイズ設定を正当化するために使用した例：

開発：VMにはMOAR CPUが必要です！

私：さて、メモリが最大の制約です。パフォーマンスと時間のヒートマップを次に示します。水曜日の午後6時が最もストレスの多い期間であるため、そのピーク期間を特定できます。ああ、ここに過去6週間の生産指標に基づくサイジングの推奨事項があります...

私はサポートで働くために使用される-とあなたが求めているものの一部のサウンド非常に合理的な（そしておそらくですが）：しかし、彼らが要求している自分が前にちょうど「性能向上」を行うように依頼するいくつかの質問があります

• 少なくともベンダーの規定の最小システム要件で既に実行していますか？
• 少なくともsysreqが最小の場合、すでに「推奨」システム設定になっていますか？

ベンダーは100のうち99回（私の経験では、サポート側と顧客/フィールド側の両方で）、システムがドキュメントが要求するものと一致しない限り、パフォーマンス関連の問題に対処しません。たぶん、1 CPUと512M RAMで時間の99.5％を正常に実行するシステムかもしれません-しかし、システム要件に4 CPUと4G RAMがあり、2 CPUと1G RAMしか持っていない場合、それらは十分に権利の範囲内ですより多くのリソースを割り当てることを要求します^*。

特定のしきい値を超えると問題が魔法のように消えるラボ/開発で見つかった何かのために、システムリソースを増やすように頼まれている可能性があります。これが事実である場合、はい、それは彼らの終わりの潜在的に貧弱なデバッグの例ですが、彼らは発生する可能性のあるすべてのバグ/問題を排除する時間がないことに留意してください-それがここに当てはまります。

また、発生している問題が「彼らの」ソフトウェアの一部ではなく、他のソース（ベンダー、OSSライブラリなど）に依存しているコンポーネントである可能性もあります。数年前の顧客で、スワップサイズ、BEA WebLogic、およびSun JREに関連するこの正確な状況に遭遇しました。

tl; dr：

つまり、サポートチームと協力し、必要に応じてエスカレーションし、解決策が見つかるまで待ちます。ただし、提案/デバッグ手順/修正の一部が壁を越えたり無意味に聞こえたりしても驚かないでください。

^{* _{それは場合は、本当にあなたが将来のバージョンのdocバグ/ RFEを提出することができるようにする場所になりそうだ、それらの余分なリソースを「必要ない」 -しかし、あなたはそれがありません実証してきたまではそのルートをプッシュしていません手元の問題}
^ _{私が書いた電子書籍は、トピック「ソフトウェアシステムのデバッグとサポート}}

チケットのエスカレーションを依頼するか、別の担当者に依頼してください。現在のレベルのサポートでは問題に適切に対処していないと感じた場合、エスカレーションがどのベンダーに役立つかによって異なります。彼らがエスカレートしない場合、必要なのは現在の担当者に満足しないことであるため、「正当化」がはるかに少ないため、別の担当者を要求することが役立ちます。

大規模なベンダーの場合、同じ問題のチケットを閉じて新しいチケットを開くだけで別の担当者にルーティングされる可能性がありますが、フォームが貧弱なので私はそれをお勧めします。

また、自分の立場に立って、RAM / vCPUがどれだけ役立つかについての理論的根拠を求めることもできますし、RAM / vCPUを増やして役に立たないことを証明することもできます。

2セントを投入します。私たちはこのアプローチで非常に成功しています-はるかに良い結果と皆の不満の減少。非難ゲームや盲目的にリソースを追加するよりも多くの労力が必要ですが、根本的な問題を見つける可能性も高くなります。

ベンダーのサポート契約に裏打ちされたオンプレミスアプリに深刻な問題があり、ベンダーがかわすシャッフルダンスを開始すると（常にCPUやRAMに対する非駆動の非データ要求が含まれているようです）、次の3つのことを行います。

1. 優先順位をシステムダウンと同等のものにエスカレートします。通常は一時停止しますが、通常、技術的に「機能している」としても、実際には使用できないと説明すると元に戻ります。それらを解決するための深刻な問題として扱います。ここでは、それを虎のチームと呼び、毎日会合を開いて、すべての関係者から最新の状況を入手します。通常、ベンダーはあなたに何かを変えるように頼みます。prodシステムの場合は問題がありますが、支援したい場合は、彼らが問題を切り分けるのを助ける責任を受け入れる必要があるので、テストを実行できる開発/ステージング環境がある場合に役立ちます。

2. ベンダーに、環境を複製してほしいと伝えてください。そうすれば、彼らはラボで問題を切り分けることができます。必要に応じて、一部のクラウド環境でスタッフをホストすることもできます。理想的ですが、環境と完全に一致する必要はありません。重要なのは、VENDORが問題を再現しようとしていることです。そうすることで、VENDORはあなたのシステムではなくシステムで当て推量をテストできます。複製された環境の図、仕様などを聞いて、彼らがそれを行っていることを確認してください。

3. 彼らに（もちろんNDAの下で）実際のデータセットを提供して、推測する代わりに実際に実行/再生できるようにします。私たちの場合、ベンダーが提供するアプリの問題（一時的なものと慢性的なものの両方）のほとんどは、付随するベンダーが提供するデータベースの問題であることがよくあります。私たちがこれを行った回数を数えることはできず、彼らは最終的に実際のデータで予期しない何かまで問題を特定しました。古いレコードは、GC設定の問題を公開します。ベンダーコードなどのトランスモッグルーチンを壊すOURデータ値のため、クエリがまったく正しく機能しません。自分で識別できないもの。

過去数年間にかなりの数のベンダーでこれを行ってきましたが、最初は私たちのやり方に非常に抵抗しています。しかし、それが機能した後、ベンダーとの四半期レビューで常にポジティブなハイライトとして浮上します。そして、それらのベンダーとの技術的関係を強固にするのに役立ちます。彼らはあいまいな問題を望んでいません。彼らは、製品を改善するために分析できる特定の問題を望んでいます。

提案が役立つことを願っています。私はそれが万能のアプローチではないことを知っていますが、あなたがそれを振ることができれば、あなたはそれが価値があると思うと思います。

本当の質問は、ここで誰が担当しているのですか？現実的に代替ベンダーに切り替えることができない場合、彼らは力を持ち、あなたが本当にできることは、彼らが言うことを何でもやり、それがうまくいくことを望んでいることです。幸せな状況ではありません！そうでない場合は、他の担当者に依頼することをお勧めします（他の人が言っているように）が、サービスに満足していないことを明確にしてください。

うまく機能しないことが確かな場合は、単に「彼らが提案した調整を行う」だけでなく、それは長期的にあなたを傷つけるあなたの関係のパターンを設定しているからです。あなたは彼らにあなたにサービスを提供するためにお金を払っており、私の家をペイントするために雇った誰かがそれが何の色になるかを決めることができる以上に彼らはあなたの行動を指示することができないはずです。

これは非常に重大な問題ではないように聞こえるので、これは劇的に聞こえるかもしれませんが、実際には、彼らがマイナーな何かをいじり回している場合、彼らはおそらく大きなものに対して同じことをするでしょう、そしてあなたが望む最後のことは6か月後に何らかの恐ろしいチャーリーフォックストロットに遭遇し、ベンダーと同じトラブルを抱えています。

現在、問題を解決するために実行する手順が、期限から2日間であり、すべてが中断している場合でも同様に機能することを確認してください...

ベンダー側からの見解を投稿します。

この顧客には、ソフトウェアのパフォーマンスが数時間ごとに低下し、本当にひどい速度に落ちてから数時間後に戻ってくるという、この問題が繰り返し発生していました。

システムのブリチンプロファイラーは、システムのCPU（またはメモリ）の速度が、予想される2GHZではなく100MHZのように遅くなっていることを示していました。VMが提供するCPUを2倍にしても症状は変わらず、彼らは私たちが無駄だと思っていました。

彼らはより速いCPUを得ることができなかったので（より多くのCPUは助けにはなりませんでした）、私たちはそれからTESTとPROD VMを交換しようとしました。問題は翌日TESTに現れました。次に、クライアントの1つをスタンドアロン（サーバーレス）インスタンスに昇格させました。サーバーが窒息している間、そのワークステーションで問題はありません。

VMホストからパフォーマンスの問題がないことを示すレポートを作成し、アプリケーションの問題であると再度​​主張しました。

最後に、私[エンジニア]（専任のサポートロールの担当者からのサポートはありませんでした）は、物理的なボックスを具体的に求めました。顧客は血まみれの殺人を叫んだが、他の潜在的な解決策を誰も持っていなかった。あなたは何を知っていますか、問題は魔法のように消えました。

私たちは問題が何であるかを決して見つけませんでした。すべてのベンチマークプログラムは正常であることが示されましたが、アプリケーションプロファイラーは、コンピューティングリソースが十分ではないと言っていました。プロファイラで今探している特定の署名があります。それを見ると、問題がVMの相互作用であることが先にわかりますが、それはその時点ではわかりませんでした。

彼らは私がそれで一杯だと思ったに違いありません。私はそうではなかった。私は選択肢がありませんでした。

編集、数年後の更新：

VM上で実行したい顧客が増え、管理者が問題を解決しようとしても喜んでいるため、優れたVMハードウェアが手に入りました。512MB RAMを搭載した2つのシングルコアVMでユーザースペースで実行する（特権を必要としない）専用のVM書き込みプログラムを構築できました。 VMホストで使用中の16個のコアの合計と、そのRAMの大部分はまだ無料です。プログラムはアラームを発生せず、メモリアクセスが遅いことを除いて、VMホストとゲストのいずれにも異常を示しませんでした。

これで、仮想マシンに問題があり、それがソフトウェアではないことを顧客に伝えることができます。VM互換ソフトウェアの顧客からの要望は時々時々受けます。同じホスト上の他のすべてのVMの速度を低下させるソフトウェアを開発できたと管理者がサポートに伝えないのはなぜだろうか。

恐ろしいのは、ロックフリー同期を含むよく知られたプログラミング手法を単純に変換したものである手法です。数百のソフトウェアベンダーが、ソフトウェアにこのVMドレインを含めることができます。激しく争われるアトミックな命令ロックを取得することはまれですが、不可能ではありません。そのすべての面白い部分は、ACROSS VMをコンテストするためのロックを得ていたことです。

これまで述べてきたものとは非常に異なるアプローチをお勧めします。ベンダーと議論する前に、報告された問題を詳しく調べて、それが何を伝えているのかを見てみてください。

報告されている実際の問題とユーザーの期待は何ですか。ユーザーが「時間がかかりすぎる」と言っている場合は、「それ」とは何か（再現できるように）、どのくらいかかると思うか、なぜ長いと思うのかを尋ねます。彼らの期待が妥当であれば、彼らがやろうとしていることの実際のパフォーマンスとシステムへの影響を測定します。システムが1か月間に30％の急上昇を示すという事実は、ユーザーがクエリを試行しているときに100％を超えて実行されていないという意味ではありません。CPUとメモリが問題のあるタスクによって負担を受けていないことをベンダーに示すことができる場合は、費用がかかる推奨事項を正当化するようベンダーに依頼できます。