New Relic ダッシュボード活用入門【基本設計編】

New Relicを導入すると、APMやBrowser、Infrastructureなどのエージェントから続々とデータが集まってきます。オブザーバビリティ実現の第一歩を踏み出した皆さんは、テレメトリーデータが見せてくれる新たなインサイトに感動してくれていることでしょう。

そして皆さんはたくさんの価値のあるデータを眺めて思うでしょう「さて、みんなのためのダッシュボードを作ろうかな」と。しかしここからが問題です。
「あれ、この真っ白なキャンバスに、いったい何を、どんな風に置けばいいんだろう…？」と固まってしまうことがあるかもしれません。

今回の記事では、こんな悩みを抱えている方に向けてダッシュボード設計のステップをお届けします。もちろん作るためのアプローチは様々で、ここには書いていないような観点で作っている方もいらっしゃるでしょう。今回は１つの例として、参考にしてみてください。
この記事ではダッシュボードの機能や作成手順については触れません。作成するための考え方にフォーカスしてご紹介します。

ステップ1：目指しているオブザーバビリティのゴールを考えよう

そもそもですが、皆さんのチーム(あるいは会社)が目指しているオブザーバビリティの姿はどういうものでしょうか？
何故、New Relicのようなオブザーバビリティツールの導入を決めたのでしょうか？
これらは皆さんが必要とするダッシュボードに辿り着くための出発点になるはずです。オブザーバビリティにより実現したい将来像を言語化してみましょう。まずは大きな方向性を書き出します。
例えば、以下のようなものが考えられます。難しく考える必要はありません。

• 障害の復旧時間を、もっと短くしたい
• ユーザーの体験を、もっと良いものにしたい
• 新機能リリースの成功率を高めたい

これらの上位にビジネスやチームのゴールが想定できると、さらに納得感あるオブザーバビリティのゴールになります。より上位のゴールから落とし込むことで、ブレない軸と判断基準を作ることができます。

ステップ2：どんな場面でオブザーバビリティを活用しようとしているか

ゴールが明らかになったら、オブザーバビリティをどのような運用または業務フローの中で活用しようとしているかを洗い出しましょう。ほとんどの場合では、すでに運用や業務のフローが出来ていて、この中のどこでオブザーバビリティを活用しようとしているか想定されているはずです。



例えば「障害復旧時間を短縮する」というゴールを目指しているとしましょう。そこでは以下のような運用があるかもしれません。

• 障害が発生した場合、アラートによる通知やユーザーからのコールが発生する
• コールセンターでこれらの情報を集約し、障害の一次切り分けを実施する
• 必要に応じてコールセンターから、ユーザーへの障害事象のヒアリングも実施する
• 詳細な調査が必要な場合は、各システム担当にエスカレーションし、担当チームによって調査を実施する
• 調査の結果、改修などが必要な場合は担当チームが実施する
• コールセンターから改修完了を必要に応じてユーザーに案内する

簡単な運用フローにしてみると、以下のようになります。運用設計まで終わっているプロジェクトであれば、もっと詳細なフロー図がすでにあるかもしれません。いちから考えなくても、それらを活用しましょう。

ステップ3：その運用を担う「ペルソナ」は誰か？

ステップ2で定義した運用フローには、どんな役割のペルソナが登場するでしょうか。このペルソナはダッシュボードを活用する人たちになります。誰をターゲットにダッシュボードを作るかは、その内容を考える上でも重要なポイントです。できるだけ具体的にイメージできるように書き出してみましょう。
例えば先ほどの運用のフローの例だと、以下の２つのペルソナが想定できます。

ペルソナ：コールセンターの オペレーター

• 24時間365日システムの正常性を監視するため、人員はローテーションによって運用されている
• 個別のシステムについて技術的な深い知識はない
• 迅速に状況を把握し、正しくエスカレーションすることがミッション
• 「これは本物の障害か？」「影響は大きいか？」「どのチームに依頼すべきか？」が知りたい

ペルソナ： SRE または 開発者

• 特定のサービスや技術領域に精通した専門家
• それぞれのシステムに担当者がいる
• コールセンターからの情報をもとに、問題の根本原因を特定・解決することがミッション。
• 「どのコード、どのクエリが原因か？」「なぜそうなったのか？」を深掘りしたい。
  

ステップ4：ペルソナの運用を助ける「ダッシュボード」を構想する

これまでのステップの集大成として、ここで初めてダッシュボードの具体的なコンセプトを考えます。作ろうとしているダッシュボードは、洗い出したそれぞれのペルソナが、運用フローのどのポイントで見ようとしているでしょうか。またそのダッシュボードがあることで、オブザーバビリティのゴールに寄与できるでしょうか。
ここでも先ほどの例について考えてみましょう。コールセンターのオペレーター向けには以下のようなコンセプトになります。

コンセプト

• 目的： コールセンターのオペレーターが、障害の一次切り分けを迅速かつ正確に行い、担当者へスムーズにエスカレーションできるようにする
• ゴールへの貢献： エスカレーションの質と速度を向上させることで、最終的に「障害復旧時間の短縮」というゴールに寄与する

このダッシュボードは、システム担当者が根本原因を探すためのものではありません。あくまでこのダッシュボードの役割は、オペレーターの切り分けと担当者とのコミュニケーションを効率化することにあります。
このような感じで、コンセプトを定義します。
コンセプトによって、どんなダッシュボードを作るべきか足がかりが見つけられたのではないでしょうか。

ステップ5：構想したダッシュボードに必要な情報を洗出す

ダッシュボードのコンセプトが決まると、そこに載せるべき情報も自ずと決まってきます。必要な情報をリストアップして、言語化してみましょう。これを起点に、それを教えてくれるテレメトリーデータを探せば良いのです。

これまで考えてきた例では、以下のような情報になるのではないでしょうか。

• コンセプト：オペレーターが一次切り分けを迅速に行い、担当者へスムーズにエスカレーションするためのダッシュボード
• 必要な情報：
  • これは本物の障害か？
    • システムの主要指標（スループット、エラーレート、レイテンシ）と、それらの正常/異常を示す閾値
    • 普段の傾向と比較できる過去のデータ（例：1時間前、1日前、1週間前）
  • 影響範囲は大きいか？
    • エラーの影響を受けているユーザー数やセッション数
    • 特定のエンドポイント、特定の地域やブラウザに偏りはあるか
  • どのへんが怪しいか？
    • 関連するサービスやコンポーネントのステータス一覧

まとめ

今回はダッシュボードの作成にあたって、真っ白なキャンバスを前に思考停止しないための考え方を５つのステップに分けてお伝えしました。
ぜひ、皆さんのチームのゴール達成に向け、最高のダッシュボード作りに挑戦してみてください！

その他

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！

New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！