Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
Search
taxin
October 25, 2023
Technology
0
580
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
taxin
October 25, 2023
Tweet
Share
More Decks by taxin
See All by taxin
OpenTelemetry実践 はじめの一歩
taxin
0
1.1k
SREを「続けていく」あなたへ
taxin
1
290
Cloud runユーザーから見たk8s
taxin
0
820
ローカルk8s環境のススメ / k8s-tools-for-local
taxin
0
1.1k
EKS 101
taxin
0
800
Other Decks in Technology
See All in Technology
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
7
4.9k
Max out Local LLM in Challenging Environments
sashimimochi
2
210
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
1.1k
Real World Type Puzzle and Code Generation
yukukotani
0
140
ルーターでプレゼンする
puhitaku
1
3.4k
Prisma ORMを2年運用して培ったノウハウを共有する
tockn
6
1.3k
【基本】データベース設計
oracle4engineer
PRO
2
290
uvを使ってストレスフリーな Python開発をしよう!
r74tech
0
260
.NET Profiler in 2024.
kkamegawa
2
2.6k
How to Lead? Testimonial of a Lead Android Engineer
oleur
1
130
Microsoft Intune 勉強会 第 2 回目
tamaiyutaro
2
520
2024春 注目のWeb系 OSS & SaaS 3選
makies
0
210
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
423
63k
Fireside Chat
paigeccino
22
2.6k
It's Worth the Effort
3n
180
27k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Docker and Python
trallard
35
2.7k
Ruby is Unlike a Banana
tanoku
96
10k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
47k
Agile that works and the tools we love
rasmusluckow
325
20k
Imperfection Machines: The Place of Print at Facebook
scottboms
261
12k
Navigating Team Friction
lara
179
13k
Transcript
Mackerel開発チームでの カスタムダッシュボードの活用例 id:taxintt / @taxin_tt 2023/10/25 Mackerel Drink Up #12
1
自己紹介 • 西川 拓志 ◦ id: taxintt / @taxin_tt •
Mackerel開発チーム SRE 2
今日の話 • カスタムダッシュボードについて • ダッシュボード利用時の悩みどころ • 開発チームにおけるダッシュボードの活用例 3
4 1. カスタムダッシュボード とは?
カスタムダッシュボードとは? • ユーザーがwidgetを自由に配置して カスタマイズができるダッシュボード ◦ アイコンをドラッグ&ドロップしてwidgetを配置 5
6
7
8
9
10
11 カスタムダッシュボード 「上手く」使ってますか?
12 2. ダッシュボード利用時の 悩みどころと開発チームの 活用例
13
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
14
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
15
認知負荷とは • ユーザーが情報を処理し、理解する際に かかる精神的なエネルギー量 • 処理すべき情報がユーザーの処理能力を 超えると認知負荷が高いと見なされる 16
「『短期記憶の負荷を減らしつつ、表示されたコン テンツの理解度を高めることを念頭において、 人の理解を助けるためのインターフェイスの仕様に 関する判断を行う』ことが認知負荷を軽減するデザ インだと考えられます。」 17 https://blog.adobe.com/jp/publish/2020/11/16/cc-web-ux-6-ways-to-reduce-cognitive-load-for-a-better-ui
• 短期記憶の負荷を減らす • 表示されたコンテンツの理解度を高めることを 念頭に置く • 人の理解を助けるためのインターフェイスの仕様 に関する判断を行う 18 認知負荷を軽減するには
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetはあるが、どう見たらいいのかわから ない
19
1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 → 原因調査
• アクションに繋がらない情報は削る 20
e.g.) SLO用のダッシュボード • SLO(サービスレベル目標) ◦ サービスの信頼性の目標・評価基準を定めたもの e.g. HTTPリクエストのSuccess rate :
99.95% • SLO運用 (SLOの更新) での利用を想定 ◦ SLOの現在の状況が把握できる 21
22
1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 → 原因調査
• アクションに繋がらない情報は削る ◦ 情報整理のためには「ダッシュボードの利用目的」も 重要になる 23
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
24
2. 利用目的を整理する • ダッシュボードを見た上でのゴールは何か ◦ サービスの正常/非正常を判断すること? ◦ 非正常な事象を調査・解消すること? • ダッシュボードを見る場の目的も明確にする
25
26 ダッシュボードを見る場
PWG (Performance Working Group) 27 https://mackerel.io/ja/blog/entry/advent-calendar2015/day19
PWG (Performance Working Group) 28 https://qiita.com/heleeen/items/62f8b001310d49f42653
PWG (Performance Working Group) • 背景 ◦ システム運用の情報が一部に閉じがちで、開発チーム のエンジニアが状況把握できてないという問題意識 •
内容 ◦ 開発チームのエンジニアとSREが パフォーマンス状況やインフラの構成変更を共有 29
PWG (Performance Working Group) • 背景 ◦ システム運用の情報が一部に閉じがちで、開発チーム のエンジニアが状況把握できてないという問題意識 •
内容 ◦ 開発チームのエンジニアとSREが パフォーマンス状況やインフラの構成変更を共有 30
PWG (Performance Working Group) • PWGとしてのゴール ◦ 開発チーム全体でシステム運用の状況を把握できる (e.g. インフラ構成変更、パフォーマンス状況)
31
PWG (Performance Working Group) • 状況を把握できる ◦ パフォーマンス問題が見られたとしても、 PWGの場としては「問題が把握できればOK」 ◦
対応自体はissueを作成して原因調査を別途行う 32
PWG (Performance Working Group) • 状況を把握できる ◦ パフォーマンス問題が見られたとしても、 PWGの場としては「問題が把握できればOK」 →
パフォーマンス状況を把握するための情報を ダッシュボードに含める 33
34 https://mackerel.io/ja/blog/entry/meetup14-3
ダッシュボード(見る場)の目的が決まる → 目的を達成するのに必要な情報が整理される → ダッシュボードに含めるべき情報が決まる 35
(再掲) 1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 →
原因調査 • アクションに繋がらない情報は削る ◦ 情報整理のためには「ダッシュボードの利用目的」も 重要になる 36
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
37
3. Markdownウィジェットの活用 • ダッシュボードの「見方」を補足する ◦ メトリックの値が示す状態 ◦ メトリックの変動が示す兆候 ◦ メトリックを基に監視しているコンポーネントの
振る舞い 38
39 https://mackerel.io/ja/blog/entry/meetup14-3
e.g.) PWG用のダッシュボード • Markdownウィジェットや補助線機能の活用 ◦ e.g.) latency = 500msを基準値とすると、 それ以下の水準でlatencyが変動していても対応不要
と判断できる 40
41 https://mackerel.io/ja/blog/entry/meetup14-3
まとめ • ダッシュボードに含める情報は最小限に • ダッシュボードや使う場のゴールを明確に して情報を整理する • 整理した情報を理解できるようにする ◦ e.g.
Markdownウィジェット、補助線機能 etc… 42
43 カスタムダッシュボードを 使う上での悩み・ノウハウ 聞かせてください