翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 付録 A ‒ カオスエンジニアリングの目標タイプ
<a name="appendix-a"></a>

以下の目標タイプの説明には、Amazon や他の組織がカオスエンジニアリングの目標を設計した実例が含まれています。

## 回復力のあるアーキテクチャの目標
<a name="resilient-architecture"></a>

カオスエンジニアリングを採用するための最初の推進要因の 1 つは、システムとインフラストラクチャ全体で単一障害点 (SPOF) を特定して削減することです。目標は、特に新しいサービスやアプリケーションについて、重要なシステムとアーキテクチャの耐障害性を検証するように設定されています。

レジリエントアーキテクチャの目標には、サービスの依存関係の障害をシミュレートするカオス実験の実行が含まれます。実験では、タイムアウト、再試行、キャッシュ動作、サーキットブレーカー設定が正しく機能しているかどうかを確認します。これらの実験は、修復の問題を発見し、顧客に影響を与えるインシデントを防ぐのに役立ちます。例については、[「 カオスエンジニアリングを使用した Prime Video での回復力のあるサービスの構築](https://aws.amazon.com/blogs/opensource/building-resilient-services-at-prime-video-with-chaos-engineering/)」を参照してください。

## サービス復旧の目標
<a name="service-recovery"></a>

サービス復旧の目標は、運用の中断やインフラストラクチャの障害から回復する能力の向上に重点を置いています。たとえば、組織は、停止が発生した場合にコアサービスの特定の復旧時間目標 (RTO) を達成することを目指している場合があります。チームはカオス実験を設計して、退避戦略、フェイルオーバーメカニズム、自動復旧プロセスを検証および最適化できます。最適化により、最終的にサービスの復元に必要な時間が短縮されます。例については、[AWS Lambda「: Resilience under-the-hood](https://aws.amazon.com/blogs/compute/aws-lambda-resilience-under-the-hood/)」を参照してください。

## ユーザーエクスペリエンスの目標
<a name="ux"></a>

特にトラフィックの多い時間帯や重要なイベントでは、一貫性があり信頼性の高いユーザーエクスペリエンスを維持することが最優先事項です。このような場合は、特定のサービスレベル目標 (SLOs) を達成することを中心とした目標を設定します。この顧客中心のアプローチにより、障害や障害が発生した場合でも、レジリエンスの取り組みが優れたユーザーエクスペリエンスの提供と直接連携します。例については、[「エンジニアリングレジリエンス: Amazon Search のカオスエンジニアリングジャーニーからの教訓](https://community.aws/posts/amazon-search-chaos-engineering-journey)」を参照してください。

## メトリクス駆動型の目標
<a name="metrics"></a>

実証済みのレジリエンスベストプラクティスを採用するサービスにポイントを与えることで計算されるレジリエンススコアなど、定量的メトリクスに基づいて目標を設定できます。その後、特定のカオス実験を使用してレジリエンススコアを決定できます。このスコアは、チームが既知の可用性リスクを軽減し、推奨されるレジリエンス対策を実装する際の進捗状況を追跡するための指標として役立ちます。ただし、このようなスコアを慎重に解釈し、より広範な耐障害性目標を犠牲にして単一のメトリクスを強調しすぎないようにすることが重要です。例については、[「障害耐性スコアについて](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resil-score.html)」を参照してください。

## 規制コンプライアンスの目標
<a name="compliance"></a>

金融サービス業界は、主に堅牢なレジリエンス機能を必要とする厳格な規制要件によって推進され、カオスエンジニアリングを採用するフロントランナーとして浮上しています。規制では、金融機関が重要なシステムやプロセスの脆弱性を事前に特定、テスト、修復することが要求されます。これらの規制には以下が含まれます。
+ 米国連邦機関が発行した運用レジリエンスを強化するためのサウンドプラクティスに関する機関間ホワイトペーパー
+ 欧州中央銀行の運用レジリエンスに関するガイドライン
+ デジタル運用レジリエンス法 (DORA) に関する欧州委員会の提案

組織が金融機関である場合は、包括的なテストおよび検証戦略を通じて運用レジリエンスを実証するための明示的な目標を設定することで、これらの規制に従ってください。例については、[「London Stock Exchange Group uses chaos engineering on AWS to improve resilience](https://aws.amazon.com/blogs/architecture/london-stock-exchange-group-uses-chaos-engineering-on-aws-to-improve-resilience/)」を参照してください。