# 変更起因インシデント ## 定義 変更起因インシデント(Change-Induced Incidents, CII)とは、ソフトウェア・構成・データ・インフラへの変更が直接の引き金となって発生するインシデントのこと。大規模オンラインサービスシステムにおける主要なインシデント原因の一つであり、変更を行わなければ起きなかった障害として、通常インシデントと区別して分析される。 ライフサイクルは「**導入(Introduction)→ 検知(Detection)→ 緩和(Mitigation)**」の 3 段で構成される([[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]])。[[インシデント管理]] の 4 段(検知→トリアージ→診断→緩和)と相補的で、「導入」段が変更起因インシデント固有の分析対象となる。 ## 主要統計(2 つの実証研究から) | 指標 | Zhao+ ISSRE2023 | Wu+ ICSE-SEIP2023 | |-----|-----------------|-------------------| | データセット規模 | 231 件 / 2 年間 | 161 件 | | 最多変更種別 | コード変更 54.5% | コード変更 54.7% | | 第 2 位変更種別 | 構成変更 28.1% | アプリ構成変更 22.4% | | 最多緩和策 | ロールバック 50.6% | ロールバック(最多) | | 重篤度(High+Critical) | — | 通常の 2.6 倍(13% 対 5%) | ## 変更カテゴリと根本原因 ### 変更カテゴリ 大規模オンラインサービスの 2 研究で一貫してコード変更が最多(54–55%)、構成変更が 2 位(22–28%)。 - **コード変更** ≈54%: バグ修正・機能追加・リファクタリング - **構成変更** 22–28%: 環境設定・機能フラグ・パラメータ変更 - **データ変更** 9–11%: スキーマ変更・マイグレーション - **インフラ変更** 6–11%: ハードウェア・ネットワーク・プラットフォーム変更 - **トラフィック変更** 3%: ルーティング・重み変更(Ant Group のみ) ### 根本原因(ISSRE2023 より) - ロジックエラー 42.9% - 非互換性 23.4% - デプロイ問題 16.0% - 性能問題 14.3% - データ不整合 3.5% ## インシデント導入タイミング - **デプロイ中**: 37.2%(カナリアリリースでは 76.8% がここに集中 → 早期顕在化) - **デプロイ直後**: 45.9%(全デプロイ完了後の即時影響) - **しばらく経過後**: 16.9%(性能問題起因の 54.5% はここ → 遅延顕在化) → **デプロイ後の監視設計**が重要: カナリアリリース + 長期モニタリング(性能系は特に)が必要。 ## 検知の問題 モニタリングによる自動検知が TTD の 7.67 倍高速(65.6 対 564.0 時間単位)にも関わらず、50.6% のインシデントで利用者が先に検知する。 ### モニタリング失敗の 3 類型(ISSRE2023) 1. **モニター未設定(46.2%)**: 変更後に必要な新規メトリクス/アラートが未定義 2. **監視不能なインシデント(35.0%)**: 変更の影響が既存の観測可能なシグナルに現れない 3. **異常未認識(18.8%)**: メトリクス逸脱は観測されるが閾値/ルールで捉えられない ### 4 課題(ICSE-SEIP2023) 1. **不足したモニタリング指標**: 変更の影響範囲に対応するメトリクスの欠如 2. **不正確な変更モニタリング**: 変更影響範囲とモニタリング対象のミスマッチ 3. **低ビジネストラフィック**: 変更直後の低トラフィックで問題が顕在化しない 4. **非効率な異常変更箇所特定**: 多数の同時変更からの問題変更の絞り込み困難 ## 緩和戦略 ### 緩和プロセスの分類(ISSRE2023) **RaIC (Recovery after Immediate Cause)**: 64.5% - 問題の即時原因を完全に取り除いてから回復 - 例: ホットフィックス適用 → サービス正常化 **RbIC (Recovery before Immediate Cause)**: 35.5% - 即時原因の除去前に緩和手段を先行させる - 例: ロールバック(変更を元に戻す) → 即時回復 - **TTM が 40.6% 短縮**(65.3 対 38.8) ### 緩和手段の分布 | 手段 | ISSRE2023 | |-----|----------| | ロールバック | 50.6% | | ホットフィックス | 16.5% | | ハイブリッド | 13.4% | | トラフィックスイッチ | 7.4% | | フォールバック | 6.5% | | インフラ変更 | 3.0% | | 無操作 | 2.6% | → **ロールバックが最善策の筆頭**であり、RbIC が有効な理由でもある。ただし 18.6% のインシデントで緩和が一度失敗し、失敗した場合の TTM は 87% 増(88.2 対 47.2)。 ## 横断的知見 - **2 つの独立した実証研究(アリババ/PKU と Ant Group/PKU)でコード変更が最多という事実が再現する**: ISSRE2023(231 件)と ICSE-SEIP2023(161 件)でそれぞれ 54.5% と 54.7% とほぼ同値。単一企業のバイアスとは言えず、大規模オンラインサービス環境における変更起因インシデントの変更カテゴリ分布は「コード 55%・構成 22–28%」がある程度の普遍性を持つと推測できる。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - **モニタリング失敗の「未設定 46.2%」は変更と監視設定の独立性という組織的問題を示す**: モニタリング未設定が失敗の最大原因であることは、変更プロセスにモニタリング設定レビューが組み込まれていないことを示す。[[SRE Book]] の「章 10 Practical Alerting」の宣言型ルール評価が解こうとした問題の別形——変更のたびに関連するアラートルールを作成・更新するプロセスが組織的に確立されていない。AlertGuardian の rule refinement エージェント([[インシデント管理]])は後付けでルール品質を改善するが、理想は変更レビュー時に必要な監視設定を予測・提案するフロントランニング。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **変更起因インシデントは重篤度と解決時間の両方で通常インシデントを大きく上回り、「変更管理の失敗は代償が大きい」を定量化した**: Ant Group の実証(ICSE-SEIP2023)は High/Critical 重篤度が 2.6 倍、TTD 75 パーセンタイルが 26.8 倍という数値を示す。この非対称性(頻度は同等でもコストが高い)は、変更起因インシデントへの投資対効果が高いことを意味する——[[SRE Workbook]] の Appendix C が「変更起因障害の多さ」をポストモーテム分析で取り上げたのと同じ構造で、2023 年の実証データで定量化された。(Source: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]], [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]]) - **RbIC(原因除去前回復)が RaIC より 40.6% 速いという知見は、自動ロールバックへの投資を強く支持する**: ロールバックが最多緩和策(50.6%)かつ RbIC の主な手段であり、TTM を大幅短縮することが実証された。これは CD/CI パイプラインにおける自動ロールバック機構の価値を直接裏付ける。ただし緩和失敗率 18.6% は「一度目のロールバックが失敗する(依存サービスの問題・スキーマ非互換等)」ケースがある程度存在することを示し、ロールバックの事前テスト(dry-run/staging 環境検証)の重要性も示唆する。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - **ChangeRCA が ACD → RCCA 問題昇格を定式化**: [[@2024__FSE__ChangeRCA - Finding Root Causes from Software Changes in Large Online Systems|Yu+ FSE2024]] は既存 ACD(Abnormal Change Detection、変更の異常度判定)から RCCA(Root Cause Change Analysis、複数 changes から defective change を pinpoint)へ問題を昇格。ACD は変更の異常性を判定するが「どの変更が原因か」は分からない。RCCA は影響面・変更フロー・KPI 差分を統合してこの問いに答える。WeChat 本番 30 件 + OnlineBoutique シミュレーション 51 件で HR@1=85.78%、HR@3=96%、FUNNEL/SCWarn/Gandalf を 20–28 ポイント超え、TTI 90% 削減。(Source: [[@2024__FSE__ChangeRCA - Finding Root Causes from Software Changes in Large Online Systems]] §1, §4) - **多モーダル変更評価の系譜**: [[@2021__ESEC-FSE__Identifying Bad Software Changes via Multimodal Anomaly Detection|MultiModal Bad Change(2021)]] → [[@2024__FSE__ChangeRCA - Finding Root Causes from Software Changes in Large Online Systems|ChangeRCA(2024)]] → [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models|LLM Change Assessment(2025)]] の 4 年スパンで「マルチモーダル異常検知 → RCCA → LLM ベース評価」へ進化。データソースの統合(KPI+ログ+トレース+変更フロー)が一貫した方向。(Source: [[@2021__ESEC-FSE__Identifying Bad Software Changes via Multimodal Anomaly Detection]] §1, [[@2024__FSE__ChangeRCA - Finding Root Causes from Software Changes in Large Online Systems]] §2, [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] §1) - **Sillito & Kutomi 2020 の観察 4 が示す「設定変更はコード変更と同等のリスクを持つが、同等のプロセスを経ない」という構造的欠陥は、22–28% という設定変更インシデント比率の根本説明となる**: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-A 観察 4 は、テスト環境が本番を再現できないケースのうち、設定変更においてその問題が特に深刻であると指摘する(「設定変更はコード変更と同じくらい影響が大きいが、同じプロセスを経ない」\[1.11\])。ISSRE2023 の 28.1%、ICSE-SEIP2023 の 22.4% という設定変更比率は、このプロセス的非対称性に起因する可能性が高い。コード変更では CI/CD パイプライン・コードレビュー・ステージング環境テストが確立されているが、設定変更は本番への直接適用・即時有効化という性質を持ちやすく、テストが追いつかない。AlertGuardian の rule refinement が「モニタリングルールの品質問題」を扱うのに対し、この観察は「変更プロセス自体の非対称性」という上流の問題を指摘している。(Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-A, [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - **「カナリアリリースでは 76.8% がデプロイ中に顕在化する」という統計を、実際のカナリア判定システムの内部設計が裏付ける**: ISSRE2023 の実証統計(本節「インシデント導入タイミング」)は、なぜカナリア段階で早期顕在化するかまでは説明しない。[[@2018__acmqueue__Canary Analysis Service]] は Google の CAS がカナリア/対照母集団のペアごとに統計検定(check)を実行し、いずれか1つでも FAIL すれば評価全体を即座に FAIL として返す設計であることを示す——この「粒度の細かい即時判定」の仕組みが、統計上観測される早期顕在化を可能にする具体的メカニズムだと言える。ただし CAS 自身も「同一環境過学習」により意図的な性能トレードオフを誤検知しうると認めており、早期顕在化の裏には自動判定特有の誤検知リスクも伴う。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2018__acmqueue__Canary Analysis Service]]) - **Gandalf は「メトリクス統計比較」ではなく「イベント相関による犯人特定」で変更起因インシデントに対処する、CAS とは異なる技術的アプローチを示す**: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]] は、Microsoft Azure で 1 日数百件が同時進行するロールアウトの中から、障害シグナルをどのロールアウトに帰責すべきかを空間・時間相関(vote-veto → 時空間相関 → 時間減衰)で判定する。CAS がカナリア/対照母集団のメトリクス分布を統計検定で比較するのに対し、Gandalf は「同時に何十ものコンポーネントがデプロイされている」という Azure 特有の状況(1クラスタあたり平均1日複数回のデプロイ、Figure 9)を前提に、複数の同時進行ロールアウトの中から単一の「犯人」コンポーネントを特定する設計になっている。ISSRE2023 が定量化した「変更起因インシデントの 45.9% はデプロイ直後に顕在化する」という統計は、Gandalf のようなロールアウト直後 1 時間を対象にした Speed Layer 監視の設計動機と直接対応する。(Source: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]], [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - **Gandalf は 18 ヶ月の本番運用で「モニター未設定(46.2%)」問題への対処を、コンポーネントオンボーディング時の必須データスキーマ化で先回りする**: ISSRE2023 のモニタリング失敗 3 類型のうち最大の原因は「変更後に必要な新規メトリクス/アラートが未定義」であることだった(§検知の問題)。Gandalf は新規コンポーネントのオンボーディング時に、デプロイイベントスキーマ(Table 1)と障害シグナルスキーマ(Table 2)への準拠を要求する構造化されたデータ取り込みプロセスを設けている(§3.3)。これは「変更のたびに関連する監視設定を作成・更新するプロセスが組織的に確立されていない」という同 concept の既存知見が指摘する問題に対し、監視サービス側がデータ契約を強制することで部分的に対処する実例と言える。ただし Gandalf 自身も latent issue によって誤ってコンポーネントを blame するケース(§5.2、あるエージェント更新の folder 削除が後の更新で顕在化)を認めており、スキーマ強制だけでは因果関係の誤帰属を完全には防げない。(Source: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - **Aegis の「build レベルでの意思決定統合」は、変更起因インシデントの「異常変更箇所特定(fault localization to change)」課題への具体的解法である**: 本 concept の未解決の問いが指摘してきた「多数の同時変更からの問題変更の絞り込み困難」(ICSE-SEIP2023 の課題 4)に対し、[[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]] は、高い並行デプロイ濃度下でも component build version 単位で相関スコア分布を集約すれば、バグのある build(右裾の長い分布)と無実の build(スコア 0 付近に集中)を分離できることを実証する。これは変更起因インシデントの「導入(Introduction)」段の課題を、統計的な分布形状という具体的な信号に落とし込んだ解法である。(Source: [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]], Figure 6) - **Aegis のケーススタディ 2 件は「モニタリング未設定(46.2%)」と「異常未認識(18.8%)」の両モニタリング失敗類型を、cross-component・cross-layer 相関で部分的に埋める実例である**: Case 1(RNM のビルド欠陥が CRP の VMSS 作成失敗として顕在化)は、CRP チームが RNM の変更を監視対象に含めていなかった(モニタリング未設定に相当)状況を、component 横断の相関で救済した例。Case 2(AzSM のロールアウトが CRP の失敗として顕在化し、根本原因は AzCPGateway という Aegis が全くカバーしていなかった component)は、直接の監視対象外(AzCPGateway)の障害が、間接的な依存チェーンを辿った相関によってようやく発見された例であり、component レベル監視の限界(「非効率な異常変更箇所特定」)を cross-layer 相関がどこまで補えるかの実例を提供する。ただし AzCPGateway 自体は Aegis のカバレッジ外のままであり、依存関係が深いほど相関だけでは解決しきれないことも同時に示す。(Source: [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]], §IV-B) - **同一 Azure チーム内で「component レベル(Gandalf, 2020)→ component/layer 横断(Aegis, 2023)」という設計拡張が起きたことは、変更起因インシデントのモニタリング失敗類型が段階的に解消されていくプロセスの実例である**: [[Gandalf]] と Aegis は著者陣の一部(Murali Chintalapati・Ken Hsieh・Qingwei Lin・Yingnong Dang)が重複しており、同じチームが自らの component レベル監視の限界(「スコープが自 component に限定される」)を、後継システムで cross-component・cross-layer 対応へ拡張した経緯が読み取れる。これは 3 年という比較的短期間で、変更起因インシデント対策の技術的スコープが組織的に拡大された事例であり、モニタリング失敗類型(未設定・監視不能・異常未認識)への対策が一度の設計で完結せず反復的に進化することを示す。(Source: [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]], [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - **ブルー/グリーンデプロイのアーキテクチャは、RbIC が RaIC より40.6%速いという統計の背後にある具体的なメカニズムを与える**: 本 concept の既存知見は、ロールバック(RbIC の主な手段)が最多緩和策(50.6%)かつ TTM を大幅短縮することを実証データから示したが、なぜロールバックがそれほど速いのかというメカニズムまでは論じていなかった。[[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.6 が描くブルー/グリーンデプロイは、新バージョン(グリーン)へ切り替えた後も旧バージョン(ブルー)のインスタンスを一定の待機時間そのまま残しておき、「新しいリリースでエラーが増えるようなら、古いリリースにトラフィックを戻せばよいだけ」と述べる。これは ISSRE2023 が定量化した「原因除去前の回復」(RbIC)が、単なる運用上の判断ではなく、あらかじめ旧環境を破棄せず温存しておくというアーキテクチャ上の設計によって高速化されていることを裏付ける——ロールバックの速さは、ロールバック操作自体の効率ではなく「戻す先がまだ生きている」という前提条件に由来する。ただし ch.24 のブルー/グリーンは §24.5 で述べる「動作に問題のあるインスタンスの交換」のような単純な障害を想定しており、ISSRE2023 が指摘する緩和失敗率 18.6%(依存サービスの問題・スキーマ非互換等でロールバックが一度失敗するケース)への言及はなく、両ソースを合わせても「旧環境を残す」設計だけでロールバック失敗を完全に防げるわけではないことが分かる。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.6) - **「最終デプロイのタイムスタンプをメトリクスと並べて可視化する」という 2011 年の実務は、Gandalf・Aegis が自動化する「変更と障害シグナルの相関」を人手で行う最も単純な先行形態である**: 本 concept が扱う Gandalf・Aegis はいずれも大量の同時進行デプロイの中から犯人コンポーネントを統計的・相関的に特定する自動化システムだが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] は 2011 年時点で、[[Flickr]] が最終デプロイのタイムスタンプを Ganglia のヘッダに常時表示し、性能劣化のグラフと突き合わせて「直近の変更」に人手で遡るという実践を報告する(§3.6)。これは変更起因インシデントの「導入(Introduction)→検知(Detection)」段を、統計モデルではなく「時刻の並置」という最小限の可視化だけで橋渡しする方法であり、Gandalf の時空間相関や Aegis の build レベル分布集約が自動化する判断を、人間の目視比較で代替していた原初的な形態と言える。単一デプロイ・単一チームの前提が成り立つ小規模な運用では、この単純な可視化だけで十分に機能していたと考えられ、Gandalf・Aegis のような自動相関が必要になったのは「同時多発デプロイ」というスケールの問題であることが、2011 年の実務との対比から浮かび上がる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.6, [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - **IMVU の「[[クラスタ免疫システム]]」(2011)は、Gandalf・Canary Analysis Service が10年近く後に精緻化する「デプロイ中の早期異常検知→自動停止」を、統計的手法を持たない単純なルールベースの形で先取りしていた**: 本 concept が集約する Gandalf(2020)・Canary Analysis Service(2018)は、いずれもカナリア/対照母集団の統計検定や時空間相関によって、進行中のロールアウトの中から問題のある変更を特定し自動的に対処する。[[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]](エリック・ライズ)が紹介する IMVU のクラスタ免疫システムは、変更をマシン1台ずつ順番にデプロイし、クラスタと個々のマシンの健康状態を監視して問題があれば変更を拒否・リバートし、解決するまでデプロイをロックするという設計であり、目的(問題のある変更をクラスタ全体に広がる前に食い止める)は Gandalf・CAS と同型である。ただし統計検定や相関アルゴリズムは持たず、単純な閾値ベースの健康チェックにとどまる点で、自動化ロールアウト監視という発想の実務的な原型に位置づけられる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4, §4.6.3, [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]], [[@2018__acmqueue__Canary Analysis Service]]) - **MagmaScope は変更チケット記述の断片性・意味的不整合という変更管理の根本的課題を LLM による意味的正規化(Change Object Rewrite)で緩和し、インシデント後の根本原因変更特定を「変更チケット検索→軽量ランキング→エージェント推論」の 3 段パイプラインとして実装した**: [[MagmaScope]]([[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]], ICSE-SEIP '26)は、[[ByteDance]] 本番 55 件の緊急インシデントにおいて、24 時間前の変更チケット群から根本原因変更を特定する設計を採用する。本 concept が整理してきた「異常変更箇所特定(fault localization to change)」の課題 4(ICSE-SEIP2023)に対し、MagmaScope は変更チケット自体が「断片的・意味的に不整合」であるという問題を直視し、LLM が変更チケット記述を標準化した Change Object(COR、[[Change Object Rewrite]])に書き直す前処理を導入する。ChangeRCA(FSE2024)が KPI+変更フローの相関に依拠するのに対し、MagmaScope は IM グループチャットという「インシデント対応中の人間の診断ストリーム」を細粒度推論のコンテキストとして活用する点が設計上の新軸。ただし、全インシデントが change-induced であることを前提とし、評価は ByteDance 固有の IM ワークフロー・専門用語・55 件という規模に制約されており、change-induced 以外のインシデントへの拡張性は未検証。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3.1-§3.4, Tables 1-2) ## 未解決の問い - 変更起因インシデントの 4 課題(ICSE-SEIP2023)のうち「低ビジネストラフィック」への対応として、カナリアリリースにシャドウトラフィック・合成負荷・暗黙テストを組み合わせる手法はどこまで実用的か。変更種別(コード/構成/インフラ)によって有効な補完手段は異なるか。([[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - 性能問題起因のインシデントの 54.5% が「しばらく経過後」に顕在化するという知見は、デプロイ後の監視期間をどう設定すべきかを問う。P50 / P99 等のパーセンタイルで何日間監視を続けるか——業種・変更規模・システムの自然変動によって最適値はどう変わるか。([[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - RbIC を実現するロールバックには、データベーススキーマ変更・API 互換性・依存サービスの前提などが障害になりうる。どの変更カテゴリで RbIC が実行可能で、どのカテゴリで RaIC しか選択できないかの体系的整理はあるか。ロールバック可能性の事前評価は変更レビュープロセスに組み込めるか。 - 変更起因インシデントの「異常変更箇所特定(fault localization to change)」は、既存の [[Fault Localization]] と手法的にどう異なるか。変更の因果グラフを活用した特定手法([[根本原因分析]]との接点)は現在どこまで研究されているか。([[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - 2 論文の著者グループは共通して [[Ying Li]](PKU)を含む。同グループが ISSRE2023 と ICSE-SEIP2023 の 2 本で PKU/アリババ・PKU/Ant Group という異なる企業との共研究を公開しているが、両研究の分析枠組みの違い(ライフサイクル分析 vs 特性比較+課題)は企業の関心の違いを反映するか、あるいは学術的設計の差異か。 - ChangeRCA の RCCA(複数 changes 中から defective を特定)と AlertRCA(アラートだけで RCA)を組み合わせて「変更 + アラート」から原因変更を特定する end-to-end 設計は未提示。両者の入力(変更フロー vs アラートイベント)を統合した本番運用事例の研究余地。 - SCELM([[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]])は ECD・FT・RCCA を 1 パイプラインに統合した最初の事例だが、「変更票の記録正確性」という組織的制約を知識ベース品質の律速要因として指摘している。自動化システムが記録精度の悪化を検出・補正する機構の設計が未解決。 - Gandalf の相関分析は「進行中のロールアウト」を前提としており、ChangeRCA が指摘するように完了済み変更の遅延顕在化障害には対応できない。ISSRE2023 が定量化する「しばらく経過後(16.9%)」の変更起因インシデントに対し、Gandalf 系の相関分析ベース手法(進行中ロールアウト前提)と RCCA 系手法(完了済み変更対応)のどちらがどの障害クラスに向いているかの体系的な使い分け指針は確立されていない。([[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - ブルー/グリーンデプロイのように旧環境を意図的に温存する設計は、ロールバック速度を高める一方でインフラコスト(二重台数の一時運用)を伴う。ISSRE2023・ICSE-SEIP2023 のデータセットには、この種のアーキテクチャ上の投資がどの程度 RbIC 比率・TTM 短縮に寄与したかを分離した分析はなく、ロールバック速度に対する「アーキテクチャ要因」と「運用プロセス要因」の寄与度を切り分ける実証研究の余地がある。([[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]]) ## 関連 - **概念**: [[インシデント管理]] / [[AIOps]] / [[根本原因分析]] / [[異常検知]] / [[障害緩和]] / [[カナリアテスト]] / [[イミュータブルインフラストラクチャ]] - **ソース**: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] / [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] / [[@2018__acmqueue__Canary Analysis Service]] / [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]] / [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]] / [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] / [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] - **エンティティ**: [[Yujin Zhao]] / [[Ying Li]] / [[Yifan Wu]] / [[Ant Group]] / [[Alibaba Group]] / [[Peking University]] / [[Gandalf]] / [[Microsoft Azure]] / [[Aegis (Azure Control Plane)]] / [[Jonah Horowitz]] / [[Flickr]] / [[Ganglia]] / [[クラスタ免疫システム]] / [[IMVU]] - **関連 MOC**: [[AIOps - Incident Management - MOC]] / [[SRE - MOC]] ## 出典 - [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]](§4 RQ1 変更種別・根本原因、§5 RQ2 導入タイミング・カナリア/段階ロールアウト、§6 RQ3 検知メカニズム・TTD・モニター失敗 3 類型、§7 RQ4 緩和戦略・RaIC/RbIC・TTM 比較・緩和失敗率、§8 実践的推奨事項) - [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]](§3 重篤度・TTD/TTF 比較・Ant Group 環境特性、§4 変更カテゴリ・根本原因の詳細、§5 緩和戦略、§6 4 課題の体系的整理) - [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]](§1 導入・4層安全機構、§4 相関アルゴリズム設計、§5 評価・ケーススタディ) - [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]](§III 相関エンジン設計、§IV-A 性能評価、§IV-B ケーススタディ) - マット・マッシー、ジョン・オルスポー, 「3章 インフラとアプリケーションのメトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §3.6(最終デプロイタイムスタンプとメトリクスの突き合わせ)。 - Jonah Horowitz, 「24章 イミュータブルなインフラストラクチャと SRE」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, §24.5, §24.6. - エリック・ライズ, 「4章 継続的デプロイ」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §4.4, §4.6.3(クラスタ免疫システムによる段階展開と自動リバート)。