プロダクトオーナーとしてSLOに向き合う〜Mackerelチームの事例〜 / SRE NEXT 2023

by https://speakerdeck.com/tatsuru

Embed

Start on current slide

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

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

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

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 以上です