# Chaos Monkey [[Netflix]] がデータセンターをクラウドに移行した2010〜2011年頃に導入したツール。サービスインスタンスを1日1回擬似ランダムに選び、勤務時間内に限って不意に停止させる。単一障害点(SPOF)への脆弱性やカスケード障害の芽を早期に発見させる目的で作られ、目の前に現れた問題を解決することに慣れたエンジニアたちが、独立した小さなチーム単位でインスタンス消失への弾力性を備えるきっかけとなった。導入後4年間で多数のインスタンスが消失したが、SPOF に関連するサービス障害は1回のみで、その1回も Chaos Monkey が勤務時間内に停止させたため担当エンジニアがすぐ対応できた。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.3) [[Jens Rasmussen]] の経済・ワークロード・安全性という3境界モデルに沿うと、Chaos Monkey は通常シグナルを欠きがちな「安全性」の境界に対して人為的にシグナルを発生させ、システムが安全性の劣る状態へ無自覚に漂流するのを防ぐ仕組みとして機能した。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.4) ## wiki 内の言及 - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]]: Netflix でカオスチームを率いた [[Casey Rosenthal]] による一次資料。Chaos Monkey 導入の経緯・効果・[[Chaos Kong]] への拡大までを記す。 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]: Netflix が本番環境での[[障害注入]]を Chaos Monkey ツールで普及させたパイオニアとして紹介される。 - [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]]: [[イミュータブルインフラストラクチャ|イミュータブルなインフラストラクチャ]]があれば、故障したノードを同じイメージから即座に交換できるため、Chaos Monkey のようなツールでシステム内に障害を誘発させ対処能力を確認する作業を安心して行えると位置づけられる。逆にイミュータブルでない環境では、故意の障害追加が「真のカオス」を招く恐れがあると注記される。(Source: §24.2, §24.4)