こんにちは。フィックスポイントの冨です。

私が新人の頃に先輩に言われて意外だったことの一つに 「日頃、ほとんど障害が発生しないシステムよりは、時々、小規模の障害が起こる システムの方が、長い目でみて安定運用が出来る。」というものでした。

つまり「障害が発生しない」といっても機械には寿命があるため、 忘れたころに、突然に大きなトラブルに見舞われてパニックになりがちであると。
一方、小規模なトラブルがちょいちょい発生していると、モニタリングが 正常に動作する事が確認できるし、障害対応のノウハウが溜まっていくため、 いざ大規模障害が発生した際には、心の余裕がまるで違うという事でした。
障害発生を積極的に改善機会と捉える視点は、さすがと感じたわけです。

本題の「カオスエンジニアリング」の考え方も、本番（またはステージング）環境で わざと障害を起こして、自動復旧可能なシステムの耐障害性を確認するといった手法、 品質向上の考え方です。

「カオス」という言葉は「混沌」というよりは、数学でいう「カオス理論」のニュアンスの 方が近いです。例えば「バタフライ効果：蝶の羽ばたきが、巡り巡って地球規模の気象変動 の引き金になる可能性がある」のように、複雑なシステム系では小規模の事象が思わぬ振る舞い につながるという事です。

複雑に構成された分散システムでは、ちょっとした機械等のトラブルや想定外の挙動が 大規模サービス障害に波及しかねないといったニュアンスです。
逆にいえば、このようなシステムでは障害の原因がどこにあるかが分かりにくく、 リカバリーが必要な範囲を限定しにくいなどの弊害が生じます。
(そして、モノリシックなシステムでは関係ない話でもあります。)

このような自動回復が可能となるように設計された分散システムにおいて、 意図的に軽い障害を発生させて、システムの振る舞いを確認する実験を繰り返し、 挙動に対する知見を引き出したり弱点を探るといった営みです。

カオスエンジニアリングの原則(Principle of Chaos Engineering)
http://principlesofchaos.org/?lang=JAcontent#