こつこつ育てるSLO

2024年12月10日に開催された『2024.12.10@株式会社ユーザベース×株式会社ZOZO×株式会社PR TIMES 3社合同フロントエンド勉強会』で登壇した際の資料です。 #zup_frontend
https://prtimes.connpass.com/event/335335/

Transcript

1. こつこつ育てる SLO
 NewsPicks, BDD Product Team, Software Engineer / ニッシー☆
 2024.12.10@株式会社ユーザベース×株式会社ZOZO×株式会社PR TIMES 3社合同フロントエンド勉強会 #zup_frontend

2. 00
 自己紹介
 ニッシー☆ / Uzabase, Inc.
 NewsPicks, BDD Product Team, Software Engineer
 23年度新卒。ソーシャル経済メディア「NewsPicks」のWebリニューアルを 24年10月まで従事。現在は経済・ビジネス情報に特化した動画配信サー ビス「NewsPicks Stage.」にてプロダクト開発を行っている。肉🍖と日本 酒🍺が大好き。
 𝕏：@yukinissie
 ©Uzabase Inc. All Rights Reserved.

3. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

4. 00
 本題の前にちょっとした余談 
 ©Uzabase Inc. All Rights Reserved.

5. 00
 AWS re:Invent 2024 に参加しました！ 
 AWS で1番大きな国際的技術イベント！ 毎年アメリカのラスベガスで行われ、世界 中のIT従事者が一挙に集まる。基調講演 や技術セッションなどで最新の技術や サービスを知ったり自身が興味を持つ技 術分野やサービスに関する知識を深める ことができる。人脈を広げる機会も多い し、それ以外にもお土産やダンスパー ティーなどお楽しみ要素がたくさん！ 
 ©Uzabase Inc. All Rights Reserved.

6. 00
 写真
 ©Uzabase Inc. All Rights Reserved.

7. 00
 【閑話休題】 
 ©Uzabase Inc. All Rights Reserved.

8. こつこつ育てる SLO
 NewsPicks, BDD Product Team, Software Engineer / ニッシー☆
 2024.12.10@株式会社ユーザベース×株式会社ZOZO×株式会社PR TIMES 3社合同フロントエンド勉強会 #zup_frontend

9. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

10. 00
 NewsPicks における働き方 -「全員プロダクト開発エンジニア」 
 「全員プロダクト開発エンジニア」 という価 値感のもと、さまざまな領域をオーバー ラップして活躍しているエンジニアが多数 在籍しています。エンジニアが個人の得意 領域にコミットすることはもちろん、 課題発 見から開発・運用まで 、チーム一丸となっ てフルサイクルで プロダクトに向き合って います。
 ©Uzabase Inc. All Rights Reserved.

11. 00
 NewsPicks における働き方 -「最高の開発者体験の追求」 
 私たちは、最高の開発者体験がユーザー価 値の向上に繋がる という考えのもと、常に開 発環境を改善 しています。安全かつ高速な デプロイ、待たない・困らない開発環境、一 貫した意思決定のためのオープンコミュニ ケーション、データの民主化 を推進していま す。また、開発者のワクワク感を醸成するた め、Kotlin推進やアーキテクチャの刷新に取 り組んでいます。
 ©Uzabase Inc. All Rights Reserved.

12. 01
 私の考える理想の開発現場が取る行動 
 私は『アジャイルソフトウェア開発宣言』と『アジャイル宣言の背後にある原則』の影響を受け ました。以下2つの引用は特に大事だと感じた部分です。
 > 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 > 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 よって、開発現場には以下の行動が求められていると考えます。
 「ユーザーに価値ある機能を継続的に爆速で届ける」 
 ©Uzabase Inc. All Rights Reserved.

13. 01
 「ユーザーに価値ある機能を継続的に爆速で届ける」ためには？ 
 「ユーザーの困りごとにすぐ気づき、対応する力」 が必要であると考えま す。
 オブザーバビリティがあるソフトウェアというのはコードを新しくデプロイし なくてもソフトウェアそのものの状態を計り知ることができる ものです が、オブザーバビティを高めることで「ユーザーに価値ある機能を継続 的に爆速で届ける」ための力が手に入れられるのではないか と考えま す。
 ©Uzabase Inc. All Rights Reserved.

