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
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
Search
sato-s
October 20, 2025
Technology
0
560
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
sato-s
October 20, 2025
Tweet
Share
More Decks by sato-s
See All by sato-s
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
8
4.8k
ハードルゼロLT発表資料
satos
0
5.3k
Other Decks in Technology
See All in Technology
ググるより、AIに聞こう - Don’t Google it, ask AI
oikon48
0
890
探求の技術
azukiazusa1
7
2.2k
Redux → Recoil → Zustand → useSyncExternalStore: 状態管理の10年とReact本来の姿
zozotech
PRO
15
7.9k
X-Ray SDKとDaemonのサポート終了と移⾏ガイド
o11yfes2023
0
110
【M3】攻めのセキュリティの実践!プロアクティブなセキュリティ対策の実践事例
axelmizu
0
150
Black Hat USA 2025 Recap ~ クラウドセキュリティ編 ~
kyohmizu
0
540
Flutter DevToolsで発見! 本番アプリのパフォーマンス問題と改善の実践
goto_tsl
1
620
Flutterで実装する実践的な攻撃対策とセキュリティ向上
fujikinaga
2
410
エンタープライズ企業における開発効率化のためのコンテキスト設計とその活用
sergicalsix
1
400
Post-AIコーディング時代のエンジニア生存戦略
shinoyu
0
280
Amazon ECS デプロイツール ecspresso の開発を支える「正しい抽象化」の探求 / YAPC::Fukuoka 2025
fujiwara3
12
3k
米軍Platform One / Black Pearlに学ぶ極限環境DevSecOps
jyoshise
1
290
Featured
See All Featured
Facilitating Awesome Meetings
lara
57
6.6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
192
56k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
The Invisible Side of Design
smashingmag
302
51k
Unsuck your backbone
ammeep
671
58k
Thoughts on Productivity
jonyablonski
73
4.9k
4 Signs Your Business is Dying
shpigford
186
22k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
24
1.6k
RailsConf 2023
tenderlove
30
1.3k
Transcript
© SmartHR, Inc. サービスレベル⽬標による 信頼性への投資最適化 齋藤 諒⼀ SmartHR VP of
Engineering 2025/10/15 画像を置換 画像を置換 佐藤 沢彦 SmartHR SRE
None
None
None
今⽇のお話 ✨“信頼性” 5
💡信頼性とは? “求められる機能を、定められた条件の下で、定め られた期間にわたり、障害を起こすことなく実⾏す る確率”[1] 6 [1] Betsy Beyer、 Chris Jones
Jennifer Petoff、 Niall Richard Murphy編/澤田武男、関根達夫、細川一茂、矢吹大輔監訳/ Sky株式会社 玉川竜司訳 『SRE サイトリライ ア ビリティエンジニアリング – Google の信頼性を支えるエンジニアリングチーム』株式会社オーム社、 2017年、p.xiv 「期待通りに使える」
信頼性が低い状態とは? ❏ 遅い ❏ 動かない 7
信頼性が低いと…… ❏ ECサイト ➠ユーザーが離脱しほかで買い物 ❏ 広告 ➠ みてもらえない ❏ 定額制サービス ➠ 解約 8
9 どこまで信頼性に投資すべきか? ✔ 100msのレスポンスを95msに改善! ✔ 0.001%の確率で発⽣するエラーを改善! 他の機能を作っていたほうがユーザーのため になったのでは?
10 信頼性 機能開発 信頼性と機能開発 への投資のバラン スを取る必要があ る
信頼性の計測
Webアプリケーションの信頼性指標 ❏ レイテンシー ❏ 悪化すれば「遅い」と⾔われる ❏ エラーレート ❏ 悪化すれば「動かない」と⾔われる 12
13 機能開発 システムの複雑さ⬆ レイテンシー悪化 エラーレート悪化 機能開発を⾏えば⾏うほ ど、信頼性は下がってし まう 信頼性 の低下
14 機能開発 レイテンシー エラーレート
15 機能開発 レイテンシー エラーレート レイテンシーやエラー レートのような信頼性を 計測し、開発計画を変え ることが重要
16 信頼性を計測し開発計画を変更.... やってない.... というひとがいるかもしれません
17 たぶん、(暗黙的 に)信頼性を計測 しててます
“それ※をどうやって計測しますか?ほとんど の⼈にとって、その答えは「今⽇誰が怒鳴っ ているかによる」でしょう”[2] 18 [2] David N. Blank-Edelman著/山口能迪訳 『SREをはじめよう –
個人と組織による信頼性獲得への第一歩』株式会社オーム社、 2024年、p.174 文字の強調(色分け)は引用者によるものです ※引⽤者注: 信頼性のこと
「誰が怒鳴っているか」による信頼性計測 ⼈数ベース 19 数⼈が怒って いる😠😠😠 誰も怒ってい ない😊 たくさんの⼈ が怒っている 😡😡😡😡
😡😡😡😡 😡😡😡😡 信頼性高 信頼性中 信頼性低
20 営業部⻑が 怒っている 😠 ⼀般社員しか 怒ってない 😊 重要ユーザーが 怒っている😡 信頼性高
信頼性中 信頼性低 「誰が怒鳴っているか」による信頼性計測 ロールベース
「誰が怒鳴っているか」に よる信頼性計測の問題点
22 信頼性に投資すべきときに投資できない 機能開発 レイテンシー エラーレート だれかを怒ら せるライン 信頼性への投 資を開始すべ きライン
❏ 誰かを怒らせて初め て信頼性の低下に気 づく ❏ 対応が後⼿に回る ❏ 発覚したときは緊急 事態
23 信頼性に投資すべき所に投資できない ❏ 1⼈の意⾒だとしても声の⼤きさや、地位の⾼さ、ビジネ ス上の関係値によって、投資対象が決まる ❏ 信頼性の悪化は、極端な使われ⽅や偶発的な問題によっ て、ごく⼀部の⼈だけにしか影響していなかった可能性 必ずしも優先度の⾼い信頼性の問題 に対処できるわけではない
24 今⽇は「誰が怒鳴っているか」よ り良いやり⽅を紹介します!
サービルレベル⽬標 (SLO)とはなにか?
• サービルレベル⽬標(SLO)とは? ◦ ➠ サービスレベル指標(SLI)に対する ⽬標値 • サービルレベル指標(SLI)とは? ◦ ➠
信頼性に対するユーザーの満⾜度を 測ることのできる指標 26
27 ECサイトにおけるSLIの具体例 ❏ 「トップページ」表⽰のレイ テンシー ❏ 「カートへ追加」ボタンのレ イテンシー ❏ 「購⼊」ボタンのエラーレー
ト “悪くなったときにユーザーが不満を抱く指標”
28 ❏ 「トップページ」表⽰のレイテンシー※が2秒以内 ❏ 「カートへ追加」ボタンのレイテンシー※が4秒以内 ❏ 「購⼊」ボタンのエラーレートが1%以内 SLIに対する⽬標値がSLOになる ※実際はp99、p95といった下位N%を除外した最も悪いレイテンシーの値が採⽤されま す。レイテンシーはネットワークの状態によって極端な悪い値が出ることがあるため、
SLOでは平均値ではなく、このような統計値が採⽤されます。
29 SLOを使った投資判断 現在 過去 未来 過去の⼀定期間のSLIを集計 SLOを達成? 機能開発に 投資 信頼性に投
資 true false これからの投資を決定
SLO導⼊前のSmartHR
31 新機能A開発 新機能B開発 新機能C開発 SLO導⼊前のSmartHR ❏ 基本は新機能の開発が続く ❏ 信頼性への投資は “問い合わせ
があった時” ❏ ⾃発的な信頼性への投資もある が、エンジニアのセンスと興味 次第
32 SLO導⼊前のSmartHR 適切な時に適切な信頼性への投 資が⾏えなかったため、信頼性 の問題が積み重なっていってし まった... ⼤規模な障害につな がってしまう...
SmartHR⼤規模障害
❏ 2024/9頃からSmartHR全体の信頼性が許容不能な レベルまで低下 ❏ レイテンシーが極端に悪化したり、レスポンスがエ ラーになる事象がユーザーから多数報告される
35 当時のSLO 当時はSLOは⼀応定義されている状態(運⽤されていない)
❏ 9⽉だけで7回の“アクセス しづらい不具合”のお知ら せ ❏ 復旧を宣⾔しても、その後 アクセスしづらい事象が再 発
❏ 相互に依存する問題が多数発⽣していた ❏ どれか1つへの対処を⾏っても信頼性が根本的に回復しな かった ❏ →このため何度も復旧宣⾔をしてしまった DBコネクション枯渇 スロークエリ 不適切なIndexの利用
DBのCPU不足 リクエストの滞留 なにが起きていたのか?
38 ⼤規模障害への反省 ❏ 本来なら逐次的に対応が⾏われているべきだった ❏ 根本的な原因は信頼性への投資を適切に⾏えない 開発プロセス SLOの本格的な導⼊へ
SLO導⼊後のSmartHR
40 SLO導⼊後のSmartHR スプリント スプリント スプリント 👁 SLOの確認 👁 SLOの確認 👁
SLOの確認 ❏ 1スプリントに1回、SLOの 確認を実施 ❏ SLOを達成したか否かに応 じて次のスプリントでのタ スクを調整 ※より洗練された運⽤ではSLOの未達成の程度 (エラーバジェット)に応じて、信頼性へ の投資を⾏うかを調整することがあります
41 SLO前 SLO後 判断タイミング 問い合わせが来たら 定期的な監視 信頼性対応時の 開発体制 緊急対応になりがち 通常のスプリントの中で消化
判断基準 問い合わせの性質‧量 計測による 判断をする⼈ 問い合わせに対応する⼈ が中⼼ プロダクトオーナー含むチーム全 体の合意に基づく 信頼性への投資がどう変わったか?
42 信頼性に対して、必要な時に必 要な投資を⾏う体制が確⽴🎉 事業成⻑への投資も安⼼
まとめ
まとめ 1. 「誰が怒鳴っているか」による信頼性 計測の問題点 2. SLOによって、信頼性に対して適切な 投資ができるようになる 3. SmartHRでは信頼性投資をSLOで改善
SLOをやってみたい場合
46
None