ユーザー エクスペリエンス スコアを分析する
今日は SysTrack 紹介時などにもよく見せられることの多いユーザー エクスペリエンス スコアを掘り下げていく方法について簡単にご紹介します。
これは実際にもよく使われることが想定されるだけでなく、 SysTrack での典型的な画面操作を理解するうえでも有用なのではないかと思います。
なぜユーザー エクスペリエンス スコアを分析するのか
はじめに SysTrackのユーザー エクスペリエンス スコアについてなじみのない方は本稿の前に以下の記事を読むことをお勧めします。
一言で言えばユーザー エクスペリエンス スコアは「業務がPCやエンドポイントによって阻害されなかった時間の割合」と言えるのではないかと思います。
SysTrack においてユーザー エクスペリエンス スコアが重要なのは以下の理由があるのではないかと思います。
- 多種の要素（13項目を評価します）を評価してユーザーのIT環境の使用感を定量化できる
- どの要素がユーザーの使用感を損なっているのかを分析することが出来る
- SysTrack 内でも多種多様な分析手段が提供されている
本稿ではよく紹介される Visualizer のダッシュボードページからどのように詳細な分析に落としていくかを紹介します。
＃ユーザー エクスペリエンス スコアはダッシュボードによって、「ヘルス」や「クオリティタイム(%)」と表記される事がありますがこれらはすべて同じ意味だとご理解頂ければと思います。
Visualizer (Enterprise) > ダッシュボード
はじめに Visualizer （Enterpriseタブ）のダッシュボードページで以下のようなユーザーエクスペリエンススコアである環境を例にとってみます。全体で見えているディスクの問題を端末レベルで起こっている事まで掘り下げるところまでをゴールとしたいと思います。
5大要因を見ると、ディスクの問題が顕著に出ていますが、ここではサマリーのグリッドのところにドリルダウン可能を意味する青い丸印があることが分かります。（”ユーザー数の割合”列）
まずは、赤枠で記した割合の数値データの部分をダブルクリックします。
Enterprise Visualizerから Desktop Visualizerへ
上記をクリックすると、左側のペインの「ヘルス」のページへ飛びます。
しかし、端末レベルで起こっていることを確認するには、Enterprise Visualizerのページは分かりにくいことが多いのでこのまま「デスクトップ」タブに移動します。
そうすると、Desktop Visualizerの 「ヘルス」のページにそのまま遷移します。
端末毎の状態確認から Resolveの画面へ
ヘルスのページからはデータビューを「生産性への影響の詳細」を選択して端末毎の状況を表示します。（下図の赤枠）このグラフは「ユーザー エクスペリエンス スコアに影響のあった時間（1週間当たり）」を示しています。つまり、グラフが長い人ほど使用感が悪く、グラフの色は13項目の割合を示しています。
大規模の環境だとここに大量の端末が表示されてしまうと思うので、その場合にはフィルター（下図のオレンジの枠）を使用して絞るとよいと思います。
今回のようなケースの場合「アクティブ時間」が一定数以上のユーザーに絞ったり「生産性への影響（合計）」の数値（これはグラフの長さに相当しますので1週間当たりのものです）が一定量以上のユーザーなどに絞ると考えやすくなると思います。
ここでグリッドを見てみると、コンピュータ名がドリルダウン可能であることに気が付きます。
ここで気になった端末名をクリックして、Resolveのページへジャンプします。
Resolve: ヘルス 分析から Blackboxへ
Resolveのページに行ったらまずは「ヘルス」のページに飛びます。
ここを見ると30日間のヘルスの内訳を確認することが出来ます。
今はディスクの問題を調査したいので任意の日付の「ディスク」の部分をダブルクリックします。
（Resolveでは3日間は15秒単位のデータを保持しているので出来るだけ直近の日付を選ぶのがポイントです。以下の例では直近3日間は特にヘルスの問題は出ていないようなので、最も影響が大きかった日を選んでいます）
ダブルクリックすると、選択した日付のBlackbox画面にジャンプします。
（このときにディスクの分析に必要なメトリックが出力されて、かつ影響時間が最も大きな時間に自動的にフォーカスされています）
黄色の線の「ディスクの分」（Disk Minutes）となっているものがいわゆるディスクの問題の影響時間になります。「％ディスク時間」が一般的に「Disk Busy」と言われる状態の割合なのでこのタイミングでCドライブが過負荷になっている状況が確認出来ました。
ディスクの分（Disk Minutes）について
SysTrackは1分単位で13項目のユーザーエクスペリエンスの阻害要因の発生を判断しています。
ディスクの分（Disk Minutes）など〇〇の分と表記される影響時間は10分毎に記録され、直近10分間のうち何分間ユーザーエクスペリエンスが阻害されたかを記録しているといます。（つまり下のグラフの例では10分を超えることはありません）
ここで何が起こっているかを確認するためにシステムデータから「アプリケーション」を選択し、IOPSでソートします。
そうすると、ここでは Windows DefenderのIOが急激に増えていることが分かります。
（ここで458.00の数字のところをクリックすると、DefenderのIOPSのグラフが追記されるので ％ディスク時間のトレンドと一致するかを確認することが出来ます）
というわけでこれを他の時間帯等にも確認すればIOの問題がどのようなタイミングで起こっているかを確認することが出来ます。
これが特定のアプリケーションで常に起こっているのであれば分かりやすいのですが、毎回違うアプリケーションで起こっている場合には端末のディスクの性能不足を疑う必要も出てきます。
注： プロセス単位のIOPSの値は誤解を呼びやすいのですが、こちらはネットワークのようなディスクに関係のないIOも加味されるためディスク全体のIOPSをプロセス単位のIOPSが上回ることがありますのでご注意ください。
以下はパフォーマンスカウンターで Process > IO Read Operations/Sec のカウンターで表示される説明です。プロセス単位のIOPSは「 IO Read Operations/Sec ＋ IO Write Operations/Sec + IO Other Operations/Sec」を表示しています。
Process > IO Read Operations/sec の説明
プロセスが読み取り I/O 操作を発している率です。このカウンターは、ファイル、ネットワークおよびデバイスの I/O を含むプロセスが生成するすべての I/O 処理状況をカウントします。
各リソースの問題での確認ポイント
このようにして概ねHealthからBlackboxに飛ぶと主要な分析メトリックが表示されるので便利なのですが、必ずしもすべて表示されているわけではないので問題となっている要素に応じて以下のようなメトリックも分析してください。
| 主なリソース | 容量指標（閾値） | 性能指標（閾値） |
|---|---|---|
| CPU | 使用率95%以上 | Queue Length：コア数＋１ |
| Memory | 空きメモリ 50MB以下 | |
| Disk | Disk Queue Length > 1 Disk Queue Time > 10ms （平均キュー期間） Disk Service Time > 20ms （キューが投げられてからの遅延） Disk Transfer Time > 20ms （ディスク遅延） %Disk Time > 80% （ディスクビジー） |
|
| Latency | Latency Gateway > 5ms Latency Sessions > 100ms （ICA/HDX、PCoIP、Blast、RDPなどのRTTも確認してください） Latency Home Directory > 25ms |
|
| Virtual Machine | VM Memory Ballooned > 0mb VM Machine Ready Time > 10% |
|
| Virtual Memory | Virtual Memory Commit Ratio > 90% | |
| Network | Network Utilization > 30% Network Packet Rate > 100mb/sec |
Network Retransmit Rate > 10% |
| Startup | App Startup > 5sec セッション スタート時間 > 30sec |
関連記事
日本国内におけるSysTrackのテクニカルサービス部門の責任者です。
