オブザーバビリティと監視 - パターン

Well-Architected Operational Excellenceの詳細 → Observability and Monitoring (監視性と監視)

パターン

参照すべき場所外観
プラットフォーム | イベント監視✅ イベントモニタリングは、非同期処理チェーンと外部インテグレーションを介して要求をトレースする相関関係 ID を取得する初期アーキテクチャに設計されています。
プラットフォーム | イベント監視✅ オブザーバビリティインフラストラクチャは、本番インシデントで診断が不可能と判明した後に改良されるのではなく、最初のスプリントから含まれます。
プラットフォーム | インテグレーション✅ インテグレーションチェックポイントを意図的に配置して、システムの境界を越えて要求をトレースできるようにする
プラットフォーム | プラットフォームイベント✅ プラットフォームイベントのペイロードは、トランザクションマーカーとコンテキストを使用して運用を可視化できるように構造化されています。
プラットフォーム | カスタムログ✅ カスタムログフレームワークは、ユーザー ID、タイムスタンプ、期間、結果を含む完全なコンテキスト情報を使用して個別のイベントを取得します。
プラットフォーム | 評価指標✅ 総計値による経時的な数値の集計により、API消費レート、Apex CPU時間の分布、一括処理ジョブの成功率などのトレンドを明らかにします。
プラットフォーム | 分散追跡✅ トレースは、同期 API コールを非同期処理チェーンに、プラットフォームイベントを登録者の実行に、インテグレーション要求を外部システム応答に接続します。
プラットフォーム | オブザーバビリティ✅ オブザーバビリティにより、調査ごとに新しい計装をリリースすることなく、システムの動作に関する任意の質問に回答できます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | イベント監視⚠️ カスタムログなしでソリューションを起動し、6 か月後に本番インシデントがプラットフォームログのみで診断できないことが判明した場合、大幅なリファクタリングが必要
プラットフォーム | イベント監視⚠️ 運用改善作業中に、ほとんどのコンポーネントに接触して計装の変更が必要になり、バグのリスクがある既存のソリューションにオブザーバビリティが後付けされる
プラットフォーム | インテグレーション⚠️ インテグレーションの失敗は発生するが、包括的なテレメトリを使用しないとシステム境界を越えて要求パスを追跡できない
プラットフォーム | プラットフォームイベント⚠️ プラットフォームイベントのペイロードに運用コンテキストがないため、インシデント調査が複数のシステムの検索に依存している
プラットフォーム | カスタムログ⚠️ ログは不十分なコンテキストを取得するため、追加情報を収集するには調査で問題を再現する必要がある
プラットフォーム | オブザーバビリティ⚠️ 事前定義されたダッシュボードでは、本番で出現するシステムの動作に関する予期しない質問に回答できない

パターン

