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
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトか...
Search
sato-s
July 12, 2025
Technology
7
3.8k
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
sato-s
July 12, 2025
Tweet
Share
More Decks by sato-s
See All by sato-s
ハードルゼロLT発表資料
satos
0
5.2k
Other Decks in Technology
See All in Technology
With Devin -AIの自律とメンバーの自立
kotanin0
2
950
「手を動かした者だけが世界を変える」ソフトウェア開発だけではない開発者人生
onishi
15
7.9k
TypeScript 上達の道
ysknsid25
23
5k
Unson OS|48時間で「売れるか」を判定する AI 市場検証プラットフォーム
unson
0
150
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
240
クマ×共生 HACKATHON - 熊対策を『特別な行動」から「生活の一部」に -
pharaohkj
0
260
AWS表彰プログラムとキャリアについて
naoki_0531
1
150
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
350
LLMでAI-OCR、実際どうなの? / llm_ai_ocr_layerx_bet_ai_day_lt
sbrf248
0
380
テキストからの実世界知能の実現に向けて
sumoai
0
110
2025-07-31: GitHub Copilot Agent mode at Vibe Coding Cafe (15min)
chomado
2
290
激動の時代、新卒エンジニアはAIツールにどう向き合うか。 [LayerX Bet AI Day Countdown LT Day1 ツールの選択]
tak848
0
620
Featured
See All Featured
Visualization
eitanlees
146
16k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
Designing for Performance
lara
610
69k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Six Lessons from altMBA
skipperchong
28
3.9k
Building Applications with DynamoDB
mza
95
6.5k
BBQ
matthewcrist
89
9.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Why Our Code Smells
bkeepers
PRO
337
57k
Rails Girls Zürich Keynote
gr2m
95
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Transcript
ARR150億円、エンジニア 140 名、27チーム、17プロダクトから 始めるSLO 2025.07.12 Sat. SRE Next@TOC有明 佐藤 沢彦
SmartHR SRE
❏ 佐藤沢彦 ❏ 経歴 ❏ 2020〜: SmartHR プロダクトエンジニア ❏ 2024〜:
SmartHR SRE (1人目) ❏ 好きなエディタ ❏ neovim ❏ 好きなコマンド ❏ dstat ❏ X ❏ @SawshoS 自己紹介
❏ SmartHRは創業当初からひたすら「とにかく顧客の要望を実現する 機能を作る」を続けていた ❏ 信頼性が課題となり SLOを導入しようとなったときには、 ARRは150 億円、140名のエンジニア、 27チーム、17のプロダクトの巨大な開 発組織
❏ それに対して SREは1名 ❏ 巨大な開発組織に少人数で SLOを導入した際の工夫、失敗、成功 についてお話します 今日のお話
“求められる機能を、定められた条件の下で、定められた期間にわ たり、障害を起こすことなく実行する確率 [1] [1] Betsy Beyer、 Chris Jones Jennifer Petoff、
Niall Richard Murphy編/澤田武男、関根達夫、細川一茂、矢吹大輔監訳/ Sky株式会社 玉川竜司訳 『SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム』株式会社オーム社、 2017年、p.xiv “信頼性”とは? この発表では 信頼性 = レイテンシーとエラーレート とさせて下さい
SmartHRとは?
None
※ARR(Annual Recurring Revenue)年間経常収益。顧客からの月間経常収益(MRR(Monthly Recurring Revenue))を12 ヶ月で乗じた もの。 現在のSmartHR: ARR200億、エンジニア170名、44チーム、22プロダクト
SmartHR 基本機能 基本機能と連携するアプリ 年末調整 文書配付 従業員サーベイ カスタム社員名簿 API連携 人事データベース •
SmartHRは”基本機能”という人事データベースを 持つアプリとそれに連携するアプリでできている
SmartHRにSREができるまで
2024年にSRE誕生 ❏ サービス開始後 9年目 ❏ ARR約150億円 “遅くない? ”
“BtoB”
一般的なtoCのWebサービス 検索サイト ECサイト ❏ 信頼性が収益に直結 ❏ 描画の遅れやエラーが収益の減少を招く ❏ 快適に動作しなければユーザーは離脱 ❏
24/365で利用される
❏ ユーザーは 仕事として 利用 ❏ ユーザーは快適な操作よりも機能性を重視 ❏ 100msの描画速度改善よりも 3hの業務を10s にする機能が望まれる
❏ メインのユーザーは 国内の労務担当者 ❏ 基本的に月 -金の9-17時にSmartHRを利用 SmartHR
一般的なtoCのWebサービス SmartHR 24/365で利用される ほとんどが月-金の9-17時 信頼性が収益に直結 信頼性が収益に直結するわけではな い SREへのニーズが少なかった (過去形)
新しいプロダクト次々とリリース
高信頼性を求められるプロダクトが増加 IdP管理 お知らせ機能 メッセージ機能 勤怠 ❏ 24/365利用される ❏ 一般従業員も利用 ❏
操作の快適さも重要
だいぶ遅くなったが SREが誕生 SRE誕生!
SLO導入の背景
SmartHRでは機能性の拡充が最優先 一般的なtoCのWebサービス SmartHR 24/365で利用される ほとんどが月-金の9-5時 信頼性が収益に直結 信頼性が収益に直結するわけではな い
❏ 新しい機能を使いたい新規ユーザーが増える ❏ 既存ユーザーの満足度の向上 ❏ 既存ユーザーが新機能の使える上位のプランに 乗り換えてくれる SmartHRが機能性を拡充したいモチベーション
SmartHRの成長戦略 「ユーザーにとって便利な機能をたくさん 作る」
「ユーザーにとって便利な機能をたく さん作る」 …が、長年、これだけを続けていると 無理が出てくる
バックグラウンドジョブが何時間待って も終わらない …… 画面遷移が遅くて仕事に支障が ……
❏ 新機能をとにかく作る ❏ 信頼性に関する問題の対応 は、”問い合わせベース ” 当時のSmartHR の開発 新機能A開発 新機能B開発
新機能C開発
「ユーザーにとって便利な 機能をたくさん作る」 信頼性 このバランスを取りたい SLOの導入
SLO導入
ARR150億円 エンジニア 140名 27チーム 17プロダクト 😊 😩 SRE1名 導入の課題 :
規模は大きいが SREは少ない
SLO導入の方針 ❏ SREはSLOのイネイブリング のみを行う ❏ SLOを徹底的にシンプル に
方針: SREはSLOのイネイブリング ※のみを行う 27チーム、17プロダクトの SLOを1人で運用するのは無理。 SREはSLOのイネイブリ ングのみを行うことにし、実際の SLOの導入・運用は各プロダクトチームに任せた。 SREがやること プロダクトチームがやること
❏ SLOのイネイブリング ❏ SLO導入ガイドの用 ❏ SLO説明会 ❏ etc… ❏ SLOの定義 ❏ SLOの運用 ※他のチームが新しい技術やスキルを習得することを支援すること
SLOの定義や運用は各プロダクトチームにやって もらう SLOを140人、27チームに理解してもらう必要があ る → そんな時間はない 😭
方針: SLOを徹底的にシンプル に SLOという複雑な概念を 27チーム、140名のエンジニアに完璧に理解しても らうのは困難。 約400ページ 約500ページ SLOを徹底的にシンプルにし、 2,3分で理解可能にした。
徹底的にシンプル なSLOとは? ❏ エラーバジェットを 管理しない ❏ バーンレートアラートを 設定しない ❏ リリースの
コントロールをしない じゃあ、逆に何をするのか????
徹底的にシンプル なSLOでやること ❏ SLOは違反している or していないの 2値 ❏ エラーバジェットを説明しなくて良い ❏
1スプリントに 1回SLO違反を確認し違反があれば、 SLOを緩め る or 次スプリントで対応する ❏ バーンレートアラートは不要 ❏ リリースのコントロールはなし、 SLOはスプリント計画の判断 材料
❏ SREはSLOのイネイブリング のみを行う ❏ SLOを徹底的にシンプル に この2つの方針で SLOを導入していった
SmartHR 基本機能 基本機能と連携するアプリ 年末調整 文書配付 従業員サーベイ カスタム社員名簿 API連携 人事データベース まず、基本機能関連のチーム
(5チーム)にSLOを導入 ❏ SmartHRで最大のトラフィック ❏ 他のアプリが依存 ❏ 5チームの有志のあつまる ”パフォーマンス会 ”が存在
結果: あまりうまくいかな かった
できたこと ❏ SLOの意義はある程度理解が広がった ❏ SLOの定義 ❏ 定期的なSLO違反確認 ❏ SLO違反対処のチケット作成 しかし、SLO違反の対応チケットが切られても、改善
対応が進まない
これ!!
成長戦略 「ユーザーにとって便利な機能をたくさん作る」 最重 要 ❏ スプリントに入れることができるのは 機能開発のみ ❏ SLO違反の対応はスプリントに入らず、実施されない
❏ SLOの理念 ❏ →わかる。いいね 👍 ❏ SLO違反の対応 ❏ →うーん🤔新機能開発に影響を出してまではでき ないよね
SLOに対する反応 機能開発と信頼性のバランスをとることはできなかった
そんな状況下で大問題が発生してしまう … SmartHR大規模障害
SmartHR大規模障害
❏ 2024/9頃からSmartHR全体の信頼性が許容不能なレベルまで 低下 ❏ レイテンシーが極端に悪化したり、レスポンスがエラーになる事象 がユーザーから多数報告される 当時のSLO
❏ 9月だけで7回の”アクセス しづらい不具合 ”のお知ら せ ❏ 復旧を宣言しても、その後 アクセスしづらい事象が再 発
なにが起きていたか? ❏ 相互に依存する問題が多数発生していた ❏ どれか1つへの対処を行っても信頼性が根本的に回復しなかっ た ❏ →このため何度も復旧宣言をしてしまった DBコネクション枯渇 スロークエリ
不適切なIndexの利用 DBのCPU不足 リクエストの滞留
大規模障害対応専門チームが組成し対応 ❏ 十数名のエンジニアが約 1ヶ月対応に専念 ❏ 29件の改善を実施 ❏ スロークエリ改善、コネクションプーラー、サーキットブレーカー、 etc… 信頼性を許容されるレベルまで回復
影響 ❏ 顧客からの信頼を損ねる深刻な影響 ❏ 顧客対応や障害対応のため現場は疲弊 ❏ ロードマップは見直しが必要に 再発防止が全社的な課題となる
SLOがうまく運用されてい れば防げたのでは?
SLOがあれば防げていた ? ❏ 以前からSLO違反が発生し、信頼性低下の兆候 は見えていた ❏ SLO違反が発生するたびに対処ができていれば、 許容不能なレベルまで信頼性が低下することは なかった
大規模障害を防ぐための SLO
❏ 再発防止のため新機能開発が最 優先されるスプリントを変えること が必要であると提案 新機能A開発 新機能B開発 新機能C開発 SLO違反対応 SLOで大規模障害を防ぐための提案
❏ SLOがエンジニアだけでなく PMなど他のステークホルダー 含む共通認識に ❏ VPoEからの合意も得られ、 SLOの導入はプロダクト部門 の注力ポイント に SLOの必要性が広く受け入れられた
大規模障害の 苦い記憶 何とかしな きゃ!
❏ SLO違反への対応が 機能開発同等のタスク としてス プリントに入るようになった ❏ プロダクトチーム側から ”SLOを導入したい ”と言われ るようになった
変わったこと
現在の状況 ❏ 2024/1月までは0チームだったが、現在は 13チーム にSLOが導入された ❏ SLO違反→対応というサイクルを回すことができてい る SLO導入成功
成功したこと 🎉
❏ ビジネス上大きな影響を出してしまった問題なので再 発防止策の必要性が共通認識だった ❏ SLOが”やったほうがいいこと ”から”やらないといけな いこと”になった SLOを大規模障害の 再発防止策 として位置づけた
❏ 導入のハードルが下がり、自主的に導入してくれる チームが出た SLOを徹底的にシンプル にしたこと
❏ SREがプロダクトの開発プロセスを知らないこともあ り、多数のチームのイネイブリングには限界 ❏ 特に1プロダクト複数チームの場合は、どのチームが どのSLOのオーナーになるかなどが複雑 チームのSLO推進担当者 を出してもらったこと
失敗したこと 😭
“SLO”は”機能開発”より優先すべきと言ったこと ❏ 高い基準の信頼性を達成するため、機能開発に割くこと のできる時間が減るという印象を与えた ❏ 今まで目指してきたものが変わると思われて反感が大 SLOは必要な信頼性が保てているかを計測するためのツー ルに過ぎないということを丁寧に説明すべきだった
まとめ
❏ SREが1名の状態で大規模なチームへの SLO導入に挑戦 ❏ シンプルな SLOをイネイブリングしていくことで少人数で多 数のチームへの SLO導入を行った ❏ 大規模障害の再発防止策として
SLOの導入を推し進めた ❏ 13チームにSLOが導入された
今後やりたいこと
❏ SLOを全チームに広げる ❏ SLO違反→対応というサイクルを徹底 ❏ シンプルな SLOを進化 ❏ エラーバジェット・バーンダウンアラートの導入
we’re hiring 2名しかいないよー
スペシャルサンクス
ご清聴ありがとうございました 🙇