グラフの壁は誰も見ない

一言でいうと

ダッシュボードは絵ではなく、質問1つに答える道具です。パネルを増やすことと、答えを早く得ることは、反対の方向へ進みます。

なぜ必要なのか

障害のときにダッシュボードを開く理由は1つです。「いま何が正常ではないのか」を30秒以内に知るためです。ところが、ほとんどのダッシュボードはその質問に答えられません。パネルが40個あり、そのうち38個は普段と同じで、どれが普段と違うのかを人が目で探さなければなりません。午前3時にその作業をする人は、結局ダッシュボードを閉じてログを見ます。

パネルが増えていく流れも決まっています。誰かが「これも見えるといい」と1つ付け足します。消す人はいません。消すには「これは誰も見ていない」を証明しなければなりませんが、ダッシュボードにはそれを証明する方法がありません。そのため、ダッシュボードは一方向にしか育ちません。

質問を先に書いておくと、その流れが止まります。パネルごとに「これはどんな質問に答えるのか」を1文で書けなければ、そのパネルは消せます。消す根拠ができることが、質問を書く本当の理由です。

どう動くのか

質問、パネルの順に作ります。逆にすると「この指標があるから描いてみよう」になり、そうして付けたパネルは誰にも解釈できません。

質問	パネル	なぜこの指標なのか
いま、ユーザーに失敗を返していますか	5xxの割合	件数はトラフィックが増えると一緒に増えます。ユーザーが経験する確率は割合です
遅くなりましたか	p95応答時間	平均は遅い側の半分を隠します
どれだけ入ってきていますか	秒あたりのリクエスト数	エラー率が下がっても、トラフィックが0なら正常ではありません
リソースはまもなく尽きますか	ディスク・コネクションの使用率	上限のある値だけがここに来ます

この4つが、GoogleのSRE本にある4つのゴールデンシグナル(レイテンシ・トラフィック・エラー・飽和)です。新しいサービスのダッシュボードを作るときは、この4つから始めればたいてい正解です。

ダッシュボードは1種類ではない

混ぜると3つとも果たせなくなる、3つの種類があります。

種類	答える質問	見る人	パネル数
状態(health)	いま正常か	ページを受けた人	4–6
診断(diagnosis)	なぜ悪いのか	原因を探す人	多くてもかまいません
容量(capacity)	いつ増やすべきか	計画する人	週単位で見ます

状態ダッシュボードに診断用のパネルを混ぜた瞬間、そのダッシュボードは30秒以内に答えを返せなくなります。診断パネルは別のダッシュボードへ移し、リンクでつなぎます。

よくある勘違い

「多く見せるほど安全だ」という考えは逆です。画面に信号が多いほど、おかしな1つを見逃す確率が上がります。状態ダッシュボードのパネルが6個を超えていたら、たいてい診断用が混ざっています。

「まずCPUを置く」という考えも誤りです。CPUが80%であることは、ユーザーにとって何の意味もありません。ユーザーが経験すること(エラー・レイテンシ)が先で、リソースはその次です。CPUは「なぜ」を問う診断ダッシュボードの材料です。

パネル1つを読めるようにするもの

同じデータでも、描き方しだいで30秒で読めることもあれば、長く眺めてもわからないこともあります。状態ダッシュボードのパネルには、最低でもこの4つがそろっている必要があります。

ベースラインが一緒に表示されています。現在の値だけでは、それが良いのか悪いのかわかりません。目標値を横線で引くか、先週の同じ時刻を重ねて描きます。特にトラフィックのように1日の周期がはっきりした指標では、昨日や先週と重ねて見ることが絶対値よりずっと役に立ちます。

単位と範囲が正直です。軸が0から始まらないと小さな変化が崖のように見え、逆に範囲が広すぎると本当の変化が平らになります。割合はパーセントで、時間はミリ秒や秒で、サイズはバイト単位で表示し、人が暗算しなくて済むようにします。

色が状態を表します。複数の線を虹色に塗っても意味はありません。正常は落ち着いた色に、問題のある状態だけを目立つ色にします。そして赤は本当に悪いときだけ使います。普段から赤いものが1つあると、そのダッシュボード全体が赤に鈍感になります。

時間範囲が質問に合っています。いま正常かを問う画面の既定の範囲が30日だと、直近の数分の変化が1点に潰れます。状態ダッシュボードは短く(1時間前後)、容量ダッシュボードは長く取ります。

ここにもう1つ勧めます。パネルに説明を付けておきます。この値が何を数えているのか、どこから来るのか、おかしいときはどこを見ればいいのかを1、2行で書いておけば、そのパネルを初めて見る人が作った人に尋ねなくて済みます。ダッシュボードを作った人がいつもその場にいるとは限りません。そして、説明を書いていて1文で書けないパネルに出会ったら、そのパネルは自分でも何を見ているのかわかっていないので、消す候補です。

実務で本当に大切なこと

ダッシュボードを作ったら、インシデントテストをしてみます。午前3時にページを受けたと想定して、このダッシュボードを開き、30秒以内に「正常か異常か」を言えるでしょうか。言えないなら、パネルが足りないのではなく多すぎるのです。

そして、ダッシュボードのタイトルに答える質問をそのまま書いておきます。「shop-api概要」よりも「shop-api: いま、ユーザーに失敗を返しているか」のほうが優れています。タイトルが質問なら、その質問に答えないパネルが目立ちます。