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
2.3k
プロダクトオーナーとして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.6k
Mackerel の EventBridge 対応開発秘話
tatsuru
PRO
1
180
技術が実現するイノベーションとWebサービス運用の未来 / Innovation from&for Web Operations
tatsuru
PRO
0
1.6k
成長するためのエンジニア組織 / Hatena Engineering Group 2018
tatsuru
PRO
1
110
はてなのログ運用 これまでとこれから / Hatena Engineer Seminar #6
tatsuru
PRO
7
12k
Mesosを使ったImmutable Infra 管理システムを作ってみた
tatsuru
PRO
8
8k
Other Decks in Technology
See All in Technology
Shadow DOMとセキュリティ - 光と影の境界を探る / Shibuya.XSS techtalk #13
masatokinugawa
0
310
alecthomas/kong はいいぞ
fujiwara3
6
1.1k
なぜAI時代に 「イベント」を中心に考えるのか? / Why focus on "events" in the age of AI?
ytake
2
800
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
6
330
Kiroから考える AIコーディングツールの潮流
s4yuba
1
290
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
330
大規模イベントを支える ABEMA の アーキテクチャ 変遷 2025
nagapad
5
510
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
3
150
Datasets for Critical Operations by Dataform
kimujun
0
120
Kiro Hookを Terraformで検証
ao_inoue
0
140
Step Functions First - サーバーレスアーキテクチャの新しいパラダイム
taikis
1
280
AIに全任せしないコーディングとマネジメント思考
kikuchikakeru
0
270
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Designing for Performance
lara
610
69k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Automating Front-end Workflow
addyosmani
1370
200k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Language of Interfaces
destraynor
158
25k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Statistics for Hackers
jakevdp
799
220k
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 以上です