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
470
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
89
sre_techmeetup_moriya.pdf
zepprix
0
970
Docker & ECS で構築するゲームアプリサーバーの話
zepprix
0
2.7k
Other Decks in Technology
See All in Technology
[MIRU2025]Preference Optimization for Multimodal Large Language Models for Image Captioning Tasks
keio_smilab
PRO
0
100
「手を動かした者だけが世界を変える」ソフトウェア開発だけではない開発者人生
onishi
15
7.6k
Kiro Hookを Terraformで検証
ao_inoue
0
130
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
ojima_h
4
520
ObsidianをLLM時代のナレッジベースに! クリッピング→Markdown→CLI連携の実践
srvhat09
7
9.7k
経理出身PdMがAIプロダクト開発を_ハンズオンで学んだ話.pdf
shunsukenarita
1
230
今日からあなたもGeminiを好きになる
subaruhello
1
650
隙間時間で爆速開発! Claude Code × Vibe Coding で作るマニュアル自動生成サービス
akitomonam
2
200
PdM業務における使い分け
shinshiro
0
670
Shadow DOMとセキュリティ - 光と影の境界を探る / Shibuya.XSS techtalk #13
masatokinugawa
0
310
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
12
2.1k
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.8k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Unsuck your backbone
ammeep
671
58k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Typedesign – Prime Four
hannesfritz
42
2.7k
Site-Speed That Sticks
csswizardry
10
720
Designing for Performance
lara
610
69k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
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