信頼性 - ディザスターリカバリーパターン


適切に設計された信頼性 → ディザスタリカバリとビジネス継続性の詳細

パターン

参照すべき場所外観
データバックアップ戦略✅ データエクスポートサービスまたは専用のバックアップおよびリカバリサービス ([Own (所有)] など) を使用した毎週または毎月の自動エクスポート。エクスポート頻度が RPO 要件に一致する。必要に応じて外部オブジェクトストレージにエクスポートされる重要なオブジェクトデータ。
メタデータバックアップ戦略✅ Salesforce DXソース形式を使用してGitでバージョン設定されたすべてのメタデータ。メタデータの変更はソース制御からのみリリースされます。CI/CD パイプラインでは、リポジトリから任意の環境を再作成できます。Git 履歴で使用可能なポイントインタイムリカバリ。
ファイルバックアップ戦略✅ Content外部ストレージにスケジュールどおりにエクスポートされたレコード、添付ファイル、ドキュメントのバージョン。規制保持要件に対応した自動ファイルエクスポート。業務上のニーズよりも古いファイルの外部アーカイブシステム。
バックアップの検証✅ Full Sandboxまたは開発者環境への四半期ごとのリストア ドリル。Runbook に記載されている手順をステップバイステップで復元します。テスト復元では、災害が発生する前にバックアップの整合性と完全性を検証します。
リカバリテストスケジュール✅ 四半期ごとの部分リストアテスト (メタデータ、特定のオブジェクト、ファイルサブセット)。完全な環境復元を含む毎年恒例の完全復旧訓練。各テスト後に文書化され、更新されたランブックで学習した教訓。
サードパーティのバックアップサービス✅ ポイントインタイムリストア機能を備えた自動バックアップ。RPO/RTO を定義するサービスレベル契約。バックアップ完了の日次自動検証。複数のリージョンにバックアップが保存されている地理的冗長性。
カスタムオブジェクトとカスタム項目✅ スケジュール済みデータエクスポートサービスの実行に含まれるカスタムオブジェクト。エクスポートではなく再計算される数式項目値と積み上げ集計項目値 (取り込むための保存値がない)、およびファイルまたは添付ファイルバイナリが個別のエクスポートパスで処理されます。復元シーケンスで文書化およびテストされた複雑なデータ型と参照関係。
ファイルと添付ファイル✅ ファイルバイナリでエクスポートされた ContentDocument および ContentVersion オブジェクト。フォルダー構造と権限を含めてバックアップされたドキュメントライブラリ。エクスポートされたファイルには、重要なドキュメント種別のバージョン履歴が保持されます。
Sandbox の更新戦略✅ 負荷テストとディザスター リカバリー検証のために、本番組織が四半期ごとにFull Sandboxに更新されました。復元手順テストとして使用される Sandbox の更新。テスト環境で機密データを保護するために更新後に適用されるデータマスキング。
バックアップの監視とアラート✅ スケジュール済みバックアップが失敗したり遅延したりしたときに自動アラートが表示されます。バックアップジョブの成功率、完了時刻、データ量のトレンドが表示されているダッシュボード。許容遅延期間を超えるバックアップ失敗のオンコールエスカレーション。

アンチパターン

