こつこつ育てるSLO

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

01  当時の悩み。。。   弊社ではすでにオブザーバビリティの準備が備わっており、SLOの設定もされていたが以下の悩みがあった。  ● 開発に集中できないくらいSLOアラートがたくさん鳴っている。。  ● アラートを見てもどのユーザーがどのように困っているかよくわからない。。  ● アラートの原因調査に割と工数を割くことに。。  →ユーザー価値を産めないし、ユーザーの困りごとにすぐに気づけない！  ©Uzabase Inc. All Rights Reserved.  ※SLOとはサービスの信頼性を測定するための目標値のこと

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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