3.2K Views
September 02, 24
スライド概要
2024年08月28日に開催された『フロントエンド・オブザーバビリティ Meetup - UB Tech vol.17』で登壇した際の資料です。 #frontend_o11y
https://uzabase-tech.connpass.com/event/324317/
ソーシャル経済メディア「NewsPicks」にてソフトウェアエンジニアとして活動中。ジンギスカン🍖とビール🍺が好き。
こつこつ育てる 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.
01 当時の悩み。。。 ● 開発に集中できないくらいSLOアラートが頻度高めに鳴っていた。。 ● アラートを見るもなんの信頼性が損なわれているかよくわからない。。 ● アラートの原因調査に割と工数を割くことに。。 →ユーザー価値を産めないし、ユーザーの困りごとにすぐに気づけない! ※SLOとはサービスの信頼性を測定するための目標値のこと ©Uzabase Inc. All Rights Reserved.
01 悩んでいたときに読んだブログ 「SLO は、チームがやるべきことについて意味のある疑念を解決する便利 なツール となります。「この課題には絶対取り組まなくては」 ということと、「こ の課題には取り組まなくていいかもしれない」 ということの間に線引きするこ とこそが目標 なのです。」 ↑Google Cloudのブログ『優れた SLO を策定するには : CRE が現場で学んだこと』より ≒必要な時だけ、今、開発するか運用するかの意思決定がしやすくなる! (意訳) →ユーザーに価値ある機能を継続的に爆速で届ける一助 にSLOの改善が あるのではないか? ©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.
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.