Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発組織全体で意識するSLI/SLOを実装している話
Search
Kuniaki Moriya
March 20, 2025
Technology
1
1.1k
開発組織全体で意識するSLI/SLOを実装している話
2025.03.20
信頼性向上の第一歩!~SLI/SLO策定までの取り組みと運用事例~
https://findy.connpass.com/event/345990/
Kuniaki Moriya
March 20, 2025
Tweet
Share
More Decks by Kuniaki Moriya
See All by Kuniaki Moriya
20241218_今年はSLI/SLOの導入を頑張ってました!
zepprix
0
420
AWSインフラ一大刷新〜幸せな運用を目指して〜
zepprix
0
75
sre_techmeetup_moriya.pdf
zepprix
0
930
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.6k
Other Decks in Technology
See All in Technology
GraphQLを活用したリアーキテクチャに対応するSLI/Oの再設計
coconala_engineer
0
190
地味にいろいろあった! 2025春のAmazon Bedrockアップデートおさらい
minorun365
PRO
2
550
勝手に!深堀り!Cloud Run worker pools / Deep dive Cloud Run worker pools
iselegant
4
620
ドキュメント管理の理想と現実
kazuhe
3
310
ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか / What can a single engineer do to connect business, design, and engineering?
kaminashi
2
860
AI 코딩 에이전트 더 똑똑하게 쓰기
nacyot
0
460
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
150
Compose におけるパスワード自動入力とパスワード保存
tonionagauzzi
0
190
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
560
更新系と状態
uhyo
8
2.2k
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
380
AIと共に乗り越える、 入社後2ヶ月の苦労と学習の軌跡
sai_kaneko
0
190
Featured
See All Featured
Writing Fast Ruby
sferik
628
61k
How to Think Like a Performance Engineer
csswizardry
23
1.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Speed Design
sergeychernyshev
29
920
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
820
Automating Front-end Workflow
addyosmani
1370
200k
Designing for Performance
lara
608
69k
Why Our Code Smells
bkeepers
PRO
336
57k
How GitHub (no longer) Works
holman
314
140k
GitHub's CSS Performance
jonrohan
1030
460k
Designing for humans not robots
tammielis
253
25k
Transcript
開発組織全体で意識するSLI/SLOを実装している話 2025.03.20 信頼性向上の第一歩!~SLI/SLO策定までの取り組みと運用事例~
シンプルフォーム株式会社 自己紹介 2 守屋邦昭(@Zepprix) 経歴 ソシャゲのサーバーエンジニア ↓ 不動産テックの SRE ↓
2024年2月にシンプルフォーム株式会社に入社 金融機関などで「法人の審査業務」に利用できる SaaS の開発・運用 SRE Magazine 004 号に寄稿したり、SRE Kaigi 2025 の会場スタッフをやったりもしてます シンプルフォーム株式会社の一人目の SRE インフラチームと開発チームを兼任 Embedded SRE として開発や信頼性向上活動をやってます
シンプルフォーム株式会社 金融エンタープライズに特化した 法人調査の自動化システム 3
シンプルフォーム株式会社 本日お話すること 4 開発組織全体で意識する SLI/SLO 導入に至る背景 検討プロセス 現状と今後の課題
シンプルフォーム株式会社 背景 5 各種メトリクスを可視化したダッシュボードが整備されており、DevOps チームが毎朝確認している 監視も整備されており、ユーザーから問い合わせがある前に障害を先に社内で検知できるケースが多い 障害発生した際には、エンジニアチームと CS が迅速に連携できている 当初は不要な気がしていた
New Relic ダッシュボード すでにいい感じに運用できているし、 無理して SLO を設定しなくてもよいのでは?
シンプルフォーム株式会社 一転、導入する機運が高まった理由 6 プロダクト毎にチームが厳密に分かれているわけではない 基盤プロダクトに対して複数の開発チームが異なる役割で開発や運用に関わる プロダクト間のデータ連携や API 連携もある プロダクトとエンジニア組織構成 データ収集オペレーション
R&D DevOps 基盤プロダクトの開発・運用 SimpleCheck SimpleMonitor 基盤プロダクト 新技術を活用した機能開発 オペレーションの自動化・効率化を担 う社内システムの開発 データ収集用 社内システム データ連携 QA インフラ
シンプルフォーム株式会社 一転、導入する機運が高まった理由 7 DevOps データ収集オペレーション 各チームの価値観の違い R&D 新機能を早くリ リースしたい! 手動オペレーション
を改善したい! 同じシステムを触っていても、チーム毎に責任領域が異なるため価値観は異なる システム障害への感度など可用性に対する意識は DevOps チームが特に高い エンドユーザー 可用性を担保したい!
シンプルフォーム株式会社 データ収集オペレーション 一転、導入する機運が高まった理由 8 DevOps それも大事だけ ど他にもやるこ とが.... DevOps チーム目線だと他チームが運用している連携用
API の可用性やデータ精度が システム全体の品質担保のネックになっているという意識が芽生えてしまう 一方で他チームにも優先したい課題が多くある 連携用 API の可用 性やデータ精度が 気になる... 各チームの価値観の違い R&D
シンプルフォーム株式会社 9 一転、導入する機運が高まった理由 SLI/SLOへの期待 xxチーム xxチーム xxチーム xxチーム xxチーム 守るべき水準
(SLO) 品質や性能等に対する意識がチーム毎に異なる現状がある 意識を引き上げる必要もあるが同時に過剰に安全側に倒しすぎて生産性を落とすのもよくない どこまで守れば良いのかの水準を定めて「攻めと守りのバランス」を取れるようにしたい
シンプルフォーム株式会社 10 一転、導入する機運が高まった理由 DevOps データ収集オペレーション R&D SLI/SLO 委員会を結成 CTO +
各開発チームに Embedded されているインフラエンジニアメンバーで委員会を結成 エンドユーザー(顧客)の目線も入れるため CS メンバーにも入ってもらう 開発組織全体で意識する SLI/SLO の検討を開始! CTO CS
シンプルフォーム株式会社 11 どのようなプロセスで進めたか 委員会メンバーが各開発チームでファシリ 「我々が守るべき品質とは?」など伝わりやすい表現で進める 意見が発散しすぎることを防ぐために最低限のルールは決めておく 各開発チームで SLI 候補をブレスト あるチームで実施したブレストの様子
ブレストのルール 計測可能であること → 抽象的過ぎても後でまとめられない 達成目標(SLO)を設定する前提で指標を考えること → 改善していく価値がありそうな指標をイメージしてもらう
シンプルフォーム株式会社 どのようなプロセスで進めたか SLI/SLO を設定する目的を早い段階でドキュメント化! 数ある SLI 案に優先度をつけていくための判断基準 やりたいことが発散しすぎる事態を防ぐ (例) 経営層への説明資料として使う、顧客に
SLA として開示する ブレスト結果をまとめるための軸を定めておく 開発組織全体で共通課題として意識する → SLA までは一旦いかない 継続的な運用改善により顧客からのシステムへの信頼を維持する → 運用改善に繋がりそうな SLI 候補に絞っていくために役立った 12 設定した目的
シンプルフォーム株式会社 結果 SLIとして計測する指標が決定!(昨年12月頃) 13 委員会結成から 2ヶ月程度でなんとかここまでこれた...!
シンプルフォーム株式会社 よかったこと 指標について考える中で現状の運用の課題が炙り出された あえて大勢の意見を集約する形を取ったことでより本質的な指標を定義できた 障害対応時にエンジニアが挙げる一次報告と CS がほしい情報に差分があるケースがあった ポストモーテムで「もっと早く検知できなかったのか?」という観点も重要!という意見が出てきた 当初、守屋は API
レイテンシやエラー率を計測することをイメージしていたが、 可用性だけではなくデータ精度やセキュリティなど重要度の高い指標が意見として上がってきた (例) 脆弱性のあるライブラリの混入率、データ収集からユーザー提供へのリードタイム(データの鮮度) ➢ SLI/SLO の検討プロセス自体が現状の運用について見直す契機となった ➢ 社内に公開した際により皆の納得感が得られる SLI を定義できた 14
シンプルフォーム株式会社 After story 現状と今後の課題 15 SLI/SLO ダッシュボード 「脆弱性のあるライブラリの混入率」など一部の SLI を開発組織の四半期
OKR として設定! 委員会の定例を月一で開催し、ダッシュボードを見ながら現状の把握や改善施策の議論を実施中 Good SLI/SLO 検討過程で明らかになったインシデントレスポンスな どの課題にも、改善を進行中! 一部の指標は計測環境の準備が必要で、まだ運用開始できてい ない 委員会メンバーだけではなく、全開発チームで運用を支える文 化づくりをしていきたい(ex: 開発チーム個別で指標を定義) Challenge
シンプルフォーム株式会社 ご清聴ありがとうございました! おわり 16