プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜 / SRE NEXT 2023
by
https://speakerdeck.com/tatsuru
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
プロダクトオーナーとして SLOに向き合う 〜Mackerelチームの事例〜 id:wtatsuru / @tatsuru 2023/09/29 SRE NEXT 2023 1
Slide 2
Slide 2 text
自己紹介 ● 渡辺 起 id:wtatsuru / @tatsuru ● 株式会社はてな ● 現 Mackerel プロデューサー ○ 2011年からインフラエンジニア ○ 開発基盤部署のマネージャーなどを経験 ○ 2022年までMackerel プロダクトオーナー 2
Slide 3
Slide 3 text
3
Slide 4
Slide 4 text
4 今日話すこと
Slide 5
Slide 5 text
5 プロダクトオーナーとして SLOに向き合う Mackerelチームの事例
Slide 6
Slide 6 text
今日話すこと MackerelチームでSLOを使って運用してきた POとして何が嬉しいのか、という話をします 6
Slide 7
Slide 7 text
メニュー ● Mackerelチームの紹介 ● SLO導入背景 ● なぜSLOを使うのか ● 実際の運用風景 7
Slide 8
Slide 8 text
メニュー ● Mackerelチームの紹介 ● SLO導入背景 ● なぜSLOを使うのか ● 実際の運用風景 8
Slide 9
Slide 9 text
Mackerelチームの紹介 Mackerel開発チーム ● 10人前後 (うちSRE 1~3) ● 2014年リリース 9
Slide 10
Slide 10 text
Mackerelチームの紹介 ● エンジニア向けプロダクト ○ 運用ノウハウを乗せて提供する ● 自分たちでもドッグフーディング ○ SLOもその流れで機運あり 10
Slide 11
Slide 11 text
メニュー ● Mackerelチームの紹介 ● SLO導入背景 ● なぜSLOを使うのか ● 実際の運用風景 11
Slide 12
Slide 12 text
SLO導入背景 監視運用のサービスとして ● 信頼性と開発速度をうまくバランス取りたい ● ドッグフーディングしたい …正直半々くらい 12
Slide 13
Slide 13 text
プロダクトの状況 ● 信頼性は「低くて困る」状況ではない ● 開発速度は当然上げたい 13
Slide 14
Slide 14 text
プロダクトの状況 現実の課題たち ● 可用性はそんなに困ってない ● 停止メンテナンス時間が長い ● デプロイが遅い、リリース頻度が低い 14
Slide 15
Slide 15 text
プロダクトの状況 15 2022 Accelerate Stete of DevOps Report https://cloud.google.com/devops/state-of-devops?hl=ja
Slide 16
Slide 16 text
プロダクトの状況 ● サービス復旧時間:数時間以内 ● 変更失敗率:5%くらい ● 運用パフォーマンス:「たいてい期待にかなう」 ● リードタイム:数日程度 ● デプロイ:週2回 (2019年当時) 16
Slide 17
Slide 17 text
プロダクトの状況 ● 運用パフォーマンスはあまり困ってない ● 開発速度は上げたい ● 目に見える課題はいくつかある おそらくよくある状況 17
Slide 18
Slide 18 text
メニュー ● Mackerelチームの紹介 ● SLO導入背景 ● なぜSLOを使うのか ● 実際の運用風景 18
Slide 19
Slide 19 text
なぜSLOを使うのか 信頼性と開発速度をうまくバランス取りたい ● 開発速度を上げたい ● 信頼性は担保されていて欲しい 19
Slide 20
Slide 20 text
信頼性って ● ではない ○ レイテンシ、エラー率 ● 主語はユーザー ○ ユーザーの期待に沿っているか ○ SLO本にあります 20
Slide 21
Slide 21 text
信頼性って Mackerel の場合、例えば ● ダッシュボードが遅いとつらい ○ 慣れるかもしれない。障害対応の時は厳しい。 ● 多少のエラーは許容できる ○ クライアントがリトライする 21
Slide 22
Slide 22 text
22
Slide 23
Slide 23 text
信頼性との関わり方 まずは観測する ● ユーザーに聞く ○ インタビュー、満足度調査、問い合わせ ● システムを観測する 23
Slide 24
Slide 24 text
信頼性との関わり方 判断する、意思決定する ● 観測結果に対応する ○ 満足度が下がっている、エラーが増えている ● 瞬発力が必要 ○ これはすぐに対応が必要? 24
Slide 25
Slide 25 text
信頼性との関わり方 まとめ:大変 ● PO = 意思決定者の介在が必要な場面が増える ● 普段から考えることは多いのに... 25
Slide 26
Slide 26 text
そこで SLO ってやつが ● 信頼性を定量化して扱うと ○ 数値化して改善サイクルに乗せられる ○ チームで判断できる ● うまく回る! ○ 楽になる ○ 数字で語れる 26
Slide 27
Slide 27 text
なぜSLOを使うのか 信頼性と開発速度をうまくバランス取りたい ● 開発速度を上げたい ● 信頼性は担保されていて欲しい ● 判断と改善をチームで回したい 27
Slide 28
Slide 28 text
メニュー ● Mackerelチームの紹介 ● SLO導入背景 ● なぜSLOを使うのか ● 実際の運用風景 28
Slide 29
Slide 29 text
実際に入れてみた ● SLIと仮の値を決めて ● 見直しフローを作って ● とりあえず始めてみた 29 詳しくは:Mackerel開発チームのリードSREが考える働き方と組織作り https://speakerdeck.com/masayoshi/developers-summit-2021-summer
Slide 30
Slide 30 text
30
Slide 31
Slide 31 text
始めやすく ● SREが叩き台を作った ● Error Budget Policy は緩く ○ 「調査をするか判断する」 ○ 徐々に判断を減らしていく 31
Slide 32
Slide 32 text
活用シーン例 ● P99がちょっと悪化した ○ →SLO割らないから無視する ● 大きな仕組みの変更でエラーがでた ○ →ちょっとリリーススケジュールを調整しよう 32
Slide 33
Slide 33 text
信頼性って難しい ● ユーザーの反応は観測が難しい ○ オブザーバビリティが低い ○ いいメトリックを見つける必要がある ● 実験しづらい ○ 反応の遅れが大きい、など 33
Slide 34
Slide 34 text
システムの難しさに向き合う SLIの定義と観測が難しいところ ● 例えば Mackerel の外形監視 ○ 「到達できない状態」も正しい挙動 34
Slide 35
Slide 35 text
システムの難しさに向き合う SLIの定義と観測が難しいところ ● 機械学習 ● そもそも考えられてなかったり 重要なところから、一つずつ解決していこう 35
Slide 36
Slide 36 text
開発速度は上がったか ● 導入当時よりは上がった 😀 ○ デプロイの仕組み変更が一番大きい ● そもそも継続的改善はやるもの ○ ここに効いたと直接実感することは少ない ○ 下支えにはなっているだろう 36
Slide 37
Slide 37 text
まとめ ● SLO導入して使ってます ● 判断が減るのが嬉しいポイント ● 難しい問題は解決しないので頑張っていこう 37
Slide 38
Slide 38 text
宣伝 ● Mackerel をよろしくお願いします ○ エンジニアも積極採用中 ● 最近 OpenTelemetry 対応中です ○ ベータユーザー募集してます 38
Slide 39
Slide 39 text
39 以上です