Chaos Engineering

制御された障害を意図的に発生させ、システムの弱点を事前に発見する実践。破壊ではなく「科学的実験」。

例：「Redisが落ちてもAPIはDBに直接アクセスして動き続けられる」という仮説を検証

「〇〇が壊れても△△は動く（定量的指標付き）」という形式で事前に立てる。定量化することで客観的に評価できる。

例：「DBが1台停止してもエラー率は1%以内に収まり、60秒以内にフェイルオーバーする」

実験が影響を与えうる範囲。最初は最小限（ローカル/ステージング）から始め、徐々に本番へ拡大。

例：Stage1: docker killでローカルプロセス停止 → Stage4: 本番の一部サーバーに適用

実験前に「エラー率X%を超えたら即中断」という条件を決めておく。これがないと単なる障害になる。

例：エラー率5%超過 または SEV2以上のアラート発火で実験を即時中止

チーム全体で定期的に模擬障害シナリオを実行する訓練。SpotifyやAmazonが定期開催し、障害対応の筋肉を維持。

例：四半期ごとに「本番DBが落ちたシナリオ」でチーム全員が対応訓練を実施

一部が壊れても全体が動き続ける能力。Circuit Breaker・タイムアウト・リトライ・フォールバックの4パターンで実現。

例：決済APIが落ちた場合、UI上は「後払いを選択してください」と代替フローを提示