サービス レベル アグリーメント (SLA) は、サービス プロバイダーとその顧客との間の契約またはコミットメントであり、プロバイダーが責任を負うサービス標準を定義します。 契約は、法的拘束力がある場合もあれば、 ウェブ ページまたはアプリケーションのパフォーマンス SLA の場合は、ユーザーまたは顧客に対して組織内で合意された標準である場合もあります。 パフォーマンスSLAを実装することで、 ユーザーエクスペリエンス に対する組織のコミットメントが強化され、(うまくいけば)幸せな顧客と多くの再訪問が保証されます。
パフォーマンス SLA の作成
長期間運用環境にあるレガシ サイトとアプリケーションの場合、SLA を決定するのが少し簡単です。 過去の顧客データや最近のユーザー行動を振り返ることができます。 たとえば、突然ショッピングカートを放棄する顧客や、特定の時点でサイトやアプリケーションから飛び降りる顧客が急増している場合は、何らかのパフォーマンスの問題が発生している可能性があります。 このような要素を使用して、SLA パラメーターのベースを形成できます。
明らかに、新しいアプリケーションや ウェブ ページには、大量の使用可能なデータを自由に使用できるという便利さがありません。 どこから始めればよいかを知るのは難しい場合があります。 SLAの概要を説明するための実際のデータを使用せずに、ページまたはアプリケーションが実際のトラフィックにどのように応答するかを実際にどのように知ることができますか?
SLAは最初からできるだけ具体的にすることが重要です。 インターネットですばやく検索すると、多くの例が出てきますが、SLAが顧客、場所、時刻、使用するデバイスやブラウザなどに固有であることを確認する必要があります。 これらの要素を、ページまたはアプリケーションの読み込み速度メトリック (最後のバイトまでの時間 (TTLB)、表示時間、DNS 解決時間など) と許容可能なしきい値と結び付けることで、パフォーマンス SLA の始まりが得られます。
ベースラインパフォーマンスメトリック
今日の世界では、ほとんどのユーザーはほんの数秒後にあなたのサイトを放棄します。 適切なパフォーマンス SLA を確実に設定することが重要です。 ありがたいことに、パフォーマンスSLAに伴うさまざまなパラメーターを定義するための道を歩み始めることができる場所はほとんどありません。
- 内部チーム。 明らかに、SLAを定義するのに役立つ最も簡単で便利な方法の1つは、独自のチームを使用することです。 彼らは以前にその道を進んでいる可能性が高いので、正確に何を含めたり避けたりするかについて、現実世界の優れた洞察を提供する可能性が高くなります。
- 業界ベンチマーク。 Google アナリティクスなどのツールを使用すると、現在のサイトを同様の業界の他のサイトと比較できます。 さらに、さまざまなマーケティング/ SEOエージェンシーが定期的に公開する業界データを大量に持っています。
- 競争。 競争力は卓越性を生み出しますよね? 少なくともそれはことわざが行く方法です。 したがって、洞察を得るために競合他社に目を向けてください。 これを行う簡単で邪魔にならない方法の1つは、サイトに対して 無料の速度テストを実行して 、さまざまなパフォーマンスメトリックをすばやく把握することです。 ウェブ アプリケーションのように、トランザクションベースのタイミングと実際のユーザーの動作が必要な場合は、スクリプトを作成し、アプリケーションに対して少数の仮想ユーザーをスピンアップできます。 ただし、船外に出ないように注意してください。 仮想ユーザーが多すぎると、アプリケーションが失敗し、ITチームに警告し、IPがブロックされる可能性があります。 よくないです。 さらに悪いことに、意図せずにDDoS攻撃を引き起こす可能性がありますが、これは違法です。 違法な可能性のあることは何もしないでください。 従うべき常に良いアドバイス。
パフォーマンスSLAまたは非機能要件の検証
ベースラインのパフォーマンス値がわかったら、サンプル期間中にサイトまたはアプリケーションを訪問するときに現実的に予想される数値に増やすことができます。 LoadView プラットフォームでは、ユーザーにいくつかの異なるロード テスト カーブから選択できます。 これらのオプションの1つは、目標ベースの曲線と呼ばれます。 SLAと非機能要件の検証に最適です。
たとえば、すでに所定のトランザクション目標がある場合、または特定の期間にWebサイトまたはアプリケーションで予想される訪問者数が(おおよそ)わかっている場合、目標ベースの曲線テストを実行すると、サイトまたはアプリケーションが事前定義された要件を満たしていることを確認できます。 さらに、 Webサイト またはアプリケーションの負荷を増やすと、将来のユーザー負荷が高くなるアプリケーションのパフォーマンスを予測するのに役立ちます。 これは通常、容量計画のために行われます。
パフォーマンスSLAのレビューと継続的な監視
LoadView を使用した実際のブラウザー ベースのテストについて詳しく知りたいですか?今日、パフォーマンス エンジニアの 1 人とデモをスケジュールして、LoadView の動作を確認してください。 私たちのチームは、セットアップと スクリプトから 実行とレポート作成まで、プラットフォームとプロセス全体を順を追って説明します。 負荷がかかった状態でのサイト、アプリケーション、および API の実際のパフォーマンスを表示および分析します。 LoadView プラットフォームは、テストの概要、個々のセッション レポート、ウォーターフォール チャート、デバイスごとのパフォーマンスなど、いくつかの異なるレポート メトリックとレポートを提供します。
または、 今日自分でプラットフォームを試してみてください。 LoadView ロード テストを使用して、最大 5 つの無料ロード テストを提供します。
Webサイトとアプリケーションのパフォーマンス監視
Web サイトまたはアプリケーションが運用環境に移行した後、 パフォーマンス テスト 中に作成したスクリプトを監視プラットフォームにアップロードして、継続的に監視する必要があります。 これにより、SLAを確実に満たし、時間の経過とともに必要なパフォーマンスの改善と変更を確認して行うときにデータが提供されます。 さらに重要なことに、継続的な監視を設定すると、2番目の問題が発生したときにアラートを受け取り、小さな問題が大きな問題を引き起こさないようにすることができます。 また、新しいアプリケーションを起動する場合、 監視 を実装すると、 ユーザーにすべての違いをもたらす可能性のある小さなパフォーマンス調整を行う必要があるデータをチームに提供できます。
LoadView ソリューションは、Web ページ、Web アプリ、インフラストラクチャ、および ウェブ サービス (SOAP/REST API) の監視を含む、パフォーマンス テストウェブ 監視ソリューションの完全なドットウェブ コム モニター スイートの一部にすぎません。 ビジネスクリティカルなすべてのサイトとアプリケーションの監視デバイスを設定して、稼働時間、可用性、またはパフォーマンスのしきい値が満たされていない場合、またはエラーが発生した場合に通知を受け取るようにします。 サイトやアプリケーションが顧客や訪問者からダウンしているのを聞く必要はありません。 それまでに、それは多くの潜在的な顧客に影響を与え、ビジネスに大きな収益をもたらした可能性があります。