# カオスの成熟モデル（CMM） ## 定義 カオスの成熟モデル(CMM、Chaos Maturity Model)は、組織におけるカオスエンジニアリングの実践を「導入(adoption)」と「洗練(sophistication)」という直交する2軸で評価するフレームワークである。ソフトウェア業界全体は単一の業界標準を維持できるほど均質ではないため、業界標準の代わりに異なる手法を比較・改良評価できるスライド式の尺度を提供する。元は Netflix のカオスエンジニアリングチームが最初の著書(Basiri et al., *Chaos Engineering*, O'Reilly, 2017)で紹介した際、カーネギーメロン大学が80年代後半から90年代初頭にかけて開発したソフトウェア開発の能力成熟モデル(Capability Maturity Model)をもじった半分ジョークだった。「プロセス」という言葉を良しとしない Netflix の文化とは対照的な概念だったが、チームがモデルに親しむにつれ、組織がカオスエンジニアリングへの投資を評価・拡大する上で実際に有意義であることが判明した。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] 章冒頭) ## 導入(adoption)軸 - **賛同者は誰か**: 導入初期は障害・セキュリティインシデントの影響を最も受ける専門職(運用・IT・SRE)が主導し、DevOps・SRE・インシデント管理チームの支持を伴う内部推進活動へ広がる。最終的には SVP・CIO・CISO レベルからのトップダウンの布告に至ることが多い。インシデントの影響を直接受ける層からマネジメント層へ提起され、方針として上から下へ公布される流れが最も一般的である。 - **組織のうちどのくらいの割合が参加するか**: 個人やアプリケーションチームの一部から始まり、専任のフルタイムチームの設置を経て、究極的には組織のすべての階層・全社員の責務として実践される状態(DevOps文化に類似)へ至る。 - **事前に満たす必要のある条件**: (1) 劣化した状態を検知するための手段の整備、(2) 社会意識、(3) 仮説が支持されるべきであるという正直な期待、(4) 対応にあたる連携体制。特に劣化状態を検知する能力が欠けていると、制御グループと実験グループの差異を見分けられず、実験結果は一時的な価値しか持たない。 - **障壁**: (1) 本番環境での実験に伴うリスク、(2) コンプライアンスが実験に待ったをかけるケース、(3) 既存システムの克服しにくい不安定さ、(4) 費用対効果を計測する難しさ。「カオス」という名称自体が経営層を怖がらせるという懸念は、著者の経験上まれである。 (Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] §15.1–§15.1.4) ## 洗練(sophistication)軸 コンサルティング(人手)からツール活用への移行として捉えられる軸で、5段階で進展する。 1. **ゲームデー**: 責任者を部屋に集め、なくても耐えられるコンポーネントを止め、学びを記録する。技術的には容易だが、負担は人間(ファシリテータ)に集中し、多くの数のサービスには対応できない。 2. **故障注入のコンサルティング**: 組織横断的に再利用できる故障注入フレームワーク(多くはプロセス間通信(IPC)のレイヤーに関与)を構築し、ファシリテータがチームに同席して実験を実行する。 3. **故障注入のセルフサービスツール**: フレームワークをセルフサービスのインタフェイスにラップし、ファシリテータの介入なしに複数チームが利用できるようにする。 4. **実験プラットフォーム**: 制御グループと可変グループにトラフィックのサンプルを振り分ける本格的な実験を、複数同時に本番環境で実行できるようにする。 5. **プラットフォームの自動化**: KPI モニタリングによる緊急停止スイッチ、システムイントロスペクションによる実験の自動構築、実験の優先順位づけの自動化により、実験の作成・優先順位づけ・実行・終了をすべて自動で回せる状態。カオス予算(一定期間の KPI 損失上限の確保)などにも拡張される。 変数を導入するレイヤーもインフラ(例: Chaos Monkey の仮想マシン停止、Chaos Kong のリージョン停止)→アプリケーション(サービス間リクエストへの影響)→ビジネスロジック(異常だが一見もっともらしいレスポンス)の順で洗練が進む。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] §15.1.5–§15.1.5.5) ## 2軸の関係(図15-1) 導入と洗練は直交する2軸であり、通常は同時に発展する。導入が行き渡る前にツールの洗練が進みすぎたり、逆にツールの改善なしに導入が広がりすぎたりすることを防ぐ力が働く。左下象限(個人のSREによるゲームデー)を起点に、右上象限(「カオスの先駆者」、高度な洗練×高度な導入状態)へ向かうほどカオスエンジニアリングが組織に価値を提供する。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] §15.2) ## 横断的知見 - **CMM は「導入」と「洗練」の2軸モデルである点で、[[インシデント対応成熟度モデル]] の単一軸4段階モデル(Absent/Reactive/Proactive/Strategic)と評価の次元数が異なる**: インシデント対応成熟度モデル(Takamura、SRE NEXT 2024)は Google SRE の信頼性マインドセットを踏襲し、組織の状態を1本の梯子上の4段階として評価する。CMM はこれに対し「どれだけ広く実践されているか(導入)」と「どれだけ技術的に高度か(洗練)」を独立した2軸として分離する点が構造的に異なり、片方が高くても他方が低い組織——例えば少人数の熟練チームが高度な実験プラットフォームを持つが全社導入は進んでいない組織、逆に全社的な意識は高いがツールが未整備な組織——を区別できる。両モデルとも「属人的な取り組みが段階を経て仕組み化・自動化されていく」という共通の成熟パス思想を持つが、評価軸の次元数という点で設計思想が異なる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] §15.2, [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]) - **両モデルとも「属人的・ボトムアップな取り組み→組織的に制度化された状態」という同じ方向の成熟パスを描く**: CMM の導入軸は、障害・セキュリティインシデントの影響を最も受ける専門職層からの提起がマネジメント層へ伝わり、SVP・CIO・CISO レベルからのトップダウンの布告として公布される、という流れを最も一般的な導入パターンとして描く。インシデント対応成熟度モデルの Strategic 段階は「プロセスが体系化・仕組み化され、フィードバックループで対応負荷を継続的に最小化する」状態として記述され、経営層の関与そのものは明示されないが、両モデルとも最終段階を「個人の属人的判断に依存しない、組織的に制度化された状態」として位置づける点で収束する。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] §15.1.1, [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]) ## 未解決の問い - CMM の導入軸(個人→アプリケーションチーム→専任チーム→全社員の責務)と、インシデント対応成熟度モデルの3フェーズ×9プロセスのマトリクスを、実際の組織評価で同時に適用した事例はあるか。両モデルは補完的に使えるか、それとも評価対象(実践の広がり方 vs インシデント対応プロセスの成熟度)が異なるため単純には組み合わせられないか。 - カオス予算(chaos budget)は [[エラーバジェット]] と概念的に類似する(いずれも一定期間の許容損失をあらかじめ確保する仕組み)が、両者は同じ指標(KPI損失 vs SLO違反)を測っているのか、それとも異なる管理対象か。 - 「洗練度」軸を定量的に測定する指標(5段階のうちどこに位置するかを外部から判定する基準)は本章では定性的な説明にとどまる。定量化を試みた事例・研究はあるか。 ## 関連 - [[カオスエンジニアリング]] — 本モデルが評価対象とする規律そのもの - [[インシデント対応成熟度モデル]] — 単一軸4段階の類似成熟度モデル。横断的知見で構造を比較 - [[GameDay]] — 洗練軸の第1段階 - [[障害注入]] — 洗練軸の第2〜3段階(故障注入コンサルティング・セルフサービスツール)の中核技術 - [[エラーバジェット]] — カオス予算との類似性が未解決の問いとして残る - [[Casey Rosenthal]] / [[Nora Jones]] — CMM を紹介した『カオスエンジニアリング』編著者 - [[Netflix]] — CMM が最初に作られた組織的背景(コンサルティング組織からツール活用への移行) - [[Chaos Monkey]] / [[Chaos Kong]] — 洗練軸におけるインフラレイヤーの初期実装例 ## 出典 - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] — 本概念の出典章 - [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]] — 横断的知見で比較したインシデント対応成熟度モデルの出典