参照すべき場所外観
プラットフォーム | イベント監視✅ APIの使用状況、ログイン アクティビティ、Apex実行、SOQLクエリ、Visualforceページ、Lightningページ、レポート実行をキャプチャする本番環境でイベント監視が有効
プラットフォーム | イベント監視✅ イベントログファイルを一元管理されたログプラットフォームに 1 時間ごとにエクスポートし、ネイティブプラットフォームの保持を超えて履歴分析が可能
プラットフォーム | イベント監視✅ 外部ログ集計により、他のシステムのエンタープライズテレメトリとの相関関係が実現し、エンドツーエンドのトランザクション追跡が可能
プラットフォーム | イベント監視✅ イベントログファイルは、コンプライアンスレポートと長期的なトレンド分析のために一致する規制要件で保持されます。
プラットフォーム | Proactive Monitoring✅ Proactive Monitoringのしきい値は、デフォルトを受け入れるのではなく、組織固有の通常の動作範囲に基づいて意図的に調整されています。
プラットフォーム | Proactive Monitoring✅ Proactive Monitoringアラートは、ユーザーに表示されるインシデントの前に、API制限の急増、同時Apex障害、SOQL行制限アプローチ、行ロックの競合を検出します。
プラットフォーム | Proactive Monitoring✅ 調整されたしきい値により、チームがTrustし、継続的な改善の好循環を生み出すためのアクションにつながるシグナルを生成
プラットフォーム | スケールセンター✅ スケールセンターのベースラインは、ソリューションの安定化時に設定され、メジャーリリース後に毎回確認されます。
プラットフォーム | スケールセンター✅ Scale Centerにより、リソースを最も消費する操作、タイムアウトしきい値に近づいているトランザクション、最適化投資の影響が最も大きい場所がわかります。
プラットフォーム | スケールセンター✅ 最新のリリースで導入された意図しない N+1 クエリパターンを明らかにするベースラインプロンプト調査からトランザクション時間が増加
プラットフォーム | 監査履歴の設定✅ [設定変更履歴] は、権限の変更、メタデータのリリース、セキュリティ設定の更新などの設定変更を追跡し、最大 180 日間保持
プラットフォーム | 監査履歴の設定✅ コンプライアンス要件や契約上の要件により履歴期間が長くなる場合、設定変更履歴エントリは 180 日を超えて保持されるようにエクスポートされます。
プラットフォーム | Shield✅ 項目監査履歴は、機密データ、変更履歴が必要な規制対象データ、重要なビジネスデータを含む項目で選択的に有効化されます。
プラットフォーム | Shield✅ 項目監査履歴では、履歴値を理解することで業務やコンプライアンスレポートに役立つ項目が最大 10 年間保持されます。
プラットフォーム | 状態チェック✅ ヘルスチェックレビューは四半期ごとにスケジュールされ、環境のリスク優先度に基づいて調査結果が修正されます。
プラットフォーム | 状態チェック✅ 状態チェックの結果は、受動的な受け入れではなく慎重にレビューされ、補償コントロールまたは異なるリスク許容度が文書化されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | イベント監視⚠️ イベントモニタリングが有効になっているがログがエクスポートされないため、調査がネイティブ保持期間に制限され、履歴トレンド分析ができない
プラットフォーム | イベント監視⚠️ イベントログファイルはプラットフォームストレージに残り、外部集計が実装されていないため、長期的な業務量計画ができない
プラットフォーム | Proactive Monitoring⚠️ Proactive Monitoringでは、感度が高すぎるか緩すぎるデフォルトのしきい値が使用されているため、チームが無視することを学習したノイズの多いアラートが生成されます。
プラットフォーム | Proactive Monitoring⚠️ アラート ノイズにより、モニタリング システムに対するTrustが破壊され、チームが有効なシグナルに応答しなくなる
プラットフォーム | スケールセンター⚠️ Scale Centerは有効になっているが、プロアクティブにレビューされることはなく、数か月の増分低下の後にユーザーから苦情が出るまでパフォーマンスはゆっくりと低下する
プラットフォーム | スケールセンター⚠️ パフォーマンス評価指標にベースラインコンテキストがなく、3 秒のトランザクション時間が典型的なのか、改善しているのか、低下しているのかが不明
プラットフォーム | 監査履歴の設定⚠️ [設定変更履歴] はエクスポートされません。保持制限により、180 日を超えるセキュリティ調査やコンプライアンス検証ができません。
プラットフォーム | Shield⚠️ [項目監査履歴] は、すべての項目で選択的に有効化されるため、対応するコンプライアンス値のないストレージコストが作成されます。
プラットフォーム | 状態チェック⚠️ 状態チェックの結果がレビューされることはありません。セキュリティ設定は、慎重に受け入れることなくベースラインの推奨事項からずれます。

パターン

