回復力が高く、デジタル成熟度が高く、ダッシュボードやその他のツールによる可観測性が高い組織は実験を通じて、発生した問題に即座に対応できるため、カオス・エンジニアリングを採用するべきです。この可観測性がない組織⁴（ibm.com外部のリンク）カオス・エンジニアリングを通じて作られた実験を解決するには、時間がかかりすぎる場合があります。

カオス・エンジニアリングは、クラウド、特にパブリッククラウドや クラウドネイティブ・アプリケーションを使用している組織にとっても必須です。パブリッククラウドでは、クラウド・プロバイダーとの調整が必要となる停電の問題が発生する可能性があるため、オンプレミスの問題に対処するのとは異なるアプローチが必要となります。

Constellation Researchによると、クラウドを使用する企業は依然として、クラウドとサービス型ソフトウェア（SaaS）がITインシデントに及ぼす影響を考慮せずにそれらのインシデントに対処することがよくあります（ibm.com外部のリンク）。

さらに、マイクロサービスの使用が増えるため、システム内で実行されるホストまたはコンテナーの数が増加し、カオス実験を通じて発見および解決できる独自の課題（ibm.com外部のリンク）が生じます。複雑さをコード設計からシステム運用に移すことで、複雑さが解消されるわけではありませんが、より高度な自動化が可能になります。

カオス・エンジニアリングは、組織が継続的統合継続的デリバリー（CI/CD）パイプラインの速度を高めるのにも役立ちます。Netflixが行ったように、カオス・エンジニアリングをCI/CDに組み込むことで⁶（ibm.com外部のリンク）、組織は継続的な実験を自動化すると同時に、その潜在的な影響をコントロールできます。

最後に、組織がAPIを介してパートナーと接続することが増えているという事実は、システムの問題が他の組織に波及する可能性があることを意味します。

カオス・エンジニアリングを導入すれば、組織はアーキテクチャーの弱点を理解して修正し、最終的には将来の障害を予測する能力を生み出すことができます。 カオス・エンジニアリングを成功させれば、組織は顧客に重大な影響を与える技術的な障害を最小限に抑えることができます。カオス・エンジニアリングは、より強固で回復力の強い、より複雑なシステム・アーキテクチャーの構築もサポートします。組織がカオス・エンジニアリングを追求することを決定したら、次のステップは、それを本番前環境で実行するか本番環境で実行するかを決定することです。

DevOpsチームには、カオス・エンジニアリング実験を実行してさまざまなシステム・プロセスをテストするための選択肢が複数あります。

• 遅延の取り込み：DevOpsチームは、意図的にネットワーク接続の遅延や障害をエミュレートするシナリオを作成できます。これには、ネットワークの遅延や応答時間の低下が含まれます。
• 障害の取り込み：システムに意図的にエラーを導入し、それが他の依存システムにどのような影響を与えるか、サービスが中断するかどうかを判断できます。障害の取り込み例には、ディスク障害の誘発、プロセスの終了、ホストのシャットダウン、電力や温度の上昇の導入などがあります。障害の取り込みにより、組織に何かが起こった場合にシステム全体の障害を引き起こす可能性がある単一障害点を特定できます。
• 負荷の生成：通常の運用を大幅に超える大きなトラフィック・レベルを送信することで、意図的にシステムにストレスをかけます。これにより、サイト信頼性エンジニア（SRE）がシステム内のボトルネックを理解し、よりスケーラブルなシステムを構築できるようになります。
• カナリア・テスト：少人数のユーザーに新製品や新機能をリリースすることで、不具合やバグがあっても一部の訪問者にしか影響せず、残りの訪問者は既存のWebサイト・エクスペリエンスにアクセスすることができます。

理想的なカオス・エンジニアリング・プロセスを構築するには 、組織による大規模な分散システムの確保を可能にする複数の原則が必要です。

• システムを理解する：これには、システム全体、新たに現れるその特性や機能、トポロジー、アーキテクチャー、依存関係、定常状態の動作、出力応答、特性（可用性、遅延、スループットなど）に関する包括的な知識が含まれます。
  
