©MIXI 1 『家族アルバム みてね』における インシデント対応との向き合い⽅ 2026/05/28 【⽇経×MIXI×カカクコム】SREで築く障害耐性〜⻑期運⽤を⽀える復旧⼒〜 @kohbis 

2 ©MIXI ABOUT ME Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X / @kohbis 好きなPagerDuty通知⾳は「Morse Code」※1 ※1 https://speakerdeck.com/tk3fftk/sorosoroon-callnotong-zhi-yin-nituitekao-etemiyou-pagerdutybian 

3 ©MIXI 『家族アルバム みてね』について（1/2） 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 

4 ©MIXI 20,000,000 15,000,000 10,000,000 5,000,000 0 25,000,000 国内 海外 ※ iOS‧Android™ アプリ登録者数、ブラウザ版登録者数の合計 2015年にリリースから、7⾔語‧175の国と地域で3,000万⼈以上の⽅にご利⽤いただいています。 『家族アルバム みてね』について（2/2） 人数 年月 30,000,000 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026.5 

5 ©MIXI みてねのインシデント対応フロー（ざっくり） 完了 終息宣言 恒久対応/振り返り 対応 主に暫定対応 切り戻し/緩和 調査 アラート確認 エスカレーション 検知 PagerDuty/Slack オンコール制度については 『家族アルバム みてね』を⽀えるオンコールエンジニア制度 

6 ©MIXI 『家族アルバム みてね』における障害耐性はなんのため？ 【前提】みてねは「家族の思い出」をあずかるサービス 【体験】 • 写真や動画を閲覧できる • 写真や動画をアップロードできる • 家族に共有できる • 商品を注⽂できる、家族に届く • 問い合わせや不安につながらない これらの「体験を損ねる」のがインシデント みてねの障害耐性は「家族の思い出にアクセスできる状態」を守るためにある 

7 ©MIXI ゼロにはできない障害 発⽣したときに「なに」と「どのように」向き合うのか 「抑制‧復旧‧学習」の前に「なにを⾒て」「どう判断するか」がある 観点 意味 観測する 家族体験の異常に気づく 判断する どの体験が壊れているかを特定する 抑制する 影響を小さくする 復旧する 通常利用できる状態に戻す 学習する 次回より早く修正する、小さく抑える 

8 ©MIXI 観測 〜みてねではなにを⾒るのか〜 ※上段で検知できるものがほとんどだが、下段で検知するものも実際には存在する レイヤー 気づきたいこと API（Ruby on Rails） 閲覧・投稿・共有など主要機能の失敗や遅延 K8s（Amazon EKS） スケール不足、リソース逼迫、 Pod配置・起動失敗 データベース クエリ遅延、読み書き性能低下、コネクション枯渇 バックグラウンドジョブ キュー滞留、処理遅延、リトライ増加 CS問い合わせ 問い合わせ増加、実ユーザー影響 ビジネス指標 注文数・利用率・CVRなどの異常な変化 

9 ©MIXI 観測するものと、アラートするものを整理する サービスの成⻑によって、⾒るべきものはあらゆる⽅向に増加する ➡ すべてにアラートを鳴らすと運⽤できない ➡ すべてをオンコール対象にはしない 観測対象は広く持ちながらも 「なにをオンコール対象にするのか」≒ 「なにが守るべき体験なのか」が重要 障害耐性は、どうやってもサービスを運⽤する組織（≒ ⼈間）に依存する ➡ 仕組み化しても⾒るべきが広いと限界を迎える 棚卸しや閾値などの継続的な⾒直しも重要 

10 ©MIXI 判断 〜体験への影響から⾒る〜 まず⾒るのは「原因」ではなく「ユーザー体験への影響」 観点 見たいこと 体験 閲覧 / アップロード / 共有 / 登録などのどこに影響しているか 範囲 全ユーザーか、一部ユーザーか、特定 OSだけか 条件 特定OS / ユーザー / 機能などに偏っているか 深刻度 完全に使えないのか、遅いのか、一部失敗しているのか 回避策 一時停止 / 切り離し / リトライで影響を抑えられるか 外部影響 CS問い合わせ、注文数、利用状況に変化が出ているか 