参照すべき場所どんな悪い感じか
バックアップ戦略⚠️ 自動バックアップが設定されておらず、プラットフォームインフラストラクチャのバックアップのみに依存しています。サードパーティのバックアップサービスは設定されていますが、テストされていません。バックアップが破損しているか、不完全である可能性があります。バックアップで手動データローダーのエクスポートを使用 (実行の一貫性がない、対象範囲が不完全、自動化されていない)。
メタデータバージョン管理⚠️ ソース管理なしで変更セットを介してリリースされたメタデータの変更。メタデータ履歴用の Git リポジトリがありません。ポイント イン タイム リカバリは不可能 - 破壊的な変更後に最新の既知の正常な構成を復元できません。
バックアップの検証⚠️ バックアップが設定されていますが、テスト環境に復元されていません。最初の復元試行は、実際の災害時に実行され、範囲が不完全または破損したアーカイブが明らかになります。文書化されているが、バックアップ担当者によってテストされていないバックアップ手順。
バックアップ範囲⚠️ 数式項目値と積み上げ集計項目値がエクスポートされず (保存されず動的に再計算される)、ファイルまたは添付ファイルバイナリで個別の処理が必要な場合、データエクスポートサービスですべてを取得すると想定し、復元時にのみギャップが検出されます。
復旧手順⚠️ Recovery runbook には、2 年前のアーキテクチャからの古いステップが含まれています。退職した 1 人のエキスパートによってテストされた復旧手順。手動の手順が複雑すぎて、ストレス下で実行するとエラーが発生しやすくなります。
バックアップ頻度⚠️ ビジネス要件が 24 時間の RPO の場合、重要なトランザクションデータを毎週バックアップします。バックアップ頻度がビジネスの重要度と一致していない - 重要度に関係なく、すべてのデータのスケジュールが同じ。監視とアラートがないため、バックアップスケジュールが欠落しています。
法令順守⚠️ 管理規制で要求されるよりも短いバックアップ保持。たとえば、HIPAA コンプライアンスドキュメント (ポリシー、リスク分析、BAA、侵害レコード) が 6 年間の保存期間より前に消去された場合や、SOX 準拠の財務監査レコードが 7 年間の保存期間より前に削除された場合などです。監査中に検出されたコンプライアンスギャップ。
ファイルストレージ⚠️ アーカイブ戦略なしで Salesforce に保存されている大容量ファイル。組織の制限に近づくまでファイルストレージが増加します。ContentVersion レコードのバックアップはありません。組織が破損するとファイルが失われます。重要なファイルの個人コピーをユーザーが保持すること。
Sandbox テスト⚠️ Full Sandbox が本番から更新されていない - テスト環境が本番と大きく異なる。Sandbox のデータ量が本番の 1% であるため、現実的なリストア検証が妨げられています。Sandbox の更新は、ディザスターリカバリー検証の機会ではなく、不便なものとして処理されます。
Monitoring⚠️ バックアップジョブはアラートなしでサイレントに失敗します。数週間後に災害が発生し、バックアップが必要になったときにバックアップの失敗を検出します。バックアップジョブの成功トレンドを示すダッシュボードがありません。請求書の到着時にのみ監視されるバックアップサービスの健全性。
暗号化鍵⚠️ Shield で暗号化されたデータを鍵素材を保護せずに安全として扱う: 鍵を循環させるだけでは以前のデータはそのまま残りますが、テナントの秘密 (暗号シュレッダー) を破棄したり、Bring Your Own Key やキャッシュのみの鍵素材を紛失したりすると、暗号化されたデータを完全に復元できなくなります。鍵の管理は、回復手順から除外されます。
組織間の連動関係⚠️ ソリューションが接続アプリケーション、外部インテグレーション、または SSO に依存している場合、プライマリ組織のみのバックアップ: 接続アプリケーションの秘密、指定ログイン情報と OAuth 認証、外部認証トークンは、データおよびメタデータの復元では保持されず、復元された組織が外部システムに対して認証できるようにする前に再設定および再承認する必要があります。外部 SSO が唯一のログインパスの場合、完全に復元された組織へのログインも、使用できない ID プロバイダーによってブロックされます。

パターン

