--- schema_version: "1" id: 3dc2407ddc19c398ee04246dadc4149528d960380dd049feff368ef1a3e6dd36 title: 耐障害性 collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/well-architected/guides/resilient.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/resilient.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 8f578927da8189b59c50b010899b69f1f0f0ef861fd706d38ec744176b7021a0 products: - 適切に設計された - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- > 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。 ## はじめに 耐障害性に優れたソリューションは、障害が発生しても高いサービス品質を維持します。パフォーマンスが低下したり、サービスが中断されたりしても、ソリューションは迅速かつ効果的に復旧します。 ソリューションの耐障害性は、次の 2 つの主要な性質に基づいています。 - **靭性**:問題が発生した場合、ソリューションは問題に耐えて耐えます。 - **弾力性**:問題が解決されると、ソリューションは理想的な状態または形状に戻ります。 耐障害性を備えたソリューションを設計するには、靭性と弾力性の両方を考慮して設計し、計画された変更や予期しない変更に直面しても耐久性と迅速な復旧の両方を確保する必要があります。 テクノロジーコンテキストでは、システムやソリューションを、共通の目標を実行するために調整する相互依存するコンポーネントのコレクションとして考えます。すべてのコンポーネントが失敗する可能性があります。これらのコンポーネント内の問題 (コードや設定の不具合からネットワークやハードウェアの問題まで) により、予期しない動作が発生する可能性があります。1 つ以上のコンポーネントに障害が発生しても、システム全体が機能し続けるか、すぐに安定した状態に戻ると、システムは回復性のある動作を示します。 Salesforce ソリューションの耐障害性を向上させるために、3 つの主要な習慣に焦点を絞ることをお勧めします。 - [**アプリケーション ライフサイクル管理(ALM)**](/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理):アイデアの創出から廃棄までのライフサイクル全体にわたって、チームがソフトウェアを管理する方法 - [**インシデント対応**](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応):システムの可用性やセキュリティに影響する問題をチームが特定し、対処して防止する方法 - [**継続性計画**](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画):予期しないイベントによって問題が発生した場合に、チームがどのように人員とシステムを機能させ続けるかを計画します。 ## アプリケーションライフサイクル管理 アプリケーションライフサイクル管理 (ALM) は、作成から廃棄までのライフサイクル全体でソフトウェアを総合的に管理する手法です。ALM は、システムの耐障害性の要であり、アプリケーションライフサイクルに関連する人、プロセス、ツール、専門分野を網羅します。これらの領域には、DevOps と配信方法、オブザーバビリティ、テスト戦略、ガバナンス、CI/CD が含まれます。 ビジネスで ALM を効果的に実践すると、チームは変化にすばやく対応し、アプリケーションは安定性や品質を損なうことなく、進化するビジネス要件に対応します。 一方、健全な ALM がない場合、チームはアプリケーションライフサイクルのすべてのフェーズで苦労します。 問題のある ALM の症状を次に示します。 - 時間がかかり、エラーが発生しやすい開発サイクル - 負荷が高く困難な導入 - 本番環境および QA 後に発見された重大度の高い問題またはバグ - 幻覚や一貫性のない動作を行う AI エージェント - リリースの安定化に必要な頻繁なロールバックまたはホットフィックスの導入 ALM はソリューションのほぼすべての側面に触れるため、ソリューションの明確で効果的な ALM プラクティスを確立することは、アーキテクチャ作業の重要な部分です。 3 つの主要な領域に焦点を当てて、ALM プラクティスを改善します。 - [**リリース管理**](/docs/architect/ja-jp/well-architected/guide/resilient#リリース管理)：変更の計画、順序付け、制御、さまざまな環境への移行 - [**環境戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略) — 開発およびテスト中にターゲット環境でアプリケーションを使用および管理する方法に関する戦略 - [**シグナリング戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#シグナリング戦略) — システム内の障害を検出して劣化が発生する前に修正するために使用する重要なシグナルとアプリケーション計測の定義 - [**テスト戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略) — ALM プロセス中にアプリケーションの成功を測定するためのテストを計画および実行する方法の指針となる原則と標準 ### リリース管理 リリース管理には、変更の計画、順序付け、制御、1 つ以上の環境への移行が含まれます。1 つのリリースは、チームが同時に対象環境に移行する計画済みの変更のグループです。 システムへの変更をリリースすると、そのシステムにはリスクが生じます。変更前のシステムが安定した状態の場合、新しい状態に移行し、将来の変更によるリスクに対して脆弱になります。今後何らかの変更によってシステムが制御不能で不安定な状態になると、重大なインシデントが発生する可能性があります。ソリューション アーキテクチャでは、耐障害性の高いリリースに向けた設計は、個々の[変更を効果](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)的にテストするだけではありません。また、システムとそのユーザーへの変更を安全に導入する方法を計画します。 チームが実行する作業は、予測可能で正確なリリース情報によって異なります。変更管理および有効化プロセスでは、どの変更をシステムに移行できるかを明確にします。リリース管理および有効化プロセスで、変更をシステムにリリースする方法と頻度を指定します。 ビジネス関係者も、特に要求する機能やバグ修正に関連するリリース情報に関心を持っています。ソリューションを Trust して関係者に価値を示すには、一貫性のある明確なリリーススケジュールを設定し、安定したリリースアーティファクトを出荷します。 Salesforce の効果的なリリース管理を確立する - アーキテクチャおよび開発ガバナンスと**緊密に連携**します。関連するすべてのガバナンスフォーラムと統制に合わせて、リリースを事前に計画してください。開発を開始する前に、AI Council で優先度の高いすべての Agentforce 使用事例を確認して承認を受けます。法務チームと倫理的な使用チームによる高リスクの Agentforce 使用事例のレビューを取得します。リリース チェックリストとドキュメントを使用して、ガバナンス活動に対して Agentforce エージェント API 名などのリリース アーティファクトを追跡します。 - **[組織ベースの開発プロセスまたはリリースプロセス](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**は使用しないでください。このパラダイムは、開発およびリリース用のより古い制限されたテクノロジーを反映しています。Salesforce CLI を使用すると、チームはソース主導の開発およびリリース機能を採用できるようになりました。 - **できるだけ安定したリリースメカニズムを選択**します。このアプローチでは、2 つのことを実現します。まず、リリース期間とサービスの中断を最小限に抑えます。次に、高度に制御された予測可能なリリース動作が可能になります。リリースメカニズムの安定性が高ければ高いほど、修正やロールバックを必要とする変更がリリースで発生する可能性が低くなります。予期しない問題が発生した場合、安定したリリースメカニズムにより、サポートスタッフやシステム管理者がロールバックをより簡単に実行できるようになります。 チームにとって最適なリリースメカニズムは、チームに必要なスキルを備えた最も安定したオプションです。推奨されるリリースメカニズムを安定性の順にリストします。すべては相互に互換性があるため、会社にとって最適な場合は複数を組み合わせて使用します。 - [**ロック解除済みパッケージ**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) — ロック解除済みパッケージは、最も安定したリリース アーティファクトです。パッケージをインストールして変更をリリースすることが、最も迅速かつ予測可能な変更の導入方法です。パッケージではバージョン管理が使用されるため、堅牢な変更管理とシステム管理者が理解しやすいきめ細かいロールバックが可能です。また、パッケージには強力なメタデータ管理が必要なため、不適切な連動関係を早期に特定できます。また、監査可能な開発パイプラインとアーティファクトも作成します。「[パッケージ化](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ性)可能性」を参照してください。 - [**DevOps センター**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5):DevOps センターでは、ロー コードまたはプロコードのスキル セットを持つデリバリ チームがソース管理を使用し、変更に対して共同で作業し、共通のリリース パスを定義することができます。DevOps センターはソース制御と統合されており、ポイント アンド クリックで変更やリリースを制御できます。 - ** [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli) を使用したソース駆動開発およびメタデータのリリース** — パッケージを使用できない場合は、Salesforce CLI を使用してソース駆動開発およびメタデータのリリースを行います。古い package.xml 形式を使用してメタデータをリリースしないでください。推奨[ソース形式](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm)とは異なる構造に従います。ソース形式は、パッケージ開発、スクラッチ組織のワークフロー、Sandbox でのより詳細な変更追跡をサポートするように進化しました。この形式は読みやすく、複雑なメタデータ型と連動関係をより分離でき、リリースマニフェストをより詳細に制御できます。 - **リリースに名前**を付けます。リリースに明確な識別子を付けることで、チームと関係者が一貫性を保つことができます。Salesforce では、各メジャーリリースの名前は「Spring」、「Summer」、または「Winter」で始まり、その後にリリース年 (「Summer '25」など) が続きます。会社でリリースを定義および整理するための命名規則がまだない場合は、命名規則を作成して使用します。明確なリリース名を使用すると、チームのシステム全体の計画、開発、提供のすべてのフェーズで情報を整理できます。[ロード](/docs/architect/ja-jp/well-architected/guide/intentional#ロードマップ)マップのリリース名を使用して、どの変更がいつ行われるかを関係者に明確に伝えます。開発アーティファクトを簡単に追跡および監査できるように、ドキュメント、変更ログ、作業説明、コードコメント、ソース制御のブランチでリリース名を使用します。 - **リリースマニフェスト内で、連動関係を適切に管理します。**Salesforce メタデータには組み込み連動関係があります。Salesforce リリースが失敗する一般的な理由は、連動関係が適切に管理されていないことです。すでに説明したように、安定したリリースメカニズムを選択することで、開発サイクルの早い段階で不適切な管理連動関係が公開される可能性があります。ロック解除済みパッケージが最も安定したリリース車両である主な理由の 1 つは、パッケージの開発と作成に必要な強力なメタデータ管理にあります。自分またはリリース管理チームが Salesforce メタデータ型間の組み込み連動関係を理解していない場合、リリースマニフェストとリリースマニフェストで問題のある組み合わせを積極的に見つけることはできません。「[連動関係管理](/docs/architect/ja-jp/well-architected/guide/composable#連動関係管理)」を参照してください。 [ALM のパターンと](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)アンチパターンは、Salesforce 組織でのリリース管理の適切さと劣悪さを示します。このパターンを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりします。 リリース管理用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### 環境戦略 Salesforce には、アプリケーション開発およびテストサイクルで使用するさまざまな[環境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)が用意されています。Salesforce の効果的な環境戦略では、環境の使用方法と適切な管理について理解する必要があります。ALM では、開発環境またはテスト環境がどの程度役立つかは、本番環境に対する忠実度と本番環境からの分離によって異なります。 優れた環境戦略には、いくつかの利点があります。 - 本番環境に対する忠実度の向上 - 迅速な環境設定と破棄 - 開発とテストの俊敏性の向上 - パイプライン全体のセキュリティの向上 - デリバリフェーズ全体での騒音と競合の低減 - 開発チームの満足度の向上 多くの場合、チームはこれらの利点の実現に苦労します。開発環境と戦略を最大限に活用するには、いくつかの問題の原因が考えられます。原因の 1 つとして考えられるのは、チームが従う開発モデルの種別です。 以前の組織ベースの開発アプローチでは、各環境が複数の機能を果たす必要がありました。チームがさまざまな種類の作業を行う場所であるだけでなく、リリースアーティファクト (つまり、リリースでリリースするメタデータ) のソースである必要がありました。環境は設定や解体が容易でなかったため、過密状態が多く、チーム間のメタデータの競合も多く、ALM 全体の速度や柔軟性にはあまり意味がありません。 ソースベースの開発モデルを使用すると、環境とリリースおよびリリースアーティファクトの関係が根本的に変わります。このモデルでは、ソース制御はリリースするメタデータのソースです。環境は、チームが作業を実行する場所です。 ただし、ソースベースの開発モデルに従うだけでは、優れた環境戦略が保証されません。ソース管理を使用しても、チームは外部システムとのインテグレーションや、管理パッケージや[データ](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)に依存するカスタマイズなど、ソース管理下にないメタデータに依存する構成をテストする条件を設定するのに苦労する可能性があります。特定の状況では、ソースベースのモデルの課題は、組織ベースのモデルに典型的な課題と似ています。 効果的な環境戦略を作成する - **ソース駆動型開発およびリリース モデルを採用できます。**[組織ベースの開発](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)モデルの使用を中止します。「[リリース管理](/docs/architect/ja-jp/well-architected/guide/resilient#リリース管理)」を参照)。リリースする環境とリリースの環境を切り離して、健全な環境戦略と健全なリリースを作成する必要があります。 - **各環境でサポートされる作業の種別を理解します。**Salesforce でサポートされる環境種別には、さまざまな機能と制限があります。環境戦略を設計するときに、環境で何ができるか、何ができないかを検討します。チームは、必要な機能を備えた環境で作業を実行します。指針については、Salesforce 開発環境とその機能の概要を参照してください。
スクラッチ組織 Developer Sandbox Developer Pro Sandbox Partial Copy Sandbox Full Sandbox
サポート組織シェイプ はい いいえ いいえ 不可 不可
ソース追跡のサポート はい はい はい 不可 不可
寿命 1 ～ 30 日 手動制御 手動制御 手動制御 手動制御
更新間隔 使用不可 1 日 1 日 5 日 29 日
リリースプレビューのサポート 開発者による制御 Sandbox インスタンスに基づく Sandbox インスタンスに基づく Sandbox インスタンスに基づく Sandbox インスタンスに基づく
プロビジョニング時間 > 5 分 時間または日 時間または日 時間または日 時間または日
Metadata Determined By ソース管理 本番 本番 本番 本番
Data Determined By 手動データ読み込み 手動データ読み込み 手動データ読み込み Sandbox テンプレート 本番
データ制限 200 MB 200 MB 1 GB 5 GB 本番と同じ
次の表を参照して、いくつかの一般的な開発タスクで使用する機能と環境を確認してください。
ToDo 組織シェイプ ソース追跡 頻繁な更新 リリースプレビューのサポート 本番のすべてのメタデータ 本番の部分メタデータ 本番からの大規模なデータセット 本番の部分的なデータセット 互換性のある環境
プロトタイピング X X X X X X X スクラッチ組織、開発者および開発者向け Pro Sandbox
新機能の調査または概念実証開発 X X X X X X X スクラッチ組織、開発者および開発者向け Pro Sandbox
ユーザー受け入れテスト X X X X X X Developer Sandbox、Developer Pro Sandbox、Partial Copy Sandbox
パフォーマンスと拡張性のテスト X X X Full Sandbox
ユーザートレーニング X X X X X* X Developer Pro、Partial Copy、*Full Sandbox
*特定の種類の作業を完了する必要がある場合は、リソース負荷の低い環境を使用します。
さらに、Einstein データ ライブラリ、Knowledge 記事、非構造化データなどの機能を使用する Agentforce エージェントの場合、Data 360 Sandbox がない限り、包括的なテストが制限されます。また、正確なテスト条件を確保するには、Data 360 Sandbox も必要です。 - **環境をリリースアーティファクトから分離します。**[組織ベースの開発](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)は使用しないでください。環境を、一定の時間作業が行われる場所として扱います。環境内のメタデータの状態は、リリースアーティファクトから分離されていると考えてください。コードまたは設定が環境で「把握」された場合、ソース管理にコミットしてリリースアーティファクトにします。 - 環境は儚いものです。プロセスをできるだけ早く作成および破棄できるようにプロセスを作成します。 - 人工物は持ちこたえるソース制御に属します。 - **環境をリリースパスから切り離す。**特定の環境に変更をリリースする必要がある必須リリースパスは、よく見られます。多くの場合、このアプローチは、アプリケーションの成熟度やリリースの安定性を検証するためのプロキシを確立するために実装されます。また、チームはこの機能を使用して、複雑なテストインフラストラクチャを設定する必要がある環境の数を最小限に抑えることもできます。ソースベースのパラダイムでは、変更を検証およびテストする方法と場所をより柔軟に設定できます。 - リリースフェーズは、環境ではなくリリースアーティファクトに適用されます。特定のリリースフェーズのすべての変更を「収集」するためだけに環境を作成しないでください。ソース制御 (特に分岐) の目的は、これです。ソース制御の分岐戦略を使用して、どの変更をどの環境にリリースするかを整理します。必要な作業に応じて、リリースのすべてのメタデータを環境にリリースする必要があります。分岐により、これが可能になります。一部の例外を除き、すべての開発環境は、関連する作業が終了した直後に更新または破棄する必要があります。特定の環境内で発生した (保持する) メタデータへの変更は、必ずソース制御に同期してください。 - 環境は、本番環境への忠実度によってのみ役立ちます。環境設定ワークフローまたは自動化を最適化して、環境をできるだけ早く解体または更新できるようにします。ALM プロセスの全体的な回復力に対する重大なリスクとして、より迅速かつ頻繁に環境を更新することを妨げる設定を検討します。関連する修復作業がある場合は、計画に追加して優先度を付けます。システムでより疎結合の[モジュラーユニット](/docs/architect/ja-jp/well-architected/guide/composable)を採用する方法を確認します。これにより、チームはスクラッチ組織でより多くの種類の開発を実行でき、Sandbox の割り当てを他の作業に割り当てることができます。スクラッチ組織で提供される機能は、ライセンスを購入していない、または有効にしていないなど、本番組織にない機能をテストするためのものです。 - ビジネスユーザーまたはエンドユーザーがアクセスできる環境では、ユーザーは重要な作業に集中できます。多くの異なるエンドユーザーやビジネス関係者が ALM 関連の作業を行おうとする、汎用的で差別化されていない環境は避けてください。特定の関係者を特定の環境に招待して有効化し、特定の作業を行います。Partial Copy Sandbox でサポートできないほど大量のデータがある環境にエンドユーザーやビジネスの関係者を置くプロセスを慎重に評価します。作業に必要なデータ量であることを確認します。ユーザー受け入れテストと初期段階の開発サイクルをできるだけ密接に連携するように計画します。すべてのテストフェーズを最適化して、開発チームとエンドユーザーのフィードバックと反復サイクルを早期化します。「[テスト戦略](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)」を参照してください。 - **変更**種別ごとに異なるリリースパスを作成します。すべての変更で同じ種別の ALM 作業を同じ順序で完了する必要があるわけではありません。システムのバックエンドコンポーネントの軽微な変更についてエンドユーザーに受け入れテストを実行させることは、時間の無駄遣いになる可能性があります。ただし、モバイルアプリケーションの開発の初期段階では、ユーザー受け入れテストと拡張性テストは非常に有益です。高リスク、中リスク、低リスクなど、さまざまなカテゴリの変更のリリースパスを特定します。 - **高リスク:**変更は、顧客、パートナー、またはすべての内部ユーザーに影響します。変更は、セキュリティまたはインテグレーションに影響します。変更により、複雑な新機能が追加されます。 - **中リスク:**変更の影響は、内部ユーザーの定義済みしきい値を超えます。変更は、データモデル、データ操作を実行する自動化、インテグレーションに影響します。 - **低リスク:**内部ユーザーの定義されたしきい値よりも少ない数に直接影響します。セキュリティの変更、データ操作やインテグレーションを伴うデータモデルや自動化は含まれません。 - **過密な環境は許可しないでください。**作業の優先順位付け、範囲設定、順序付けの規律が欠けていると、必然的に開発環境に過負荷が発生し、作業量が多すぎたり、多すぎたり、多すぎたり、異なっていたりします。過密な環境では、開発チーム間のストレス、あいまいさ、対立が生じます。また、開発パイプライン内にノイズが発生し、品質管理活動が妨げられます。このような悪影響に加えて、開発環境の過密は環境のメンテナンスとセキュリティにとって深刻な脅威です。ALM プロセスの潜在的な問題の兆候として過密を考慮します。根本原因の問題を調査して対処します。それでも過密が解消されない場合は、[Sandbox を追加](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5)できます。 [ALM のパターン](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)とアンチパターンのリストには、Salesforce 組織での適切な環境管理と不適切な環境管理が示されます。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。 環境管理用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### シグナリング戦略 シグナリング戦略では、システム全体の機能低下に連鎖する前に障害を検出、診断、修正するために必要な重要なシグナルとアプリケーション計測を定義します。効果的な計装により、アプリケーションは、障害の受動的な被害者から、問題を検出し、その動作を調整し、必要に応じて正常な機能低下を調整できる独自の回復力でアクティブな関係者に変換されます。 アプリケーションが包括的な計装を実装すると、ストレス下での自己規制、オペレーターへの健康状態の伝達、調整された回復活動への参加が可能になります。これらの機能により、個々のコンポーネントに問題が発生しても、システムはサービス品質を維持できます。一方、適切な計装が行われなければ、アプリケーションはブラックボックスとなり、破滅的な症状が現れるまで黙って失敗します。チームはユーザーから問題の報告を受けて初めて対応し、トラブルシューティングは観察ではなく考古学の課題になります。 - **アプリケーション内のエラー**を検出します。高負荷時に発生する一般的な障害パターンを検出して対応するように、アプリケーション自身が計測する必要があります。キューの飽和度を考慮します。メッセージキューが処理できるよりも早くいっぱいになると、インストルメンテーションされていないアプリケーションは、メモリを使い果たすかタイムアウトのカスケードが発生するまで作業を受け入れ続けます。適切に計測されたアプリケーションは、キューの深さ、却下率、処理遅延を監視し、しきい値を超えた場合に防御的な応答をトリガーします。 - **アプリケーション外からのシグナルを効果的に処理**:オペレーティングシステムからの信号の処理は、もう 1 つの重要な計装ポイントを表します。グレースフルシャットダウンを有効にするには、アプリケーションが終了シグナル (SIGTERM、SIGINT) のハンドラーを登録する必要があります。シャットダウン中、適切に計測されたアプリケーションは新しい作業の受け入れを停止し、進行中の要求の完了、バッファのフラッシュ、接続のクリーンアップ、サービス検出からの登録解除を許可します。このオーケストレーションされたシャットダウンにより、データの損失が防止され、ロードバランサーは中断することなくトラフィックをリダイレクトできます。 - **複雑な障害シナリオに対応する手段:**これらの基本パターン以外にも、アプリケーションではより微妙な障害モードを測定する必要があります。コンポーネントが一部の観測者には正常で、別の観測者には異常がないように見えるグレーの障害を特定するには、内部信号と外部信号の両方を関連付ける必要があります。アプリケーションは、データベース接続プールを計測して正常性チェックを報告し、同時に徐々に低下していくトランザクション完了率を追跡できます。効果的な計装戦略では、複数の観測点を重ねます。 - **ビジネス評価指標**では、注文完了率や検索結果の品質など、アプリケーション固有の成功指標を追跡します。 - **システム評価指標**は、リソース使用率、遅延の分布、およびエラー率を監視します。 - **合成プローブは**クリティカル パスを継続的に実行し、ユーザーがパフォーマンス低下に遭遇する前に検出します。 - **分散トレーシング**では、サービスの境界を越えて要求レベルの表示が提供されます。 これらのシグナルは、自動化されたシステムと人間のオペレーターの両方がアプリケーションの健全性を評価できる標準化されたインターフェースを介して公開されます。計装自体がアプリケーションのレジリエンス戦略の一部となり、エラー率に基づいてサーキット ブレーカーを停止し、オートスケーラーでキューの深さに対応し、[オペレータはインシデント](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)中に情報に基づいた意思決定を行うことができます。 [ALM のパターンと](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)アンチパターンは、Salesforce 組織での適切なシグナリング戦略と不適切なシグナリング戦略を示します。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。 シグナリング戦略用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### テスト戦略 テスト戦略は、ALM プロセス中のアプリケーションの成功と失敗を測定するテストを計画および実行する方法に関する一連の指針と標準です。テスト戦略では、テストに関与するすべての関係者が、特定のテストの優先度、目的、範囲について常に把握し、その範囲に合わせて調整します。また、プロジェクトチームは効果的で周到なテスト計画を作成できます。 通常、開発者または品質保証とテストの専門家が特定のテストの作成と実行に関与します。テスト戦略は、特定のプロジェクトでどのような種類のテストを実行する必要があり、どのような順序でテストを実行する必要があるかをこれらの個人が把握するのに役立ちます。また、テスト戦略は、チームが適切な形式のテスト、テスト計画、アーティファクト (テストデータセット、デバイス、トラフィックまたはネットワークシミュレーターなど) を作成するために必要なものを確保できるようにするのに役立ちます。 効果的なテスト戦略では、単体テスト、UI テスト、回帰テストなど、さまざまなテスト種別をさまざまな組み合わせや条件でどのように、いつ、どこで、なぜ実行するかを明確に把握し、システムと進行中の変更の動作を明らかにします。効果的なテスト戦略では、1 つの種類のテストでは測定が困難な、拡張性、信頼性、使いやすさなどの非機能要件にシステムがどの程度適合しているかを示すテストが生成されます。 Salesforce の効果的なテスト戦略を作成する - **テストは反復的かつ頻繁に、可能な限り自動化された方法で実行します。**チームがさまざまなワークロードに対してさまざまなテスト種別を実行できるようにするテスト自動化を設計および実装します。変更がソース制御に反映されるときにさまざまなテスト実行が自動的に実行されるように調整します。このアプローチにより、チームは早い段階で回帰を事前に特定して対処できます。可能な場合は、この取り組みに継続的インテグレーション/継続的デリバリ (CI/CD) を使用します。それ以外の場合は、チームがセルフサービス方式でテストの順序を早期に頻繁に実行できるように、明確なテスト計画を作成します。Agentforce エージェントのテストでは、さまざまな入力が含まれる AI エージェントの厳格なバッチ テストをテスト センターに依頼し、さまざまなシナリオで適切に機能することを確認します。 - すべての変更ですべての種類のテストが必要なわけではありません**。**効果的なリリースパイプラインが高リスク、中リスク、低リスクのアプリケーションに対応するのと同じように、効果的なテスト戦略も対応します。さまざまな種類のリスク、使用事例、または複雑さがあるアプリケーションに適したテスト体制を選択して従う方法をチームに明確に示します。「[環境戦略](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略)」を参照してください。 - **さまざまな環境種別で実行できるテストを定義します。**正確なテストでは本番環境への忠実度が重要な要素ですが、テストの種類によって意味が異なります。たとえば、回帰テストでは、メタデータとある程度のデータに関して本番環境に対して忠実である必要があります。特定のテストセットで本番に対してどのような忠実度が必要かを定義し、さまざまなテストに適した条件をサポートできる環境の種類を明確に分類します。各環境種別に適した作業種別の概要については、「[環境戦略](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略)」を参照してください。 - **耐久性、ストレス、パフォーマンス、拡張性のテストを使用して、アプリケーションの成熟度を継続的に測定します。**これらのテストは、本番レベルのニーズに対するアプリケーションのリリース準備状況を示します。主要な新機能の場合、アプリケーション開発サイクルでこれらのテストをいくつかの間隔で実行します。これらのテストを、進行中の ToDo の一部ではなく、1 つのフェーズまたは開発フェーズの一部のみとみなすのはアンチパターンです。チームがアプリケーションのパフォーマンスに関するフィードバックを早期に頻繁に取得することが最も役立ち、本番レベルの準備状況からどの程度アプリケーションに近いか遠いかをより深く理解できます。変更が本番に移行する前に問題をより適切に特定して対処する機能は、より高度なテストを頻繁に実行することで複雑さを増す価値があります。 - **重要なテスト**。拡張性テストやパフォーマンステストを実施する時間はおそらく固定されており、システムのあらゆる側面をテストすることは現実的ではありません。すべての機能が均等に使用されるわけではなく、すべての拡張性のボトルネックがビジネスに均等に影響するわけではありません。スケールテストは、システムで最も使用頻度が高く、価値の高い部分に焦点を絞ります。組織の拡張性とパフォーマンスを確認および改善するための最も重要な機会を定義して理解します。 - **「十分」がどのようなものかを知る。**拡張性テストとパフォーマンステストの成功条件を定義することが重要です。自分と開発チームがテストベンチマークとして成功条件を使用していることを確認します。また、開発チームが構築する機能要件も伝えます。通常、これらの条件には、合意した値未満の応答時間で特定の数の同時ユーザーをサポートすることと、[サービスレベル目標(SLO)](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)が含まれます。主要な目標条件を定義し、条件が満たされていることを確認する拡張性とパフォーマンスのテストを設計します。 - **適切な環境があることを確認します。**拡張性とパフォーマンスのテストでは、特に本番環境への忠実度が求められます。本番以外の環境でのデータセット、要求のデモグラフィック、要求率、作業負荷の特性はすべて、本番で表示される内容とできる限り一致する必要があります。スケール テストでは、Full Sandbox を使用する必要があります。組織にスケール テスト用の Full Sandbox がない場合、適切なスケール テストを実行できません。 - **テスト ワークロードが機能以外の要件の測定に役立つことを確認します。**次の点を考慮してください。 - **テストデータ** \- 本番から分離されたデータに対してあらゆる種類のテストを実行する必要があります。Apex 単体テストでは、[データファクトリパターンを](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm)実装して、環境データから分離された独自のテストデータをコードで生成します。また、さまざまな形式でテストデータセットを作成して管理し、データ読み込み動作をテストしたり、開発環境に UI ベースのテスト用のデータを入力したり、インテグレーションテストを支援したりできます。すべてのテストデータは、外部化されたデータセットとして管理されるか、データファクトリコードによってオンデマンドで作成されるかに関係なく、機密データおよび識別可能なデータで整理する必要があります。否定的な単体テスト動作と境界単体テスト動作をサポートするには、破損したデータ、不完全なデータ、および不正な形式のデータを含める必要があります。 - **模擬サービスおよびスタブサービス** \- インテグレーションテストでは、模擬サービスとスタブサービスを使用して API 応答をシミュレーションできます。Apex では、Apex テストで使用するモック フレームワークを作成するための [Stub API](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) がサポートされています。Apex テストで使用できるモックフレームワークを作成するためのモック。モックとスタブは、複雑なデータファクトリや外部のテストデータセットへの依存度を下げて、システムのデータ処理動作を検証するのに役立ちます。本番のようなトラフィックやデータ量が関連しないテストでは、モックやスタブの方が適している場合があります。 - **デバイスと支援技術** - [魅力的な](/docs/architect/ja-jp/well-architected/guide/engaging)アプリケーションと[アクセス](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)可能なアプリケーションを構築するうえで重要なのは、さまざまなデバイスとさまざまな種類の支援技術でユーザーの期待に応えられるようにすることです。有意義なユーザビリティテストを効果的に実施するには、より多くの投資とさまざまな種類の専門知識が必要になる可能性がありますが、リリース時にユーザー向けアプリケーションがどの程度適切に設計されているかを把握する上で、これは不可欠な要素です。 - **シミュレーター** \- 本番同様の大量のユーザー要求、API トラフィック、またはネットワーク速度の変動を複製する必要がある場合、これらの条件をシミュレートするツールが必要になることがあります。すべてのテストにこのレベルの投資が必要なわけではありません。多くの場合、これらのツールは拡張性とパフォーマンスのテストで最も役立ちます。 - **AI およびエージェント テスト** \- テストの主な目標は、AI の幻覚を減らすことです。AI の幻覚は、捏造された誤った回答です。AI の使用事例をテストして、顧客に対する理解が不完全であること、データが欠落していること、メタデータが不完全な項目があること、データが古いことに起因する一般的な問題を明らかにします。テストセンターを使用して、このようなテストに必要なテストデータの作成を支援します。 ### ALM パターンとアンチパターン 次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。 ✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-application-lifecycle-management)で ALM のその他のパターンを検出します。
パターン アンチパターン
リリース管理 本番：
- メタデータは、次のような安定したリリースメカニズムを使用していることを示します。
-- ロック解除済みパッケージに整理されるメタデータ
-- DevOpsセンターが有効でインストール中
-- ソース形式を使用したメタデータ API を介したリリース
- リリースログには、使用可能な履歴内の失敗したリリースは表示されません。
-リリース履歴には、リリース期間内の明確なリリースケイデンスおよび非常に均一なリリースクラスターが表示されます。		 本番：
- メタデータは、次のような組織ベースのリリースメカニズムを使用していることを示します。
-- 変更セットの積極的な使用
-- メタデータ API を使用したリリースでは package.xml 形式を使用します。
- リリースログには、使用可能な履歴内の失敗したリリースの繰り返しが表示されます。
- リリースに識別可能なケイデンスがないか、リリースのクラスターが不規則である (ホットフィックスとアドホックロールバックの兆候)。
DevOps センターが有効になっておらず、インストールされていません。
ロードマップとドキュメント:
リリース名は明確です。
- 機能が特定の指定リリースに明確に関連付けられている。
- リリース名は検索および検出可能です。
-チームは、アーティファクト、開発項目、その他の作業に正しいリリース名でタグ付けするための明確なガイドラインを見つけて従うことができます。
- リリース名別にリリースマニフェストの明確なビューをまとめることができます。
- 生成 AI アプリケーションの品質しきい値は、さまざまな開発フェーズで定義されます。		 ロードマップとドキュメント:
- リリース名は含まれません。
-機能が特定のリリースに明確に関連付けられていない。
- リリース名がその場限りで使用されているか、存在しない。
- チームは、アーティファクト、開発項目、その他の作業を異なる方法で参照します。
- リリース名を使用して、リリースマニフェストの明確なビューをまとめることはできません。
- 生成 AI アプリケーションの品質しきい値が定義されていないか、定義されているとしても、さまざまな開発フェーズで定義されていない。
環境戦略 組織内:
- ソース駆動型の開発およびリリースモデルを採用している。
- Developer Sandbox および Developer Pro Sandbox でソース追跡が有効になっている。
特定の環境のメタデータはリリースアーティファクトから独立しています。
- 環境はリリースパスに直接対応していません。
- 変更のリリースパスは、変更の種別 (高リスク、中リスク、低リスク) によって異なります。
-過密環境は存在しない。
- リスクの高い設定変更が本番で直接行われることはありません。
- ピーク営業時間中にリリースは発生しません。
- Data 360 Sandboxを使用して、Einsteinデータ ライブラリ、Knowledge記事、非構造化データを必要とするエージェントの使用事例を適切にテストする 		組織内:
組織ベースの開発およびリリースモデルを採用している。
- Developer Sandbox および Developer Pro Sandbox でソース追跡が有効になっていない。
特定の環境のメタデータはリリースアーティファクトです。
- 環境はリリースパスに直接対応します。
- 変更の種別に関係なく、すべての変更のリリースパスは同じです。
- 過密環境が存在する。 - リスクの高い設定変更が本番で直接行われている。
- リリースは営業時間のピーク時に行われます。
- Einsteinデータ ライブラリ、Knowledge記事、非構造化データを必要とするAgentforceエージェントは、Data 360 Sandboxを使用してテストされません。
シグナリング戦略 組織内:
- チームは、状態チェック API と SLO の定義と標準化に関して協力します。
- シグナリング戦略の定期的なレビューと調整は、事後および運用準備状況レビューの一環です。
本番：
- すべてのアプリケーションに状態チェックが実装されています。
- アプリケーションは、負荷や機能などの状態に関する明示的なシグナルを提供します。
- アプリケーションは、連動関係が正常でない場合に正常に機能しないように設計されています。
- 負荷制限は、カスケード障害を防ぐために使用されます。
設計の場合:
バックプレッシャおよび負荷制限メカニズムにより、トラフィックによってサービスが過負荷になることを回避します。
- 連動関係は最終的に失敗すると想定されます。シグナルハンドラーは、失敗を改善するために構築されています。		 組織内:
- チームがサイロで業務を行っているため、一貫性と互換性のない健康シグナリングメカニズムが構築されている。
- シグナル戦略は後付けであり、インシデントが発生したときにのみ対処されます。
本番：
- コンポーネントが正常性ステータスを通知せずに警告なしで失敗する。
- アプリケーションは、正常なサービスへの要求を無期限に再試行します。
- すべての要求は、重要度に関係なく同じ優先度で処理されます。
- 問題を特定するために、オペレータはユーザーからの苦情や重要なシステム障害などの事後対応型対策のみを使用します。
設計の場合:
- すべての連動関係が常に使用可能であることを前提としており、ネットワークパーティション、遅延の急増、その他の一般的な問題は考慮されていません。
- アプリケーションが過負荷の場合でもすべての受信要求を受け入れるため、遅延や障害の可能性が高まる
テスト戦略 ビジネス:
- ユーザビリティテストでは、さまざまなデバイスと支援技術が使用されます。
- シミュレーターを使用して、拡張性とパフォーマンスのテストで本番同様の条件を再現します。
- 変更がソース制御に反映されると、テストが自動化されて実行されます。
- アプリケーション開発サイクルで耐久テスト、ストレステスト、パフォーマンステスト、スケールテストがいくつかの間隔で実行され、進行中のタスクとみなされます。
- B2C スケールのアプリケーション、大量のユーザー、大量のデータがある場合、QA プロセスの一部としてスケールテストを含めます。
スケールテストは、システムの優先度の高い側面に焦点を絞っています。
スケールテストには明確な条件があります。
- Full Sandbox でスケールテストを実施します。
- プロンプトエンジニアリングには人間による品質レビューが含まれます。
Agentforce テストセンターは、堅牢なエージェントテストに使用されます。		 ビジネス:
- ユーザビリティテストは実施されないか、実施されるとしても、一部のデバイスで実施されます。
- 本番同様のユーザー要求量、API トラフィック、ネットワーク速度の変動はテストされません。
テストの自動化が行われていない。
- 耐久、ストレス、パフォーマンス、スケールテストは、開発のフェーズまたはフェーズとみなされます。
- QA プロセスの一環としてスケールテストを実施しておらず、B2C スケールのアプリケーション、大量のユーザー、大量のデータがある。
-スケールテストに優先順位が付けられていない。
スケールテストに明確な条件がない。
Partial Copy SandboxまたはDeveloper Sandboxでスケール テストを実施します。
- プロンプトエンジニアリングには人間による品質レビューは含まれません。
- Agentforce エージェントはテストされません。テストされている場合は、Agent Builder を使用してアドホックでのみテストされます。
組織内：
- すべてのテストデータは、機密データと識別データで整理されます。		 組織内：
- テストデータは本番データと同一です。
Apex:
- データファクトリパターンが単体テストに使用される
- モックとスタブを使用して API 応答をシミュレーションします。		 Apex:
- 単体テストは組織データに依存します。
- モックとスタブは使用されません。
設計標準およびドキュメント:
- 環境は、サポート可能なテストの種類によって分類されます。
リスク、使用事例、複雑さに応じて適切なテスト体制が指定されます。		 設計標準およびドキュメント:
各環境でサポートされるテストの種類が明確でない。
- テスト計画は、リスク、使用事例、複雑さで分類されません。
## インシデント対応 セキュリティおよびサイトの信頼性エンジニアリング (SRE) では、インシデント対応は、システム全体の可用性やセキュリティに影響するイベントをチームが特定して対処する方法、および根本原因に対処して将来の問題を防止する方法に焦点が当てられます。インシデント対応には、問題の発生後およびリアルタイムで問題に対処するために必要なプロセス、ツール、および組織行動が含まれます。 アーキテクトは、稼働開始後にソリューションの運用を日常的に監視する立場にはなりません。レジリエンスのための設計の一環として、サポートチームが第 1 レベルの診断を実行し、システムを安定させて、調査と根本原因の軽減を開発またはメンテナンスチームに効果的に渡すことができる復旧機能を設計します。ユーザーを日常的に直接サポートするチームは、システムのアーキテクチャに対する深い理解や専門知識を持っていない可能性があります。これらのチームには、日常業務を監視し、潜在的なインシデントを診断するときにシステムから情報にアクセスし、可用性に影響する問題の効果的な初期対応者となるために必要なツールとプロセスが不可欠です。 [リカバリ時間](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)、[優先順位付け](/docs/architect/ja-jp/well-architected/guide/resilient#優先順位を付ける機能)、[監視とアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)に重点を置くことで、Salesforce ソリューションのインシデントに対するチームの対応を改善できます。 ### Time to Recover (リカバリ時間) インシデントが発生した場合、最優先事項はシステムを安定した稼働状態に復元することです。多くの場合、企業はインシデントから回復する唯一の方法は「問題を解決する」ことだと考えています。この前提は、正確な根本原因の分析と修復が、システム内の重要な問題を最終的に解決する方法であるという点で公平です。しかし、危機対応の初期段階での「問題解決」は、最も現実的なアプローチではありません。インシデントの重大度によっては、その 1 秒やその影響が収益や評価の低下につながる可能性があります。 多くの場合、根本原因を診断して対処しようとすると、システムを稼働状態に戻す作業が遅延します。論理的には、インシデント対応者に根本原因の対処を依頼するアプローチを採用すると、専門分野のエキスパート (SME) とサポートスタッフに大きな負担がかかります。インシデント*中*に根本原因を見つけて修正するには、SME がインシデントごとに待機する必要があるため、顧客対応の第一線のサポートスタッフが対応できない可能性があります。また、チームが変更をリリースし、その結果、インシデントがさらに発生する可能性もあります。最終的に、このようなアプローチではコストが増加し、チーム全体の帯域幅が消費され、危機発生時に顧客の Trust とブランドの評判が損なわれる可能性があります。 適切なインシデント管理パラダイムは、最初のステップとして復旧に優先順位を付けて集中することです。システムが安定した状態に復元されたら、責任のない事後調査、インシデント調査、根本原因の修復、および同様の活動をフォローアップできます。この業務順序により、インシデント対応スタッフは、必要に応じてのみ支援するように関連 SME にアラートを送信することで、復旧戦略の優先順位付け、診断、実行をより適切に行うことができます。また、SME はインシデントの根本原因を特定して修正できます。 インシデント対応に復旧優先の考え方を採用する - サービスレベル目標の **SLO を確立**して達成します。SLO は、パフォーマンスやアップタイムなど、システムの特定の非機能要件 (NFR) について関係者と共に策定する標準です。これらの目標は、一定期間のサービスレベルインジケーター (SLI) によって測定されます。SLO がないと、インシデント対応や複雑な問題のトラブルシューティングに関する作業の多くが無秩序で反応的になる可能性があります。たとえば、「この特定のエラーを報告した一部のユーザーに対して、このエラーを停止する」ように迅速なアクションを促すことができます。このサイクルにより、チームは根本原因分析をインシデント対応に近づけることができます。これは、事後対応的な対応が停止される可能性があるからです。SLO と SLI を確立すると、より効果的に開始できます。SLO を確立するには、次の質問について考えます。 - **今後 1~3 年間のシステムの NFR は?**たとえば、NFR には、システムでサポートする必要がある応答時間、ピーク要求レート、同時ユーザー数が含まれる場合があります。 - **顧客とそのユーザーに何を体験してもらいたいですか?**「ユーザーは Salesforce でレポートをすばやく実行できます」というこの質問への回答に基づいて SLO を設定します。 - **何を測定でき、どの期間測定する必要がありますか?**この質問への回答に基づいて SLI を作成します。前の例に一致する SLI は、「レポートの読み込みの _x_% が平均 _n_ 秒以内に行われ、30 日間にわたって測定された」とします。 - **リカバリ戦略を定義して標準化します。**変更のロールバックと回避策の実装は、システムを再び機能させ、インシデントの影響を最小限に抑えるのに役立ちます。サポートチームまたは運用チームの適切なメンバーが実行できる復旧戦略とプロトコルを文書化します。復旧戦略はインシデント種別によって異なります。次の表に、インシデント種別を復旧戦略に対応付ける一般的なフレームワークを示します。障害ポイントの特定と軽減戦略の定義についての詳細は、「[可用性」](/docs/architect/ja-jp/well-architected/guide/reliable#可用性)を参照してください。
インシデント種別 見かけのトリガー リカバリ戦略
システム停止 ログインの破損やアカウントアクセスの問題 アカウント回復ポリシー
Service unavailability (サービス利用不可) 冗長なバックアップ サービスの有効化、手動の回避策
本番環境のバグ 最近の変更 以前のバージョンのリリースのロールバックまたはリリース解除
原因不明のバグの発生 手動の回避策、重要でない機能の無効化、中小企業へのエスカレーション
- **クリア終了条件**を定義します。SLO を使用して、システムがインシデントや影響の状況に該当しないかどうかを判断します。 - **インシデント後の確認と根本原因の修復のプロセスを定義します。**サービスが復元されたら、時間をかけてインシデントを確認します。レビュー時には、*無責任な事後*対応を行います。関係者と協力して、障害や非難を個人に割り当てるのではなく、*何*が*どのよう*に起こったかに関する明確な事実を確立することに集中します。さまざまなレビュー形式を使用して、長期的な問題に対処する方法を検討します。 - *アクション後レビュー*では、インシデントへの対応に焦点が絞られます。これは、適切な対応プロセスと戦略が実施されているかどうかを評価するのに役立ちます。 - *根本原因分析*では、インシデントの根本原因に焦点を絞ります。インシデントの原因となったシステムの設計と実装のバグや問題を特定するのに役立ちます。 - 合意したリカバリプロトコルを**定期的に**練習します。復旧プロトコルを実践して、全員がインシデントを適切に処理できるようにします。Sandbox とテスト環境を使用して、チームがインシデントのシミュレーションと復旧を練習できるようにします。また、インシデント後のレビューも練習します。これらすべての実践を行うことにより、復旧をエンジニアリングとサポートの文化の一部とすることができます。 [インシデント対応パターンと](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)アンチパターンは、Salesforce ソリューションでリカバリに優先順位を付けるアーキテクチャを示します。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。 リカバリ時間に役立つ Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### 優先順位を付ける機能 テクノロジーのコンテキストでは、トリアージには問題とサポート要請にカテゴリと重要度レベルを割り当てることが含まれます。ソリューションがどんなに綿密に計画されていても、ユーザーサポートの問題や要求が発生します。これらの問題は、十分なトレーニングや変更管理の欠如、UI/UX のギャップ、予期しないエンドユーザーの動作、[監視やアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)で検出されない緊急のシステム問題などに起因します。 サポートチームと運用チームは、ユーザーサポートクエリを効率的に調査し、迅速に診断できる必要があります。問題の優先順位付けを行い、重大度の低い懸念を除外して重要なシステムインシデントをすばやく見つけることは、これらのチームの主要な能力です。優先順位付けが不十分だと、すべてのレベルのユーザーサポートが低下し、重要なインシデントが長期化し、顧客とビジネスがさらに中断するリスクが高まります。 日々の業務やサポートに関与していないかもしれませんが、アーキテクトは、Salesforce Platform で作成するソリューションでサポートチームや運用チームが効果的に問題の優先順位を付けられるようにする責任があります。 チームが Salesforce ソリューション内の問題を効果的にトリアージできるようにする - **サポートチームが有益な情報にアクセスできるようにします。** - **システムと設計パターン**を文書化します。ソリューションの[読みやすさ](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)と一貫性を確保することは、サポートスタッフがサポートを担当するシステムを理解できるようにするうえで重要です。ドキュメントでは、システムのさまざまな部分で問題やインシデントに優先順位を付ける方法に関する情報をチームが見つける方法を検討します。また、チームは影響領域に基づいて復旧戦略に関する技術情報にすばやくアクセスできるようにします。トピック分類やアクションの選択など、Agentforce の一般的な問題に関連するトラブルシューティングガイドを提供します。これにより、チームは権限や設定に関連する問題をすばやく優先順位付けできます。 - **デバッグを念頭に**置いて設計します。サポートチームと組織管理者は、さまざまな環境でユーザーの問題を正しくトリアージするために、デバッグと診断を有効にする必要があります。*デバッグに便利な*パターンの例として、システム全体の実行パスにロギングやカスタムエラーメッセージを組み込むパターンがあります。イベントログやエージェントビルダーの推論ビューなどのツールを使用して、一般的な Agentforce デバッグアプローチのサポートチームを有効にします。 - インシデントの SME と関係者を**特定します**。インシデントからの回復をサポートする必要がある関連 SME または関係者、およびインシデント後の分析に関与する必要がある関連 SME または関係者のリストを作成します。 - ハンドオフは**慎重に処理**してください。稼働開始の一環として、サポートチームまたは運用チームへの各ソリューションの引き渡しの品質を確認します。サポートスタッフが関連するシステムアーキテクチャや模擬インシデント対応訓練を受講するためのトレーニングを提供します。ログやケースノートで取得されない情報をチームが文書化する方法や、インシデント対応者が根本原因調査にどのように貢献できるか、または修正のユーザー受け入れテストをどのように実行するかなど、インシデント後の引き継ぎについて考えます。 - **相談を受けた場合は、すべてのユーザーがリカバリを最優先事項として意識してください。** - **迅速な対応。**受信したユーザーサポート要求、監視通知、アラートにすばやく対応します。 - **症状と問題を区別します。**対処する必要がある実際のシステムインシデントがあるかどうかを判断します。実際の問題のあるコンポーネントを特定します。合意された[リカバリ戦略](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)に従って、システムをインシデント状況から迅速に抜け出すことができます。 - 重要な使用事例をサポートする Agentforce エージェントの場合、実行可能で関連する回避策が用意されていて、冗長性対策としてすぐに有効にできることを確認します。たとえば、手動処理に切り替えたり、関連ドキュメントにリダイレクトして手動で確認したりできます。 [インシデント対応パターンと](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)アンチパターンは、効果的なトリアージのための設計が Salesforce ソリューションでどのように行われるかを示しています。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。 トリアージに役立つ Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### 監視とアラート *監視*と*アラート*は、サイトの信頼性エンジニアリングで広く使用されている用語です。システムの耐障害性のコンテキストでは、監視はシステムの現在の状態を継続的に評価し、アラートはシステムの状態に関する潜在的な懸念事項に関する関係者への通知を自動化します。効果的な監視とアラートは、サポートスタッフの規模と増加からシステムの規模と増加を切り離すための重要な要素です。 Salesforce には、システムの動作を監視するさまざまな組み込み機能があります。Salesforce では、アドオンまたは [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) の一部として[リアルタイムイベント監視](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm)も提供しています。どの Salesforce ソリューションでも、監視とアラート用に設計された設計には次の利点があります。 - 自動インシデント対応機能 - 適切なタイミングで適切なユーザーに関連情報を提供 - 履歴ビューとトレンド分析のための明確な情報 Salesforce ソリューション内で効果的な監視とアラートを作成する - **自動化を優先**事項にする。重要な状態の変更についてユーザーに通知することは、システムの安定性と運用を維持する上で重要ですが、理想的なアーキテクチャでは、可能な場合は問題が自動修正され、緊急で回復できない問題に関するアラートのみが送信されます。自動修正機能がなくても、自動化によってアラートとレポートがより便利になります。 - **Salesforce がすでに提供**している機能から開始します。Salesforce Platform には、ガバナ制限に関するソリューションの運用を監視するための関連ログと API が用意されています。さらに、プラットフォームはガバナ制限違反や同様の問題についてアラートを送信します。これらのログとアラートを基礎として、システムのセルフリカバリ、インシデントレポート、アラートをより完全に自動化する方法を検討します。たとえば、ログを監視し、特定の種別のイベントが記録されたときに復旧アクションを実行する自動化を実装できます。 - システム状態に対する**変更を分類**します。監視およびレポートする主要な状態の具体的で意味のあるカテゴリを作成します。これらのカテゴリは、[アプリケーションコンポーネント](/docs/architect/ja-jp/well-architected/guide/composable#状態管理)で状態を管理するために定義したカテゴリに揃えます。状態変更情報の処理方法に [API 指向](/docs/architect/ja-jp/well-architected/guide/composable#api-管理)の考え方を採用する。一貫したメッセージ形式と状態カテゴリにより、自動化、レポート、アラートが簡素化されます。 - **自動化ロジックをシステムの他の部分に合わせます。**適切な自動化[エラー処理](/docs/architect/ja-jp/well-architected/guide/automated#エラーハンドリング)を構築している場合は、状態の変更を分類して自動化で応答する方法にこれらのパターンを拡張できます。復元可能とみなされる状態の変更については、再試行動作を自動化できます。重大または致命的とみなされる状態変更の場合、ユーザーへのアラートを自動化します。 - **ノイズの発生**を回避します。ユーザーが受信するアラート (特にアクションを実行する必要がないアラート) が多すぎると、すべてのアラートを無効化または無視する傾向があります。このシナリオでは、[有益な](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ)アラートを作成する努力が台無しになります。アラートを受信するユーザー、トリガーする対象、トリガーされるタイミングの範囲を広げるために、次のことを検討してください。 - **関係者マップ**を作成します。システムが適切なアラートを適切な関係者に適切なタイミングで提供するには、まず関係者グループを特定して分類します。 - **ユーザー権限に**基づいてメッセージを転送します。応答する能力と権限を持つ受信者にのみアラートを送信します。ビジネスユーザーは、アクセス権のあるレコードの問題を修正することで修正できる問題についてのアラートを利用できます。問題により技術的な対応が必要な場合は、サポートスタッフにアラートを送信する必要があります。 - **予想される応答**を明確にします。アラートは、人の介入が必要なシナリオでのみ送信します。受信者に期待されるアクションを明確に示すようにメッセージを構造化します。関係者にアラートを送信して表示する場合、関係者からアクションを実行する必要がないときは、その旨を、関係者に送信されるメッセージのバージョンで明確にします。 - **アラートをタイムリー**かつ適切にする。発生した障害に応じて配信され、まだ修正が必要なアラート) は、潜在的な障害に関するアラートほど役に立ちません。理想的には、システムで問題が発生したときにサポートスタッフにすぐにアラートが送信され、業務に悪影響が及ぶ前に問題[を優先順位](/docs/architect/ja-jp/well-architected/guide/resilient#優先順位を付ける機能)付けできるようにしてください。 [パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)のリストは、効果的な監視とアラートを作成するための Salesforce ソリューションのアーキテクチャを示しています。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。 監視およびアラート用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### インシデントレスポンスパターンとアンチパターン 次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。 ✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-incident-response)でインシデント対応のより多くのパターンを検出します。
パターン アンチパターン
Time to Recover ビジネス:
-回復プロトコルは定期的に実行されます。
- チームは本番のどのサービスを所有し、どのサービスに責任があるかを把握できます。
-チームは問題の診断をサポートする関連ツールを理解します。		 ビジネス:
- リカバリプロトコルが存在しないか、定期的に実行されていない。
- 本番のさまざまなサービスを所有し、責任を持つチームが明確でない。
- チームには、問題の診断をサポートするツールに関するガイダンスや標準はありません。
ドキュメント:
-リカバリー戦略はインシデント種別とトリガーで定義および分類されます。
- インシデント対応の終了条件は SLO に含まれており、明確です。
インシデント中に権限を昇格させるための有効化条件と割り当てロジックが明確である。
インシデント対応権限セットと承認が明確にリストされている。
一般的な問題の特定と診断に役立つトラブルシューティングガイドが存在する。		 ドキュメント:
インシデント対応がアドホックに実行される。
-インシデント応答の終了条件が存在しない。
- 昇格した権限が割り当てられていないか、割り当てられている場合はアドホックに割り当てられています。
インシデント対応権限セットと承認がリストされていない。
組織内：
- インシデント対応用のセッションベースの権限セットが存在し、復旧時にサポートスタッフに割り当てることができます。
[Setup Audit Trail (設定変更履歴)] には、指定されたリカバリテスト担当者が、合意された時間にテスト環境にログインし、リカバリテストスクリプトに従ったことが示されます。		 組織内：
- インシデント対応用のセッションベースの権限セットが存在しないか、存在する場合、サポートスタッフに権限がありません。
- [設定変更履歴] で、指定されたリカバリテスト担当者がテスト環境にログインしていないか、リカバリテストスクリプトに従っていないことが示される
テスト計画:
- リカバリテスト用のテストスクリプトが存在し、繰り返し可能である。
・インシデントシミュレーションの環境が明確に記載されている。		 テスト計画:
-リカバリテスト用のテストスクリプトが存在しない。
インシデントシミュレーションの環境が確立されていない。
トリアージ機能 ビジネス:
- インシデントが発生する前に、複雑な問題をサポートするように警告する必要がある SME または関係者を特定します。
-配送チームとサポートチーム間の引き継ぎは稼働開始の一部です。
- 相談があれば、Salesforce アーキテクトが迅速に対応し、チームが復旧に集中できるようにします。		 ビジネス:
- 警告を受ける必要がある SME または関係者は、インシデントが発生するまで特定されません。
-配送チームとサポートチーム間の引き継ぎはリリースプロセスに含まれません。
- Salesforce アーキテクトは、インシデント対応は自分の作業範囲外であると考えています。
ドキュメント:
- 特定のソリューションで使用されているシステムおよび設計パターンをサポートスタッフが検出および参照可能。		 ドキュメント:
- 特定のソリューションで使用されているシステムおよび設計パターンをサポートスタッフがすぐに使用できない。
組織内：
-ロギングとカスタムエラーメッセージがシステム全体の実行パスに組み込まれます。		 組織の場合: - ログ記録メッセージとカスタムエラーメッセージは使用されません。
監視とアラート 組織内：
- アラートは、人の介入が必要なシナリオをユーザーに通知するためにのみ使用されます。その他の失敗は記録され、報告可能です。
-アラートは、そのアラートに応答できるユーザーに送信されます。
可能な場合は、潜在的な障害が発生する前にアラートが配信されます。		 組織内：
- アラートは、後続のアクションが必要かどうかに関係なく、何らかの障害が発生したときに送信されます。
-技術的なソリューションが必要な問題に関するアラートがビジネスユーザーに配信されます。
- アラートは、すでに発生した失敗に対してのみ配信されます。
ドキュメント:
- プロンプトチューニングアラートのエントリ条件は、直接および間接的な生成 AI フィードバック評価指標に基づいて定義されます。		 ドキュメント:
- 生成 AI アプリケーションのプロンプトチューニングアラートをトリガーするための条件が定義されていません。
## 継続性計画 ビジネスレジリエンスの鍵は、計画外のイベントによって発生した問題を通じて人とシステムが機能できるようにする方法に焦点を当てた継続性計画です。ビジネス継続性計画 (BCP) では、危機を乗り越えてプロセスを進める方法を人重視で考えます。継続性計画の技術的な側面は、BCP の災害復旧部分に含まれます。「[テクノロジー継続性](/docs/architect/ja-jp/well-architected/guide/resilient#テクノロジーの継続性)」を参照してください。 適切な継続性計画がなければ、危機やシステムの停止時に組織がどのように対処すべきかを把握できない可能性があります。効果的な継続性計画がない場合、顧客、関係者、ビジネスに壊滅的な影響を与える可能性があります。有害事象が発生した場合、重要なプロセスのメンテナンスや復旧が行われないまま経過すると、財務上の損害、評判の低下、従業員の安全、さらには規制へのコンプライアンスのリスクが高まります。 [Salesforce のビジネス](/docs/architect/ja-jp/well-architected/guide/resilient#ビジネス継続性)継続性の定義、[テクノロジーの継続](/docs/architect/ja-jp/well-architected/guide/resilient#テクノロジーの継続性)性の計画、バックアップおよび[リストア機能の構築](/docs/architect/ja-jp/well-architected/guide/resilient#バックアップおよび復元機能の構築)の 3 つの領域に集中することで、より適切な継続性計画をシステムに組み込むことができます。 ### ビジネス継続性 すでに BCP が設定されている場合があります。含まれている場合は、Salesforce が含まれていることを確認します。会社に BCP がない場合は、関係者と協力して Salesforce 組織を対象とする BCP を作成します。 Salesforce は、多くのビジネス部門の顧客データと重要なビジネスプロセスの情報源として信頼されています。そのため、BCP で Salesforce が果たす役割は、他のシステムが果たす役割とは異なる場合があります。Salesforce は、復旧のために優先度の高い多くの領域に関与する可能性があります。 Salesforce システムに関連する事業継続計画を作成する - **リカバリの優先**事項を明確にする。[インシデント対応](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)の一般的なアプローチと同様に、危機の瞬間のシステムにはリカバリが最優先される必要があります。多くのビジネスクリティカルなサービスが Salesforce で実行されます。関係者がさまざまなビジネス機能を復旧するための適切な優先度を特定できるようにする必要があります。一般的なフレームワークは次のとおりです。 - 不可欠なビジネスインフラストラクチャの安定化。 - カスタマーサービスの安定化。 - 従業員とパートナーのサービスを安定させます。 - **BCP でエコシステムを考慮**します。Salesforce は、お客様の環境で唯一のシステムではありません。Salesforce と統合するシステム、AppExchange ベンダーからインストールされたソリューション、および Salesforce のデータやプロセスに接続するその他のシステムに関する BCP のギャップを特定します。提供できるかどうかがベンダーによって異なる場合は、それらのベンダーに継続性計画について問い合わせます。機能を評価し、システムの可用性を維持する方法を計画します。 - **BCP の懸念事項をテスト戦略に統合します**。BCP のテスト計画を作成して実行します。見過ごされがちなプロセスや人に関連する BCP の領域をテストすることは特に重要です。BCP の関連項目を全体的な ALM [テスト戦略](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)に組み込みます。メンテナンススケジュールを作成してそれに従い、テストを確認して計画を最新の状態に保ちます。 [継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでの適切な継続性計画と不適切な継続性計画を示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。 ビジネス継続性を定義するための Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### テクノロジーの継続性 テクノロジーの継続性の目標は、システムのコンポーネントの問題によってビジネスに不可欠な業務が妨げられないようにすることです。Salesforce では、サービスの可用性を最高レベルに維持し、あらゆる問題に関する透明性の高い情報を提供することを優先しています。Salesforce システムのパフォーマンスと問題に関するリアルタイム情報は [Trust.salesforce.com](https://trust.salesforce.com/) で確認できます。Salesforce を基盤とするアーキテクトは、Salesforce がプラットフォーム全体で提供するサイトの信頼性、セキュリティ、およびパフォーマンス機能をソリューションで活用できます。 ただし、Salesforce ソリューションの全体的な継続性は、Salesforce が提供する組み込みサービスの範囲を超えて拡張されます。アーキテクチャの観点から見ると、Salesforce テクノロジーの継続性計画は、まず Salesforce が大企業の状況にどのように適合するかについて質問し、回答する必要があります。Salesforce と統合するシステムの種類は?外部システムは Salesforce のプロセスまたは情報にどのように依存しますか?Salesforce 組織で AppExchange ソリューションに依存しているプロセスまたは機能は何ですか?ユーザーはサードパーティ ID サービスまたは SSO を使用して Salesforce にアクセスしますか? Salesforce システムでテクノロジーの継続性を高める - **インフラストラクチャを評価します。**テクノロジーの停止や問題に対する最も一般的な修復戦略は、インシデント中にフォールバックできる冗長なサービスやシステムの構築です。Salesforce では、意図的に冗長化されたアーキテクチャを採用しています。つまり、顧客のシステムとサービスのコピーを異なる物理的な場所に保持しています。必要に応じてユーザートラフィックをデータセンター間で転送できるサイトの切り替えなど、いくつかのディザスタリカバリ技術を使用しています。意図的な冗長性を構築する必要がある可能性がある場所を特定するには、次の質問を自分に投げかけます。 - \[X] サービスのサービス中断中はどうなるでしょうか?そのサービスから別のサービスに切り替えることはできますか? - \[X] のリカバリにはどのくらい時間がかかりますか?顧客への影響は?パートナーへの影響は?内部チームへの影響は? - [バックアップ](/docs/architect/ja-jp/well-architected/guide/resilient#バックアップおよび復元機能の構築)とその頻度は?バックアップによって、ビジネスをサポートするために必要なデータが提供されるか? - ベンダーとの依存関係があるか?顧客の BCP 計画は? - **運用サポートを提供します。**運用サポートとは、チームができるだけ早く再開して稼働できるようにすることです。業務量要件の大幅な増加や、予期しない変化 (業界全体、地域全体、グローバルなど) による需要にシステムでどのように対処できるかを検討します。サイト信頼性エンジニアリング (SRE) またはサポートチームがインシデントに効果的に対応するために必要となる可能性のある追加のリソースやガラス破損時の手順を BCP が考慮していることを確認します。運用サポートについて尋ねる質問は次のとおりです。 - 停止時に、技術チームは作業を継続するために必要なツールを使用できますか?計画の検証やギャップの特定のために停止をシミュレーションしましたか? - 災害が特定の地域で発生した場合、その地域の補償プランはありますか? - お客様はグローバルですか?24 時間 365 日稼働していますか? - 障害が発生したときに適切な個人に通知する適切な[監視とアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)がありますか? - **リカバリ戦略を自動化してテストします。**問題を修正したら、問題の発生場所と修正方法を特定します。可能な場合は、修復に基づいて復旧戦略を自動化し、プロセスの問題を調整します。多くの会社は、システムの耐障害性をテストするためにサービスのサブセットのインシデントシミュレーションをスケジュールします。たとえば、システム管理者アカウントのロックアウトや侵害のシミュレーション、AppExchange プロバイダーの停止や問題のシミュレーションなどです。「[インシデント対応](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)」を参照)。テストと自動化によってサービスを迅速に復元する方法に関する質問を次に示します。 - インシデントシミュレーションのスケジュールと実行頻度は? - サービスを安定した状態に戻すのにかかる時間はわかりますか? - 安定した配送プロセスが確立されているか? - フェイルオーバーとリカバリを自動化できる場所は? インシデント後レビューから出た項目は、他の開発項目と同様に扱います。計画システムに追加して、優先度を付けて作業できるようにします。 [継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでの適切なテクノロジー継続性計画と不適切なテクノロジー継続性計画を示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。 テクノロジー継続性計画用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### バックアップおよび復元機能の構築 バックアップしたデータまたはメタデータのコピーを復元すると、組織が最新の既知の安定した状態に戻ることができます。また、重大なシステム障害やサービスの中断時にフェイルオーバーシステムを提供することもできます。データとメタデータを定期的にバックアップし、暗号化されたバックアップ済みコピーを安全な場所に保存すると、アーキテクチャの耐障害性が強化されます。 バックアップおよび復元戦略がないと、本番データとメタデータが悪意を持って破損した場合、不具合が誤って本番に取り込まれた場合、または大量のデータの読み込み中の障害で本番データが破損した場合に、クリーンなバージョンの本番データを復元できません。次のいずれかのシナリオでは、ビジネスクリティカルな本番データが破損したり、完全に失われたりする可能性があります。バックアップおよび復元テクノロジーの設定には、継続性計画に加えて、大量のデータを軽減する戦略の支援やコンプライアンス関連の保持ポリシーの遵守など、さまざまな利点があります。 Salesforce ソリューションでバックアップおよび復元戦略と確実に連携する - **始めましょう。**優れたバックアップおよび復元戦略を実現するための最初のステップは、そもそも戦略を持つことです。組織のすべてのデータとメタデータを夜間にバックアップするといった単純な作業でも、災害時に重要な情報や機能が失われないようにすることができます。 - **バックアップへのアクセスを制限します。**システム管理者のみが、データのバックアップコピーにアクセスできます。このアクセス制限により、ビジネスユーザーは、組織での表示が許可されていないバックアップコピーのレコードを表示できなくなります。 - **復元プロセスを定期的にテストします。**実装するバックアップおよび復元戦略に関係なく、Full Sandbox または Partial Copy Sandbox で復元プロセスを定期的[にテストし](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)、必要なときに正常に機能することを確認します。 - **バックアップおよびリストア戦略をデータアーカイブ戦略と一致させます。**レコードがアーカイブまたはシステムから消去されたときにバックアップまたはアーカイブで何を実行するかを決定します。「[データ量](/docs/architect/ja-jp/well-architected/guide/reliable#データ量)」を参照)。 データ量が非常に多く、次のバックアップの実行を開始するまでにフルバックアップを完了するための時間がない場合は、より詳細なバックアップ戦略が必要になる可能性があります。また、組織のデータが頻繁に変更されるため、更新が組織にとってミッションクリティカルなものである場合は、より詳細なバックアップ戦略が必要になる場合もあります。 バックアップ戦略をより詳細にする - バックアップの範囲を**特定のオブジェクト**に限定します。この戦略では、さまざまなオブジェクトから異なる間隔でレコードをバックアップします。データの一貫性を維持するために、子オブジェクトは親オブジェクトと同じ間隔でバックアップする必要があります。 - **タイム ボックスの\*\***部分バックアップ\*\*。この戦略では、フルバックアップ (すべてのデータとメタデータ) と部分バックアップ (メタデータと前回のバックアップ以降に追加または変更されたレコードのみ) を区別します。 **\*フル バックアップの実行は停止しないでください。**データ量が多いと実行時間が長くなる場合でも、完全なバックアップを排除しないでください。データ量が多い場合は、定期的で頻度の低いフルバックアップ (毎週のバックアップなど) を計画します。また、部分的なバックアップやオブジェクト固有のバックアップをより頻繁に計画します (夜間のバックアップや X 時間ごとのバックアップなど)。このアプローチにより、復元プロセスで使用する最も完全で正確なデータセットを柔軟に再構築できます。\* [継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでのバックアップおよび復元機能の適切さと劣悪さを示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。 ### Salesforce のバックアップとリカバリ Salesforce Backup and Recover (Salesforce バックアップおよびリカバリ) は、Own 買収からの Own Recover を含む統合 Salesforce ソリューションであり、重要なデータを損失や破損から保護します。安全性が高く、設定が容易で、いつでも使用できるソリューションにより、ビジネスの継続性とデータの復元性が確保され、コンプライアンスが簡素化されます。 Salesforce のバックアップとリカバリを使用して、データの損失を防止し、データインシデントから迅速に復旧し、全体的なデータ管理戦略を簡素化します。価値の高いデータおよび規制対象のデータのバックアップポリシーを作成し、数回クリックするだけでそのデータを復元できます。 #### 自動バックアップのリリース 日次自動バックアップにより、メタデータ、Sandbox、管理パッケージデータ、添付ファイルなど、重要な組織データがすべて保護されます。必要な頻度でバックアップを実行して、目標復旧時点 (RPO) の目標を達成し、導入を保護します。バックアップには常にアクセスでき、安全かつコンプライアンスに従って保存されます。継続的なデータ保護は、さらに機密性の高いデータやトランザクションデータにも対応しており、急速に変化する重要な情報をより迅速にリカバリできます。 #### データのプロアクティブな監視 メールに直接送信されるプロアクティブなアラートを使用して、異常なデータアクティビティ、データ損失、破損を検出します。統計的な異常値を特定したり、異常なデータアクティビティを通知するルールを作成したりするためのリアルタイムアラートを受信して、インシデントをこれまで以上に迅速に検出できるようにします。 #### 正確で迅速な復元 Salesforce のバックアップとリカバリでは、変更を詳細に可視化することで、影響を受けるデータをすばやく特定して復元できるため、リカバリが迅速化されます。ビジュアルグラフなどのツールでは不要な変更が強調表示され、使いやすいリカバリ機能では影響を受けるオブジェクト、項目、レコードが正確に復元されます。 #### バックアップの使用の拡張 このツールを使用すると、分析、監査、コンプライアンスのためにバックアップを使用できます。検索可能な履歴データ、過去のデータを表示するオープン検索機能、外部分析または倉庫のエクスポート機能を利用できます。これにより、Salesforce API を追加することなく、バックアップを再利用できます。 #### 統合バックアップデータ管理 バックアップとリカバリでは、すべてのバックアップ、管理、運用、コンプライアンスを 1 つのコンソールで統合できます。このコンソールでは、すべての本番組織と Sandbox のバックアップへのアクセス、管理、カスタマイズ、監視ができます。また、データ主体の要求を実行してバックアップデータのコンプライアンスを確保し、バックアップスケジュール、頻度、保持ポリシーを完全に制御してカスタマイズすることもできます。 #### Salesforce のバックアップとリカバリの主な使用事例 - **データインシデントの影響**を軽減します。Salesforce バックアップおよびリカバリでは、影響を受けるレコードをインシデント前の状態に戻すことで、サイバー攻撃や内部または外部の悪意のある活動などのデータインシデントを軽減できます。バックアップとリカバリのエクスポート機能では、ユーザーの重要なデータへの継続的なアクセスと使いやすさが保証されます。 - **永続的なデータ損失**を防止します。データ損失の主な原因は依然として人為的ミスです。バックアップとリカバリは、これらの間違いに対する正確かつ迅速なソリューションを提供します。 - **データコンプライアンスと法的要件への対応が容易になります。**Salesforce バックアップおよびリカバリでは、共有責任モデルがサポートされているため、バックアップデータの一括忘れやデータ修正のセルフサービス機能を使用できます。 バックアップおよびリストア用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。 ### 継続性計画パターンとアンチパターン 次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。 ✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-continuity-planning)で、継続性計画のためのより多くのパターンを検出します。
パターン アンチパターン
ビジネス継続性 ビジネス:
・ 「 リカバリファースト」の考え方を採用し、最優先のビジネス機能と機能をできるだけ早く影響から除外することを重視します。
- BCP テスト計画のレビューのためのメンテナンススケジュールがある。		 ビジネス:
インシデント管理には「問題を解決する」という精神が唯一のアプローチです。
- BCP テスト計画は定期的に更新されません。
ドキュメント:
- Salesforce が使用できなくなった場合にデータの処理を続行またはトリアージする手順、BCP の使用をトリガーするイベントのリスト、BCP テストの手順と間隔を含む BCP が存在します。
- BCP には、上流と下流のシステムおよび連動関係が含まれます。		 ドキュメント:
BCP が存在しないか、完了していないか、Salesforce のみが含まれている。
テスト計画:
プロセスと人に関連する BCP の領域が考慮されます。		 テスト計画:
プロセスと人に関連する BCP の領域は考慮されません。
テクノロジーの継続性 ビジネス:
-意図的な冗長性システムやフェールオーバーシステムを構築する必要があるかどうかを評価済み
- インシデント回復戦略は可能な限り自動化されています。		 ビジネス:
-意図的な冗長性やフェイルオーバシステムの必要性を評価していない
インシデント回復戦略はすべて手動です。
ドキュメント:
- BCP は、チームがインシデントに効果的に対応するために必要となる可能性のある追加のリソースやガラス破損時の処置を考慮します。		 ドキュメント:
- BCP に運用サポートのニーズが含まれていない。
バックアップと復元 ドキュメント:
- データとメタデータの両方のバックアップおよびリストア戦略が存在する。		 ドキュメント:
- バックアップおよび復元戦略が存在しないか、存在するとしても不完全であり、データのみに適用されるか、メタデータのみに適用されるかのいずれかです。
会社：
-バックアップは、承認されたユーザーのみがアクセスできる安全な場所に保存されます。
- テスト計画とテストログでは、データの復元が Full Sandbox または Partial Copy Sandbox で年に 2 回以上テストされていることが示されています。		 会社：
-バックアップは人間が判読できません。
- バックアップは、未承認のビジネスユーザーがアクセスできる場所に保存されます。
-データ復元プロセスがないか、データ復元プロセスがテストされていません。
## 耐障害性のための Salesforce ツール
ツール説明アプリケーションライフサイクル管理インシデント対応継続性計画
Apex Hammer テスト 現在および新しいリリースでの Salesforce Apex テストについて説明します。 X
ApexスタブAPI モックフレームワークを作成してテストを合理化します。 X
バックアップとリカバリ データの損失を防ぐためにバックアップを自動的に生成します。 X
Big Object プラットフォームで大量のデータを保存および管理します。 X
項目履歴管理 項目履歴を追跡および表示します。 X
Get Adoption and Security Insights for Your Organization(組織の採用およびセキュリティに関するインサイトの取得)新しいウィンドウでリンクを開く 組織での Lightning Experience の採用と使用状況を監視します。 X
データの一括読み込みジョブの管理 Bulk API を使用して、大量のレコードの更新または削除を行います。 X
リアルタイムイベントモニタリングイベントの管理 イベント監視のストリーミングおよびストレージ設定を管理します。 X
データおよびストレージリソース Salesforce 組織のストレージ制限と使用量を表示します。 X
デバッグログの監視 ログを監視し、ログをトリガーするフラグを設定します。 X
ログインフォレンジックによるログイン活動の監視 なりすましを示す可能性がある行動を特定します。 X
設定変更履歴を使用した設定変更の監視 システム管理者による最近の設定変更を追跡します。 X
トレーニング履歴の監視 (この機能は、現在日本のお客様に対してサポートしていません) ユーザーが受講した Salesforce トレーニングクラスを表示します。 X
バックグラウンドジョブの監視 組織のバックグラウンドジョブを監視します。 X
スケジュール済みジョブの監視 レポートスナップショット、スケジュール済み Apex ジョブ、ダッシュボードの更新を表示します。 X
拡張性テスト システムのパフォーマンスをテストし、結果を解釈します。 X
プロアクティブな監視 Salesforce 監視サービスを使用して中断を最小限に抑えます。 X
Salesforce Data Mask Sandbox のデータを自動的にマスキングします。 X
[システムの概要] ページ 組織の利用状況データと制限を表示します。 X
力の使用:Lightning:糸くず Salesforce CLIを使用してコードを分析および検証します。 X
## レジリエントに関連するリソース
リソース説明アプリケーションライフサイクル管理インシデント対応継続性計画
パフォーマンスと拡張性のテストにおける7つのアンチパターン パフォーマンスと拡張性のテストでは、一般的なアンチパターンは避けてください。 X
複雑なSalesforceアプリケーションでのパフォーマンスの分析とホットスポットの拡張 組織のパフォーマンスと拡張性の問題に対処するためのアプローチについて説明します。 X
災害復旧計画の作成 (Trailhead) 災害復旧計画を作成します。 X
ビジネス継続性はバックアップ/リストア以上のもの BCP を包括的に把握します。 X
設計標準テンプレート 組織の設計標準を作成します。 X
Salesforce の診断および監視ツール 実装の品質とパフォーマンスを改善する方法について説明します。 X
ビジネス継続性計画の指針 効果的な BCP の基礎となる基本原則を確認します。 X
Salesforce でのスケールテスト方法 スケールテストライフサイクルの 5 つのフェーズについて説明します。 X
パフォーマンステストの概要 パフォーマンステスト方法を開発する方法について説明します。 X
組織の監視 セルフサービス監視オプションについて説明します。 X
テスト戦略テンプレート 拡張性とパフォーマンスのテスト計画を作成してカスタマイズします。 X
テスト戦略テンプレート テスト戦略が完了していることを確認します。 X
ソース駆動開発について (Trailhead) パッケージ開発とスクラッチ組織について説明します。 X
## ご意見をお聞かせください Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。