SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり

Transcript

1. #srenext #srenext_c SREプラクティスを複数のプロダクト・組織で 自律的に回し続けるための仕組みづくり Ryusuke Tesaki KINTO Technologies, Inc. SRE Team — SRE NEXT 2026
2. #srenext #srenext_c KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
3. #srenext #srenext_c KTCが手掛けたプロダクト(一例) 気軽にマイカーを持てる、 クルマのサブスクサービス ハードウェアもソフトウェアも アップグレードし続ける特別なクルマ クルマのオーナーに向けた 愛車のカスタム・機能向上サービス
4. #srenext #srenext_c オフィス — 5 拠点 室町オフィス 〒103-0022 東京都中央区日本橋室町2-3-1 室町古河三井ビルディング（COREDO室町2） 神保町オフィス 〒101-0054 東京都千代田区神田錦町3丁目22番地 テラススクエア 名古屋オフィス 〒450-0002 愛知県名古屋市中村区名駅4丁目8番18号 名古屋三井ビルディング北館 Osaka Tech Lab 〒530-0001 大阪府大阪市北区梅田3丁目1番3号 ノースゲートビルディング Fukuoka Tech Lab 〒810-0041 福岡県福岡市中央区大名2丁目6-50 福岡大名ガーデンシティ
5. #srenext #srenext_c 自己紹介 プラットフォーム開発部 xREグループ SREチーム 手﨑 事業会社にてSREを担当後、 2025年10月KINTOテクノロジーズ入社 大阪オフィス所属 Central SREやEmbedded SREとして 複数のプロダクトのSREを担当
6. #srenext #srenext_c KTC における SRE/DBRE の立ち位置 ⚫ 従業員数: 約400名 アプリケーション開発組織 • KINTOサービス開発 • 決済/ID基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発 etc... プラットフォーム開発部 • Cloud Infrastructure • Cloud Security • xRE (SRE: 2名 / DBRE: 5名) • MSP (24×365保守運用) • Platform Engineering アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 … プラットフォーム開発部 Cloud Security Cloud Infrastructure xRE (SRE / DBRE) MSP Platform Engineering
7. #srenext #srenext_c KTC SREの目的 サービス品質の維持と、開発サイクルの高速化により、サービスのビジネス価値を最大化 サービス品質の維持 利用者の期待を満たす 開発サイクルの高速化 市場の変化や要望に答える 開発者が価値を生み出す業務により注力できる環境を提供する必要がある サービスのビジネス価値を最大化
8. #srenext #srenext_c 複数のプロダクト組織にCentral SREとEmbedded SREの両輪で、SREプラクティスを組織に定着させていく Central SREとEmbeddedの2つの形で活動 ← Central SRE → ← Embedded SRE → 0% 100% Central SRE 横断的な活動で60%くらいをカバーする ソリューションを構築する Reactiveな活動になる 例：オブザーバビリティツールの導入 Embedded SRE proactiveな活動で100%まで引き延ばす ・ 横断的なソリューションをプロダクトに浸透させる ・ 個別最適な要素を取り入れる 例：トイルの工数、インシデント対応の工数の可視化 60%
9. #srenext #srenext_c 本日お話しすること SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり Central SREとして組織横断型のEnabling活動と見えてきた課題 Embedded SREによるEnabling活動と見えてきた課題 Agent によるEnabling活動への挑戦
10. #srenext #srenext_c Central SREとして組織横断型のEnabling活動と 見えてきた課題 1
11. #srenext #srenext_c KTC SRE がビジネス価値を最大化するための第一歩 サービスの状況をモニタリングしてビジネスへの影響を最小限に抑える まずはモニタリングとインシデントレスポンスから 見えないものは管理できない システムの状態を可視化し、正常が分かっているからこそ異常がわかる リアルタイムな影響把握で迅速な意思決定を行う 根拠ある改善と予防策の策定を可能にする Figure III-1. Service Reliability Hierarchy
12. #srenext #srenext_c なぜNew Relic を推進したのか 可視化→解釈→アクションが自律的に回る“育てられる基盤”となる 可視化の先にあるアクションが重要 自分たちで「見える」を育てられる 課題発見と改善につなげるための仕組みが揃っている 可視化を目的にしない、その先にあるものを見る 仮説→実装→観測→学習のループを短くし、 意思決定の速度と質を上げる 顧客体験の変化をプロダクト内の要因まで 遡れるようにし優先順位付けを迷わない
13. #srenext #srenext_c New Relic 活用の推進 New Relic導入だけでは最大限には活用できない KTC環境に合わせた導入手順や活用事例のドキュメントを作成して推進 ツールそのものを知る必要がある APM Metrics Trace Log ・・・
14. #srenext #srenext_c New Relic 活用の推進ードキュメント作成
15. #srenext #srenext_c New Relic 活用の推進ーメトリクスを見る習慣づけ New Relic を導入したはいいものの、障害発生時にしか使わない 日常的なメトリクス監視やプロアクティブな改善が根付いていない プロアクティブなパフォーマンス改善が始まった 現場ならではの改善提案も出るようになった 取り組み 開発チームと New Relic をどう活用するかについて定期的な MTG を実施 ダッシュボードを作って日次の定例で眺めてもらうことに
16. #srenext #srenext_c 組織横断型のEnabling活動と見えてきた課題 取り組み 見えてきた課題 1 ドキュメント作成 監視やSREプラクティスの手順を、社内の技術スタッ クに合わせて文書化 ⚫ あまり読まれない ⚫ SREの負荷は下がるが、あるからといって活用が進むわけ ではない 2 勉強会・定例での推進 プロダクトに合わせた実践を、開発チームと一緒に進 める ⚫ 意欲のある人がいれば効果は出るが、プロダクトに最適 な進め方の提案が難しく、次第に頭打ち 組織横断型のEnabling活動だけではプロダクトの信頼性向上への取り組みは難しい 横断組織型のSREからEmbedded SREとしての活動への挑戦 プロダクトチームの一員として、Embedded SREとしてを活動を進める
17. #srenext #srenext_c Embedded SREによるEnabling活動と 見えてきた課題 2
18. #srenext #srenext_c 横断組織型のSREからEmbedded SREとしての活動 既に稼働中のプロダクトや新規構築中のプロダクトに対してSREとして参画 アプリケーション開発組織 • KINTOサービス開発 • 決済/ID基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発 etc... プラットフォーム開発部 • Cloud Infrastructure • Cloud Security • xRE (SRE: 2名 / DBRE: 5名) • MSP (24×365保守運用) • Platform Engineering アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 … プラットフォーム開発部 Cloud Security Cloud Infrastructure xRE (SRE / DBRE) MSP Platform Engineering 2つのプロダクトを担当
19. #srenext #srenext_c SREとして各プロダクトの状況に合わせて活動 プロダクトの置かれている状況は様々で一律に判断はできない 各プロダクトで何が最優先で効果的なのか図りながら進めていく必要がある オブザーバビリティの整備 プロダクト固有の課題 トイルの削減 技術スタックの違い 開発チームの習熟度の違い 組織形態の違い
20. #srenext #srenext_c 優先度を図りながらも土台を築いていく 見えないものは管理できない システムの状態を可視化し、正常が分かっているからこそ異常がわかる リアルタイムな影響把握で迅速な意思決定を行う 根拠ある改善と予防策の策定を可能にする Figure III-1. Service Reliability Hierarchy 個別の対応だけ進めていては信頼性を高めることには繋がらない 信頼性は、下層の上にしか積み上がらない SREの本質は品質の維持と開発サイクルの高速化
21. #srenext #srenext_c 運用定着にむけた取り組み 一度構築して終わりではなく日々の運用を定着するまで推進していく 毎朝 ダッシュボードやログを確認 週次・月次 サービス全体のレポートを作成し、 チームで振り返る アラート整備 余計なアラートの除外 新しいアラートの追加 デプロイ 当日とその後、挙動の変化を確認 インシデント対応 調査対応後は ポストモーテムを検討する ダッシュボードの最新化 日々の運用に合わせた整備 繰り返し見える形で実施することで定着する
22. #srenext #srenext_c 実際のプロダクトでの取り組み事例 プロダクト 結果 1 グループ会社向け社内システム(新規構築) ローンチ前からSREとして参画。オブザーバビリティ 整備や負荷試験によるCapacity Planningなど数ヶ月で一 気通貫で実施 ⚫ オブザーバビリティの重要性や信頼性の話を設計段階か らできるように ⚫ 稼働状況やエラー内容の振り返りMTGを定着 新規プロダクトの例 新規構築フェーズ 設計段階からSREが参画・構築 運用が定着
23. #srenext #srenext_c 実際のプロダクトでの取り組み事例 プロダクト 結果 2 一般顧客向けECサイト(稼働中) 開発チームによる独自運用がある。Monitoring基盤の 再設計が必要な状態 ⚫ 汎用的なアラート設計ではなくプロダクトに最適化 ⚫ ログの状況を、全員が共通認識で測れるように ⚫ MySQLバージョンアップやリアーキテクチャなどを並走 稼働中のプロダクトの例 従来からの運用 プロダクトに最適化して強化 余計な認知負荷を増やさない サービス全体がより高信頼性に
24. #srenext #srenext_c 実際のプロダクトでの取り組み事例 同じEmbedded SREでも、取り組み方を変える必要がある 各プロダクトに合わせた形で信頼性向上に対する取り組みを進めることができた ← Central SRE → ← Embedded SRE → 0% 100% Central SRE 横断的な活動で60%くらいをカバーする ソリューションを構築する Reactiveな活動になる Embedded SRE proactiveな活動で100%まで引き延ばす ・ 横断的なソリューションをプロダクトに浸透させる ・ 個別最適な要素を取り入れる 60%
25. #srenext #srenext_c より多くのプロダクトに展開していきたい １人が関わるプロダクトとしては２〜３プロダクトが限界 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 … プラットフォーム開発部 Cloud Security Cloud Infrastructure xRE (SRE / DBRE) MSP Platform Engineering
26. #srenext #srenext_c Embedded SREとしての活動の課題 今までの課題 試行 Embedded SREとして開発メンバーの一員として取り組む • 開発チームの一員としてプロダクトの状況に合わせて、信頼性の話を設計段階からできるようになった • 運用としてシステムの稼働状況を確認する活動を組み込むことができ、インシデント対応以外でもオブザーバビリティツールが 活用されるように 新たな課題 複数のプロダクトに展開する難しさ 横断組織によるEnablingだけではプロダクトの信頼性向上への取り組みは難しい • １人が関わるプロダクトとしては２〜３プロダクトが限界 • 人を増やして対応させることは現実的ではない アプローチ SREに代わって関与し続けるAgentをプロダクトごとに配置して解消できないか 継続／拡大を仕組みで解決する実現手段としてAgentを活用
27. #srenext #srenext_c AgentによるEnabling活動への挑戦 3
28. #srenext #srenext_c どこまでをAgentの活動目標とするか Level Monitoring Incident Response Postmortem / Root Cause Analytics Testing / Release Capacity Planning Development Product Lv1 観測 メトリクス/ ログ/トレー ス収集 インシデント 情報を収集 障害情報・時 系列を収集 リリース影響 を観測 使用量・負荷 を継続観測 CI/CD・変更 履歴を観測 SLO/UX/事業 指標を観測 Lv2 判断 正常から逸脱 を判断 対応優先度と 方針を判断 原因と再発傾 向を分析 異常と失敗兆 候を判断 将来負荷とボ トルネックを 分析 信頼性リスク の高い変更を 分析 ユーザー価値 への影響を分 析 Lv3 実行 アラート調整 ダッシュボー ド生成 障害対応を実 行 ポストモーテ ム作成・改善 実行 安全なリリー ス制御を実行 キャパシティ 調整を実行 信頼性向上の 変更を実行 信頼性とUXを 考慮し制御 Figure III-1. Service Reliability Hierarchy
29. #srenext #srenext_c 各プロダクト専用のAgent を構築 1人のSREを配置する代わりに専用のAgentを配置 監視ツール New Relic ／ AWS 利用者からの 問い合わせ プロダクト チーム Slack 等で 状況を報告 Agent 目的・価値観 ／ 推論・判断 SREとしての価値観にもとづき状況を判断 記憶（短期・長期） 今の状況と過去の対応履歴を蓄積 プロダクト固有 固有のコンテキスト ＋ 対応能力 プロダクトごと最適化した情報 観測 行動 SRE（人間） 人間への問いかけ・新しい能力の開発
30. #srenext #srenext_c なぜプロダクトごとにAgentを構築するのか 各プロダクトに合わせた動き方をする必要があるため 専用の情報を使って信頼性向上に対する取り組みを進める コンテキスト サービスレベル アーキテクチャ 機能 業務用DBへの接続 専用サイトへのアクセス 記憶領域 これまでの対応履歴 分析結果やその推移
31. #srenext #srenext_c アーキテクチャ AWS Bedrock AgentCoreで構築 イベントに応じて呼び出し スケジュールに応じて呼び出し
32. #srenext #srenext_c アーキテクチャ AWS Bedrock AgentCoreを採用した理由 プロダクト固有の コンテキスト 専用の記憶領域 プロダクト固有の 機能
33. #srenext #srenext_c Agentに現在実装できている範囲 Level Monitoring Incident Response Postmortem / Root Cause Analytics Testing / Release Capacity Planning Development Product Lv1 観測 メトリクス/ログ/ト レース収集 インシデント情報を 収集 障害情報・時系列を 収集 リリース影響を観測 使用量・負荷を継続 観測 CI/CD・変更履歴を観 測 SLO/UX/事業指標を観 測 Lv2 判断 正常から逸脱を判断 対応優先度と方針を 判断 原因と再発傾向を分 析 異常と失敗兆候を判 断 将来負荷とボトル ネックを分析 信頼性リスクの高い 変更を分析 ユーザー価値への影 響を分析 Lv3 実行 アラート調整 ダッシュボード生成 障害対応を実行 ポストモーテム作 成・改善実行 安全なリリース制御 を実行 キャパシティ調整を 実行 信頼性向上の変更を 実行 信頼性とUXを考慮し 制御 = 現在実装できている範囲 Monitoring・Incident Response・Postmortem を Lv2（判断）をカバー
34. #srenext #srenext_c AgentによるEnabling活動例 Agentにできること 目的 毎週の定期通知 ダッシュボードを見る習慣がないチームへ 「情報が存在する」ことを認識してもらう デプロイ翌日の確認 昨日のリリース、その後の状況を確認 デプロイ後の稼働状況の変化を見てもらう インシデント対応とポストモーテム インシデント対応時は自動分析し 後日ポストモーテムの作成を提案する インシデント対応時の確認箇所やポストモーテ ムの文化を知ってもらう 運用を自動化するためだけのAgentではなく、SREのEnabling活動を推進する
35. #srenext #srenext_c AgentによるEnabling活動ー認知を促す Agentにできること 目的 毎週の定期通知 ダッシュボードを見る習慣がないチームへ通知して促す まず「情報が存在する」ことを認識してもらう 定期的に稼働状況の レポートを取得 レポートの内容を記憶 異常時は過去の情報と 比較検証 New RelicやAWSから情報を取得 コンフルエンスにレ ポート集約 改善チケットを作成
36. #srenext #srenext_c AgentによるEnabling活動ー変化に気づく デプロイ翌日の確認 昨日のリリース、その後の状況を確認 デプロイ後の稼働状況の変化を見てもらう Agentにできること 目的 デプロイ中のステータスを報告 デプロイ後の稼働状況を報告 New RelicやAWSから情報を取得
37. #srenext #srenext_c インシデント対応とポストモーテム インシデント対応時は自動分析し 後日ポストモーテムの作成を提案する インシデント対応時の確認箇所やポストモーテ ムの文化を知ってもらう AgentによるEnabling活動ー振り返りの提案 Agentにできること 目的 インシデント調査結果を報告 解消後にポストモーテム作成を推進 過去の対応履歴を蓄積・参照 DBから業務データを 確認 コンフルエンスにレ ポート集約 改善チケットを作成 New RelicやAWSから情報を取得
38. #srenext #srenext_c チームに影響を与え続けるAgent スケジュール 毎朝 週次・月次 サービス全体のレポート作成 イベント デプロイ イベント前後の対応 アラート プロダクトの稼働状況に対して継続的に関与 聞けば答えるだけでなく自ら関与し続けチームに影響を与える Agent 気づきを促す 開発チーム 今まで認識しないなかった微細な変化にも対応できるように
39. #srenext #srenext_c Enablingできる範囲はこれからも広がっていく Level Monitoring Incident Response Postmortem / Root Cause Analytics Testing / Release Capacity Planning Development Product Lv1 観測 メトリクス/ログ/ト レース収集 インシデント情報を 収集 障害情報・時系列を 収集 リリース影響を観測 使用量・負荷を継続 観測 CI/CD・変更履歴を観 測 SLO/UX/事業指標を観 測 Lv2 判断 正常から逸脱を判断 対応優先度と方針を 判断 原因と再発傾向を分 析 異常と失敗兆候を判 断 将来負荷とボトル ネックを分析 信頼性リスクの高い 変更を分析 ユーザー価値への影 響を分析 Lv3 実行 アラート調整 ダッシュボード生成 障害対応を実行 ポストモーテム作 成・改善実行 安全なリリース制御 を実行 キャパシティ調整を 実行 信頼性向上の変更を 実行 信頼性とUXを考慮し 制御 = 現在実装できている範囲 Monitoring・Incident Response・Postmortem を Lv2（判断）をカバー
40. #srenext #srenext_c プロダクトや組織に閉じないAgentの活動 Agent同士や、Agentと人の協調により自律的な活動が進む 協調 協調 協調 プロダクトB プロダクトA プロダクトC 開発チームA 開発チームB 開発チームC SRE
41. #srenext #srenext_c より多くのプロダクトにSREプラクティスを展開 信頼性の土台を築きながら人が注力できる範囲を拡大 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 プラットフォーム開発部 Cloud Security Cloud Infrastructure xRE (SRE / DBRE) MSP Platform Engineering アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織
42. #srenext #srenext_c まとめ 4
43. #srenext #srenext_c まとめ Central SRE として組織横断型のEnabling活動と見えてきた課題 ドキュメントや勉強会だけでは活用が頭打ちに プロダクトの一員としての取り組みへ Embedded SRE によるEnabling活動と見えてきた課題 各プロダクトの状態に合わせた形で信頼性の向上に取り組めた １人が関われるプロダクト数には限界がある AgentによるEnabling活動への挑戦 １人のSREの代わりに専用Agentを配置し、人手に頼らず関与し続ける仕組みへ より多くのプロダクトにSREプラクティスを展開できる準備 SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり
44. #srenext #srenext_c すべての組織がサービスのビジネス価値を最大化する 役割に閉じず誰もが信頼性に関わる → “Inclusive SRE” 協調 協調 協調 開発チームA 開発チームB 開発チームC SRE PDM QA 開発チーム Designer プロダクトB プロダクトA プロダクトC
45. #srenext #srenext_c THANK YOU