SREって何？ 現場で学んだサイト信頼性の第一歩

TechRAMEN 2025の発表資料です。
https://techramenconf.github.io/

Transcript

1. ©MIXI SREって何？ 現場で学んだサイト 信頼性の第一歩 株式会社MIXI 井上 翔太
2. ©MIXI 自己紹介 名前：しょっさん
 X（旧: Twitter）/ mixi2：@syossan27
 所属：株式会社 MIXI
 活動：
 • SRE Kaigi • SRE Magazine • ゆるSRE勉強会 • o11ycon
3. ©MIXI Fanstaのご紹介 • スポーツ観戦ができる飲食店に特化した検索サービス • スポーツ観戦できる飲食店をエリアやチーム、放映予定から検索し、予約できる • お店にとってはスポーツ観戦ができることを告知し、集客することができる ©Fansta
4. ©MIXI このセッションは インタラクティブ・セッショ ン と題して分岐しながら進みま す
5. ©MIXI 挙手をとりながら 進めていきますので 楽しんでいきましょ う！
6. ©MIXI まずは練習
7. ©MIXI SREを 知ってるよ！/やってるよ！ 知ってる/やってる 知らない/やってない
8. ©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という 手法で す。
9. ©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という 手法で す。 Googleが提 唱
10. ©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という 手法で す。 Googleが提 唱 サービスの信頼性を担 保
11. ©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という 手法で す。 Googleが提 唱 サービスの信頼性を担 保 SWEを用いた運用へのアプロー チ
12. ©MIXI SREとは？ SREは手法であるため、様々なプラクティスが存在しています。 • SLI / SLO の定義 • モニタリング / オブザーバビリティ • トイルの最適化 • エラーバジェットの策定 / 運用 • リリースエンジニアリング • インシデント管理 • ポストモーテム（ポストインシデントレビュー） • etc…
13. ©MIXI SLI / SLO の定義 そもそも"信頼性"とはなに か？
14. ©MIXI SLI / SLO の定義 そもそも"信頼性"とはなに か？ サービスによって大きく異なる • 店舗予約システム ◦ 予約ができること • ニュースサイト ◦ 記事が正しく読み込まれて、閲 覧できること ⇒ ユーザーの関心が高い・そのサービス の根幹となる体験が損なわれないこと
15. ©MIXI SLI / SLO の定義 そもそも"信頼性"とはなに か？ サービスによって大きく異なる • 店舗予約システム ◦ 予約ができること • ニュースサイト ◦ 記事が正しく読み込まれて、閲 覧できること ⇒ ユーザーの関心が高い・そのサービス の根幹となる体験が損なわれないこと これをSLI / SLOとして定義していく
16. ©MIXI SLI / SLO の定義 どのようにSLI / SLOを定義するのか？ SLI ユーザー観点でのシステムメトリクス • ユーザー体験に基づいたメトリクスを取得 • CUJを設計し、ユーザー体験を理解して、SLIを見つ け出す • まずはサービスの可用性/レイテンシなど SLO ユーザーが満足する目標値 • SLIに対してパーセンテージで 目標値を設定 する ◦ 例：一ヶ月の間にサービスは99.9%正常に稼働している • "時間"をもとに決めるのもGood
17. ©MIXI エラーバジェットの策定 / 運用 信頼性を保てるエラーの許容量を策 定
18. ©MIXI エラーバジェットの策定 / 運用 信頼性を保てるエラーの許容量を策 定 SLOから許容できるエラー量を算出 SLOが99.9%だと0.1%はエラーを発生させ る余裕があるということ ポリシーを設定 し、エラーバジェットが 減った場合にどうするか？の運用を決めて おく ⇒ 基本的には使い切ったら 機能リリースを ストップし、エラーへの対応を最優先
19. ©MIXI エラーバジェットの策定 / 運用 信頼性を保てるエラーの許容量を策 定 "挑戦"と"安定"のバランスを保つ指標とする SLOから許容できるエラー量を算出 SLOが99.9%だと0.1%はエラーを発生させ る余裕があるということ ポリシーを設定 し、エラーバジェットが 減った場合にどうするか？の運用を決めて おく ⇒ 基本的には使い切ったら 機能リリースを ストップし、エラーへの対応を最優先
20. ©MIXI モニタリング / オブザーバビリティ サービスを"知る"ためのプラクティ ス
21. ©MIXI モニタリング / オブザーバビリティ サービスを"知る"ためのプラクティ ス モニタリング： 「既知の未知」を知ることができる リアクティブに 既知の障害 で未知な状態 である ことをユーザーに知らせる （例. 特定時間帯にCPU負荷が高くなる現象が発生し ている[既知]が、何故かはわからない[未知]） オブザーバビリティ： 「未知の未知」を知ることができる プロアクティブに 未知の障害 で未知な状態 を調 査することができる （例. サービスが動いていないと一部ユーザーから報 告が来た[未知]が、何故かはわからない[未知]）
22. ©MIXI モニタリング / オブザーバビリティ サービスを"知る"ためのプラクティ ス モニタリング： 「既知の未知」を知ることができる リアクティブに 既知の障害 で未知な状態 である ことをユーザーに知らせる （例. 特定時間帯にCPU負荷が高くなる現象が発生し ている[既知]が、何故かはわからない[未知]） オブザーバビリティ： 「未知の未知」を知ることができる プロアクティブに 未知の障害 で未知な状態 を調 査することができる （例. サービスが動いていないと一部ユーザーから報 告が来た[未知]が、何故かはわからない[未知]） モニタリングとオブザーバビリティの特性の違いを踏まえて環境を整える
23. ©MIXI トイルの最適化 繰り返して行われる手作業を最適化
24. ©MIXI トイルの最適化 繰り返して行われる手作業を最適化 大量の作業が発生する前に最適化を • 戦術的である • 長期的価値がない • 自動化できる • サービス成長に比例する に当てはまるものは優先的に対応しましょ う トイルは自動化して変容させたり、 仕組み の再設計で不要化させることで対応する
25. ©MIXI トイルの最適化 繰り返して行われる手作業を最適化 大量の作業が発生する前に最適化を • 戦術的である • 長期的価値がない • 自動化できる • サービス成長に比例する に当てはまるものは優先的に対応しましょ う トイルは自動化して変容させたり、 仕組み の再設計で不要化させることで対応する 恒常的にトイル対応して、信頼性の高い組織へ
26. ©MIXI リリースエンジニアリング 高い信頼性はリリースから始ま る
27. ©MIXI リリースエンジニアリング 高い信頼性はリリースから始ま る CI/CDの整備や、安全なリリース手 法、デプロイ高速化など信頼性と直結 一見すると信頼性との関連性がないように 見えるが、SREとの結びつきが強い エンジニアの負荷を減らし、リリースサイ クルを円滑化させ、信頼性が担保された成 果物をデプロイし、障害時には迅速なロー ルバックを実現させる
28. ©MIXI リリースエンジニアリング 高い信頼性はリリースから始ま る CI/CDの整備や、安全なリリース手 法、デプロイ高速化など信頼性と直結 一見すると信頼性との関連性がないように 見えるが、SREとの結びつきが強い エンジニアの負荷を減らし、リリースサイ クルを円滑化させ、信頼性が担保された成 果物をデプロイし、障害時には迅速なロー ルバックを実現させる 後からやるとコスト増なので、最初期にやりましょう！
29. ©MIXI インシデント管理 障害時の対応を標準化す る
30. ©MIXI インシデント管理 障害時の対応を標準化す る 個々が自由に対応するのではなく、 "障害が起きたらこうする "を決める • ウォールームの設置 • 役割の設定 • エスカレーションプロセス 突然やりましょう！となっても上手く動く ことが難しいので、事前に ロールプレイ を やって慣れておきましょう
31. ©MIXI インシデント管理 障害時の対応を標準化す る 信頼性の毀損を最小化するための備え 個々が自由に対応するのではなく、 "障害が起きたらこうする "を決める • ウォールームの設置 • 役割の設定 • エスカレーションプロセス 突然やりましょう！となっても上手く動く ことが難しいので、事前に ロールプレイ を やって慣れておきましょう
32. ©MIXI ポストモーテム（ポストインシデントレビュー） インシデントをその後の糧にす る
33. ©MIXI ポストモーテム（ポストインシデントレビュー） インシデントをその後の糧にす る インシデントは解決して終わりでは ない インシデント後になるたけ早くチーム全体で行 う • インシデント状況の共通理解 • ネクストアクション を中心に記録し、話し合いすることで インシデ ントへのレジリエンスを高め 、より信頼性を高 めるキッカケにする
34. ©MIXI ポストモーテム（ポストインシデントレビュー） インシデントをその後の糧にす る 大事なのは"非難なき話し合い" インシデントは解決して終わりでは ない インシデント後になるたけ早くチーム全体で行 う • インシデント状況の共通理解 • ネクストアクション を中心に記録し、話し合いすることで インシデ ントへのレジリエンスを高め 、より信頼性を高 めるキッカケにする
35. ©MIXI これを踏まえて
36. ©MIXI 現場の話
37. ©MIXI 前提
38. ©MIXI 開発チーム：６名 SREチーム：　 　
39. ©MIXI 開発チーム：６名 SREチーム：１名
40. ©MIXI 少人数チームでの話
41. ©MIXI ここで分岐！
42. ©MIXI どちらの話を聞きたい？ 具体的なタスクや施策の 話 文化や進め方の話
43. ©MIXI 具体的なタスクや施策の 話
44. ©MIXI トイルの最適化 運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはた んまりありました。最初期はコスパの良いトイルを片付けていきましょう。 初期 • スクラム運用ツールの開発 • QA作業円滑化のためにデバッグツールを開発 • 開発環境の使用状況管理ツールの開発 • Xでのサービスに対するポストをSlack通知 • メンテナンスモードの簡易化
45. ©MIXI トイルの最適化 ❏ GH PJ上に各ステータスごとのストー リーポイント数を表示するChrome拡張 の作成 ❏ バーンダウンチャート可視化・管理
46. ©MIXI トイルの最適化 運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはた んまりありました。 初期 • スクラム運用ツールの開発 • QA作業円滑化のためにデバッグツールを開発 • 開発環境の使用状況管理ツールの開発 • Xでのサービスに対するポストをSlack通知 • メンテナンスモードの簡易化 初期はコスパの良いトイルを優先的に
47. ©MIXI トイルの最適化 運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはた んまりありました。 現在 • Slack bot × OpenAI APIでの自然言語による一時権限付 与 • GPTsを利用したQAチーム向けSQL作成支援 • Claude Code Actionを利用したRenovateの自動一次調 査 現在はAIの興隆で 最適化に新たな視点が芽生えた
48. ©MIXI リリースエンジニアリング git-flow, CI/CDをgit-pr-releaseやArgoCD, CircleCIを利用して構成
49. ©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビュー を行う • 障害概要 • 時系列 • 詳細 • 対応内容 • モニタリング情報 • 再発防止策 • 気付き • 参考情報
50. ©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビュー を行う • 障害概要 ◦ 「詳細な障害発生時刻」「対応者」「ステータス（どういう状態になったのか経過と結 果）」を記載 • 時系列 ◦ 箇条書きで「起こったこと」「行ったこと」についてコンパクトに記載 • 詳細 ◦ 「発生した要因」「発生に至った根本原因」「影響範囲」について記載 • 対応内容 ◦ 修正したPRのリンクや実行したコマンドなど、技術観点を忘れず対応した内容を記載
51. ©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビュー を行う • モニタリング情報 ◦ インシデントに気付いた際のモニタリング情報や、調査/解決までのプロセスで利用した モニタリング情報を記載 • 再発防止策 ◦ インシデントの再発を防止するための案を記載 ◦ チームで考えた結果を記載するのが良い • 気付き ◦ 個人的なメモ、教訓など気付いたことを記載 • 参考情報 ◦ インシデント対応で参考になった情報など
52. ©MIXI 他にも色々やってるよ！ • 小さなサービスでの SREとの付き合い方【MIXI TECH CONFERENCE 2023】
53. ©MIXI 他にも色々やってるよ！ • Fanstaの１年を大解剖！ 一人SREはどこまでできるのか！？
54. ©MIXI 他チームとのコラボレーション SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考 えなくてはいけない
55. ©MIXI 他チームとのコラボレーション ※ David N. Blank-Edelman 編, 山口 能迪 監訳、渡 邉 了介 訳 (2021年) SREの探求 - オライリージャパン より引用 SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考 えなくてはいけない 弾力性が高いサービスを構築するためには、考え方の多様性がチーム内に存在し ている必要があります。 この最後の要因は、技術的な知識のレベルよりもエンジニア同士の関係性のほう がはるかに大きな影響を与えます。※
56. ©MIXI 他チームとのコラボレーション SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考 えなくてはいけない 弾力性が高いサービスを構築するためには、考え方の多様性がチーム内に存在し ている必要があります。 この最後の要因は、技術的な知識のレベルよりもエンジニア同士の関係性のほう がはるかに大きな影響を与えます。※ ※ David N. Blank-Edelman 編, 山口 能迪 監訳、渡 邉 了介 訳 (2021年) SREの探求 - オライリージャパン より引用 個人的には信頼貯金を貯めるという考え方が好き 信頼貯金を貯めるフェーズ・消費するフェーズを分けて施策を変えていく
57. ©MIXI 文化や進め方の話
58. ©MIXI なぜSREを実践すること になったのか？
59. ©MIXI 経緯 ▪ 2021/03〜 とある機能の実装の流れからインフラをちょこちょこと触るようになる ▪ 2021/04〜 負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時 調査などのタスクに積極的に関わる ▪ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕 組み作りをしたり、インシデント管理をしたり・・・
60. ©MIXI これはSREというやつでは ・・・?
61. ©MIXI サービス規模に関わらず、SREは誰かが必ずやってい る 何故SREは必要となったか？ 気付いたら"SRE"と呼ばれることをやっていた
62. ©MIXI サービス規模に関わらず、SREは誰かが必ずやってい る 何故SREは必要となったか？ 気付いたら"SRE"と呼ばれることをやっていた ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチー ム SREとは、 ソフトウェアエンジニアに運用チームの設計を依頼したときにでき あがるもの です。※ 小さなチームでは運用チームを持たないことが多いので（雰囲気兼任が多い） "明確な"運用チームの動きが生まれたらそれがSREのはじまりと言える
63. ©MIXI SREの始め方 How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ Google社のブログ記事の中で６つのSREの導入パターンが紹介されています。 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started より引用
64. ©MIXI SREの始め方 How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ Google社のブログ記事の中で６つのSREの導入パターンが紹介されています。 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started より引用 1. SREも開発もやるなんでも屋さん 2. インフラの保守や、CI/CDなどの保守 3. SREに関するツールを開発・導入・運用 4. 主要なアプリケーションのみの信頼性向上を担 う 5. 特定の開発チームに組み込まれたSREチーム 6. 開発チームに組み込まれないSREチーム
65. ©MIXI SREの始め方 How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ Google社のブログ記事の中で６つのSREの導入パターンが紹介されています。 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started より引用 1. SREも開発もやるなんでも屋さん 2. インフラの保守や、CI/CDなどの保守 3. SREに関するツールを開発・導入・運用 4. 主要なアプリケーションのみの信頼性向上を担 う 5. 特定の開発チームに組み込まれたSREチーム 6. 開発チームに組み込まれないSREチーム 初期はこち ら
66. ©MIXI SREの始め方 How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ Google社のブログ記事の中で６つのSREの導入パターンが紹介されています。 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started より引用 1. SREも開発もやるなんでも屋さん 2. インフラの保守や、CI/CDなどの保守 3. SREに関するツールを開発・導入・運用 4. 主要なアプリケーションのみの信頼性向上を担 う 5. 特定の開発チームに組み込まれたSREチーム 6. 開発チームに組み込まれないSREチーム 今はこちら
67. ©MIXI １人でSREをやるのは中々難しい場 面が多いので出来れば複数人チーム で！
68. ©MIXI 何からやるか？
69. ©MIXI 何からやるか？ 何はなくともサービスにおける"信頼性"の定義から！ SLI/SLOを定義することにより、目指すべき信頼性を見える化す る
70. ©MIXI 何からやるか？ 何はなくともサービスにおける"信頼性"の定義から！ SLI/SLOを定義することにより、目指すべき信頼性を見える化す る まずはSLIの開発をして観 察 意味のあるSLOを設定してみ る 観察 更新
71. ©MIXI 何からやるか？ その後はDickersonの信頼性の階層構造 ※ を参考にするのがオススメ ※ David N. Blank-Edelman 著 / 山口 能迪 訳 (2024年) SREをはじめよう - オライリージャパン より引用
72. ©MIXI 何からやるか？ その後はDickersonの信頼性の階層構造 ※ を参考にするのがオススメ ※ David N. Blank-Edelman 著 / 山口 能迪 訳 (2024年) SREをはじめよう - オライリージャパン より引用 あくまでも一つの"型"。組織に合わせてプラクティスをチョイスしよ う！
73. ©MIXI 何からやるか？ 「SREをはじめよう」にもあるが、まずはモニタリング・オブザーバビリティ とインシデントレスポンスを整備することで、耐障害性を向上させる ※ David N. Blank-Edelman 著 / 山口 能迪 訳 (2024年) SREをはじめよう - オライリージャパン より引用 Done • Cloud Monitoringによるアラートポリシー拡充 • Cloud Loggingに沿った構造化ロギング • 各種サービスでのAudit Logsの導入と通知設定 • Cloud Trace × OpenTelemetryの導入 • 各種Runbookの作成
74. ©MIXI ▪ Audit Logsの通知例 過去の経緯からFirebaseでのサービスアカウント一覧画面の表示時に通知を出 すようにしている。 Audit Logsは基本取っておくようにしておくとよし
75. ©MIXI ▪ Cloud Trace
76. ©MIXI ▪ Cloud Trace - Span
77. ©MIXI 最後の分岐
78. ©MIXI どちらの話を聞きたい？ AIを使う未来の話 反省など過去の話
79. ©MIXI AIを使う未来の話
80. ©MIXI AIの荒波がやってきた！
81. ©MIXI もちろん SREも例外ではありませ ん
82. ©MIXI SRE × AIを考える SREのどこにでもAIを活用できる余地がある 既に関連サービスはいち早く取り組んでいる
83. ©MIXI SRE × AIを考える SREのどこにでもAIを活用できる余地がある 既に関連サービスはいち早く取り組んでいる • PagerDuty ◦ Agentic Site Reliability Engineer ◦ Agentic Operations Analyst ◦ Agentic Scheduler • Datadog ◦ Bits AI
84. ©MIXI SRE × AIを考える SREのどこにでもAIを活用できる余地がある 既に関連サービスはいち早く取り組んでいる • PagerDuty ◦ Agentic Site Reliability Engineer ◦ Agentic Operations Analyst ◦ Agentic Scheduler • Datadog ◦ Bits AI サービスを使うも良し、作るも良し。可能性は無限大！
85. ©MIXI 理解するためやってみた
86. ©MIXI SQL作成支援GPTs まずはお手軽にQAチーム向けにChatGPTのGPTsを作成 労力の割に効果が・・・
87. ©MIXI 一時権限付与ツール Slack botに自然言語でメンションを 飛ばすことでGCの一時権限付与を実 行
88. ©MIXI 一時権限付与ツール Slack botに自然言語でメンションを 飛ばすことでGCの一時権限付与を実 行 開発チームに存在した • スラッシュコマンドでの複雑さ • 適切なロールを探し出す手間 を解決！
89. ©MIXI 一時権限付与ツール Slack botに自然言語でメンションを 飛ばすことでGCの一時権限付与を実 行 開発チームに存在した • スラッシュコマンドでの複雑さ • 適切なロールを探し出す手間 を解決！ OpenAI API（Responses API）,VectorStore, Function Callingで 実装
90. ©MIXI 作る以外もやるよ！ "モノをつくる"以外にも様々なAIに関するアレコレを一手に引き受けた • AI利用の書類業務 ◦ 申請 / 契約や、それに付随する説明 • 利用推進 ◦ Slackチャンネルを作成し、AIに関する情報を逐一放流 ◦ 困っている利用者の拾い上げ • ガイドラインなどのドキュメント整備 ◦ Claude Codeなどツールの利用ドキュメント ◦ MCPサーバーの安全利用のためのガイドライン • etc…
91. ©MIXI まだまだやりたいことがあ る！
92. ©MIXI 楽しいからやる は大事
93. ©MIXI 価値を生むために AIを利用する も大事
94. ©MIXI Andrej Karpathy曰く ※ アイアンマンスーツのようにaugmentation（能力拡張）と agent（自律エージェント）が調節できるような "autonomy slider"を今後10年間でagentに徐々に動かしてい くことが重要になってくる SREもこの流れがきているので乗っていこ う！ ※ Andrej Karpathy: Software Is Changing (Again) (2025年) https://www.youtube.com/watch?v=LCEmiRjPEtQ
95. ©MIXI 反省など過去の話
96. ©MIXI 色々やってきたが もちろん失敗もある
97. ©MIXI 失敗事例１：目安箱 開発チームが潜在的に抱えている問題を拾い上げるために目安箱を設置
98. ©MIXI 失敗事例１：目安箱 開発チームが潜在的に抱えている問題を拾い上げるために目安箱を設置 投票数が少なく、目立った効果を上げることは出来ず撤廃 ・・・
99. ©MIXI 失敗事例１：目安箱 開発チームが潜在的に抱えている問題を拾い上げるために目安箱を設置 投票数が少なく、目立った効果を上げることは出来ず撤廃 ・・・ 原因１ 導入時期の問題 • リリースからまだ日が経っておらず、問題として 出やすい運用に関するトイルが生まれていなかった • 新規メンバーが入ってまだ間もないタイミングだった 原因２ トイルの自覚 • トイルがトイルだと自覚されずに律儀に対応されてし まっていた
100. ©MIXI 失敗事例２：相談アワー 対面で相談を受け付けるための相談アワーを試してみた
101. ©MIXI 失敗事例２：相談アワー 対面で相談を受け付けるための相談アワーを試してみた 成果に繋がる相談もあったものの、利用頻度が低く撤廃・・・
102. ©MIXI 失敗事例２：相談アワー 対面で相談を受け付けるための相談アワーを試してみた 成果に繋がる相談もあったものの、利用頻度が低く撤廃・・・ 原因１ バーチャルオフィスの利用率低下 • チームとしてGatherを使っていたが、そもそもバー チャルオフィスの利用率が段々低下した 原因２ 作業時間の確保を優先 • 終了理由ではあるのですが、SREにかけられる時間が 増えてきた時期で作業時間確保を優先したため
103. ©MIXI 失敗したが後に リベンジしたパターンも
104. ©MIXI 失敗→成功事例：依存ライブラリのアップデート運用 Renovateを利用したライブラリアップデートを一人で担っていた そのため、頻度が半年に一回に・・・
105. ©MIXI 失敗→成功事例：依存ライブラリのアップデート運用 Renovateを利用したライブラリアップデートを一人で担っていた そのため、頻度が半年に一回に・・・ リベンジ 運用を開発チームを巻き込む形に • コラボレーションの意識が希薄だったなと反省をもと に運用に開発チームを巻き込むことにした • 今ではスプリントプランニングにライブラリアップ デートを盛り込んでもらえることに • さらに、AIを活用してClaude Code Acitonを利用し た一次調査、またアップデートにもClaude Codeを利 用
106. ©MIXI 失敗→成功事例：依存ライブラリのアップデート運用 Renovateを利用したライブラリアップデートを一人で担っていた そのため、頻度が半年に一回に・・・ リベンジ 運用を開発チームを巻き込む形に • コラボレーションの意識が希薄だったなと反省をもと に運用に開発チームを巻き込むことにした • 今ではスプリントプランニングにライブラリアップ デートを盛り込んでもらえることに • さらに、AIを活用してClaude Code Acitonを利用し た一次調査、またアップデートにもClaude Codeを利 用 失敗も糧にして成功施策を生み出していこう！
107. ©MIXI エンディング
108. ©MIXI インタラクティブ・セッショ ン いかがでしたでしょうか？
109. ©MIXI この発表を通じて SREに少しでも興味を持って いただければ幸いです
110. ©MIXI 宣伝！① 2026/01/31にSRE Kaigiというカンファレンスを開催します！！！！！ 
 今回の発表でSREに興味が出たらぜひ来てね！！✌ 

111. ©MIXI 宣伝！② SRE MagazineというSREに関するWebマガジンや、ゆるSRE勉強会という勉強会も定 期開催しているよ！ 

112. ©MIXI 　ご清聴ありがとうございました