# ML障害管理の原則 Navigation: [[index]] | [[SRE - MOC]] ## 定義 ML 障害管理の原則は、『信頼性の高い機械学習』11 章が YarnIt の 3 つの機能停止事例(検索ランキングモデルの再訓練停止、パートナー間データ結合のキー変更による破損、天候変化とサプライヤー喪失による「奇妙な推薦」)を横断して抽出した、ML システム固有の障害対応の枠組みである。障害管理の基本コンセプト(障害の状態を知る・役割を確立する・フォローアップのために記録する)そのものは ML/非 ML で変わらず、障害の 8 段階(障害前→トリガー→障害の開始→検出→トラブルシューティング→軽減策→解決方法→フォローアップ)や、FEMA の National Incident Management System に由来する 4 基本役割(障害指揮官・コミュニケーションリーダー・オペレーションリーダー・計画リーダー)もそのまま踏襲される。ML 障害管理の原則が固有に扱うのは、この共通の骨格の上で ML システムが何を変えるかである。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.1.1〜§11.1.2) 3 事例から抽出される 3 つの包括的テーマが指針の中核をなす。**共通したテーマ**——ML の機能停止はエンドユーザーやパイプラインの末端で最初に検知されやすく、100% の確率で少数ユーザーに影響するような偏りは集計指標に現れない。**定義困難なテーマ**——ML 障害は影響と時間の両面で開始・終了が明確に定義しづらく、モデルには「壊れている」と「もっと良くなるかもしれない」の間に急激な境界がない。**無制限なテーマ**——ML の機能停止のトラブルシューティングと解決には、技術・製品・ビジネス部門にまたがる広い組織の範囲が必要になる(コストが高いという意味ではない)。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.5.1) ## 役割別の準備・障害対応・継続的改善 11 章は 3 テーマを踏まえ、4 つの役割ごとに「準備」「障害対応」「継続的な改善」の 3 フェーズで指針を整理する。 - **モデル開発者/データサイエンティスト**: 準備段階で全モデル・データのバージョン管理と出所メタデータの整備、許容できるフォールバック(縮退運用)の指定、有用な評価指標の決定を行う。障害対応ではオンコールローテーションに参加し仮説の生成・検証を担うが、プライバシーや倫理原則を侵害する要求を阻止する備えも必要になる(→ §11.6.2)。継続的な改善ではモデル品質評価ループの短縮に取り組む。 - **ソフトウェアエンジニア**: データ出所の明確化、モデルとバイナリのロールアウト分離、訓練運用間スキューの回避、ロールアウト/ロールバックツールの整備を準備段階で行う。うまく機能していれば障害対応時に呼び出されることはまれになる。 - **ML の SRE/運用エンジニア**: 人員の余裕確保、障害対応の訓練と練習、アーキテクチャレビュー、SLI/SLO の設定、ビジネスの理解、客観的な障害宣言基準の整備を準備段階で担う。障害対応では「一歩下がってシステム全体を見る」姿勢が必須になる——収益悪化がデータ欠落由来、運用のクラッシュが訓練側の設定変更由来ということが起こりうるため。継続的な改善ではフォローアップ項目を「価値が高く実施が容易」を優先して整理し、「価値は高いが実装困難」な項目は上級リーダーとの定期レビューに回し他の戦術的作業と混ぜない。 - **運用マネージャー/ビジネスリーダー**: ML の仕組みと限界を理解し、組織の障害対応能力への投資(人員配置・訓練・予備時間)を担保する。障害対応時は情報を得る権利とビジネス影響の背景を提供する役割に徹し、主導権を握ろうとしないことが求められる。 (Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.5.2〜§11.5.5) ## 特別なトピック:知識要件と倫理 11.6 節は 2 つの特別な論点を扱う。第一に、ML 運用エンジニアに必要なのはモデルの層数のようなモデリングの詳細知識ではなく、コンポーネント間の関係とシステム内のデータフローの理解である。小規模組織ではモデル開発者・システム開発者・運用エンジニアが同一人物/同一チームに集約されがちだが、組織が大きくなるほど運用エンジニアがモデル開発者である必要はなくなる。多くの組織が直面する最大の信頼性課題は ML 知識の不足ではなく、分散システムの構築・運用に関する知識と経験の不足である。第二に、オンコールエンジニアはトラブルシューティング中に生の顧客データへ迅速にアクセスする必要があるため、影響(公平性に影響するモデル障害は集計 KPI に現れないまま実害を及ぼしうる)・原因(意図的な設計決定や不十分な倫理配慮に由来しうる)・トラブルシューティング(生データへの魅力的だが危険なアクセス)・行動への呼びかけという 4 側面で倫理的配慮を要する「プライバシー保護障害管理」が必要になる。解決は多様なチーム構成・責任ある AI プラクティスの設計段階からの採用・データアクセスへの正当な理由とログ記録と複数担当者制の 3 点に集約される。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.6.1〜§11.6.2) ## 横断的知見 - **FEMA/ICS 由来の 4 役割は SRE Book と『信頼性の高い機械学習』で同一だが、11 章は「何が ML で変わるか」を明示的に 3 軸へ切り出す**: [[インシデント管理]] concept が集約する SRE Book Ch14([[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]])は、非管理型インシデントの最大の悪化要因を「フリーランシング(独断行動)」と特定し、インシデントコマンダー・オペレーション・コミュニケーション・プランニングの 4 役を ICS(Incident Command System)として処方する。11 章もほぼ同一の 4 役割(障害指揮官・コミュニケーションリーダー・オペレーションリーダー・計画リーダー)を FEMA の National Incident Management System から引くが、SRE Book が役割の設計と権限の形式化に主眼を置くのに対し、11 章はこの共通の骨格を出発点として「検出のしやすさ・関与する役割とシステムの広さ・タイムラインの明確さ」という 3 点が ML でどう変化するかを明示的に切り出す。同じ役割設計が ML/非 ML で不変であることを 2 つの独立したソース(SRE Book・本書)が確認しつつ、変化点を特定するという役割分担が生まれている。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.1.2, [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) - **「ML システムに RPO は本質的に存在しない」という 11 章の主張は、継続的トレーニングが前提とする分布シフトの不可避性の、障害復旧semantics における帰結として読める**: 11 章脚注は、復旧時点目標(RPO: 障害から復旧した後にシステムを完全機能状態へ戻せる時点)という従来の災害復旧概念が ML システムにはほぼ存在しないと述べる——既存入力で過去の状態を再現することはできても、ML は世界の現在の変化への適応を目的とするため、重要な RPO は常に変化する「今」に対する「今」だけになる。[[継続的トレーニング]] concept が定義する CT の前提(「入力データの分布は学習時と予測時とで大きく変わらない」という仮定が長期運用では成立しなくなる)は、まさにこの現象を訓練パイプライン設計の側から説明する。継続的トレーニングが「なぜ再学習が必要か」を分布シフトの観点で説明するのに対し、11 章は同じ分布シフトが災害復旧の基本概念(RPO)そのものを無効化するという、インシデント管理側から見た帰結を与える。両ソースは異なる文脈(MLOps パイプライン設計 対 障害復旧目標設定)から出発しながら、「ML システムは静的な過去状態への復旧という発想と相性が悪い」という同一の結論に収束する。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.4.2.1 脚注6, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.1.3) - **事例 1 のフォローアップ(モデル経年監視・ゴールデンクエリ安定性監視・訓練率監視)は、[[MLモデル監視]] concept が既に集約する「モデルの鮮度」という先行指標の実例であり、9 章の一般原理を具体的な監視項目へ翻訳する**: [[MLモデル監視]] concept は、実務入門書(仕事ではじめる機械学習 6 章)の「モデルの学習からの日数」という鮮度指標が、事後の症状検知(Weichbrodt の症状ベースアラーティング・TrainCheck)を補う事前予防的な先回り型指標だと位置づけ、9 章がその一般原理(実績値取得の構造的遅延・欠如)を与えると整理している。11 章の事例 1(検索ランキングモデルが訓練システムの障害により 3 週間更新されず、クリック率が徐々に劣化した)のフォローアップは、この「モデルの鮮度」という抽象的な先行指標を、ウォールクロック年齢/データ年齢の閾値監視・ゴールデンクエリテストの安定/不安定の両方向監視・訓練完了期限に対する訓練率監視という 3 つの具体的な機械的実装に翻訳する。11 章自身が「これについては 9 章でも取り上げています」と明示的に接続しており、本 wiki の MLモデル監視 concept が既に集約した理論的枠組み(鮮度指標)と、11 章が提供する実装レベルの詳細(閾値監視 3 種)は、同一の失敗モードに対する抽象度の異なる記述として補完し合う。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.4.1, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.4.1, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.3.4.1) - **「集計指標では見えない少数ユーザーへの 100% 影響」という 11 章の共通したテーマは、9 章のスライス監視の必要性を障害検知の言葉で裏書きする**: 11 章 §11.5.1 は ML 障害の典型例として「100% の確率で少数のユーザーに影響を与えるものがあり、そのようなユーザーだけのスライスを見ない限り集計した指標はおそらく何も問題を示さない」と述べる。これは [[MLモデル監視]] concept が 9 章から集約した「モデル/データ/サービスの 3 分割」や実績値取得の構造的遅延の議論とは異なる角度から、監視設計に「集計対 スライス」という次元を加える。11 章はこの現象を障害の**検知しにくさ**の説明として提示するのに対し、監視設計側では「どの粒度で異常検知を行うか」という設計判断の根拠として読み替えられる——集計指標だけを見る監視は、定義上この種の障害を検知できない。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.5.1) ## 未解決の問い - 11 章は「価値が高く実施が容易」「価値は高いが実装困難」というフォローアップの 2 軸優先順位づけを示すが、[[障害緩和]] concept が集約する GPU クラスタの段階的緩和(深刻度に応じた多段エスカレーション)のような定量的な優先順位づけ手法と統合できるか。11 章の優先順位づけは定性的な運用ガイドラインにとどまる。 - 「ML システムに RPO は存在しない」という主張は、モデルのロールバック(古いモデルへの復元)という実務上よく使われる緩和策とどう整合するか。ロールバックは「過去のある時点への復旧」であり、11 章自身が示す「重要な RPO は常に変化する今に対する今だけ」という主張と表面的に緊張関係にあるように見えるが、11 章はこの緊張を明示的に解消していない。 - ML 運用エンジニアに必要なのは「分散システムの知識」であり「ML モデリングの詳細知識」ではないという 11 章 §11.6.1 の主張は、[[複雑システム障害論]] が扱う「劣化モードで稼働する」複雑システムの一般論とどこまで整合するか。ML システム固有の複雑性(訓練-運用間の非決定性・世界との強い結合)は、一般的な分散システムの複雑性と質的に異なる部分があるのか、11 章は明確に切り分けていない。 - 「プライバシー保護障害管理」規約を業界横断で形式化すべきという 11 章末尾の提言(§11.6.2.4)は、[[プライバシーエンジニアリング]] concept が集約する『SREの探求』15 章の Guard/Strengthen/Extinguish 分類のどこに位置づくか。11 章の提言は「トラブルシューティング中のデータアクセス」という Extinguish 局面に近い具体的な処方箋(正当な理由・ログ記録・複数担当者制)を持つが、[[プライバシーエンジニアリング]] concept が既に指摘する「6 章の Extinguish に対応する具体的な処方箋が本 wiki にまだない」という空白を、この規約がどこまで埋められるかは今後の検証を要する。 ## 関連 - ソース: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] - 概念: [[インシデント管理]] / [[MLモデル監視]] / [[プライバシーエンジニアリング]] / [[継続的トレーニング]] / [[複雑システム障害論]] / [[障害緩和]] / [[オンコール]] - 実体: [[YarnIt]] / [[Cathy Chen]] / [[Niall Murphy]] / [[Kranti Parisa]] / [[D. Sculley]] / [[Todd Underwood]] - 書籍: [[信頼性の高い機械学習]] - 関連 MOC: [[SRE - MOC]] ## 出典 - Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 11 章(§11.1, §11.4.1〜§11.4.3, §11.5, §11.6).