4章 情報ではなくデータ
#システム運用アンチパターンのチラ見会
4.1　データではなく利用者から始める
システムに関するデータが多すぎてどれが役に立つのかよくわからない場合があります。そうなると「何を知りたいのか？」と考えるのではなく、「どんなデータが手元にあるのか？」という視点で調査をしてしまいます。
これほんとうにアンチパターンなんだけど、なんなんだろうな。。。〜活用っていう仕事を考える時に、課題やニーズから入るんじゃなくて、できることから入っちゃうの。。。
すべての人に役に立つ究極のダッシュボードは現実には存在しない
誰にとっても役に立たない
これめっちゃ刺さりました＞＜
最初のステップではダッシュボードの対象者を特定するべき
チームごとにとりあえずSLI/SLO 定めるためにつくりましょーってなったけど、対象者誰かはチームメンバだけでもないし、必ずしも明確ではないなあ..
Redash のダッシュボードとか、初見ではまったく整理されていなさすぎて、整理係がぜったい必要な気がする..
各自適当に使ってくださいでも、使えるんだろうけどまずい気が
次にダッシュボードの目的が重要
トラブルシューティング用のダッシュボードとステータス表示用のダッシュボードでは、想定されるユースケースがまったく異なるため、見た目も大きく異なる
4.2　ウィジェット：ダッシュボードの構成要素
私はデータが存在しないこととゼロ値を区別するようにしています。
基本的な話だけど大事だなー
そういえば、まったく表示されていないグラフがあった(ゼロではない）けど、放置していた.. (^^;
0に近いと気が付かなかっただけだった..
4.3　ウィジェットに文脈を与える
数字は文脈がなければ意味をなしません
ダッシュボードの主観的な見易さは考えても、人にどう動いてもらいたいまでは考えてなかった
色の話を読んでいて、パワーポイントがめっちゃみづらくなったり、Webサイトがみづらくなるのと同じことを感じた。ダッシュボードといえどもトンマナふくめて大事だよなー。
Latency とかError rate とかが外部システムに依存してるグラフだったりするので、その文脈も一緒に表示できると一番いいんだよなあ..
4.4　ダッシュボードの構成
ダッシュボードの先頭行は最も重要なメトリクスのために確保すべき。
先頭行にいれるウィジェットの数はできれあ５つ以下にしましょう。
重要なものは上部ぐらいの感覚だった。スクロールが嫌なので2ウィジェットとかにしがち。個数よりも重要度でまとめておくことが重要。書籍の内容とは間違ってない？
ノートウィジェットみたいな解決先は避けがちなんだけど、まぁたしかにあるといいんだよなっていうのはわかる。ノートの内容のメンテナンスが追いつかなくなるイメージがあるんですよね。
4.5　ダッシュボードの命名
- とりあえずチーム名にしてたけど、３つ書いて更新したら少し解像度があがったっぽい
4.6　本章のまとめ
みんなからのコメント
実践する/伝えるためのハードルはなにか？
かなり具体的なのであまりハードルはなさそう？
ダッシュボード設計について意外と本がないから、この章に辿り着けないとかっていうのはあるかもしれないけど。
入門監視とかにもなかったでしたっけ
それぐらいしか思いつかなかったっていう。。。
一緒に使うと良さそうなプラクティスやマインドセットはなにか？
勉強会とか、ベイビーステップとか？
ハードルの乗り越え方はなにか？実践/伝える方法はなにか？
導入（目的はよくわからないにしても、まずボトムアップで各チームに適当にメトリクス選んで作ってもらう）に苦労していると聞いてた。「ダッシュボードの対象者誰にするんですか？」って今のうちに聞いておくといいのかも..
だれがいつ使うのかが明確になってるとよさそう
どれくらい効果がありそうか？
命名規則とかはダッシュボードだけじゃなくて、いろんなものを見直すのに使えそう。