

# 障害管理
<a name="failure-management"></a>

****  
 障害は発生するものであり、最終的にはすべてが時間の経過とともにフェイルオーバーします。つまり、ルーターからハードディスクまで、TCP パケットを破壊するオペレーティングシステムからメモリユニットまで、そして一時的なエラーから永続的な障害まで、どれもが対象となるのです。これは、最高品質のハードウェアを使用しているか、最低料金のコンポーネントを使用しているかにかかわらず、当たり前のことです - [https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html) 

 低レベルのハードウェアコンポーネントの障害は、オンプレミスのデータセンターで毎日対処する必要がある問題です。ただし、クラウドでは、お客様はこれらのタイプの障害のほとんどから保護されるはずです。例えば、Amazon EBS ボリュームは、特定のアベイラビリティーゾーンに配置され、単一のコンポーネントに障害が発生したときに保護できるように、自動的にレプリケートされます。すべての EBS ボリュームは、99.999% の可用性を実現するように設計されています。Amazon S3 オブジェクトは、最低 3 つのアベイラビリティーゾーンに保存され、年間 99.999999999% のオブジェクト耐久性を実現しています。クラウドプロバイダーに関係なく、障害がワークロードに影響を与える可能性があります。したがって、ワークロードの信頼性を確保する必要がある場合は、回復力を持たせる手順を実行しなければなりません。

 ここで説明するベストプラクティスを適用するための前提条件として、ワークロードを設計、実装、および運用する担当者がビジネス目標とこれを達成するための信頼性目標を確実に把握しているようにする必要があります。その担当者は、信頼性要件を認識し、トレーニングを受ける必要があります。

 以下のセクションでは、障害を管理してワークロードに影響を与えるのを防ぐためのベストプラクティスについて説明します。

**Topics**
+ [データのバックアップ方法](back-up-data.md)
+ [障害部分を切り離してワークロードを保護する](use-fault-isolation-to-protect-your-workload.md)
+ [コンポーネントの障害に耐えられるようにワークロードを設計する](design-your-workload-to-withstand-component-failures.md)
+ [テストの信頼性](test-reliability.md)
+ [ディザスタリカバリ (DR) を計画する](plan-for-disaster-recovery-dr.md)