14. 01
 当時の悩み。。。 
 弊社ではすでにオブザーバビリティの準備が備わっており、SLOの設定もさ れていたが以下の悩みがあった。
 • 開発に集中できないくらいSLOアラートがたくさん鳴っている。。
 • アラートを見てもどのユーザーがどのように困っているかよくわからな い。。
 • アラートの原因調査に割と工数を割くことに。。
 →ユーザー価値を産めないし、ユーザーの困りごとにすぐに気づけない！
 ©Uzabase Inc. All Rights Reserved.
 ※SLOとはサービスの信頼性を測定するための目標値のこと
15. 01
 悩んでいたときに読んだブログ 
 「SLO は、チームがやるべきことについて意味のある疑念を解決する便利 なツールとなります。「この課題には絶対取り組まなくては」 ということと、「こ の課題には取り組まなくていいかもしれない」 ということの間に線引きするこ とこそが目標 なのです。」 ↑Google Cloudのブログ『優れた SLO を策定するには : CRE が現場で学んだこと 』より ≒必要な時だけ、今、開発するか運用するかの意思決定がしやすくなる！ （意訳） →ユーザーに価値ある機能を継続的に爆速で届ける一助 にSLOの改善が あるのではないか？ ©Uzabase Inc. All Rights Reserved.

16. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

17. 02
 オブザーバビリティと SLOの関係（1/2）
 「従来のモニタリングのデータやメトリクスを使 用したSLOでは、根本的な問題を解決するた めのガイダンスが得られない ため、アクション 可能ではないアラートが作られてしまいます。 こ れに併せてオブザーバビリティのデータを SLO に使用することで、より正確で、デバッグしや すいものになります。 」
 書籍『オブザーバビリティ・エンジニアリング』（ p143）より引用
 ©Uzabase Inc. All Rights Reserved.

18. 02
 オブザーバビリティと SLOの関係（2/2）
 オブザーバビリティのデータを利用することで 正確でデバッグが容易な SLOを定めることできる。
 SLO自体はサービスの信頼性（可用性や応答速度）の目標値であり、その アラートは信頼性の悪化についていち早く伝えるものである。
 →オブザーバビリティのデータを利用した SLOを改善することでユーザー に価値ある機能を継続的に爆速で届ける一助になりそう！ 
 ©Uzabase Inc. All Rights Reserved.

19. 02
 ここまでのまとめ 
 • SLOを設定すれば必要な時だけ、今、開発するか運用するかの意思 決定がしやすくなる のでは？！（意訳） • オブザーバビリティーのデータを利用することで正確でデバッグ容易 なSLOを設定できる！ • 現状、SLOの設定周りで改善の余地を感じている。。 • SLOを改善すれば、ユーザーに価値ある機能を継続的に爆速で届け る一助に繋がるかも！ ©Uzabase Inc. All Rights Reserved.

20. 03
 SLOの改善事例とその学び 
 ©Uzabase Inc. All Rights Reserved.

21. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

22. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

23. 03
 SLOの名前から何の信頼性を見ているのか分からない 
 アラートが来てるけどSLOの名前から何が問題かすぐに分からない
 ©Uzabase Inc. All Rights Reserved.

24. 03
 改善①：SLOの名前を具体的にする 
 早く認知できるようにSLOの名前を具体的なものにしました。
 ©Uzabase Inc. All Rights Reserved.

25. 03
 改善②：CUJベースでもっと具体的な命名にする 
 CUJをSLOの名前にしてSLOの設定内容をカッコ内に記載するようにした
 ©Uzabase Inc. All Rights Reserved.
 「Latency - トップページ」 ↓ 「[Web] トップページを閲覧できる (Latency/28日間/99%/4000ms未満)」
26. 03
 SLOの定義について 
 「できるだけ定義を明快にするため に、SLO では計測の方法 と、計測値が適性である条 件を指定するべき です。」
 書籍『SRE サイトリライアビリティエンジニアリング』（ p46）より引用
 ©Uzabase Inc. All Rights Reserved.

27. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

28. 03
 SLIが冗長で無駄なアラートが多く、認知負荷になっていた 
 Web版のNewsPicksでは複数システムで成り立っている
 ©Uzabase Inc. All Rights Reserved.

29. 03
 SLIが冗長で無駄なアラートが多く、認知負荷になっていた 
 Web版のNewsPicksでは複数システムで成り立っている
 全てのエンドポイントをSLIとして見ていた
 よってSLOとそのアラートがたくさんあった
 ©Uzabase Inc. All Rights Reserved.

