翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ダウンタイムコストとカオスエンジニアリングの出現
情報技術インテリジェンスコンサルティング (ITIC)
ダウンタイムは一般的に収益を生み出すオンラインシステムに関連していますが、悪影響はそれよりもはるかに大きくなります。すべての大企業や組織は、主要な収益モデルに関係なく、人事や給与などの内部システムの可用性に大きく依存しています。
これらのコア内部サービスに影響を与えるダウンタイムは、企業の機能を妨げる可能性があり、大幅な運用の中断や財務上の影響につながる可能性があります。結果として生じる問題には、次のようなものがあります。
-
従業員やベンダーへの支払いの遅延
-
顧客の注文または取引を処理できない
-
侵害されたセキュリティシステムによって許可される機密データの侵害
-
生産性と収益機会の喪失
-
コンプライアンス違反に対する規制上の罰則
-
ブランド評価の低下
カオスエンジニアリングは、制御された中断を意図的に導入します。カオスエンジニアリングを使用して障害に対するシステムの対応を理解または検証することは、システムの耐障害性を向上させるための重要なプラクティスとなっています。カオスエンジニアリングにより、組織は問題を事前に発見し、レジリエンスメカニズムを検証し、最終的に計画外のダウンタイムやそれに関連するコストを削減できます。カオスエンジニアリングの利点は次のとおりです。
-
技術的負債の公開
-
操作筋の運動
-
システムへの信頼の構築
-
障害ポイントの特定
-
モニタリングとオブザーバビリティの向上
-
実験ベースの学習のサポート
-
耐障害性の向上によるダウンタイムの短縮
システムが複雑になり、顧客の期待が高まるにつれて、カオスエンジニアリングの重要性が高まっています。ガートナーは、組織が予期しないダウンタイムを短縮し、回復力を向上させるための重要なプラクティスとしてカオスエンジニアリングを推奨
カオスエンジニアリングの導入の課題
カオスエンジニアリングはシステムのレジリエンスを向上させるためにますます重要なプラクティスですが、カオスエンジニアリングの導入は以下の障害に直面する可能性があります。
-
リスクに関する誤解 ‒ 一般的な誤解は、カオスエンジニアリングが本番環境でのみ行われ、過剰なリスクに関する懸念につながることです。この認識は、カオスエンジニアリングプラクティスの体系的で制御された性質を理解していないことから生じます。AWS Well-Architected フレームワークで説明されているように、本番稼働用以外の環境で障害シミュレーションを最初に実行します。
-
長期的なビジネス価値 - カオスエンジニアリングの利点は徐々に蓄積されるため、ビジネス価値を定量化し、初期投資を正当化することは困難です。ROI が遅くなると、組織はカオスエンジニアリングに優先順位を付け、維持することが困難になります。
-
スキルと専門知識のギャップ - カオスエンジニアリングには、組織内ですぐには利用できない可能性のある独自のスキルと専門知識が必要です。この専門知識を構築または獲得することは、特に実践を初めて行う組織やリソースが限られている組織にとって、大きな障壁となる可能性があります。
この戦略ドキュメントの残りの部分では、主にカオスエンジニアリングのビジネス価値を示す 2 番目の課題に焦点を当てます。
カオスエンジニアリングの蓄積効果
開始日と終了日が明確に定義された従来のテクノロジープロジェクトとは異なり、カオスエンジニアリングは継続的な学習とシステムの回復力の継続的な改善の継続的な実践です。時間の経過に伴うカオスエンジニアリング複合の利点。
システムが進化し、より複雑になるにつれて、新しい障害モードが登場します。潜在的な問題を特定するには、さらに多くのカオス実験が必要です。特に複雑なシステムやプロセスを持つ大企業や、障害が外部のサービスプロバイダーによって所有されている場合、問題の修正には数か月かかることがあります。
学習と改善の機会としての失敗を受け入れる文化のシフトは、何年もかけて成長し、組織に根付いています。カオスエンジニアリング実験を自動化し、サポートツールを開発するための投資は、カオスエンジニアリングの実践を合理化し、強化し続けています。この組織の知識を構築し、システムのレジリエンスを理解することは、時間の経過とともに蓄積される段階的なプロセスです。カオスエンジニアリングによって開発された知識、プロセス、ツールは、継続的に進化するシステムとともに実践が成熟するにつれて価値が増大します。
次の図は、カオス導入が次の段階に進むにつれて、時間の経過とともに価値がどのように向上するかを示しています。
-
初期導入
-
学習
-
障害モード分析
-
1 回限りの実験
-
定期的な GameDays
-
継続的な実験

図に示すように、カオスエンジニアリングの利点は、障害がシステムに注入される前に開始されることがよくあります。カオス実験自体を計画および設計するプロセスは、すぐに価値をもたらします。潜在的な障害シナリオ、単一障害点、システム内の不確実性領域を特定すると、改善につながります。
例えば、障害シナリオを記述し、潜在的なカスケード効果、障害モードと効果分析 (FMEA) と呼ばれるプロセスについて話し合うと、見落とされた可能性のある明らかな弱点やギャップを明らかにするのに役立ちます。組織は、システムが意図的な中断にさらされる前であっても、これらの問題に積極的に対処できます。詳細については、「レジリエンス分析フレームワーク」を参照してください。
さらに、カオスエンジニアリングイニシアチブに伴うシステムオブザーバビリティとモニタリングへの注目が高まり、すぐにメリットがもたらされ始めます。システム動作と障害モードの可視性を向上させることで、チームはシステムの通常の動作状態をよりよく理解できます。また、可視性を高めると、チームは、オペレーション条件が制限にプッシュされたときにどのように低下、適応、失敗するかを理解できます。
1 回限りの実験モードと定期的な GameDay モードはどちらも、連続実験モードよりも手動によるアプローチです。エンジニアが観察や実験を通じて仮説を積極的に形成し、改良する、実践的で探索的なプロセスが必要です。
一方、継続的実験モードは、本質的により自動化されています。このモードは、制御された反復的な方法で承認済みおよび検証済みの仮説を実行することに重点を置いています。専用のカオスパイプラインを通じて