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
450
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
83
sre_techmeetup_moriya.pdf
zepprix
0
950
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.6k
Other Decks in Technology
See All in Technology
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
5
440
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
210
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
150
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
生成AIでwebアプリケーションを作ってみた
tajimon
2
150
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
170
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
Model Mondays S2E02: Model Context Protocol
nitya
0
220
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
730
~宇宙最速~2025年AWS Summit レポート
satodesu
1
1.8k
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
3
120
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
270
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.3k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Music & Morning Musume
bryan
46
6.6k
Building Applications with DynamoDB
mza
95
6.5k
Bash Introduction
62gerente
614
210k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Done Done
chrislema
184
16k
How GitHub (no longer) Works
holman
314
140k
Building an army of robots
kneath
306
45k
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