30. 03
 改善：分散トレースの起点のみ見るように 
 分散トレースを利用することでエラー検知から原因となるエラーまで追うこと ができるので始まり以外はSLIとして扱わないようにした。
 そうすることで冗長なアラートを廃止できた。
 ©Uzabase Inc. All Rights Reserved.
 例えばここだけを見るように
31. 03
 改善：分散トレースの起点のみ見るように 
 分散トレースを利用することでエラー検知から原因となるエラーまで追うこと ができるので始まり以外はSLIとして扱わないようにした。
 そうすることで冗長なアラートを廃止できた。
 ©Uzabase Inc. All Rights Reserved.
 分散トレースでエラーを追う エラー 直接 原因 アラート通知 オブザーバビリティ最 高！ 開発者
32. 1. 私の考える理想の開発現場が取る行動 
 2. オブザーバビリティと SLOの関係
 3. SLOの改善事例とその学び 
 3.1. SLOの名前から何の信頼性を見ているのか分からない 
 3.2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 
 3.3. SLOを振り返らず初期の目標をずっと見ていた 
 4. まとめ
 00
 目次
 ©Uzabase Inc. All Rights Reserved.

33. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 SLO導入当時は目標に達成していなかったのでREDな日々でした。
 ©Uzabase Inc. All Rights Reserved.
 レイテンシー目標が 赤い、赤いな〜〜 週次で改善だ！ SLOダッシュボード
34. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 徐々に改善されていきました！（いい話）
 ©Uzabase Inc. All Rights Reserved.
 赤がほとんどなくなった ぞ！いいぞ〜〜 SLOダッシュボード
35. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 ついに全部GREENになりました！めでたしめでたし
 ©Uzabase Inc. All Rights Reserved.
 ついに全て緑に！ オールクリア！ SLOダッシュボード
36. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 めでたしめでたし、、
 ©Uzabase Inc. All Rights Reserved.
 ばんざーい！ SLOダッシュボード
37. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 めでたしめでたし？？
 ©Uzabase Inc. All Rights Reserved.
 ばんざーい！ SLOダッシュボード Few months later…
38. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 ただ緑色の窓を見ることが常態化してしまった！
 ©Uzabase Inc. All Rights Reserved.
 今日もGREENだね〜〜 SLOダッシュボード
39. 03
 SLOを振り返らず初期の目標をずっと見ていた 
 開発を進めている限り、同じ指標、目標値を追い続ければよいとは限りま せん。
 なぜなら、ある時最適だった SLOも、時が進めば意思決定に必要な情報が 提供されていない状態にだってなりえます。 
 →指標をアップデートして、本当に必要な情報を観測しよう。
 （すみません、このページは全部持論です）
 ©Uzabase Inc. All Rights Reserved.

40. 03
 改善：月次で SLOチェックポイントを行いました 
 チームみんなで集まって、SLOの妥当性について話し合う場を作りました。 →SLOそのものの知識共有やSLO改善の議論の場になりました。
 ©Uzabase Inc. All Rights Reserved.

41. 04
 まとめ
 ©Uzabase Inc. All Rights Reserved.

42. 04
 まとめ
 • SLOを設定すれば必要な時だけ、今、開発するか運用するかの意思 決定がしやすくなるのでは？！ （意訳） • オブザーバビリティーのデータを利用することで 正確でデバッグ容易な SLOを設定できる！ • わかりやすい SLO名、分散トレースを活用した SLOの数の削減 、定期 的なメンテナンス の実行でSLOを改善！ • SLOを改善すれば、ユーザーに価値ある機能を継続的に爆速で届け る一助に繋がるかも！ ©Uzabase Inc. All Rights Reserved.

43. SLOをこつこつ育てて 
 ユーザーの理想を叶えましょう！ 
 ©Uzabase Inc. All Rights Reserved.

44. ご清聴ありがとうございました！ 
 ©Uzabase Inc. All Rights Reserved.

45. 02
 参考文献
 • Google Cloudのブログ『優れた SLO を策定するには : CRE が現場で学んだこと 』 • 書籍『オブザーバビリティ・エンジニアリング 』
 • 書籍『SRE サイトリライアビリティエンジニアリング 』
 • 書籍『サイトリライアビリティワークブック 』
 • 書籍『入門 監視』
 • 書籍『アジャイルサムライ――達人開発者への道』
 • 書籍『LeanとDevOpsの科学』
 ©Uzabase Inc. All Rights Reserved.