--- schema_version: "1" id: 28753281740316ae2fb58437e7e3161167e42f22ed19996df60f8059a5f89f69 title: 信頼性 - 可用性 collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/well-architected-tools/guides/trusted-availability.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/well-architected-tools/guide/trusted-availability.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 718b0f7dbec00cedf1fa23e8db96db5ac6883743fc381046392f4bc8dd59905c products: - 適切に設計されたツール - Architect Site Content Repo --- # 信頼性 - 可用性 ### 障害の軽減パターン 適切に構築された[信頼](/docs/architect/ja-jp/well-architected/guide/trusted-overview)性 → [信頼性](/docs/architect/ja-jp/well-architected/guide/reliable) → [可用性](/docs/architect/ja-jp/well-architected/guide/reliable#可用性) → [障害の軽減](/docs/architect/ja-jp/well-architected/guide/reliable#障害の軽減) | Where to look?
商品領域 \| ロケーション | What does good look like? (良いものは?)
パターン | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | プラットフォーム \| ビジネス | ✅ 障害軽減計画は頻繁にテストされる 障害軽減計画は定期的 (1 ～ 2 年ごと) に、事後の一環として重大インシデントの後に反応的に、主要なビジネスイベントや IT イベントの前にプロアクティブにテストされます。 | | プラットフォーム \| 組織 | ✅ 緩和コントロールがすぐに導入され、経時的に成熟し、できるだけ早く自動化を組み込む | | プラットフォーム \| 組織 | ✅ 非同期プロセスが監視される 非同期プロセスは、Proactive Monitoring を使用するか、外部スケジュール済みジョブによって実行された AsyncApexJob を照会して監視されます。問題を早期に検出するためのアラートが提供され、検出時間 (TTD) とエンゲージメント時間 (TTE) が短縮されます。 | | プラットフォーム \| 組織 | ✅ トレーニングを受けたエンドユーザーのサブセットがリストビュー、レポート、ダッシュボードを作成 トレーニングを受けたエンドユーザーは、文書化されたガイドラインと定期的なレビューを含む組織全体のレポート戦略の一環としてレポート、リストビュー、ダッシュボードを作成します。 | | プラットフォーム \| 組織 | ✅ 障害点トリガーとそれに対応する緩和計画は、人、プロセス、技術で分類されます。 | ### リスク管理パターン 適切に構築された[信頼](/docs/architect/ja-jp/well-architected/guide/trusted-overview)性 → [信頼性](/docs/architect/ja-jp/well-architected/guide/reliable) → [可用性](/docs/architect/ja-jp/well-architected/guide/reliable#可用性) → [リスク管理](/docs/architect/ja-jp/well-architected/guide/reliable#リスク管理)についての詳細 | Where to look?
商品領域 \| ロケーション | What does good look like? (良いものは?)
パターン | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | プラットフォーム \| ビジネス | ✅ 確立されたリスク評価フレームワークが使用されている | | プラットフォーム \| ビジネス | ✅ リスク評価は、さまざまなステークホルダーグループによって承認されています。 | | プラットフォーム \| ビジネス | ✅ リスク評価フレームワークは、業界および会社の標準に準拠しています。ISO/IEC 27001、NIST サイバーセキュリティフレームワーク (CSF)、COBIT (情報および関連技術の統制目標)、ISO/IEC 27005、GDPR (一般データ保護規則)、OWASP (オープン Web アプリケーションセキュリティプロジェクト)、CSA Cloud 統制マトリックス (CCM)、PCI DSS (Payment Card Industry Data Security Standard)、または SOC 2 (System and Organization Controls) | | プラットフォーム \| ビジネス | ✅ 大きな変更を導入する前にリスクを評価する ビジネスや実装に大きな変化が発生する前にリスクを積極的に評価する。Signature Success のお客様は、Key Events Management を活用します。 | | プラットフォーム \| ビジネス | ✅ 季節ごとのスパイクは事前に計画されています。 ピーク利用状況イベント (トラフィックの季節的なスパイクなど) は事前に計画されています。Signature Success のお客様は、Key Events Management を活用します。 | | プラットフォーム \| ビジネス | ✅ リスク評価は頻繁にレビューされます。 リスク評価は、重大インシデントまたは危機対応コールの後、新製品、機能のロールアウト、新規ビジネスユニットのオンボーディングの前、主要なビジネスイベント (季節的な急増、重大なビジネスの変化) の前、定期的 (1 ～ 2 年ごと) に反応的にレビューされます。 | | プラットフォーム \| ビジネス | ✅ リスクは、人、プロセス、テクノロジーの領域に分類 | | プラットフォーム \| ドキュメント | ✅ 顧客への影響に基づいてリスクの重要度を分類して評価する | | プラットフォーム \| ドキュメント | ✅ リスク軽減・対応計画に優先順位を付け、優先度の高いリスクに焦点を絞る | --- ### 障害軽減対策パターン 適切に構築された[信頼](/docs/architect/ja-jp/well-architected/guide/trusted-overview)性 → [信頼性](/docs/architect/ja-jp/well-architected/guide/reliable) → [可用性](/docs/architect/ja-jp/well-architected/guide/reliable#可用性) → [障害の軽減](/docs/architect/ja-jp/well-architected/guide/reliable#障害の軽減) | Where to look?
商品領域 \| ロケーション | What to avoid?
アンチパターン | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | プラットフォーム \| ビジネス | ⚠️ 障害軽減計画は十分にテストされていない 障害軽減はテストされないか、最初の設計/構築フェーズ後にのみテストされる | | プラットフォーム \| ビジネス | ⚠️ 季節的な急増が事前に考慮されていない (トラフィックの季節的な急増など) ピーク利用状況イベントが事前に計画されていない | | プラットフォーム \| 組織 | ⚠️ 緩和ではオートメーションが使用されません | | プラットフォーム \| 組織 | ⚠️ 障害点トリガーは分類されません。軽減アプローチはアドホックまたは存在しない | | プラットフォーム \| 組織 | ⚠️ 緩和措置が再検討または進化していない | | プラットフォーム \| 組織 | ⚠️ 非同期プロセスがプロアクティブに監視されていない 非同期プロセスは、非同期プロセス自体の一部であるカスタムエラーログメカニズムに依存しているか、まったく監視されていない | | プラットフォーム \| 組織 | ⚠️ リストビュー、レポート、ダッシュボードについてはエンドユーザーが単独で責任を負います。エンドユーザーは公開レポート、リストビュー、ダッシュボードを自由に作成でき、これらのメタデータ項目の定期的なパフォーマンスレビューは存在しません。 | ### リスク管理のアンチパターン 適切に構築された[信頼](/docs/architect/ja-jp/well-architected/guide/trusted-overview)性 → [信頼性](/docs/architect/ja-jp/well-architected/guide/reliable) → [可用性](/docs/architect/ja-jp/well-architected/guide/reliable#可用性) → [リスク管理](/docs/architect/ja-jp/well-architected/guide/reliable#リスク管理)についての詳細 | Where to look?
商品領域 \| ロケーション | What to avoid?
アンチパターン | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | プラットフォーム \| ビジネス | ⚠️ リスクが明確でない | | プラットフォーム \| ビジネス | ⚠️ Salesforce のリスク評価フレームワークはアドホックである | | プラットフォーム \| ビジネス | ⚠️ リスク評価フレームワークはサイロで開発されています。リスク評価フレームワークは 1 つのチームが個別に開発しており、会社のガイドラインや業界標準に準拠していません。 | | プラットフォーム \| ビジネス | ⚠️ リスク管理は「1 回限り」の活動とみなされ、リスク評価が 1 回のみ実行されるか、リスク評価フレームワークが定期的に更新されていない | | プラットフォーム \| ドキュメント | ⚠️ リスクの重要度やカテゴリを評価するときに顧客の視点が考慮されない | | プラットフォーム \| ドキュメント | ⚠️ リスク軽減および対応計画は、考えられるすべてのリスクを把握しようとします。 | ---