11 ©MIXI 抑制 — 影響を⼩さくする 影響を広げないために、状況に応じてサービスの動かし⽅を変える 対応 例 止める 一部機能停止、メンテナンスモード 絞る バッチ処理やバックグラウンドジョブの停止 緩める オートスケール閾値変更、リソース増強、制限値の一時緩和 切り離す 問題のあるリージョン、ジョブ、外部連携、特定機能の切り離し 逃す Read-only化、キャッシュ利用、リトライ抑制 

12 ©MIXI 復旧 — 通常利⽤できる状態に早く、確実に戻す 「復旧」に必要なものが事前にどれだけ準備されているか（オンコール制度含む） たとえば • 誰が対応を始めたか分かる • 作業ログが残る • 最初に⾒る場所が分かる • Runbookにたどり着ける • 必要に応じてエスカレーションできる • 暫定対応を戻し忘れない etc. 障害耐性を⽀える復旧⼒は運⽤の積み重ねによって実現する 運⽤が確⽴されていなければ仕組み化‧⾃動化にもつなげられない 

13 ©MIXI みてねにおけるオンコール担当の条件 障害対応時に適切なコミュニケーションができること • できるだけ早く反応できる • 必要な連絡先を判断し円滑にコミュニケーションを⾏うことができる • 対応ログを適切な箇所に残しながら作業ができる AWSや各種モニタリングツールの扱いに慣れていること • 原因特定のためにモニタリングツールを利⽤しそのメトリクスを理解している • ログの検索‧保全ができる • 適切な負荷対策ができる ⾃分のスキルに過度な⾃信を持っていないこと • 個⼈で判断せずエスカレーションポリシーを遵守できる 

14 ©MIXI 学習 〜次回の検知‧緩和‧復旧を改善する〜 復旧して終わりにしない ➡ ポストモーテムで⾒ること ➡ 何が起きたか / どの体験に影響したか / どう検知したか / どう判断したか / どう抑制 したか / どう復旧したか / 次にどう早く気づくか / 次にどう影響を⼩さくするか etc. 学びの反映先 • アラート条件‧通知 • Runbook • 障害対応フロー • オンコールトレーニング ポストモーテムは、次の運⽤を変えるためにある ➡ みてねではエンジニア組織全体にポストモーテムを書く⽂化がある 

15 ©MIXI それでも悩ましいインシデント管理 過去に挙げていた悩み ※1 • Runbook不⾜ ➡ アラートにページリンクを追加するように徐々に充⾜ • 原因調査の属⼈性 ➡ Runbook同様に地道なドキュメント追加 • インシデントコマンダー不在 • ポストモーテム作成が後回し ➡ AIの活⽤により⼤幅に改善 とはいえ、今も簡単ではない • コンポーネント‧監視対象が増える • ユーザー体験との対応づけが難しい • 情報共有の場づくりが難しい • Runbookを最新に保つのが難しい ※1 https://speakerdeck.com/kohbis/insident-management-is-a-tough 

16 ©MIXI おまけ 〜今後のAI活⽤〜 みてねでは、⼀部でAI活⽤ • インシデント発⽣時の調査、修正 • Slackチャンネル（ウォールーム）からポストモーテム⾃動⽣成（Notion AI） • 根本原因への対策や恒久対応など本当に⼈間が考えるべきこと以外は AIによる⾃動⽣成 AWS DevOps Agent ※1 の検証実施中 重要となるのはこれまでの蓄積 ➡ アラート / Runbook / 対応履歴 / ポストモーテム etc. AIを活かすにも、まず⼈間が何を⾒て判断しているかを整理する必要がある ※1 https://aws.amazon.com/jp/devops-agent/ 

17 ©MIXI まとめ みてねの障害耐性は、家族体験を守るための運⽤改善 障害はゼロにできない • だから、何を⾒るかが重要 • 何を守るかを判断する • アラートはすべてで鳴らさず、⼈間が対応すべきものを設計する • 復旧⼒は、ツール‧Runbook‧エスカレーション⽂化で⽀える • 学びを次の観測‧判断‧抑制‧復旧に戻す 運⽤は完成しない 「家族の思い出をあずかる」サービスだからこそ、⾒るべきものを⾒直し続ける 

©MIXI 18 ありがとうございました