参照すべき場所外観
プラットフォーム | ユーザーフロー✅ ビジネスへの影響に基づいて重要なユーザーフローを定義し、成功率、完了時間、放棄ポイント、エラー率についてエンドツーエンドで監視
プラットフォーム | ユーザーフロー✅ 重要なフローには、収益を生み出す活動 (注文送信、契約締結、商談成立)、大規模活動 (ログイン、検索、レコード作成)、コンプライアンスが必要な活動 (同意取得、データ主体の権利履行) が含まれます。
プラットフォーム | ユーザーフロー✅ フローには、重要な各ステップの開始、完了、破棄、失敗を示すトランザクションマーカーが付けられます。
プラットフォーム | ユーザーフロー✅ 各フェーズのプラットフォーム イベント(カートの検証、在庫チェック、支払処理、履行トリガー)で計測される注文送信フロー。フェーズ別の成功率が表示されます。
プラットフォーム | ユーザーフロー✅ フローレベルの監視により、コンポーネントレベルの監視ではどのトランジションポイントでも障害が発生する可能性があるため、目に見えない問題が明らかに
プラットフォーム | ユーザーフロー✅ フローの成功率が許容しきい値を下回った場合、または期間が遅延目標を超えた場合にアラートが起動
プラットフォーム | インテグレーション✅ インテグレーション状態監視は、外部システム障害、ネットワーク問題、認証問題、レート制限アプローチをユーザー対応障害にカスケードする前に検出します。
プラットフォーム | インテグレーション✅ 重要な同期インテグレーションの成功率が 99% を下回った場合のアラートの監視
プラットフォーム | インテグレーション✅ ベースラインに存在しなかった新しいエラー種別が表示された場合のエラー分布監視アラート
プラットフォーム | インテグレーション✅ 同期ユーザー向け通話で 3 秒を超えた場合の遅延パーセント監視 (p95) アラート
プラットフォーム | インテグレーション✅ 既知のレート制限または SLA しきい値の 80% を超えた場合のスループット監視アラート
プラットフォーム | インテグレーション✅ 回路が開くと外部システムの劣化を示す回路ブレーカー状態監視アラート
プラットフォーム | インテグレーション✅ 継続的な再試行率が 5% を超えた場合の再試行率監視アラートで信頼性の問題を示す
プラットフォーム | インテグレーション✅ 一元化された監視プラットフォームへのインテグレーションテレメトリルートにより、システム境界を越えた相関関係を実現

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | ユーザーフロー⚠️ コンポーネントは独立して監視され、正常な動作を示していますが、12% のユーザーが重要なフローを破棄し、その理由がわかりません。
プラットフォーム | ユーザーフロー⚠️ コンポーネントの健全性ダッシュボードが緑色で表示されるが、ユーザーは重要なワークフローを完了できず、監視アーキテクチャの障害が露呈する
プラットフォーム | ユーザーフロー⚠️ 複数のApexクラス、フロー、プラットフォーム イベント、外部インテグレーションを使用するユーザー ジャーニーでは、エンド ツー エンドの可視性に欠ける
プラットフォーム | ユーザーフロー⚠️ 重要なビジネスジャーニーには計装がなく、成功率と放棄ポイントは不明
プラットフォーム | インテグレーション⚠️ インテグレーションの失敗は、プロアクティブではなく、ユーザー対応の失敗に連鎖した後にのみ検出されます。
プラットフォーム | インテグレーション⚠️ インテグレーションテレメトリは、境界を越えた相関関係と根本原因の分析を防ぐために個々のシステムで分離されたままです。
プラットフォーム | インテグレーション⚠️ 根本原因を早期に明らかにするのではなく、損傷を受けた後のダウンストリーム症状に関するアラートを監視する

パターン

