Oded、Catcall、および Gilbert によるコメントは的を射ています。
私が IT 取引を学んだ銀行は、単一の DBMS と単一のトランザクション プロセッサを実行する単一の MVS (後の Z/OS) メインフレームでコア ビジネス全体を実行していました (TSO をトランザクション プロセッサとして数えない限り)。
トランザクション プロセッサは定期的に (たとえば、1 日に 1 回) ダウンしました。銀行は常に 1 分もかからずに稼働を再開したため、銀行が破綻することはありませんでした。走行距離はさまざまですが、1 日の営業時間の 1 分 (480 分、または 0.25% 未満) を失うことは、実際には危険なほどの混乱ではありません。
単一の DBMS も時々 (たとえば、月に 2 回) ダウンしました。sysprogs が「DBMS がダウンしています」とフェンス越しにヘルプデスク担当者に向かって叫んでいるのを今でも聞くことができます。銀行は常に数分で稼働を再開したため、銀行が破綻することはありませんでした。走行距離はさまざまですが、毎月数分のビジネス時間を失うことは、実際には危険なほど混乱するべきではありません.
銀行が本当に倒産寸前だったのは、開発チームが銀行の絶対的な中核事業の新しいプロジェクトを台無しにして、銀行が完全に廃業したかのようだったときでした (その実際の事業は) 3 日か 4 日続けて。これは 0.25% のビジネス時間の損失ではなく、ほぼ 100 倍の損失でした。
私の話の教訓?それらの2つ。(a) リスク評価 (= 確率評価) とリスク加重 (= 確率加重) コスト見積もりがすべてです。(b) SO で質問した場合 (これは、回答者が主題に関してあなたよりも専門知識を持っているという一種の認識/期待を意味します)、Oded や Catcall のような人々が正確で適切な簡潔な回答を提供します。重要なのは、その回答を裏付けるために論文やケース スタディを求めないことです。専門家の専門知識を受け入れたくない場合は、そもそもなぜわざわざ質問する必要があるのでしょうか。