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.3k
開発組織全体で意識する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
API基盤をAPI Gateway+LambdaからECSに移行した舞台裏
zepprix
0
52
20241218_今年はSLI/SLOの導入を頑張ってました!
zepprix
0
520
AWSインフラ一大刷新〜幸せな運用を目指して〜
zepprix
0
95
sre_techmeetup_moriya.pdf
zepprix
0
1k
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.7k
Other Decks in Technology
See All in Technology
PLaMoの事後学習を支える技術 / PFN LLMセミナー
pfn
PRO
9
4k
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
160
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
1.1k
プロポーザルのコツ ~ Kaigi on Rails 2025 初参加で3名の登壇を実現 ~
naro143
1
200
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
5
3.8k
社内お問い合わせBotの仕組みと学び
nish01
1
530
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
4
300
Large Vision Language Modelを用いた 文書画像データ化作業自動化の検証、運用 / shibuya_AI
sansan_randd
0
130
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
240
JAZUG 15周年記念 × JAT「AI Agent開発者必見:"今"のOracle技術で拡張するAzure × OCIの共存アーキテクチャ」
shisyu_gaku
0
140
Where will it converge?
ibknadedeji
0
200
Wasmのエコシステムを使った ツール作成方法
askua
0
100
Featured
See All Featured
Done Done
chrislema
185
16k
KATA
mclloyd
32
15k
Why Our Code Smells
bkeepers
PRO
339
57k
Automating Front-end Workflow
addyosmani
1371
200k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
19
1.2k
Music & Morning Musume
bryan
46
6.8k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
How to Think Like a Performance Engineer
csswizardry
27
2k
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