Supportでは、チケットとユーザーデータを使用して、チケットのリストを「ビュー」に整理できます。ビューの詳細については、「ビューを使用したチケットワークフローの管理」を参照してください。
多くの条件を設定した複雑なビューや、多数のチケットを返すビューを作成したことがある場合、ビューの読み込みや表示にかかる時間に不満をお持ちになったことがあるかもしれません。複雑な条件設定や膨大な数のチケットによって、ビューのパフォーマンスが低下することがあります。
この記事では、Zendesk Supportでビューを最適化するために使用できるベストプラクティスをいくつか学習します。ここで述べる内容は、すべきこととすべきでないことの厳密なリストではなく、パフォーマンスのために最適化され、不必要な複雑さを回避するビューを作成するための提案です。
この記事では、次のトピックについて説明します。
基本的な注意事項
第一に、ビューの条件ステートメントを作成する場合、以下のことは行なわないでください。
- 複数のテキストフィールドをチェックする。
- ヌル値をチェックする。例：「担当者 = ( - )」
- 適用範囲の広い排除条件を使用する。例：NOTステートメント
代わりに、できるだけ具体的な包括条件を使用してください。 - タグをチェックする。
- 「次の文字列/単語を含まない」の条件でチケットの説明をチェックする。
文字列/単語のチェックは、タグのチェックよりさらに複雑です。
タグをチェックする条件と、単語/文字列をチェックする条件は、どちらも不適切であり、後者の方がより不適切です。
なお、ビューを表示する際には、アーカイブされていないすべてのチケットを検索し、ビューで定義された条件に一致するチケットを見つける必要があります。最善の方法は、存在しないものではなく、存在するものを探すようにビューを定義することです。
大きなデータセットの操作
膨大な量のチケットを表示する必要がある場合、チケットをまずZendesk Support外部のデータウェアハウスにエクスポートし、そこからデータを取り出す方法が現実的です（例：年度末レポートのために数十万件のチケットを取り出す場合など）。
チケットのアーカイブ
Zendesk Supportでは、「終了」ステータスになってから120日経過したチケットは自動的にアーカイブされます。これらのチケットは、アーカイブ後もアクセス可能ですが、ビューには含まれなくなります。「チケットのアーカイブについて」を参照してください。
ページネーション
チケットの量が多くなると、ビューに表示される検索結果は複数ページにわたります。たとえば、1ページあたり30件のチケットを表示する複数ページに分割されます。これは業界用語でいわゆる「大きなオフセットクエリ」と呼ばれるもので、パフォーマンスへの影響を顕著にもたらす可能性があります。
「ページネーションの上限値はどこか」という問いに対する答えは、ページネーションに対する厳密な数値制限ではなく、以下に挙げる要素に関連して決まります（とはいえ、数十ページを超える場合、ビューはより複雑化します）。
- チケットの量
- ビューに同時アクセスするエージェントの人数
- 条件
クエリのストッパーとは
クエリのストッパーとは何でしょうか。これは、極端に大きなビューが読み込まれることで処理に多大な負荷がかかることを阻止するために、Zendeskのオペレーションチームが導入したしくみです。
クエリのストッパーが作動する主な原因は次の２つです。
- ビューで、チケットの計算が非常に複雑になり、さらに大量のチケットが返される場合。
メモ：パーソナルビューでは、膨大な量のチケットが返される場合にのみ、クエリストッパーが必要となります。 - ビューの表示に一度に大きな負荷がかかる場合（数百人ものエージェントが同じビューを同時に表示する場合など）
複雑なビュー
複雑なビューであっても、1日に1度しか開かれないなら、おそらく問題ありません。どの日でも、初めてビューを開いたときが、その日でそのビューの表示にかかる時間が最長になります（キャッシュがどこかのタイミングでクリアされた場合を除く）。非常に複雑な条件が設定されているビューでは、数千件のチケットが含まれ、さらに数百人のエージェントが1分間に何回もアクセスするときには、ビューのパフォーマンスへの影響は最も大きくなります。