| R.1 |
合理的な信頼性アプローチを目標とする - 多ければ多いほど良いとは限りません。 高可用性のために内部向けシステムを構成することは良いアイデアのように聞こえるかもしれませんが、大規模なインフラストラクチャーを維持するという運用上の負担により、組織の使命に集中できない場合、信頼性の向上にかかるコストが高すぎることになります。 復旧時間の期待値を関係者と一緒に慎重に設定します。 |
| R.2 |
サポートされているツールを使用して定期的なシステムのバックアップを作成し、バックアップの復元を定期的にテストする計画を作成します。 バックアップ ワークフローにテストが含まれないと、システムの復元が失敗するリスクが生じます。 |
| R.3 |
システム信頼性戦略における最も弱い関連性 (技術、人員、プロセスのギャップなど) を理解します。 システムの稼働時間と SLA の保証は、最も脆弱なサポートシステムまたはコンポーネントによって制限されます。 |
| R.4 |
下位環境を使用して構成をミラーリングし、高可用性やバックアップ プロセスなどの信頼性アプローチをテストします。 |
| R.5 |
エスカレーション パスを定義し、問題が適切なスタッフにすぐに確実に届くようにして、問題を解決するための処置を実行できるようにします。 |
| R.6 |
ユーザーのワークフローを理解する - サービスは単純なヘルス チェックに基づいて動作していると報告する場合がありますが、ユーザーのワークフローが成功しなかった場合、システムの停止と見なされることが少なくありません。 実際のユーザーのワークフローを理解すると、問題のあるサービスまたはコンポーネントを迅速に絞り込んで、問題を修正するのに役立ちます。 |