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
プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜 / SRE NEX...
Search
tatsuru
PRO
September 29, 2023
Technology
0
1.8k
プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜 / SRE NEXT 2023
tatsuru
PRO
September 29, 2023
Tweet
Share
More Decks by tatsuru
See All by tatsuru
Mackerelのプロダクト開発 - エンジニア中心の開発プロセスで大切にしていること
tatsuru
PRO
0
4.2k
Mackerel の EventBridge 対応開発秘話
tatsuru
PRO
1
120
技術が実現するイノベーションとWebサービス運用の未来 / Innovation from&for Web Operations
tatsuru
PRO
0
1.3k
成長するためのエンジニア組織 / Hatena Engineering Group 2018
tatsuru
PRO
1
91
はてなのログ運用 これまでとこれから / Hatena Engineer Seminar #6
tatsuru
PRO
7
12k
Mesosを使ったImmutable Infra 管理システムを作ってみた
tatsuru
PRO
8
7.7k
Other Decks in Technology
See All in Technology
夏休みの(最後の)宿題 for JuliaTokyo #12
antimon2
0
140
#Zenoh 完全に理解した 〜組込み純情篇〜
takasehideki
1
470
【Λ(らむだ)最近のアプデ情報 / RPALT20240904
lambda
0
180
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
2
230
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
13k
実践的なバグバウンティ入門
scgajge12
4
2.3k
Eventual Detection Engineering
ken5scal
0
1k
FastConnect の冗長性
ocise
0
7.2k
contenteditableと向き合う
kikuchikakeru
2
240
脆弱星に導かれて
nishimunea
1
1.6k
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
280
CRTO/CRTL/OSEPの比較・勉強法とAV/EDRの検知実験
chayakonanaika
1
1k
Featured
See All Featured
How GitHub (no longer) Works
holman
310
140k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Building Your Own Lightsaber
phodgson
101
6k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.8k
Mobile First: as difficult as doing things right
swwweet
220
8.8k
Thoughts on Productivity
jonyablonski
66
4.2k
Designing Experiences People Love
moore
138
23k
A Philosophy of Restraint
colly
202
16k
BBQ
matthewcrist
83
9.1k
Web development in the modern age
philhawksworth
204
10k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
Transcript
プロダクトオーナーとして SLOに向き合う 〜Mackerelチームの事例〜 id:wtatsuru / @tatsuru 2023/09/29 SRE NEXT 2023
1
自己紹介 • 渡辺 起 id:wtatsuru / @tatsuru • 株式会社はてな •
現 Mackerel プロデューサー ◦ 2011年からインフラエンジニア ◦ 開発基盤部署のマネージャーなどを経験 ◦ 2022年までMackerel プロダクトオーナー 2
3
4 今日話すこと
5 プロダクトオーナーとして SLOに向き合う Mackerelチームの事例
今日話すこと MackerelチームでSLOを使って運用してきた POとして何が嬉しいのか、という話をします 6
メニュー • Mackerelチームの紹介 • SLO導入背景 • なぜSLOを使うのか • 実際の運用風景 7
メニュー • Mackerelチームの紹介 • SLO導入背景 • なぜSLOを使うのか • 実際の運用風景 8
Mackerelチームの紹介 Mackerel開発チーム • 10人前後 (うちSRE 1~3) • 2014年リリース 9
Mackerelチームの紹介 • エンジニア向けプロダクト ◦ 運用ノウハウを乗せて提供する • 自分たちでもドッグフーディング ◦ SLOもその流れで機運あり 10
メニュー • Mackerelチームの紹介 • SLO導入背景 • なぜSLOを使うのか • 実際の運用風景 11
SLO導入背景 監視運用のサービスとして • 信頼性と開発速度をうまくバランス取りたい • ドッグフーディングしたい …正直半々くらい 12
プロダクトの状況 • 信頼性は「低くて困る」状況ではない • 開発速度は当然上げたい 13
プロダクトの状況 現実の課題たち • 可用性はそんなに困ってない • 停止メンテナンス時間が長い • デプロイが遅い、リリース頻度が低い 14
プロダクトの状況 15 2022 Accelerate Stete of DevOps Report https://cloud.google.com/devops/state-of-devops?hl=ja
プロダクトの状況 • サービス復旧時間:数時間以内 • 変更失敗率:5%くらい • 運用パフォーマンス:「たいてい期待にかなう」 • リードタイム:数日程度 •
デプロイ:週2回 (2019年当時) 16
プロダクトの状況 • 運用パフォーマンスはあまり困ってない • 開発速度は上げたい • 目に見える課題はいくつかある おそらくよくある状況 17
メニュー • Mackerelチームの紹介 • SLO導入背景 • なぜSLOを使うのか • 実際の運用風景 18
なぜSLOを使うのか 信頼性と開発速度をうまくバランス取りたい • 開発速度を上げたい • 信頼性は担保されていて欲しい 19
信頼性って • ではない ◦ レイテンシ、エラー率 • 主語はユーザー ◦ ユーザーの期待に沿っているか ◦
SLO本にあります 20
信頼性って Mackerel の場合、例えば • ダッシュボードが遅いとつらい ◦ 慣れるかもしれない。障害対応の時は厳しい。 • 多少のエラーは許容できる ◦
クライアントがリトライする 21
22
信頼性との関わり方 まずは観測する • ユーザーに聞く ◦ インタビュー、満足度調査、問い合わせ • システムを観測する 23
信頼性との関わり方 判断する、意思決定する • 観測結果に対応する ◦ 満足度が下がっている、エラーが増えている • 瞬発力が必要 ◦ これはすぐに対応が必要?
24
信頼性との関わり方 まとめ:大変 • PO = 意思決定者の介在が必要な場面が増える • 普段から考えることは多いのに... 25
そこで SLO ってやつが • 信頼性を定量化して扱うと ◦ 数値化して改善サイクルに乗せられる ◦ チームで判断できる •
うまく回る! ◦ 楽になる ◦ 数字で語れる 26
なぜSLOを使うのか 信頼性と開発速度をうまくバランス取りたい • 開発速度を上げたい • 信頼性は担保されていて欲しい • 判断と改善をチームで回したい 27
メニュー • Mackerelチームの紹介 • SLO導入背景 • なぜSLOを使うのか • 実際の運用風景 28
実際に入れてみた • SLIと仮の値を決めて • 見直しフローを作って • とりあえず始めてみた 29 詳しくは:Mackerel開発チームのリードSREが考える働き方と組織作り https://speakerdeck.com/masayoshi/developers-summit-2021-summer
30
始めやすく • SREが叩き台を作った • Error Budget Policy は緩く ◦ 「調査をするか判断する」
◦ 徐々に判断を減らしていく 31
活用シーン例 • P99がちょっと悪化した ◦ →SLO割らないから無視する • 大きな仕組みの変更でエラーがでた ◦ →ちょっとリリーススケジュールを調整しよう 32
信頼性って難しい • ユーザーの反応は観測が難しい ◦ オブザーバビリティが低い ◦ いいメトリックを見つける必要がある • 実験しづらい ◦
反応の遅れが大きい、など 33
システムの難しさに向き合う SLIの定義と観測が難しいところ • 例えば Mackerel の外形監視 ◦ 「到達できない状態」も正しい挙動 34
システムの難しさに向き合う SLIの定義と観測が難しいところ • 機械学習 • そもそも考えられてなかったり 重要なところから、一つずつ解決していこう 35
開発速度は上がったか • 導入当時よりは上がった 😀 ◦ デプロイの仕組み変更が一番大きい • そもそも継続的改善はやるもの ◦ ここに効いたと直接実感することは少ない
◦ 下支えにはなっているだろう 36
まとめ • SLO導入して使ってます • 判断が減るのが嬉しいポイント • 難しい問題は解決しないので頑張っていこう 37
宣伝 • Mackerel をよろしくお願いします ◦ エンジニアも積極採用中 • 最近 OpenTelemetry 対応中です
◦ ベータユーザー募集してます 38
39 以上です