参照すべき場所外観
目標復旧時間 (RTO) の定義✅ 組織全体で均一ではなく、ビジネス能力ごとに定義された RTO。収益が重要な業務: 数分から 1 時間。顧客対応サービス: 1 ～ 4 時間。内部ツール: 4 ～ 24 時間。履歴レポート: 日数。ビジネス関係者の承認を得て文書化した RTO。
目標復旧時点 (RPO) の定義✅ 機能あたりの許容されるデータ損失に基づいて定義された RPO。金融トランザクション: ほぼゼロの RPO (秒、イベント駆動型非同期レプリケーション)。顧客レコード: ほぼゼロ (CDC により数分)。Analytics データ: 時間 (スケジュール済み同期)。一時的なワークフロー状態: 日 (複製は不要)。
チームの対応可能状況と役割✅ すべての重要なロールについて文書化されている主担当者とバックアップ担当者。Operation Knowledgeに単一障害点はありません。プライマリレスポンダー、最初のバックアップ、2 番目のバックアップを定義するエスカレーションツリー。Salesforce が使用できないときにシステムにアクセスできる連絡先情報。
コミュニケーション手順✅ ユーザー、顧客、役員に通知するユーザーを定義するインシデントコミュニケーション計画。プラットフォームの停止中にユーザーとコミュニケーションを取るために Salesforce の外部でホストされる外部状況ページ。プライマリコミュニケーションツールを使用できない場合のオンコールチーム向けの SMS 通知システム。文書化したエスカレーション期間 (チームからマネージャー、役員へとエスカレーションするタイミング)。
ベンダー連動関係の対応付け✅ Salesforce、インテグレーションパートナー、ISV パッケージプロバイダーなど、文書化されているすべての重要な外部ベンダー。ベンダーの SLA とサポート期間が文書化されている (24 時間 365 日、営業時間のみ)。ベンダーのエスカレーション連絡先と手順が文書化されている。重要な連動関係で特定された代替ベンダーオプション。
規制通知義務✅ 業種 (金融サービス、ヘルスケア、政府) ごとに文書化されている必須インシデント通知要件。各管理規制の必須期間に一致するように定義された通知期間。誰がどの規制機関に届出を行うかを定義する責任マトリックス。迅速な規制通知のために準備されたテンプレート。
ビジネスインパクト分析✅ 収益への影響、ユーザーへの影響、規制リスクでランク付けされた各ビジネス能力。ビジネスインパクトランキングに基づくリカバリの優先順位付け。ビジネスの重要度に比例して災害復旧に割り当てられるリソース。影響分析は、ビジネスの優先度の進化に合わせて毎年確認されます。

アンチパターン

参照すべき場所どんな悪い感じか
RTO/RPO 定義⚠️ 測定可能な RTO/RPO 目標のない「システムは信頼できる必要がある」。ビジネス関係者の入力なしで IT チームによって定義された RTO/RPO。重要度の違いを無視したすべての機能の目標の統一 (「99.999% のアップタイムが必要」)。
チームの準備状況⚠️ 1 人の Salesforce システム管理者が、ドキュメントやバックアップ担当者なしでディザスターリカバリー手順を把握している。オンコールの循環には、復旧手順を実行したことのない担当者が含まれます。災害時 (休暇、病気、退職者) にプライマリレスポンダーが対応できない。
コミュニケーション計画⚠️ コミュニケーションプランなし - インシデントがすでに進行中の後でユーザーに通知する必要があることを発見する。Salesforce の停止中は、Salesforce 自体でホストされている状況ページは使用できません。リカバリの試行中に役員に通知するために待機している時間。
ベンダー連動関係⚠️ 災害が発生するまでベンダーの SLA 条件を認識しておらず、営業時間のみを対象とするベンダーからの 24 時間 365 日のサポートを予期している。ベンダーのエスカレーション連絡先が文書化されていない。リカバリには ISV パッケージプロバイダが必要ですが、会社はもう営業していません。
規制要件⚠️ 必須の違反通知法を認識していない。48 時間が経過した後に 24 時間通知の要件を検出します。テンプレートが用意されていない - コンプライアンスクロックが鳴っている間にインシデント対応中に規制通知のドラフトを作成。
リカバリの優先順位付け⚠️ 災害発生時に、収益が重要な業務を優先するのではなく、すべての機能を同時に復元しようとする。顧客対応注文システムに対応する前に内部レポート機能の復旧に 8 時間を費やしている。
テストとドリル⚠️ 訓練でテストされたことのない事業継続計画。ドキュメント化された手順が検証なしでストレス下で機能することを前提としています。実際の災害時に未発見の問題から回復するために数日を費やしているにもかかわらず、「時間がない」ために机上の演習が回避された。
Knowledgeの伝達⚠️ Disaster Recovery Knowledge 1人のシニア アーキテクトに集中し、何も文書化していない。ディザスター リカバリー トレーニングなしでオンボーディングされた新規チーム メンバー。全員が、明示的な訓練や訓練なしで、災害時に何をすべきかを知っていると仮定します。
前提条件の検証⚠️ リカバリ手順は、15 分以内にアクセスできるバックアップを前提としていますが、コールドストレージからのバックアップの取得には 8 時間かかります。チームが 30 分以内に対応可能で、オンコールのローテーション手順またはエスカレーション手順が定義されていないことを前提としています。テストで検証されなかった楽観的な仮定に基づく復旧時間の推定。

