# 結論
<a name="conclusion"></a>

 このドキュメントでは、高可用性のための 12 のルールを定めています。
+  **ルール 1** — 分散システムの可用性を向上させるには、障害の頻度が少ない (MTBF が長い)、障害検出時間が短い (MTTD が短い)、修理時間が短い (MTTR が短い) という 3 つの要素があります。
+  **ルール2** — ワークロード内のソフトウェアの可用性は、ワークロード全体の可用性にとって重要な要素であり、他のコンポーネントと同様に重視する必要があります。
+  **ルール 3** — 依存関係を減らすことは、可用性にプラスの影響を与える可能性があります。
+  **ルール 4** — 一般的には、可用性の目標がワークロードの目標と同等かそれ以上の依存関係を選択します。
+  **ルール5** — スペアリングを使用すると、ワークロード内の依存関係の可用性が向上します。
+  **ルール6** — スペアリングのコスト効率には上限があります。必要な可用性を実現するには、必要最小限のスペアのみを使用します。
+  **ルール 7** — 特にリカバリ中は、データプレーンのコントロールプレーンに依存関係を作成しません。
+  **ルール 8** — 可能な限り、依存関係が損なわれてもワークロードが正しく動作できるように、依存関係を疎結合します。
+  **ルール9** — MTTD と MTTR を減らすには、可観測性と計測が不可欠です。
+  **ルール 10** — 問題解決ではなく、影響の軽減に焦点を当てます。最速の方法で通常のオペレーションに戻す。
+  **ルール11** — 障害を分離すると、全体的な障害発生率が低下するため、影響範囲が狭まり、ワークロードの MTBF が増加します。
+  **ルール 12** — オペレーターが正しいことを簡単に行えるようにします。

 ワークロードの可用性を向上させるには、MTTD と MTTR を減らし、MTBF を増やす必要があります。つまり、テクノロジー、人材、プロセスを対象として、可用性を向上させる次の方法について説明しました。
+  MTTD 
  +  カスタマーエクスペリエンスのメトリクスを積極的に監視することで、MTTD を削減します。
  +  きめ細かなヘルスチェックを活用して、迅速なフェイルオーバーを実現します。
+  MTTR 
  +  影響範囲と運用健全性メトリクスを監視します。
  +  1/再起動、2/リブート、3/再イメージ化/再デプロイ、4/交換の順に MTTR を短縮します。
  +  影響範囲を把握して、障害を回避します。
  +  仮想マシンや物理ホストを介したコンテナやサーバーレス機能など、再起動時間が短いサービスを利用します。
  +  可能であれば、障害の発生したデプロイを自動的にロールバックします。
  +  診断オペレーションと再起動手順のためのランブックと運用ツールを確立します。
+  MTBF 
  +  本番環境にリリースする前に厳密なテストを実施し、ソフトウェアのバグや欠陥を排除します。
  +  カオスエンジニアリングと障害挿入を実装します。
  +  障害を許容できるように、依存関係には適切な数のスペアリングを持たせます。
  +  障害コンテナによって障害時の影響範囲を最小限に抑えます。
  +  デプロイと変更に関する標準を実装しまう。
  +  シンプルで直感的かつ一貫性があり、十分に文書化されたオペレーターインターフェイスを設計します。
  +  オペレーショナルエクセレンスの目標を設定します。
  +  可用性がワークロードの重要な側面である場合は、新機能のリリースよりも安定性を優先します。
  +  過負荷にならないように、スロットリングまたは負荷分散、あるいはその両方を使用して使用量クォータを実装します。

 障害を防止を完全に成功させることはできないことに留意してください。影響の範囲と大きさを制限し、理想的にはその影響を「ダウンタイム」のしきい値以下に保ち、非常に迅速で信頼性の高い検出と軽減に投資し、可能な限り最良の障害隔離機能を備えたソフトウェア設計に注力します。今日の分散システムでは、依然として障害を不可避なものとして受け入れ、高可用性を実現するためにあらゆるレベルで設計する必要があります。