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.2k
開発組織全体で意識する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
460
AWSインフラ一大刷新〜幸せな運用を目指して〜
zepprix
0
87
sre_techmeetup_moriya.pdf
zepprix
0
960
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.7k
Other Decks in Technology
See All in Technology
United™️ Airlines®️ Customer®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedguide
0
780
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
640
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
220
ロールが細分化された組織でSREは何をするか?
tgidgd
1
200
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
150
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
280
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
290
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
240
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
180
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
2
220
衛星運用をソフトウェアエンジニアに依頼したときにできあがるもの
sankichi92
1
230
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
100
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Rails Girls Zürich Keynote
gr2m
95
14k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Speed Design
sergeychernyshev
32
1k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Faster Mobile Websites
deanohume
307
31k
Embracing the Ebb and Flow
colly
86
4.7k
Gamification - CAS2011
davidbonilla
81
5.4k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Music & Morning Musume
bryan
46
6.7k
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