パターン

参照すべき場所外観
RTO アーキテクチャの調整✅ アーキテクチャに関する意思決定は RTO コミットメントと一致します。Minutes RTO では、自動フェールオーバーとホットスタンバイが必要です。時間 RTO では、スクリプトによるリカバリとウォームスタンバイが必要です。Days RTO では、コールドバックアップからの手動リカバリが可能です。過剰な設計は、ビジネスが複雑さを正当化しないところでは回避されます。
RPO レプリケーション戦略✅ 複製方法が RPO 目標と一致する。RPO (目標復旧時点): レコードの保存ごとにプラットフォームイベントを介して非同期イベントストリーミング (伝達遅延の秒数、少なくとも 1 回の配信)。Minutes RPO (分 RPO): Change データキャプチャ async replication (変更データキャプチャ非同期レプリケーション)。Hours RPO (時間 RPO): スケジュール済みバッチ API 抽出。Days RPO (目標復旧時点): 固定スケジュールでの手動バックアップ。
RTO テスト✅ 一定の条件下でテストされた回復手順。ディザスタリカバリ訓練中に測定された実際の RTO。目標 RTO と達成 RTO のギャップを特定し、修正します。プライマリ・エキスパートだけでなく、バックアップ担当者もRTOを達成できます。
RPO 検証✅ リカバリテスト中に測定されたデータ損失。訓練中の目標と比較した実際の RPO。本番で継続的に監視されるレプリケーション遅延。複製が RPO コミットメントに間に合わない場合に設定されたアラート。
機能固有の RTO/RPO✅ ビジネスの重要度を反映する RTO/RPO 目標は、ビジネス能力によって異なります。E コマース注文フロー: 15 分の RTO、ほぼゼロの RPO (マルチ組織のアクティブ-パッシブを正当化)。内部Knowledgeベース: 8時間のRTO、24時間のRPO(バックアップからの手動リストアを推奨)。
費用便益分析✅ 実装コストに対してバランスの取れた RTO/RPO 目標。より厳しい目標では、投資を飛躍的に増やす必要があります。ディザスタリカバリへの投資を正当化するダウンタイムコストを示すビジネスケースが文書化されています。年次レビューでは、投資とビジネス価値の継続的な連携を確認します。
SLA の調整✅ ソリューションの RTO/RPO 目標は、プラットフォームの SLA ベースラインを考慮します。ソリューションでは、複数組織アーキテクチャのプラットフォームのベースラインよりも優れた RTO しか提供できません。プラットフォーム機能を基盤として設定された現実的な目標。
リカバリ機能の監視✅ バックアップ通貨の継続的な監視 (バックアップ期間と RPO 目標)。バックアップがスケジュールより遅れた場合にアラートを表示します。リカバリインフラストラクチャ (セカンダリ組織、外部ストレージ) が動作していることの自動検証。
自動リカバリと手動リカバリ✅ 積極的な RTO 目標 (分) では、最小限の人手による自動フェールオーバーが必要です。中程度の RTO 目標 (時間) では、人間が開始するスクリプト形式のリカバリが可能です。緩和された RTO 目標 (日数) では、文書化された手順に従って手動リカバリが可能です。

アンチパターン

