# カオスエンジニアリング (Chaos Engineering) ## 定義 カオスエンジニアリングは、「本番環境においてシステムが逆境条件に耐える能力への信頼を構築することを目的として、システム上で実験を実施する規律」である（Principles of Chaos Engineering より）。ユニットテスト・性能テストでは検出できないレジリエンス上の欠陥を、意図的な障害注入(Fault Injection)によって事前に発見・修正する。（Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.3） 実験サイクル: **Steady State の定義 → 仮説の立案（爆発半径最小化と並行）→ Fault Injection → メトリクス分析 → 障害修正 → 仮説の検証 → 実験から学ぶ → システムの改善 →（次の Steady State へ）** 標語: "Hope is not a strategy" / "Chaos in production is not about courage. It is about preparation." ## 実験カテゴリ（Bradesco 第1フェーズ 30+ シナリオ） | カテゴリ | 代表的シナリオ | |---|---| | Hardware | コンテナ/VM 障害、CPU/メモリ/ディスク枯渇、サーバ停止、強制再起動 | | Communication | ネットワーク Blackhole/レイテンシ/パケットロス、DNS 停止、ポート障害 | | App/Microservice | Circuit Breaker、キャッシュ全停止・縮退、Application Probe 停止、Retry Logic | | App/Middleware | ミドルウェアクラスタ障害、証明書失効、メッセージングシステム停止 | | App/Database | DB クラスタ停止・縮退、ストレージサブシステム障害 | （Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.6） ## 導入フェーズの典型パターン（Bradesco 事例） **第1フェーズ: SRE 依存の手動実験** 1. アーキテクチャ把握（シーケンス図・C4 図） 2. クリティカルシナリオのマッピング 3. ステークホルダー合意 4. ツール準備（Azure Chaos Studio, Chaos Toolkit, Dynatrace 等） 5. テスト実行（障害シミュレーション・メトリクス収集） 6. 修正後の再テスト **第2フェーズ: 自動化とガバナンス** 手動実験から「SRE チーム拡大なしのスケール」へ移行するために自動化が必須。再利用可能テンプレート・事前チェック/実行/事後検証パイプライン・継続的/オンデマンドテスト。Bradesco では内製ツール [[EasyPerform]] でガードレール・証跡管理・スケジュール実行を実現した。 ## 本番環境実施の前提条件（p.12） - 行動が文書化されたステージングで事前検証済み - ロールバックランブック（60 秒以内リバート）のテスト済み - フルオブザーバビリティスタック稼働（Dynatrace, Grafana, Elasticsearch 等） - 計画的な低ボリューム実行ウィンドウ - ブラストラジウム定義（1 名前空間 / 1 サービス / 1 依存） ## 横断的知見 - **金融機関という規制環境でも本番カオスは実施可能**: ガードレール・証跡管理・段階的導入（ステージング→自動化→本番）の3要素で規制コンプライアンスを維持しながら実験できる。Bradesco は Gremlin・Azure Chaos Studio・ToxyProxy 等を組み合わせ、EasyPerform で監査証跡を 100% 確保した。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「SRE チームを拡大せずに信頼性フレームワークをスケールするには自動化が不可欠」**: 手動実験フェーズは SRE への高依存を生み、スケールの天井となる。自動化・再利用可能テンプレート・ガバナンスプラットフォームの組み合わせがブレークスルーとなった。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **発見された脆弱性は設定ミスが多い**: Redis フェイルオーバー（フォールバック未実装）、Hikari Timeout（30s → 1s 推奨）、Circuit Breaker（Resilience4j 未使用）、JVM の DNS キャッシュ TTL（`networkaddress.cache.ttl=30` 未設定）など、いずれも設定変更で解決可能な問題だった。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.7) ## 未解決の問い - 30 シナリオで 10 のブラインドスポット発見という比率（33%）は他組織の事例と比較してどの程度か？ - Bradesco の EasyPerform のような内製ガバナンスツールが必要な理由は、既存 OSS（Gremlin, LitmusChaos 等）ではカバーできない何があるためか？ - カオスエンジニアリングと通常の障害演習（DR テスト）の違いをどのように組織に説明するか？ - 本番実施への移行タイミングの判断基準（ステージングでの検証成熟度、オブザーバビリティ充足度）はどう定量化できるか？ ## 関連 - [[GameDay]] — カオスエンジニアリングの演習形式。チームへのリアリスティック訓練 - [[レジリエンスエンジニアリング]] — 学術的基盤。「障害のために設計する」という思想的親族 - [[障害注入]] — 実装技術レイヤー - [[EasyPerform]] — Bradesco の内製ガバナンスプラットフォーム - [[Bradesco]] — 本事例の実施組織 ## 出典 - [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]