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

Transcript

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