参照すべき場所どんな悪い感じか
非現実的な目標⚠️ 15 分の RTO を約束し、手動リカバリ手順の実行に 4 時間を要する。同期レプリケーションインフラストラクチャを使用せずにRPOゼロを約束。アーキテクチャのサポートなしで IT 部門が設定した RTO 目標。
アーキテクチャの不一致⚠️ 30 分の RTO コミットメントがあるが、自動化されたフェールオーバーおよびリカバリ手順が完全に手動ではない。RPO コミットメントなし。ただし、日次バックアップのみが構成されます。自動化と冗長性に対応する投資なしで積極的な目標。
テスト対象外⚠️ RTOが定期的なディザスタリカバリ訓練で検証されていない。2 時間の RTO は達成可能だが、時間的制約の下で実際にリストアされないと仮定します。実際の災害時に 4 時間の RTO を文書化するには、実際には 18 時間かかります。
均一目標⚠️ ビジネスの重要度に関係なく、すべての機能に同じ RTO/RPO が割り当てられている。内部バッチレポートシステムは、収益に不可欠な E コマースで同じ目標を使用しながら、99.9999% の可用性を実現するように設計されています。重要でない機能に多額の過剰投資し、重要なシステムに過少投資する。
連動関係を無視する⚠️ RTO は Salesforce 組織の復元のみを前提としていますが、ソリューションは外部 ID プロバイダーによっても使用できません。RPO では、データのバックアップは十分であると想定されますが、インテグレーションログイン情報と設定はバックアップされません。リカバリ時間の推定では、連動システムのリストア時間は無視されます。
レプリケーションのギャップ⚠️ 15 分の RPO を目指すが、12 個の重要なオブジェクトのうち 3 個のみの変更データキャプチャが設定されている。プラットフォームイベント複製が設定されていますが、イベント配信遅延の監視は行われていません。レプリケーションインフラストラクチャは破損し、障害が発生するまで数週間検出されません。
コスト無知⚠️ 実装コストを把握せずに99.9999%の可用性を実現する。費用便益分析なしで設定された RTO/RPO 目標。すでに顧客にコミットされている目標に必要なインフラストラクチャに資金を提供したくないビジネス。
静的目標⚠️ 5 年前に定義された RTO/RPO は、ビジネスの成長や優先度の変化にもかかわらず再評価されていません。ソリューションは進化し、重要度が変化しても目標は変わりません。年次レビュープロセスがありません。
ドキュメントのギャップ⚠️ RTO/RPO 目標はアーキテクチャドキュメントに文書化されているが、ビジネス関係者には伝達されていない。コミットされたリカバリ機能を認識していない。ビジネスで 1 時間のリカバリが期待されていても、アーキテクチャでは 24 時間の RTO しかサポートされていない場合に検出されたギャップ。
偽精度⚠️ インフラストラクチャを監視するときに「99.97% の可用性」にコミットすると、その精度を測定できません。基礎となる分析が概算の場合に厳格さを示唆する偽の精度で定義された目標。
不在の監視⚠️ リカバリー機能を継続的に監視していない。バックアップが RPO コミットメントに違反するスケジュールから 2 日遅れているが、アラートがない。複製更新を受信していないが状態チェックが設定されていないアクティブ-パッシブアーキテクチャのセカンダリ組織。
実行なしの計画⚠️ 積極的な RTO/RPO 目標はあるが、自動化、テスト、検証済みの手順がない、美しいディザスタリカバリ計画。[コンプライアンスを満たすために作成された計画] チェックボックスをオンにしても、コミットメントの背後にある運用上の現実はありません。

パターン

