performance-testing - ビッグバン書き換えのパフォーマンス テストへの抵抗はありますか?

Question

私は、文字通り 2 年以上にわたって「ビッグバン」の書き直しに取り組んできました。経営陣は、アプリが数百万のマネーメーカーの主力ウェブアプリに取って代わる前に、パフォーマンス測定、キャパシティプランニング、および最適化に時間/リソースを割り当てるようにという私の呼びかけを一貫して容赦なく無視し、軽視してきました.

最後に、彼らはそれを行うことに同意しました (そして、現在運用中であり、テストの対象となる並列ベータ サーバーを起動することで、彼らが大騒ぎするのを防ぐことに成功しました)。彼らがこれを優先するために最後まで待ったのは好きではありませんが、遅いよりはましです。

将来、このような状況に対処するために、誰もがどのような提案をしますか? この種のテストの必要性について、マネージャー/クライアントを教育する最善の方法は何ですか?

私は彼らに、CodePlex に関する Microsoft のパフォーマンス ガイドを見せました。そのページには、経験豊富な専門家からの厳しい警告が記載されています。「Release It!」という本も見せました。そして、「午前 3 時の電話」について著者が提供するガイダンス。最終的に彼らはしぶしぶ納得しましたが、真実は、これが開発の優先事項であり、最終的な完全なシステム テストの前に開発中に部分的に測定されるべきだったということです。

ASP だけを作成し、.NET を作成したことのない多くの管理者や昔ながらのエンジニアは、自分ですべてをコーディングすることに慣れており、新しい .NET アプリのキャッシュ、チューニング、状態監視のすべてのオプションを理解していません。

ありがとう

Answer 1

あなたが気付いていないこと (そして多くのエンジニアが気付いていないこと) は、これがエンジニアリングの状況ではなく「セールスの状況」であるということです。顧客が社内にいるかどうかに関係なく、プロセスはほとんど同じです。

販売とは、顧客を動かしている問題の種類を見つけ出し、製品が顧客の問題の 1 つまたは複数をどのように解決するかを示すことです。パフォーマンスに問題があると思わない場合は、そうではありません。単純なことです。物事を自分のやり方で見るように彼らを教育することはできるかもしれませんが、「教育的な販売」は時間とお金の面で高くつき、多くの顧客は「彼らがすでに知っていること」と言われることに憤慨しています。このグループを本で打ち負かすことでこのグループを教育しなければならなかったように思えますが、目標を達成するためのより簡単な方法があったかもしれません.

それは何だったでしょう？私にはわかりませんが、彼らは知っているので、彼らに尋ねてください。最終的に決断を迫られたのは何だったのかを尋ねます。自分が正しかったことに突然気がついたのかもしれません。直接言われることは少ないかもしれませんが、彼らの答えをよく聞けば、行間が読めるかもしれません。営業では、セールス コール (成功したかどうかに関係なく) について事後分析を行うことは、顧客の動機と、アイデアを提示する際に自分のスキルをどのように調整できるかを理解するために重要です。

次回は、顧客が何を達成したいのか、現在および長期的にどのような問題を抱えているのかについて、自由回答形式の質問をする必要があることがわかります。それは常に機能しますか？もちろんそうではありませんが、エンジニアリングの問題の社会的側面に対処することを学ぶことは、習得する価値のあるスキルです.

Answer 2

システムがサポートできると期待する具体的な数値 (同時ユーザー数/タスク数/など) に同意してもらうと、システムが要件を確実に満たすことが開発作業の明確な部分になります。

Answer 3

人を説得する方法はいろいろありますが、あなたが挙げた例は「より高い権限を行使する」ことです。ただし、ほとんどの管理者は、技術的なガイダンスによって必ずしも説得されるとは限りません。

このような状況では、リスクベースのアプローチを使用しました。プロジェクトごとに、リスク ログを保持し、プロジェクトに対する最大のリスク、その可能性、影響、および軽減オプションを特定します。多くの場合、これらの項目を定量化できます。これにより、マネージャーは適切な決定を下すことができます。

書き換えの最初の時点で、リスク ログに次のエントリが含まれている可能性があります。

リスク: システム パフォーマンスがユーザーの期待に応えられない

可能性：不明

影響: ロード時間が長すぎるため、エンド ユーザーが Web サイトを放棄します。プロジェクトは失敗します。

影響のコスト: $$$プロジェクトのコストはいくらでも。

軽減策: 隔週のパフォーマンス テスト。

緩和コスト: $$$時間と費用の面で考えられる金額

推奨事項: パフォーマンス テストを実行して、リスクを定量化します。

ほとんどの管理者は、可能性が不明であるが、コストがプロジェクトの失敗であるリスクに非常に不快感を覚えます。一方、あなたは巨大なコミットメントを求めているわけではありません - リスクを定量化するのに十分です.

私はリスク ログをプロジェクトの利害関係者と定期的に (少なくとも月に 1 回) 見直したいと考えています。私は常に「影響が大きい/可能性が高い」リスクから始めますが、次に「影響が大きい/可能性が不明」なリスクに移ります。各リスクに関する利害関係者の決定を記録して、会議メモを配布することもお勧めします。繰り返しになりますが、書面による記録で影響の大きいリスクを無視するという決定に自分の名前が付けられているのを見たマネージャーは、その決定について慎重に検討します。

いくつかのパフォーマンス テストを実行してリスクを定量化したら、コストとパフォーマンスの問題の可能性に基づいて、さらにリスクに基づいた決定を下すことができます。これは、セキュリティ、アクセシビリティ、スケーラビリティなど、他の古典的な機能以外の問題を管理するための良い方法でもあります。

問題を定量化することで、エンジニアリング上の決定ではなく、ビジネス上の決定に変えることができます。

Answer 4

これについて、無制限のパフォーマンス チューニングおよびベンチマーク プロセスとして議論しないでください。年配の管理者は、あなたが釣りをしている、またはシステムを金メッキしていると心配するでしょう。

代わりに、認定演習として議論してください。現在のトラフィック レベルを特定し、安全マージンを追加して、システムが実際の生活に耐えられることを証明することがテストの目的であることを説明します。

パフォーマンス ホットスポットの作業は引き続き行うことができます。とんがった髪の上司に、あなたのすべての仕事が具体的なビジネス目標に向けられていることを安心させる必要があるだけです.

Answer 5

展開後にどのようなパフォーマンスの問題が発生するかなど、この開発プロジェクトについて慎重にメモしてください。人々は問題を嘆きますが、あなたは巧みに、その種の問題を優先するよう提案することができます。一部の人々は、直接的な一人称の証拠のみを受け入れます。