こつこつ育てるSLO

こつこつ育てる SLO NewsPicks, Platform Team, Software Engineer / ニッシー☆ 2024.08.28@フロントエンド・オブザーバビリティ Meetup - UB Tech vol.17 #frontend_o11y

00 自己紹介 ニッシー☆ NewsPicks, Platform Team, Software Engineer 23卒。学生時代にハッカソンでクラウドを活用したサービス開発をしまくっ ていたらいつの間にかアジャイルやDevOpsの脳みそになってしまってい ました。。ジンギスカン🍖とビール🍺が好きです。 𝕏：@yukinissie ©Uzabase Inc. All Rights Reserved.

00 目次 ©Uzabase Inc. All Rights Reserved.

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

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

00 本イベントに参加されているみなさんの興味（ 𝕏より） ● オブザーバビリティ ● プロダクトエンジニア ● SRE ● 開発生産性 ● ソフトウェアエンジニアリング ● 4keys ● OpenTelemetry ● 開発者体験 ● Observability SaaS ● 開発組織の設計 ©Uzabase Inc. All Rights Reserved.

00 本イベントに参加されているみなさんのおおよその職種（ 𝕏より） ©Uzabase Inc. All Rights Reserved.

00 参加者の共通点は・・・？ ソフトウェアで素早く継続的に ユーザーに価値を届けたいエンジニア！ ©Uzabase Inc. All Rights Reserved.

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

こつこつ育てる SLO NewsPicks, Platform Team, Software Engineer / ニッシー☆ 2024.08.28@フロントエンド・オブザーバビリティ Meetup - UB Tech vol.17 #frontend_o11y

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

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

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

01 私が思う理想の開発現場 私は『アジャイルソフトウェア開発宣言 』と『アジャイル宣言の背後にある原則 』の影響を受け、開 発現場には以下が求められていると考えます。 「ユーザーに価値ある機能を継続的に爆速で届ける」 これを叶えるためには ユーザーの困りごとにすぐ気づき、対応する 必要があると考えます。 ©Uzabase Inc. All Rights Reserved.

• https://agilemanifesto.org/iso/ja/manifesto.html
• https://agilemanifesto.org/iso/ja/principles.html

01 当時の悩み。。。 ● 開発に集中できないくらいSLOアラートが頻度高めに鳴っていた。。 ● アラートを見るもなんの信頼性が損なわれているかよくわからない。。 ● アラートの原因調査に割と工数を割くことに。。 →ユーザー価値を産めないし、ユーザーの困りごとにすぐに気づけない！ ※SLOとはサービスの信頼性を測定するための目標値のこと ©Uzabase Inc. All Rights Reserved.

01 悩んでいたときに読んだブログ 「SLO は、チームがやるべきことについて意味のある疑念を解決する便利 なツール となります。「この課題には絶対取り組まなくては」 ということと、「こ の課題には取り組まなくていいかもしれない」 ということの間に線引きするこ とこそが目標 なのです。」 ↑Google Cloudのブログ『優れた SLO を策定するには : CRE が現場で学んだこと』より ≒必要な時だけ、今、開発するか運用するかの意思決定がしやすくなる！ （意訳） →ユーザーに価値ある機能を継続的に爆速で届ける一助 にSLOの改善が あるのではないか？ ©Uzabase Inc. All Rights Reserved.

• https://cloud.google.com/blog/ja/products/gcp/building-good-slos-cre-life-lessons#:~:text=SLO は、チームがやるべきことについて意味のある疑念を解決する便利なツールとなります。「この課題には絶対取り組まなくては」ということと、「この課題には取り組まなくていいかもしれない」ということの間に線引きすることこそが目標なのです。

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

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

02 オブザーバビリティと SLOの関係（ 2/2） オブザーバビリティのデータを利用することで 正確でデバッグが容易な SLOを定めることできる。 →ユーザーに価値ある機能を継続的に爆速で届ける一助になりそう！ ©Uzabase Inc. All Rights Reserved.

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

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

03 SLOの改善事例とその学び 1. SLOの名前から何の信頼性を見ているのか分からない 2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 3. SLOを振り返らず初期の目標をずっと見ていた ©Uzabase Inc. All Rights Reserved.

03 SLOの改善事例とその学び 1. SLOの名前から何の信頼性を見ているのか分からない 2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 3. SLOを振り返らず初期の目標をずっと見ていた ©Uzabase Inc. All Rights Reserved.

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

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

03 改善②： CUJベースでもっと具体的な命名にする CUJをSLOの名前にしてSLOの設定内容をカッコ内に記載するようにした 「Latency - トップページ」 ↓ 「[Web] トップページを閲覧できる (Latency/28日間/99%/4000ms未満)」 ©Uzabase Inc. All Rights Reserved.

03 SLOの定義について 「できるだけ定義を明快にするため に、SLO では計測の方法 と、計測値が適性である条 件を指定するべき です。」 書籍『SRE サイトリライアビリティエンジニアリング』（p46）より引用 ©Uzabase Inc. All Rights Reserved.

03 SLOの改善事例とその学び 1. SLOの名前から何の信頼性を見ているのか分からない 2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 3. SLOを振り返らず初期の目標をずっと見ていた ©Uzabase Inc. All Rights Reserved.

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

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

03 改善：分散トレースの起点のみ見るように 分散トレースを利用することでエラー検知から原因となるエラーまで追うこと ができるので始まり以外はSLIとして扱わないようにした。 そうすることで冗長なアラートを廃止できた。 例えばここだけを見るように ©Uzabase Inc. All Rights Reserved.

03 改善：分散トレースの起点のみ見るように 分散トレースを利用することでエラー検知から原因となるエラーまで追うこと ができるので始まり以外はSLIとして扱わないようにした。 そうすることで冗長なアラートを廃止できた。 エラー オブザーバビリティ最 高！ アラート通知 分散トレースでエラーを追う ©Uzabase Inc. All Rights Reserved. 開発者 直接 原因

03 SLOの改善事例とその学び 1. SLOの名前から何の信頼性を見ているのか分からない 2. SLIが冗長で無駄なアラートが多く認知負荷になっていた 3. SLOを振り返らず初期の目標をずっと見ていた ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた SLO導入当時は目標に達成していなかったのでREDな日々でした。 レイテンシー目標が 赤い、赤いな〜〜 週次で改善だ！ SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた 徐々に改善されていきました！（いい話） 赤がほとんどなくなった ぞ！いいぞ〜〜 SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた ついに全部GREENになりました！めでたしめでたし ついに全て緑に！ オールクリア！ SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた めでたしめでたし、、 ばんざーい！ SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた めでたしめでたし？？ ばんざーい！ Few months later… SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた ただ緑色の窓を見ることが常態化してしまった！ 今日もGREENだね〜〜 SLOダッシュボード ©Uzabase Inc. All Rights Reserved.

03 SLOを振り返らず初期の目標をずっと見ていた 開発を進めている限り、同じ指標、目標値を追い続ければよいとは限りま せん。 なぜなら、ある時最適だった SLOも、時が進めば意思決定に必要な情報が 提供されていない状態にだってなりえます。 →指標をアップデートして、本当に必要な情報を観測しよう。 （すみません、このページは全部自論です） ©Uzabase Inc. All Rights Reserved.

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

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

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

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

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

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

• https://cloud.google.com/blog/ja/products/gcp/building-good-slos-cre-life-lessons#:~:text=SLO は、チームがやるべきことについて意味のある疑念を解決する便利なツールとなります。「この課題には絶対取り組まなくては」ということと、「この課題には取り組まなくていいかもしれない」ということの間に線引きすることこそが目標なのです。