参照すべき場所外観
データの冗長性✅ プラットフォームは、インフラストラクチャのバックアップを自動的に提供します。アプリケーションレベルのレプリケーションは、ビジネスでより迅速なリカバリが必要な場合にプラットフォームのバックアップを補完します。Change データキャプチャ (変更データキャプチャ) または Platform Events (プラットフォームイベント) では、重要なデータがセカンダリストレージに継続的に複製されます。レプリケーションにより、インフラストラクチャのバックアップでは対処できない論理的な破損や構成エラーからのリカバリが可能になります。
アプリケーションの冗長性✅ 個々のトランザクションの失敗に耐えるステートレスなアプリケーションロジック。水平スケールを妨げるサーバー側の状態はありません。カスタムメタデータ型と設定のカスタム設定は、すべてのアプリケーションサーバーですぐに使用できます。アプリケーションサーバーは、特定のサーバーの状態に依存することなく、任意の要求を処理できます。
インテグレーションの冗長性✅Circuit Breakerパターンでインテグレーションの失敗を検出します。プラットフォームイベントは、外部システムが使用できないときに、ユーザーの操作をブロックするのではなく要求をキューに入れます。ユーザー対応機能から分離された外部システム障害。重要なインテグレーション用に特定された複数の外部ベンダーオプションにより、ベンダーの停止中にプロバイダーをすばやく切り替えることができます。
重要なワークロードの複数組織パターン✅ アクティブ-パッシブパターン: プライマリ組織はすべてのトラフィックに対応し、セカンダリ組織は同期済みですがアイドル状態になり、プライマリリージョンの停止中にフェールオーバーします。有効-有効パターン: 両方の組織で本番トラフィックを継続的に処理し、ユーザーは地域またはビジネスユニットごとに割り当てられます。マルチ組織は、ビジネスでプラットフォーム機能を超える RPO/RTO が必要な場合にのみ有効です。
複数組織のデータ同期✅ 変更データキャプチャでは、重要なデータのほぼリアルタイムのレプリケーション (15 分の RPO) が提供されます。プラットフォームイベントでは、重要なトランザクション (ほぼゼロの RPO) のイベントストリーミングが提供されます。参照データの Bulk API 2.0 スケジュール済みレプリケーション (24 時間の RPO を許容)。両方の組織で同じレコードが変更されたときに有効-有効に対して定義された競合解決戦略。
複数組織のアクティブ/パッシブ アーキテクチャ✅ 米国東部地域のプライマリ組織がすべての本番トラフィックに対応します。ヨーロッパ地域のセカンダリ組織は CDC を介して同期されていますが、アイドル状態です。DNS ルーティングまたは認証レイヤーによって、ユーザーは有効な組織に転送されます。自動状態チェックでは、プライマリ組織が 10 分間連続して使用できない場合にフェールオーバーがトリガーされます。
複数組織のアクティブ-アクティブアーキテクチャ✅ ユーザープロファイル地域項目に基づくヨーロッパ組織の EMEA ユーザー、米国組織の AMER ユーザー。共有参照データ (取引先、商品) の双方向レプリケーション。地域データはそれぞれの組織 (注文、ケース) に保持されます。競合の解決では、顧客マスターデータに地域権限のある最終更新者勝ちが使用されます。
地理的分布✅ Hyperforce地域のデータセンターでは、地理的な分散が可能です。プラットフォームで管理される冗長性により、99.9%の可用性を実現する単一リージョンの導入。99.95% 以上の要件または規制データレジデンシー要件でのみ考慮される地域全体のマルチ組織。
外部システムの冗長性✅ 重要な外部 API にはプライマリエンドポイントとフェールオーバーエンドポイントがあります。Circuit Breaker は、プライマリで障害が継続した場合にフェールオーバーエンドポイントに切り替えます。重要なインテグレーションでは、地理的冗長性を備えた外部サービスが単一地域プロバイダーよりも優先されます。
インフラストラクチャの監視✅ Status APIを使用して監視されるTrust.salesforce.com。インスタンス固有の状況通知を登録します。ソリューションは、パフォーマンス低下時の重要でない負荷を減らすことで、プラットフォームの健全性状況に動的に対応します。Scale Centerでは、リソースを大量に消費する操作が冗長性容量に影響する前に識別されます。
フェールオーバーの自動化✅ 積極的な RTO 目標では手動ではなく自動フェールオーバーが優先されます。状態チェックは、1 ～ 5 分ごとに失敗を検出します。フェールオーバー決定ロジックにより、偽陽性が回避されます (一時的なエラーではなく、継続的な障害が必要)。フェールオーバー先も正常でない場合の自動ロールバック。
単一障害点✅ アーキテクチャレビューでは、すべての単一障害点を特定します。特定された各 SPOF は、ビジネスへの影響と軽減コストを評価します。冗長性によって影響の大きい SPOF を軽減。リスクの受け入れと復旧手順が文書化されている影響の少ないSPOFを受け入れます。
冗長性機能のテスト✅ スケジュール済みフェールオーバードリルでは、自動フェールオーバーロジックが検証されます。負荷時にテストされたバックアップシステム (アイドル状態のウォームスタンバイだけではない)。セカンダリ組織の業務量が検証された、アクティブ-パッシブテスト中の本番環境の負荷の処理。各テストから得られた教訓により、自動化と手順が改善されます。

