SLOの設計が初っぱなから覆った話

「生成AIで何が変わった？現役SREが語る、プロダクト改善の実像」にて発表

Transcript

1. 　 1 SLOの設計が初っぱなから覆った話 2025年09月16日 株式会社TOKIUM 部署名 開発部 氏名 對馬克
2. 2 プロダクト本部 開発部 對馬克(つしま まさる) Tsushima Masaru TOKIUMでembedded SREをしています。 • プロダクト開発チームとSREチームの橋渡し的なこ とをしています。 • datadogでダッシュボードを作ってる時間が一番楽 しいです
3. 3 会社概要 「未来につながる時を生む」をミッションに、支出管理にまつわるプロダクトを提供しています 複数のSaaSプロダクトを提供 最近はAIエージェント開発がアツい
4. Contents 1. 最終的にどうなった？ 2. 経緯 3. まとめ 4
5. 5 最終的にどうなったか？
6. 6 2つのSLOを並行運用することにした 最終的にどうなったか？ • time slice SLOとmetrics SLOという2つのSLOを同時並行で運用 ◦ time slice SLOは、外部に説明するための指標として利用 ◦ metrics SLOは、チーム内でのみ運用する
7. 7 time slice SLO/metrics SLOの解説 最終的にどうなったか？ 5分では語り切れない。zennにまとめたのでよければ読んでみてください！ https://zenn.dev/tokium_dev/articles/e6cb9456a7bb47
8. 8 経緯
9. 9 当初はtime slice SLOのみを導入する想定でいた 経緯 • 對馬が所属しているチームにSLOを試験的に導入することになった • SREチームリーダーに相談したところ、 「time slice SLOを標準化したい」とのことだった SREチームリーダー こいつでいきたい 勉強しよ、、、
10. 10 導入の段取りを考える 経緯 TOKIUMではSLOの運用実績がないので、関係者にどう説明していくかを考える必要があった • 主な関係者は、SREチーム、マネージャー、それから開発チームのメンバー • SREチームからは既に設計案があがっていたので意見を尊重する • 他の方々にはSLOの概念を理解してもらって、「とりあえずやってみましょうか」の スタンスでいく想定でいた SREチームリーダー 設計まもります いい感じに説明します
11. 11 設計案をまとめてまずは開発チームレビュー
12. 12 チームレビュー 経緯 time sliceが〜 稼働率が〜 標準設計が〜
13. 13 チームレビュー 経緯 説明は以上です。 何か質問ありますか？
14. 14 チームレビュー 経緯 前職でSLO運用経験のあるメンバーからこんな質問が datadogのドキュメントに 「可能な限りメトリクス ベースの SLO を使用してください」 って書いてないですか？
15. 15 チームレビュー 経緯 ・・・？
16. 16 レビューの指摘事項 経緯 datadogのドキュメント「SLOタイプの比較」より引用 https://docs.datadoghq.com/ja/service_management/service_level_objectives/guide/s lo_types_comparison/
17. 17 なぜmetricsベースがベストプラクティスなのか？ 経緯 5分では語り切れない。zennにまとめたのでよければ読んでみてください！ https://zenn.dev/tokium_dev/articles/e6cb9456a7bb47
18. 18 なぜSREチームはtime sliceを標準化したいのか？ 経緯 ・・・ なぜtime sliceを標準設計 に したいんですか？
19. 19 なぜSREチームはtime sliceを標準化したいのか？ 経緯 とりあえずSREチーム に聞いてみましょう
20. 20 SREチームとのmtgをセッティング
21. 21 話はまとまらず 経緯 SREチームリーダー Time slice SLOだと 該当の時間帯にエラー が発生したかどうかは た偶発的なものにすぎ ない エラーが頻発した時に timeslice SLOだと 稼働率をベースとする ことで対外的説明がし やすいというメリット がある アラートとSLOを別も のにするとSLOの価値 が薄まる ・・・
22. 22 じゃあどっちでもいいよ 経緯 SREチームのリーダー じゃあ どっちでもいいよ
23. 23 両方運用してみることに
24. 24 2つのSLOを並行運用することにした あくまで試験導入段階なので、とりあえず両方運用してみることに • metrics SLOはエラーの発生回数をそのままSLOに反映できるため、 チーム内でメインで追う値とする • Time slice SLOは、外部に稼働状況を説明する目的で使っていく ◦ 「エラーがn%発生していました」という説明より「n時n分にダウンしていました」 という説明のほうがやりやすい そもそも計算方法が違うので、両立できるかは結構心配、、、最終的にはどっちかに絞りたい
25. 25 まとめ
26. 26 まとめ まとめ 教訓 • 関係者それぞれがどういう意見を持っているかは事前に把握しておこう • 特に強い意見を持っている人は事前に把握しておいた方がよい！ よかったこと 試験導入の段階で深く議論できたこと 今後の本格運用をよりよい形で迎えられそう 皆さんのSLO運用で苦労した経験もぜひ聞かせてください！