• 失敗を受け入れる：ソフトウェア・エンジニアにとって、インシデントの発生を防ぐように設計されているにもかかわらず、インシデントの発生を許容するのは、最初は矛盾しているように思えます。ただし、IT サービスでは中断が必ず発生するため、組織のチームが勤務時間外後、何時間も経ってから対応したり、これまでその問題に直面したことがないといった状況にあうよりも、管理された環境で中断を体験し、解決策を先見的に見つける方がベターです。
• 定常状態の動作を確立する：まず、エンジニアリング・チームは、実験によって定常状態が受ける影響を比較できるように、システムが正常に動作しているときの動作を定義する必要があります。
• 現実世界のインシデントを特定する：カオス・エンジニアリングの実験は、ありそうもない状況を作り出すのではなく、日常起こり得ることにできるだけ近づける必要があります。ネットワークやインフラストラクチャーの障害、不正なコード、電源の問題、トラフィックの過負荷などが発生する可能性があります。
• 大々的にテストする：カオス・エンジニアリングでは、使用環境で調査を実施できます。つまり、特定の日に複数のテストを行い、リソースを最大限に活用して、できるだけ多くの問題を特定して解決します。
• 自動化を利用する：あらゆる規模の組織が、手作業では手間がかかりすぎる実験を自動化することで、カオス・エンジニアリングを利用できます。これにより、カオス・エンジニアリング・プロセス中のITチームの負担が一部軽減されます。実験の設計、障害の取り込み、インフラストラクチャーのプロビジョニングはすべて、組織が自動化できる実験の側面です。
• 爆発半径に注意せよ：カオス・エンジニアは、顧客への実害ができるだけ小さくなるよう、爆発半径を最小化することに細心の注意を払わなければなりません。爆発半径を最小化するには、次のような方法があります。
  • サービスのサブセットをターゲットにする：カオス・エンジニアリングは、特に本番環境においては、組織のサービスを根本的に混乱させてはなりません。サービスの特定のサブセットをターゲットにすることで、インシデント発生時の影響を最小限に抑え、システム全体の停止を確実に阻止できます。
  • 実験を有限時間の間実行する：実験には開始と終了が必要です。この実験のポイントは、インシデントを長期間放置して実行するのではなく、インシデントを作成して解決することです。
  • ピーク・トラフィックを避けて実験を実行する：組織は、インシデント発生時に大容量のトラフィックがシステムに与える影響を具体的に測定しようとしている場合を除き、ピーク時間中に実験を実行することを避けるように努める必要があります。
  • 開発環境で実験を実行する：顧客体験サービスの中断を防ぐ最も簡単な方法は、本番前の環境で実行することです。ただし、これは条件が本番環境とは異なることを意味し、何が起こっているかについて誤ったイメージを与える可能性があります。これを最小限に抑えるには、本番前環境と本番環境が可能な限り相互にミラーリングされるようにします。
  • すべてのコンポーネントを実験する：組織のシステムは継続的に変化するため、カオス実験は決して終わりません。「すべて」をテストすることも目標にする必要があります。すべてのコンポーネント、レイヤー、サービス、プロセス全体にわたるそれらの依存関係を調べます。

カオス・エンジニアリングを利用する組織は、本番環境と本番前環境のどちらでカオス・テストを使用するかを決定する必要があります。カオス・エンジニアリングが本番環境で最も有益である理由はいくつかあります。ライブ環境は、インシデントが顧客体験に及ぼす影響を理解する上で最も正確な環境になります。もう1つの理由は、本番前環境がライブ環境とまったく同じ設定ではない可能性があるため、実験にばらつきが生じることです。

たとえば、本番前環境でインシデントが発生した場合、実際の環境と同じトラフィック・レベルでないため、現実的な対応ができない可能性があります。また、その環境と同じセキュリティー設定がされていない可能性もあります。

組織によっては、実際のサイトで意図的に問題を引き起こすことを恐れ、本番前サイトまたは開発サイトで実験を実行することがあります。そうすることで、発生した問題がライブ顧客体験に影響するのを確実に防ぎます。顧客体験への影響を軽減するため、組織によっては、本番環境に移行する前に本番前環境でプロセスを把握することから開始します。

組織は、リスク許容度に基づいて、使用する環境を選択します。究極的には、カオス・エンジニアリングは実際の大規模な問題をテストすることを目的としているため、本番環境では、何が起こっているのか、何を修正する必要があるのかを最も正確に把握することができます。