参照すべき場所外観
プラットフォーム | SLI✅ 対応可能状況 SLI は、重要なフローが正常に実行されるまでの時間の割合をユーザーの観点から測定します (200 の状況コードだけでなく、期待される結果を受信)。
プラットフォーム | SLI✅ 遅延 SLI は、p50 (中央値)、p90 (異常値を除く 90 パーセント)、p95 (最悪異常値を除く 95 パーセント)、p99 (最悪経験を示す 99 パーセント) で操作を完了するまでの時間を測定します。
プラットフォーム | SLI✅ 遅延目標は、操作の重要度とユーザーの期待によって異なります (500 ミリ秒の検索は瞬時に実行され、入力の同じ遅延は遅く感じます)。
プラットフォーム | SLI✅ スループット SLI は、時間単位あたりの成功した業務量を測定し、業務量の稼働率と増加トレンドを明らかにします。
プラットフォーム | SLI✅ レイテンシと組み合わされたスループットにより、負荷の増加時にシステムのパフォーマンスが維持されるのか、量の増加時にパフォーマンスが低下するのかがわかります。
プラットフォーム | SLI✅ エラー率 SLI はエラー種別を区別します (検証失敗などのユーザーエラーとガバナ制限例外などのシステムエラー)
プラットフォーム | SLO✅ アーキテクチャパターンを選択する前に、ビジネス要件に基づいて許容される SLI しきい値を定義してサービスレベル目標を設定する
プラットフォーム | SLO✅ ビジネス要件「営業担当は 5 秒以内に商談の更新を確認する必要がある」が SLO を促進「商談の詳細ページの読み込みは p95 で 3 秒以内に完了」がアーキテクチャの決定を促進
プラットフォーム | SLO✅ SLOは、システムで現在達成されている内容に基づいて定義されるのではなく、ビジネス要件から生まれ、アーキテクチャ上の意思決定を促進する

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | SLI⚠️ 対応可能状況は、ユーザーの視点 (期待される結果を受け取る) ではなく技術的な観点 (200 状況コード) で測定されます。
プラットフォーム | SLI⚠️ 遅延は中央値でのみ測定され、p95 または p99 パーセントの最悪ユーザーエクスペリエンスは理解されません。
プラットフォーム | SLI⚠️ エラー率 SLI はユーザーエラーとシステムエラーを区別せず、異なるソリューションを必要とするさまざまな問題をマスキングします。
プラットフォーム | SLO⚠️ アーキテクチャが最初に構築され、次に SLO が「現在達成しているもの」として定義され、システム設計でユーザー要件が考慮されなかったために 12 秒のページ読み込みが受け入れられる
プラットフォーム | SLO⚠️ SLO はビジネス駆動型ではなくアーキテクチャ駆動型であり、ユーザーが何を必要としているかではなく、システムが何を達成するかに基づいて目標を設定する

パターン

参照すべき場所外観
プラットフォーム | アラート✅ 重要度分類により、重要なインシデント (本番が使用できない、データが破損するリスク、セキュリティ侵害) をページのオンコールエンジニアにすぐに転送
プラットフォーム | アラート✅ 重大度の高いインシデント (パフォーマンスの低下、部分的な停止) では、営業時間内に迅速に調査するための通知が生成されます。
プラットフォーム | アラート✅ 警告 (しきい値に近づいている、設定ドリフトしている) により、プロアクティブな修正のための日次ダイジェスト通知が生成されます。
プラットフォーム | アラート✅ アラートコンテキストには、影響を受けるユーザー数、エラーメッセージ、スタック追跡、最近のリリース、関連アラート、関連するダッシュボードへのリンクが含まれます。
プラットフォーム | アラート✅ 豊富なコンテキストにより、基本情報を収集することなく、重要度の評価と調査を即座に行うことで、承認までの平均時間を短縮
プラットフォーム | アラート✅ アラートのグルーピングにより、1 つの根本的な問題に対して数百件の関連アラートが発生するアラートストームを回避
プラットフォーム | アラート✅ インテグレーションの失敗により、インテグレーションエンドポイント別にグループ化された 1 つのアラートがトリガーされ、過去 5 分間に 156 件の失敗した要求がレイテンシグラフ、エラー分布、ダッシュボードリンクと共に表示されます。
プラットフォーム | アラート✅ アラートの抑制により、予想されるメンテナンス期間や自動修正期間中に既知の一時的な状況でアラートが生成されないようにします。
プラットフォーム | アラート✅ 定期メンテナンス中、キャッシュウォーム中のリリース後数分間、および再試行ロジックが成功した一時的な障害時にアラートが抑制されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | アラート⚠️ すべてのアラートは重要度分類なしで同じチャネルに転送され、重大インシデントは通常の警告と区別されません。
プラットフォーム | アラート⚠️ アラートには診断コンテキストがないため、オンコールエンジニアは重要度を評価する前に個別のクエリを使用して基本情報を収集する必要があります。
プラットフォーム | アラート⚠️ インテグレーションの失敗により、5 分間で 156 件の個別のアラートが生成されます。各アラートはタイムスタンプを除き同じです。
プラットフォーム | アラート⚠️ アラートストームにより、回答者は 1 つの根本的な問題と何百もの関連症状を区別できません。
プラットフォーム | アラート⚠️ 既知のメンテナンス時間中および監視に対するTrustを損なうノイズを発生する一時的な状況でアラートが起動
プラットフォーム | アラート⚠️ ノイズの多い偽陽性によるアラートの疲労により、チームは通知を無視し、応答の有効性が低下します。