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
20241218_今年はSLI/SLOの導入を頑張ってました!
Search
Kuniaki Moriya
December 18, 2024
Technology
0
460
20241218_今年はSLI/SLOの導入を頑張ってました!
渋谷でSRE大忘年会 LT 資料
Kuniaki Moriya
December 18, 2024
Tweet
Share
More Decks by Kuniaki Moriya
See All by Kuniaki Moriya
開発組織全体で意識するSLI/SLOを実装している話
zepprix
1
1.2k
AWSインフラ一大刷新〜幸せな運用を目指して〜
zepprix
0
85
sre_techmeetup_moriya.pdf
zepprix
0
960
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.7k
Other Decks in Technology
See All in Technology
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
960
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
280
怖くない!はじめてのClaude Code
shinya337
0
400
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
120
MobileActOsaka_250704.pdf
akaitadaaki
0
130
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
1
230
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
150
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
280
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
240
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
Model Mondays S2E04: AI Developer Experiences
nitya
0
150
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Facilitating Awesome Meetings
lara
54
6.4k
Six Lessons from altMBA
skipperchong
28
3.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
How to train your dragon (web standard)
notwaldorf
95
6.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Scaling GitHub
holman
460
140k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
RailsConf 2023
tenderlove
30
1.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Docker and Python
trallard
44
3.5k
Transcript
今年はSLI/SLOの導入を頑張ってました! 2024.12.18 渋谷でSRE忘年会
シンプルフォーム株式会社 自己紹介 2 守屋邦昭(@Zepprix) 経歴 ソシャゲのサーバーエンジニア ↓ 不動産テックの SRE ↓
2024年2月にシンプルフォーム株式会社に入社 金融機関などで「法人の審査業務」等に利用できる SaaS の開発・運用 SRE Magazine 004 号に 寄稿させていただきました! シンプルフォーム株式会社の一人目の SRE インフラチームと開発チームを兼任 Embedded SRE として開発や信頼性向上活動をやってます
シンプルフォーム株式会社 金融エンタープライズに特化した 法人調査の自動化システム 3
シンプルフォーム株式会社 今年やったこと 4 開発組織全体で意識する SLI/SLO の導入
シンプルフォーム株式会社 背景 5 各種メトリクスを可視化するダッシュボードが整備されており、DevOps チームが毎朝チェックしている 監視も整備されており、ユーザーから問い合わせが来る前に障害を社内で検知できているケースが多い 障害発生時にはエンジニアと CS が迅速に連携できている 当初は不要な気がしていた
New Relic ダッシュボード すでにいい感じに運用できているし、 無理して SLO を設定しなくてもよいのでは?
シンプルフォーム株式会社 一転、導入する機運が高まった理由 6 複数チームに分かれているが、プロダクト数に合わせて分割されているわけではない 基盤プロダクト「SimpleCheck」など開発・運用時に複数チームが触る領域がいくつか存在する プロダクト間の API 連携もあり SimpleCheck SimpleMonitor
新規プロダクト DevOps T R&D 新規プロダクト T データ収集の自動化・効率化 T QA T インフラ T データ収集用 社内システム プロダクトとエンジニア組織構成
シンプルフォーム株式会社 一転、導入する機運が高まった理由 7 DevOps T データ収集の自動化・効率化 T 各チームの価値観の違い R&D 新規プロダクト
T 新規プロダクトを 早くリリースした い! 手動オペレーション を改善したい! 同じシステムを触っていても、チーム毎に責任領域が異なるため価値観は異なる システム障害への感度など可用性に対する意識は DevOps チームが特に高い エンドユーザー 可用性を担保したい!
シンプルフォーム株式会社 一転、導入する機運が高まった理由 8 DevOps T データ収集の自動化・効率化 T R&D 新規プロダクト T
それも大事だけ ど他にもやるこ とが.... DevOps チーム目線だと他チームが運用している連携用 API の可用性やデータ精度が システム全体の品質担保のネックになっているという意識が芽生えてしまう 一方で他チームにも優先したい課題が多くある 連携用 API の可用 性やデータ精度が 気になる... 各チームの価値観の違い
シンプルフォーム株式会社 9 一転、導入する機運が高まった理由 SLI/SLOへの期待 xxチーム xxチーム xxチーム xxチーム xxチーム 守るべき水準
(SLO) 品質や性能等に対する意識がチーム毎に異なる現状がある 意識を引き上げる必要もあるが同時に過剰に安全側に倒しすぎて生産性を落とすのもよくない どこまで守れば良いのかの水準を定めて「攻めと守りのバランス」を取れるようにしたい
シンプルフォーム株式会社 10 一転、導入する機運が高まった理由 DevOps T データ収集の自動化・効率化 T R&D 新規プロダクト T
SLI/SLO策定委員会を結成 各開発チームからの有志 + CTO で構成 エンドユーザー(顧客)の目線も入れるため CS メンバーにも入ってもらう 開発組織全体で意識する SLI/SLO の検討を開始! CTO CS
シンプルフォーム株式会社 11 どのようなプロセスで進めたか 委員会メンバーが各チームでファシリ 「我々が守るべき品質とは?」など伝わりやすい表現で進める 意見が発散しすぎることを防ぐために最低限のルールは決めておく 各開発チームで SLI 候補をブレスト あるチームで実施したブレストの様子
ブレストのルール 計測可能であること → 抽象的過ぎても後でまとめられない 達成目標(SLO)を設定する前提で指標を考えること → 改善していく価値がありそうな指標をイメージしてもらう
シンプルフォーム株式会社 どのようなプロセスで進めたか SLI/SLO を設定する目的を早い段階でドキュメント化! 数ある SLI 案に優先度をつけていくための判断基準 やりたいことが発散しすぎる事態を防ぐ (例) 経営層への説明資料として使う、顧客に
SLA として開示する ブレスト結果をまとめるための軸を定めておく 開発組織全体で共通課題として意識する → SLA までは一旦いかない 継続的な運用改善により顧客からのシステムへの信頼を維持する → 運用改善に繋がりそうな SLI 候補に絞っていくために役立った 12 設定した目的
シンプルフォーム株式会社 結果 SLIとして計測する指標が決定! 13 委員会結成から 2ヶ月程度でなんとかここまでこれた....
シンプルフォーム株式会社 よかったこと 指標について考える中で現状の運用の課題が炙り出された あえて大勢の意見を集約する形を取ったことでより本質的な指標を定義できた 障害対応時にエンジニアが挙げる一次報告と CS がほしい情報に差分があるケースがあった ポストモーテムで「もっと早く検知できなかったのか?」という観点も重要!という意見が出てきた その結果、SLI/SLO とは別にインシデントレスポンスやポストモーテムの改善がスタートした
当初、守屋は API レイテンシやエラー率を計測することをイメージしていたが、 可用性だけではなくデータ精度やセキュリティなど重要度の高い指標が意見として上がってきた (例) 脆弱性のあるライブラリの混入率 ➢ SLI/SLO の検討プロセス自体が現状の運用について見直す契機となった ➢ 社内に公開した際により皆の納得感が得られる SLI を定義できた 14
シンプルフォーム株式会社 来年やりたいこと 現在は SLI モニタリングできるように計測や可視化(ダッシュボード)の仕組みを実装中 しばらく計測した実績値から SLO を順次定義していく予定 運用イメージ SLI/SLO
をいい感じに運用する エンジニア定例でダッシュボードを確認し、異常がある場合は委員会から担当チームに対応を依頼 月一で委員会の定例 MTG を行い各指標のチューニングや改善施策を議論 エラーバジェット整備などは今後検討 15
シンプルフォーム株式会社 ご清聴ありがとうございました! おわり 16