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
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
Search
abnoumaru
March 28, 2025
Technology
1
600
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
March 28, 2025
Tweet
Share
More Decks by abnoumaru
See All by abnoumaru
IVRyエンジニア忘年LT大会2024 クリティカルユーザージャーニーの整理
abnoumaru
0
440
ゆるSRE勉強会 #8 組織的にSREが始まる中で意識したこと
abnoumaru
2
1.9k
3-shake SRE Tech Talk #10 LLMのO11yに触れる
abnoumaru
2
12k
マイクロサービスの現場からプラットフォームエンジニアリングの可能性を探る!
abnoumaru
2
12k
SLOいつ決めましょう?
abnoumaru
4
2.5k
あなたらしくSRE(公開用)
abnoumaru
5
8.3k
SRE Lounge 20180117
abnoumaru
0
6.7k
IDCFクラウドを使ってどこまでチューニングできるか試してみた
abnoumaru
0
250
AWS認定ソリューションアーキテクトを受けた話
abnoumaru
1
1.9k
Other Decks in Technology
See All in Technology
Lakebaseを使ったAIエージェントを実装してみる
kameitomohiro
0
130
PO初心者が考えた ”POらしさ”
nb_rady
0
210
Model Mondays S2E04: AI Developer Experiences
nitya
0
140
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
7.1k
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
200
AI時代の開発生産性を加速させるアーキテクチャ設計
plaidtech
PRO
3
160
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
110
改めてAWS WAFを振り返る~業務で使うためのポイント~
masakiokuda
2
260
Delegating the chores of authenticating users to Keycloak
ahus1
0
140
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
3
22k
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
7.8k
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.3k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
35
6.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
How to train your dragon (web standard)
notwaldorf
95
6.1k
RailsConf 2023
tenderlove
30
1.1k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Six Lessons from altMBA
skipperchong
28
3.9k
For a Future-Friendly Web
brad_frost
179
9.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Code Reviewing Like a Champion
maltzj
524
40k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
2025/03/29 IVRyの組織の形と SLO運用の現状 2025/03/29 【JAWS東北支部共催】Road to SRE NEXT@仙台 abnoumaru @
IVRy Inc.
2024年10⽉にIVRyに⼊社。 Circle: Development > Platform Project:Architecture > SRE 仙台は⼈⽣3度⽬! ⼀昨⽇⼈⽣で初めてせり鍋⾷べた。
株式会社IVRy SRE Project Owner abnoumaru
対話型⾳声AI SaaS IVRy 3 最短5分‧⽉2,980円から電話業務を⾃動化‧効率化することができるサービスで、 ボタンプッシュによる⾃動応答/SMS返信/電話転送に加えて、AI⾳声対話など様々な機能が利⽤可能
業態に合わせた⾃由な応答設定 4 ダイヤルプッシュとAIの対話をハイブリッドで設定し、 受けたい電話と⾃動化したい電話を分類。電話業務を効率化できる
なぜ話そうと思ったか?
IVRy、SREに突⼊していた 6 メンバーが増えて各々の得意が重なりSREらしいプラクティスが芽吹いてきている
SLOについて共有してみんなと話したい 7 過去2回の体外発表はSLOについて話している ⻑期化して迷⼦になったり⾃然消滅もしやすい SLOの話なんてなんぼあっても良いですから
組織の形? 8 SREやSLOの話をするにあたり組織の形、具体的なドキュメントや会議内容は ⾒聞きしてくれる⼈が「⾃組織ならどうするか?」と判断するときに重要だと思う 組織の話や具体的な部分にも触れていきます 💪
IVRyの組織の形
職能毎の組織開発に責任を持つサークルと 3ヶ⽉ごとに事業成⻑を⽬指したOKRにコミットするプロジェクトがある サークル/プロジェクト制 10
Architecture PJは横断的なプラットフォームを⾒ている プラットフォームという特徴からPlatform Circle ≒ Architecture PJが実情 Platform Circle /
Architecture PJ 11 Archtecture
Architecture PJのサブプロジェクト 12 SRE 信頼性への責任 Dev Infra 開発基盤への責任 Data Infra
データ基盤への責任 サブプロジェクトとしてSREの活動をしている 3つのサブプロジェクトがあるがメンバーはほぼ重複している
IVRyのSRE
電話とAIの信頼性 14 つながって当たり前な電話×未知の領域であるAI チャレンジングな領域で信頼性と向き合う楽しさがある (加えて⼤量の⾮構造な⾳声やテキストデータをどう扱うか?がポイント)
3つのObjectiveを掲げて活動してきた(2Qは別途掲げる) 2025 1Q IVRyのSREのObjective 15 SLOを価値ある判断材料として運⽤できる状態を⽬指す インシデントを最速で復旧させる仕組みを作る 全⼈類が電話をかけてきても耐えられるサービスを⽬指す 1 2
3
Architectureの今後の技術テーマ 16 LLMの信頼性 WebSocketの 信頼性 電話の流量制御 トイル削減 負荷試験基盤 障害試験 インシデント
レスポンス 電話の信頼性 データ基盤 デリバリ速度 認証基盤 ログ基盤
IVRyのサービスで守りたいこと
電話⾃動応答のアーキテクチャ 18 IVRyは「クライアント」の代わりに電話をとり「エンドユーザー」に⾃動で応答するサービス システムは①エンドユーザー側と②クライアント側に分かれる エンドユーザー側 電話応答システム クライアント側 ルール設定システム 詳細:https://speakerdeck.com/ymachida/architecture-of-a-large-scale-automated-phone-response-service-supporting-25-million-cumulative-calls 電話応答システム
AI対話システム ルール設定システム
アーキテクチャで最も優先していること 「電話はつながって当たり前」を守ること 特にエンドユーザー側の⾃動応答が損なわれないような設計を意識 👉 SLOは電話体験を中⼼に⼩さく始めている 19
策定時の反省 10⽉に⼊社後SLOの導⼊をアサインしてもらい 元々電話応答システムもルール設定システムも⼀気にやろうとしたが SREで⼤事な⼩さく始めるに反していた 👉 ユーザに届けたい価値を基準に各々のペースでやればよい ex. 実はうまく取れておらず修正が必要、違反しても量が多いと改修しきれない、ドキュメントをたくさん整えていく必要がある... 20
SLOの運⽤
SLOの観察 APMで必要なエンドポイントのSLOを主に観察 誰でも任意参加可能なMTGで眺めてる 22
SLO違反があったときは? エンジニア全体の定例でSLO観察のコーナーをして対応状況を共有 23
SLOのドキュメント 24 SLO OnboardingとSLO Docsを⽤意している ドキュメントを利⽤して対象サービスに説明 詳細:https://zenn.dev/luup_developers/articles/sre-gr1m0h-20250205 / https://sre-magazine.net/articles/2/ryuichi_1208/ SLO
Onboarding SLO Docs
SLOの設定する流れ 25 履歴や承認のことを考えてマークダウンをGitHubで管理しているが DocsからTerraformが⼿作業だと多分更新が廃れる SLO Docs 変換するツールを作って メンテナンスするより 変換はLLMに任せる? Markdown
locals.tf
SLO DocsからTerraformの⽣成 26 だいたい構造化されたデータを構造化されたデータにするをAIに任せる案 今回はDevinにお願いしたけどコスト的にLLMを⾃分で叩くツールを作る⽅がいい AIに任せるだけなくどのAIに任せるか?を考える瞬間が出てきて時代を感じる
IVRyは開発でもAIの検証が活発 27 プロダクトに組み込まれたLLMとは別に主に業務で利⽤しているツール 過渡期なのでアンテナを張りながら要望に応じて様々なツールを積極的に検証 Gemini Advanced NotebookLM Plus Cursor Devin
Cline GitHub Copilot
SLOに関するいいエピソード
リアクティブ→プロアクティブな変化 29 「なんか遅いかも」「CLからこんな連絡が...」だけではない プロアクティブに異常に気づける仕組みが増えた 👍 ex. SLOによりリリース後の全体的なレイテンシに気づいて 体感やクライアントからの連絡前に対処できる
すでにSLOはSREだけの関⼼事ではない 30 前スライド「SLO違反があったときは?」の調査および対応は サービスを主に担当するメンバーとSREに所属するメンバーで対応できた 信頼性を回復するという判断を SREだけではない範囲でできている 👍
SREがコードにも踏み込めている 31 前スライド「SLOの観察」を回復させる対応は SRE内部で状況を確認した後、⾃分がボールを持って進めようとしている
最後に 32 IVRyもSREがはじまっていました SLO導⼊6ヶ⽉程度の現状を共有 SLOが共通のものさしとして動き出した感があり 実際に活⽤された事例も出てきている 次のステップとしてSLOがより開発サイクルに ⾃然と組み込まれた運⽤を確⽴したい (SRE解散の第⼀歩)
None