アンチパターン

参照すべき場所どんな悪い感じか
単一障害点⚠️ ソリューション全体は、フォールバックのない単一の外部 API に依存します。カスタムドメインプロバイダーは SPOF です。プロバイダーが失敗すると、ユーザーは Experience Cloud にアクセスできません。単一インテグレーションユーザーアカウント - 無効にすると、すべてのインテグレーションが失敗します。
テストされていない冗長性⚠️ マルチ組織のアクティブ-パッシブアーキテクチャが設定されていますが、テストされていません。セカンダリ組織が同期していないが、状態チェックが設定されていない。最初のフェールオーバー試行は、実際の災害時に発生し、セカンダリ組織が破損しているか機能していないことが明らかになります。
データ同期ギャップ⚠️ 30 個の重要なオブジェクトのうち 5 個に対して CDC 複製が設定されたアクティブ-パッシブのマルチ組織。フェールオーバーは発生しますが、セカンダリ組織に必要なデータの 80% がありません。レプリケーション遅延監視なし - セカンダリ組織がプライマリ組織に 3 日遅れてアラートなし。
冗長性の誤り⚠️ 両方の組織が実際に同じ Hyperforce リージョンでホストされている場合、マルチリージョンアーキテクチャを想定しています。実際に同じ上流プロバイダーを使用する「冗長」外部 API。すべて同じ単一障害点を通過する複数のインテグレーションパス。
ステートフルアーキテクチャ⚠️ アプリケーションロジックは、メモリ内状態に依存して水平スケーリングを防止します。1 つのアプリケーションサーバーですべてのユーザーセッション状態が保持されます。サーバーを再起動すると、すべてのユーザーがログアウトされます。静的リソースがプラットフォームキャッシュではなくアプリケーションメモリにキャッシュされるため、サーバー間で不整合が生じます。
ブレーカーなし⚠️ 外部インテグレーションが失敗し、すべてのトランザクションが 120 秒タイムアウトするまで待機します。1 つの外部システムが使用できない場合、すべてのユーザーが影響を受けます。障害の切り分けなし - インテグレーションが 1 つ失敗すると、プラットフォーム全体のパフォーマンスが低下します。
手動フェイルオーバーのみ⚠️ 手動のフェイルオーバー手順のみを使用する複数組織アーキテクチャ。業務が停止している間にフェイルオーバーを開始するには 2 時間の手順が必要です。自動状態チェックが実装されていない。フェイルオーバーの決定には、リカバリを遅らせる経営陣の承認が必要です。
業務量計画の失敗⚠️ 本番負荷の 20% に対応するサイズのアクティブ-パッシブアーキテクチャのセカンダリ組織。フェールオーバーは発生しますが、セカンダリ組織は完全な本番トラフィックを処理できません。両方の組織の業務量が 85% のアクティブ-アクティブアーキテクチャで、一方の組織に障害が発生しても冗長性はありません。
設定ドリフト⚠️ リリースが同期されないため、プライマリ組織とセカンダリ組織が時間と共に異なる。メタデータはプライマリにリリースされますが、セカンダリにはリリースされません。フェールオーバーにより、6 か月前のコードバージョンを実行しているセカンダリ組織が表示されます。
オーバーエンジニアリング⚠️ 5 人で使用する内部管理ツールのアクティブ-アクティブレプリケーションを備えたマルチ組織アーキテクチャ。ビジネス上の重要性から判断されないマルチ組織の運用の複雑さ。バッチレポートの可用性目標は 99.999% で、99% で許容されます。
地理的誤解⚠️ Hyperforce「マルチ リージョン」で自動的にマルチ組織機能が提供されるとします。1 つの組織が常に 1 つの地域に存在し、マルチ地域には複数の組織が必要であることを理解していない。単一組織アーキテクチャでは不可能な地域ベースの冗長性。
インテグレーション結合⚠️ すべてのインテグレーションは同期であり、非同期フォールバックはありません。外部システムが使用できないと、ユーザー操作がブロックされます。キューイングメカニズムなし - 外部システムが一時的に停止した場合、トランザクションは失敗します。インテグレーションが使用できない場合、ユーザーは続行できません。