# カオスエンジニアリング ― 回復力のあるシステムの実践 ## 概要 『カオスエンジニアリング ― 回復力のあるシステムの実践』は、[[Casey Rosenthal]] と [[Nora Jones]] が編著した *Chaos Engineering: System Resiliency in Practice*(O'Reilly Media, 2020)の日本語版である。[[Netflix]] で生まれた実践を一分野として体系化し、原則・大企業での実践事例・人間的な要素・ビジネス価値・応用領域という 5 部構成で扱う。 単著の解説書ではなく、Slack・Google・Microsoft・LinkedIn・Capital One・PingCAP といった各社の実践者と、レジリエンスエンジニアリング/ヒューマンファクターの研究者が章ごとに執筆する論集の形をとる。そのため同じ「カオスエンジニアリング」という語に対して、ツールとしての故障注入から、人間のメンタルモデルを引き出す装置としての実験まで、複数の立場が並置される点に特徴がある。 ## 書誌情報 - **原書**: *Chaos Engineering: System Resiliency in Practice*(Casey Rosenthal and Nora Jones, O'Reilly Media, 2020) - **編著**: [[Casey Rosenthal]](ケイシー・ローゼンタール)、[[Nora Jones]](ノラ・ジョーンズ) - **訳**: 堀 明子、松浦 隼人 - **出版社**: オライリー・ジャパン(発売元: オーム社) - **発行日**: 2022 年 6 月 15 日(初版第 1 刷) - **ISBN**: 978-4-87311-988-5 - **構成**: イントロダクション + 全 21 章(第 I 部 舞台準備 / 第 II 部 原則の実践 / 第 III 部 人間的な要素 / 第 IV 部 ビジネス要因 / 第 V 部 進化) - **献辞**: David "The Dude" Hussman に捧げられている ## 構成と主要テーマ ### イントロダクション: カオスの誕生 Netflix でカオスエンジニアリングが成立するまでの歴史を、実務上の危機を起点として辿る。 → [[@2022__OReillyJapan__カオスエンジニアリング - Introduction カオスの誕生]] — 2008 年のデータベース障害とクラウド移行を引き金に Chaos Monkey が生まれ、2012 年の AWS ELB 障害が Chaos Kong を、2015 年の Principles of Chaos Engineering 定式化とカオスコミュニティデーが分野の輪郭を作った。実践が理論に先行した成立順序を時系列で示す。 ### 第 I 部 舞台準備(1〜3 章) なぜカオスエンジニアリングが必要なのかを複雑系の性質から導き、規律としての定義を与える。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 1 複雑なシステムとの出会い]] — 線形/非線形とメンタルモデルの構築不能性で複雑なシステムを定義し、妥当な設計判断をしたチームでも防げない 3 つの機能停止実例を通じて、偶発的複雑性も本質的複雑性も持続可能な形では削減できないと論じる。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] — 動的安全モデル(経済性・ワークロード・安全性)と複雑性の経済的支柱(状態・関係・環境・可逆性)という 2 つのモデルを並置し、安全性と可逆性という異なる 2 軸から独立にカオスエンジニアリングを正当化する。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] — 「実験 対 テスト」「ベリフィケーション 対 バリデーション」の対比で規律の性質を定め、「モノを壊すこと」や抗脆弱性との違いを明確にしたうえで、発展した 5 原則(定常状態の仮説・実世界事象の多様化・本番実験・継続的自動化・影響範囲の局所化)を提示する。 ### 第 II 部 原則の実践(4〜8 章) 大企業 5 社が、それぞれの制約のもとでどう導入したかの事例集。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 4 Slackの惨劇シアター]] — カオス前提で設計されていないレガシーなシステムに対し、開発環境先行・段階的ゲート付きの演習プロセスを設計する。実験の前に予備キャパシティ確保・自動インスタンス入れ替え・タイムアウト/リトライ見直しという前提条件が要る。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 5 Google DiRT 災害からの復旧テスト]] — 2006 年開始の全社演習プログラム。技術システムだけでなくビジネスプロセスや非エンジニアリング部門まで対象に含め、SLO 非破壊ルールと 2 名以上の外部レビュワーによる計画審査で制度化する。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 6 Microsoftにおける実験の多様化と優先順位づけ]] — 障害シナリオを「既知×期待どおり/既知×予期せぬ/未知×予期せぬ」に整理し、発生頻度・対処確度・切迫度の 3 特性と単一/複合/波及の 3 段階で優先順位をつける。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] — リクエストレベルの故障注入 LinkedOut と、対象母集団を従業員・合成ユーザへ差し替える戦略により、実メンバーへの影響をほぼゼロに抑える。爆発半径を「狭める」のでなく「差し替える」第三のパターン。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 8 Capital Oneにおけるカオスエンジニアリングの導入と進化]] — 規制産業での導入。監査証跡の生成とデータ非流出のため独自ツールを内製し、実験中のアラート受信自体を実験失敗のシグナルとみなす。コンプライアンスを制約でなく普及の追い風として位置づける。 ### 第 III 部 人間的な要素(9〜12 章) カオスエンジニアリングをツールでなく、人間の認知と組織に働きかける装置として捉え直す。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 9 先見性を生み出す]] — 認知面接とファシリテーションでチーム間のメンタルモデルの差異を可視化し、後知恵バイアスを避けて先見性を養う。Netflix の ChAP は技術的に成功したが実際に使ったのは作成者 4 人にとどまり、自動化がかえって専門知識の広がりを浅くした。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 10 人間的なカオス]] — 3 原則を組織そのものに適用する。人物の不在を単一障害点として注入するゲームデー、チーム間ローテーション、ボトムアップの文化的実験の 3 事例。Westrum の組織文化モデルを実験受容度のスニフテストに使う。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 11 ループの中の人々]] — Fitts のリスト(1951)と HABA-MABA に代表される機能配分の思想を認知システム工学から批判する。Hollnagel の「置き換えの神話」を引き、人間は約束を結び責任を持てる点で機械と本質的に異なると論じる。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] — 人間の直感は伝達不可能なので実験選択の基準に据えられない。LDFI(系統ドリブンな故障注入)により、可観測性データから SAT/ILP で実験候補を機械的に導出する。 ### 第 IV 部 ビジネス要因(13〜15 章) 投資としての正当化と、組織的な成熟度の測り方。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 13 カオスエンジニアリングの費用対効果]] — インシデント削減の恩恵は「可用性向上 → 機能リリース高速化 → 複雑さ増大」の力学で一時的になりやすい。Kirkpatrick モデルの 4 段階を ROI 証明に転用し、ChAP は「救えた SPS」で継続的価値を示した。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 14 オープンな心、オープンな科学、そしてオープンなカオス]] — 対立的マインドセットは「カオスエンジニア対自分たち」の衝突を生み、協調的マインドセットは共同オーナーシップを生む。Open Chaos Initiative は実験を 7 要素で定義し、定常状態の仮説を実行フロー中に 2 回評価する。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 15 カオスの成熟モデル（CMM）]] — 「導入」と「洗練」という直交する 2 軸。導入は賛同者・参加割合・前提条件・障壁の 4 考慮点(最重要は劣化状態の検知能力)、洗練はゲームデーからプラットフォームの自動化までの 5 段階で進む。 ### 第 V 部 進化(16〜21 章) 規律としての一般化と、ソフトウェア以外の領域への展開。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 16 継続的ベリフィケーション]] — CI → CD → CV という系譜に位置づけ、カオスエンジニアリングを包含する上位規律として継続的ベリフィケーションを定義する。CV ツールを ChAP(経験的検証)と Vizceral(定性的検証)の両極に分ける。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] — 物理世界に作用し結果が不可逆な系への拡張。機能安全規格(IEC 61508 系譜)と FMEA の手順はカオスエンジニアリングの原則に対応するが多点故障を扱えず、ソフトウェアの多用がこれを深刻化させる。測定・注入行為自体が系に影響するプローブ効果も課題。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 18 HOPとカオスエンジニアリングの出会い]] — 製造業の安全マネジメント体系 HOP の 5 原則(誤りは正常・非難しても何も直らない・コンテキストが行動を左右する・学習と改善が肝要・意図的な対応が重要)と接続する。アクションアイテムのクローズ自体への注力が有効性を犠牲にするという批判を含む。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] — PingCAP の TiDB/TiKV での実践。100% ユニットカバレッジでも Raft スナップショット破損は捉えられない。故障注入をアプリ/CPU・メモリ/ネットワーク/ファイルシステムの 4 分類に整理し、Schrodinger で自動化する。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] — セキュリティ制御そのものを実験対象にする。RCA が非難・孤立・恐怖の文化を生むという批判のもと、Red/Purple チームを補完する ChaoSlingr を示す。ポート設定ミス実験で半数のケースでファイアウォールの検知・ブロックが失敗した。 → [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 21 おわりに]] — 「線の下(ツール)/線の上(人々・組織)」を区別し、回復力を作るのはツールでなく人々だと結ぶ。信頼性のためのルール強制がかえって逆効果になりうる 3 例(冗長性・複雑性除去・効率化)を挙げる。 ## 影響と位置づけ Netflix の実践から出発した個別のツール群を、原則・事例・人間的側面・ビジネス価値・応用領域という 5 層で束ね、カオスエンジニアリングを一個の工学的規律として確立した書籍である。特徴は次の 3 点にある。 第一に、**規律の定義を「故障注入」から切り離した**点。3 章が「実験であってテストではない」「バリデーションでなくベリフィケーション」という対比で定式化したことで、ツールの有無ではなく問いの立て方が規律の同一性を決めるようになった。16 章はこれを継続的ベリフィケーション(CV)という上位概念へ一般化し、CI/CD の系譜に接続している。 第二に、**人間と組織を主題として本編に組み込んだ**点。第 III 部は分野の主要な批判者(John Allspaw、Peter Alvaro)を著者に迎え、9 章が Netflix ChAP の普及失敗を、11 章が機能配分思想の限界を、12 章が人間の直感の伝達不可能性をそれぞれ論じる。編著者自身の枠組みに対する批判が同一の書籍に収められている点が、単なる実践書と異なる。 第三に、**応用領域への拡張を示した**点。データベース(19 章)、セキュリティ(20 章)、サイバーフィジカルシステム(17 章)、製造業の安全マネジメント(18 章)へ接続し、この規律が Web サービスの可用性に限定されないことを示した。とりわけ 17 章の可逆性の制約と 18 章の HOP との接続は、ソフトウェア工学の外側にある安全科学の蓄積へ橋を架けている。 ## 関連 - 概念: [[カオスエンジニアリング]] / [[継続的ベリフィケーション]] / [[セキュリティカオスエンジニアリング]] / [[カオスの成熟モデル（CMM）]] / [[動的安全モデル]] / [[複雑性の経済的支柱]] / [[先見性]] / [[機能配分]] / [[機能安全]] / [[HOP]] / [[障害注入]] / [[ブラスト半径]] / [[レジリエンスエンジニアリング]] / [[GameDay]] - 編著者: [[Casey Rosenthal]] / [[Nora Jones]] - 章著者: [[Richard Crowley]] / [[Jason Cahoon]] / [[Oleg Surmachev]] / [[Logan Rosen]] / [[Raji Chockaiyan]] / [[Andy Fleener]] / [[John Allspaw]] / [[Peter Alvaro]] / [[Russ Miles]] / [[Nathan Aschbacher]] / [[Bob Edwards]] / [[Liu Tang]] / [[Hao Weng]] / [[Aaron Rinehart]] - 組織: [[Netflix]] / [[Slack Technologies]] / [[Google]] / [[Microsoft]] / [[LinkedIn]] / [[Capital One]] / [[PingCAP]] / [[Verica]] / [[Jeli]] - 関連 source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] / [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] / [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]] ## 出典 - Casey Rosenthal, Nora Jones 編, 堀明子・松浦隼人 訳, 『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022.