synthetic-monitoring

合成監視では、スクリプト化されたテストを本番環境に対してスケジュールに沿って24時間365日実行します。障害、パフォーマンスの低下、フローの破損を、実際のユーザーから報告される前に検知できます。午前3時にトラフィックがゼロでも、アプリが正常に動作しているかを確認するのはプローブだけです。常に200を返すものの認証を行わないログインページは、単純な稼働時間チェックを通過しますが、ダッシュボードが読み込まれることを検証する合成プローブなら検知できます。このスキルでは、プローブの設計、アラート連携、SLA 検証、マルチリージョン実行、そして午前3時のページ通知を対応可能なものにするランブックの運用規律を扱います。

クイックルート

状況	移動先
プラットフォームを選ぶ（Checkly、Datadog、Grafana、CloudWatch…）	プラットフォームの選択肢
プローブを作成する（ログイン、API ヘルス、検索）	プローブ設計 → references/probe-implementations.md
プローブは実行されるのに、ユーザーから障害の報告がある	障害モード
アラートが多すぎる、または実際の障害を検知できない	アラート連携
SLA のダウンタイム予算を計算する	SLA 検証
午前3時にプローブが失敗し、オンコール担当者が対応に迷っている	references/platforms-and-ci.md のランブックテンプレート

---

ヒアリング項目

まず .agents/qa-project-context.md を確認します。存在する場合はコンテキストとして使用し、そこですでに回答されている質問は省略します。回答によって、プローブのセット、アラート設定、SLA の計算が変わります。

重要なフロー（作成するプローブを決定します）：

• 最も重要なユーザージャーニーは何ですか（ログイン、検索、購入手続き、登録、主要なワークフローなど）？これらがプローブのリストになります。
• どのフローが壊れると、直ちに収益の損失や顧客離れにつながりますか？これらは実行間隔を最短にし、オンコール担当者にページ通知します。
• 気づかれないまま失敗するフロー（データ同期、バックグラウンドジョブ、Webhook など）はありますか？サイレント障害はユーザーから報告されないため、特にプローブが必要です。
• 可用性と応答時間に関する SLA／SLO は文書化されていますか？ダウンタイム予算とアラートしきい値を決定します。

現在の監視状況（ギャップの場所を決定します）：

• 現在、何が導入されていますか（稼働時間チェック、APM、エラー追跡、ダッシュボードなど）？重複を避け、ギャップを見つけます。
• 監視対象とユーザー体験の間にギャップはありますか？プローブが役立つのはそのギャップです。
• 現在、本番環境の問題をどのように把握していますか（アラート、ユーザーからの報告、ソーシャルメディアなど）？ユーザーからの報告で把握しているなら、まず改善すべき指標は検知時間です。
• 直近の障害は何で、検知までにどれくらいかかりましたか？プローブが達成すべき検知時間の目標を設定します。

インフラストラクチャ（リージョンと CDN の検証内容を決定します）：

• アプリは複数のリージョンから配信されていますか、それとも1つのリージョンからですか？マルチリージョン配信には、マルチリージョンでのプローブが必要です。
• オリジンの障害を隠す可能性のある CDN、キャッシュ、エッジレイヤーはありますか？ある場合、プローブで x-cache／オリジンのヘッダーを検証する必要があります。
• 決済、認証、メールなどのサードパーティ依存先には、それぞれ監視がありますか？そのステータスページをランブックに反映します。
• どのアラートシステムがありますか（PagerDuty、OpsGenie、Slack、メールなど）？通知のルーティング設定を決定します。

テストアカウント（データの安全性を決定します）：

• 本番環境に、合成テスト専用のアカウントはありますか？専用アカウントがないと、プローブが実データや分析データを汚染します。
• テストアカウントを分析、課金、メールキャンペーンから除外できますか？できない場合、プローブのトラフィックによって、その後のすべての数値が偏ります。
• プログラムによるアカウント作成やデータのクリーンアップのための API アクセスはありますか？アカウントを作成してから削除するプローブが可能かどうかを決定します。

---

基本原則

1. 合成テストでユーザー体験を継続的に検証する

RUM は何が起きたかを示しますが、合成監視は、実際のユーザーがアクティブかどうかに関係なく、今何が起きているかを示します。午前3時にトラフィックがゼロでも、アプリが正常に動作しているかを確認するのは合成プローブだけです。RUM を補完するものであり、置き換えるものではありません。合成監視は既知の経路を予測可能な入力で確認し、RUM は実際のユーザーが問題を引き起こす予想外の方法を見つけます。

2. プローブはシンプルかつ高速に保ちます

2 分かけて 15 ページにアクセスするものはプローブではなく、本番環境で実行する E2E スイートです。プローブは短時間（1 回あたりの実行時間は 30 秒未満）、対象を絞り（それぞれ 1 つの重要な経路を確認）、安定している必要があります（retries: 0、不安定さは一切許容しません）。30 秒という上限は厳守すべき予算です。「それでもパスする」遅いプローブは、ユーザーが感じる性能低下を見えにくくしています。

3. 単発の失敗ではなく、傾向に対してアラートを発します

プローブが 1 回失敗しても、それはノイズです。ネットワークの瞬断や DNS の一時的な問題は常に発生します。2 回連続した失敗はシグナルであり、2 つ以上のリージョンで失敗すれば、局所的な問題ではないと確認できます。連続失敗と複数リージョンのしきい値を設定しないと、アラート疲れによってチームがページャーを無視するようになります。

4. プローブで本番データに影響を与えてはいけません

プローブは 24 時間 365 日、数分おきに実行されます。小さな副作用（レコードの作成やカウンターの増加）でも積み重なります。プローブは非破壊的にし、作成したデータは直ちにクリーンアップする必要があります。また、合成トラフィックは分析、課金、そして重要な点として、SLO／エラーバジェットの計算自体から除外してください。そうしないと、プローブによって自分たちの信頼性の数値が水増しされます。

5. ステータスコードではなく、目的を検証します

200 を返しても認証が一度も成功しないログインページは壊れています。200 を返しても検索結果が 0 件の検索ページも壊れています。プローブでは、単にページが 2xx を返すかではなく、データが読み込まれる、認証が成功する、結果が表示されるなど、ユーザーが目的を達成できることを検証します。

---

プローブの設計

インフラストラクチャのコンポーネントではなく、重要なユーザージャーニーを中心にプローブを設計します。ユーザーが気にするのはロードバランサーが正常かどうかではなく、ログインして製品を使えるかどうかです。

プローブ	検証する内容	頻度	タイムアウト
ホームページの読み込み	DNS、CDN、サーバー、基本的なレンダリング	1 分	10s
ログインフロー	認証サービス、セッション管理	5 分	15s
コアワークフロー	主要な価値を提供する操作（ドキュメントの作成、レポートの実行）	5 分	20s
API ヘルスチェック	バックエンドサービス、データベース接続	1 分	5s
検索	検索インデックス、クエリ処理、結果のレンダリング	5 分	15s
チェックアウト（該当する場合）	決済連携（サンドボックスモード）、カート、注文の作成	10 分	25s
サードパーティ連携	OAuth プロバイダー、メール配信、ファイルストレージ	10 分	15s

プローブの実装

ほとんどのニーズは、3 種類のプローブでカバーできます。ログインフロー（Playwright ブラウザー）、API ヘルスチェック（ステータス＋認証＋レイテンシ予算）、検索プローブ（クエリを入力 → 送信 → ステータスだけでなく検索結果を検証）です。それぞれを 1 つの重要な経路に絞り、タイムアウトを短く設定し、retries: 0 にします。実行可能なログインフロー、API ヘルスチェック、検索プローブと、環境に対応した設定については、references/probe-implementations.md を参照してください。

非破壊的なプローブのパターン

Safe patterns:
  - Read-only operations: GET requests, page loads, searches
  - Sandbox transactions: payment in test mode, email to internal addresses
  - Create-then-delete: create a draft, verify, delete immediately
  - Synthetic flag: operations tagged as synthetic, excluded from processing

Dangerous patterns (avoid):
  - Creating real orders, tickets, or user-facing records
  - Triggering real notifications (email, SMS, push)
  - Modifying shared resources (config, permissions, settings)
  - Operations that cannot be automatically cleaned up

専用のテストアカウント

Account requirements:
  - Clearly identifiable: email contains "synthetic" or "monitor"
  - Flagged in database with an is_synthetic flag (is_synthetic = true)
  - Excluded from analytics, billing, email campaigns, support queues
  - Excluded from RUM and SLO/error-budget pipelines (synthetic traffic is not real traffic)
  - Pre-populated with stable test data that probes can rely on
  - Credentials in a secrets manager (process.env), rotated quarterly
  - Separate accounts per concurrent probe (avoid state conflicts)

---

プラットフォームの選択肢

プラットフォーム	強み	使用する場面
Checkly	Playwright ネイティブ、コードファースト、Git 連携。Rocky AI エージェント（2026 年に GA）は、Playwright/API/Multistep/TCP/DNS/ICMP チェック全体にわたる根本原因分析を自動で実行するようになりました。あらゆる AI エージェントから CLI にアクセス可能。MCP サーバー	E2E にすでに Playwright を使用しているチーム
Datadog Synthetic	APM との深い連携、ブラウザーおよび API テスト	Datadog プラットフォームを利用しているチーム
Grafana Synthetic Monitoring	オープンソース、Grafana ダッシュボードと連携。k6 2.x と併用可能。再現性を確保するためにバージョンチャンネル（v1.x/v2.x）を固定	Grafana スタックを利用しているチーム
AWS CloudWatch Synthetics	ブループリント（ハートビート、API、リンク切れ、ビジュアル差分）。Python または Node の Puppeteer によるカナリア	すでに AWS を利用しているチーム
New Relic Synthetics	フルスタック可観測性との連携	New Relic プラットフォームを利用しているチーム
Better Stack	軽量なアップタイム監視＋ステータスページ＋オンコール	中小企業に適しており、すばやくセットアップ可能
Uptime Kuma	OSS、セルフホスト可能、軽量	セルフホストが必要な場合、小規模な構成
カスタム（Playwright / k6 / Puppeteer + cron）	完全な制御、ベンダーロックインなし	予算が限られている場合、または独自要件がある場合

プローブは Playwright（TS/JS）、Puppeteer、k6（JS — k6 2.0 は 2026 年 5 月にリリースされ、AI 支援によるテスト作成と、より明確な Assertions API を提供。合成監視に最適）、または Python（CloudWatch Synthetics、Checkly）で作成できます。チームがすでに保守しているものを選んでください。新規セットアップでは Pingdom を避けてください。これはレガシーなアップタイム監視ツールです。プローブをアプリとともにバージョン管理できる、コードファーストの代替手段（Checkly、Grafana、カスタム Playwright）を優先してください。

カスタム実装とマネージド実装

セルフマネージドの場合：GitHub Actions の schedule cron（5 分ごと）で Playwright プローブをスケジュールし、シークレットを使って本番環境の認証情報を渡し、監視 Webhook に結果を報告します。マネージドの場合：Checkly は Playwright ネイティブで、固定頻度で複数のロケーションから実行されます。どちらの場合も、環境に応じた設定にして、異なるベース URL としきい値を使いながら、ステージング環境と本番環境で同じコードを実行できるようにしてください。GitHub Actions のワークフロー、Checkly の設定、アラートルーティングルール、ランブックのテンプレートについては、references/platforms-and-ci.md を参照してください。

---

アラート連携

プローブの失敗がすべてインシデントになるわけではありません。実際の問題を検出しつつ、ノイズを減らすルールを設定してください。

Alerting rules:
  - Single failure: log, do not alert (transient network issue)
  - 2 consecutive failures from same region: warning (possible issue)
  - 2 consecutive failures from 2+ regions: alert on-call (confirmed outage)
  - Latency >2x baseline for 10 minutes: warning (performance degradation)
  - Latency >3x baseline for 5 minutes: alert on-call (severe degradation)
  - Any probe timeout: alert if 3 consecutive (service unresponsive)

ルーティング。 収益に関わる経路（login、checkout、api-health）の重大な失敗は、オンコールに通知（PagerDuty + Slack インシデント）し、短い再通知間隔を設定します。二次的なプローブの警告は Slack の監視チャンネルに送信し、情報レベルのイベントには長い再通知間隔を設定します。これらのルートで照合するには、プローブが各結果に severity と probe のラベルを付ける必要があります。完全な alerting-rules.yaml とラベル付けの手順については、references/platforms-and-ci.md のルーティングに関する注記を参照してください。

計画メンテナンス中は合成監視アラートを抑制します。 メンテナンス時間帯は合成監視によるページ通知を停止し（プローブは仕様どおり失敗するため）、エラーバジェットの計算から除外してください。そうしないと、予定された作業で予算が消費され、何の必要もないのにオンコールへページ通知が届きます。

アラートメッセージの形式 — すぐに調査を開始できるだけのコンテキストを含めてください。

Alert template:
  Title: [SYNTHETIC] {probe_name} failing from {region}
  Severity: {critical|warning|info}
  Consecutive failures: {count}
  Last success: {timestamp}
  Error: {error_message}
  Duration: {last_response_time_ms}ms (threshold: {threshold}ms)
  Dashboard: {link_to_dashboard}
  Runbook: {link_to_runbook}
  Regions affected: {list_of_failing_regions}

{link_to_runbook} はプローブごとのランブックを指します（6 行で、テスト対象、最初に確認する項目、手動での再現方法、エスカレーション、ダッシュボード、担当者を記載）。テンプレートについては references/platforms-and-ci.md を参照してください。

---

SLA の検証

可用性の計算

Availability = (total_minutes - downtime_minutes) / total_minutes × 100

Where:
  - total_minutes = calendar month in minutes (43,200 for a 30-day month)
  - downtime_minutes = minutes where synthetic probes detected failure

SLA tiers (downtime/month, monthly basis on 43,200 min):
  99.0%  = 432 min   = 7h 12min     (basic web app)
  99.9%  = 43.2 min  = 43min 12s    (business application)
  99.95% = 21.6 min  = 21min 36s    (critical SaaS)
  99.99% = 4.32 min  = 4min 19s     (infrastructure/platform)

ここに示すのは、一般的な可用性目標であり、規範的なティアではありません。ティア名ではなく、ユーザーへの影響分析に基づいて目標を選んでください。現代の実践（Google SRE Workbook、OpenSLO）では、ラベル付きのティアよりも、明示的な SLO とエラーバジェットのポリシーが重視されます。ユーザーに見える障害を定義し、ユーザーが許容できる影響に基づいて予算を設定し、それに沿って SLO を定めてください。参考資料：https://sre.google/workbook/ ; https://openslo.com/

応答時間のパーセンタイル

平均値ではなくパーセンタイルを追跡してください。平均値では、最も厳しいユーザー体験が見えなくなります。

SLA response time targets (example):
  Homepage load:  P50 < 1s,    P95 < 3s,   P99 < 5s
  API response:   P50 < 200ms, P95 < 500ms, P99 < 1s
  Search results: P50 < 500ms, P95 < 2s,   P99 < 4s
  Login flow:     P50 < 2s,    P95 < 5s,   P99 < 8s

エラーバジェットの追跡

エラーバジェットによって、SLA の目標をエンジニアリング上の判断に結び付けられます。

Error budget calculation:
  SLO: 99.9% availability on a 43,200-min month
  Budget: 0.1% of total time = 43.2 minutes/month

  Budget consumed this month: 12 minutes (28%)
  Budget remaining: 31.2 minutes (72%)

Actions by budget status:
  >50% remaining: normal operations, ship features
  25-50% remaining: caution, review recent changes
  <25% remaining: freeze non-critical deploys, focus on reliability
  Budget exhausted: incident mode, every deploy needs extra scrutiny

計画メンテナンスによる合成プローブのダウンタイムはこの計算から除外してください。除外しないと、計画作業によって予算が消費されたように見えます。

---

マルチリージョン監視

ユーザーがいるリージョンからプローブを実行します。us-east-1 では正常に動作していても、ap-southeast-1 で障害が発生しているサービスは、APAC のユーザーにとっては障害が発生しています。

Region selection strategy:
  - Minimum 3 regions for global services
  - Always include: closest to primary infrastructure, largest user base, farthest from primary
  - Example for US-primary service: us-east-1, eu-west-1, ap-southeast-1
  - Example for EU-primary service: eu-west-1, us-east-1, ap-northeast-1

リージョンごとのレイテンシーを個別に追跡します。グローバル平均では、特定リージョンのパフォーマンス低下が隠れてしまいます。

Regional latency dashboard:
  Region       | P50    | P95    | Status
  us-east-1    | 120ms  | 340ms  | healthy
  eu-west-1    | 280ms  | 620ms  | healthy
  ap-southeast | 450ms  | 1200ms | warning (P95 above threshold)

Alert when:
  - Any region's P95 exceeds its regional threshold
  - Latency difference between regions exceeds 5x (CDN or routing issue)
  - A region that was healthy becomes consistently degraded

CDN の検証。 合成プローブは、レスポンスヘッダー（x-cache、cf-cache-status）を確認して HIT になっていることを検証し、server ヘッダーが想定されるプロバイダーと一致することを確認することで、CDN のキャッシュを検証します。これにより、CDN の設定ミスや、古いキャッシュによって隠れているオリジンの障害を検出し、ユーザーがキャッシュされていない遅いレスポンスに遭遇する前に対処できます。

---

アンチパターン

頻繁に壊れる複雑なプローブ

10 ページを移動し、5 つのフォームに入力し、20 個の要素をアサートするプローブは、合成プローブではなく E2E テストです。壊れたとき、アプリがダウンしているのか、プローブが不安定なのかを判断できません。対処法： プローブごとに重要なパスを 1 つに絞り、30 秒未満、アサーションは 5 個未満にします。失敗の原因がすぐに分かるようにします。

失敗のたびにアラートを送信する

ネットワークの瞬断、DNS の一時的な問題、クラウドの一時的な問題によって、時折失敗が発生します。そのたびにアラートを送信するとノイズになり、チームがアラートを無視するようになります。対処法： 2～3 回連続して失敗し、2 つ以上のリージョンで失敗した場合にページャーを鳴らします。重大度を段階的に上げ、最初の失敗はログに記録し、2 回目は警告し、3 回目にページャーを鳴らします。

テストアカウントが分離されていない

プローブが 1 つのアカウントを共有していると、互いに干渉します。あるプローブが設定を変更すると、別のプローブはデフォルト設定を想定しているため失敗します。対処法： 同時実行するプローブごとに専用の合成アカウントを用意し、合成アカウントとして識別できるようにして、分析と課金の対象から除外します。

正常系のパスだけを監視する

「ページが読み込まれ、200 を返す」ことだけを確認するプローブでは、読み込みページの背後にある機能の障害を見逃します。200 を返しても認証が完了しないログインは、正常に動作しているとは言えません。対処法： 意味のある内容をアサートします。データが読み込まれること、認証が成功すること、主要な操作が完了すること、検索結果が返されることを確認します。「ユーザーが目的を達成できるか」を確認するプローブ 1 つは、「ページが 200 を返すか」を確認するプローブ 10 個分の価値があります。

プローブ失敗時のランブックがない

午前 3 時にアラートが発生します。オンコール担当者は「ログインプローブが失敗」と確認しますが、何を最初に確認すべきか、プローブが何を行うのか、実際の障害とプローブの問題をどう見分けるのかが分かりません。対処法： すべてのプローブにランブックをリンクします（テスト内容、最初に確認する項目――サードパーティのステータス、最近のデプロイ、アプリのテレメトリー、手動での再現手順、エスカレーション、ダッシュボードへのリンク）。references/platforms-and-ci.md のテンプレートを参照してください。

新たな傾向（2026 年）：エージェント主導の初動対応。 Checkly Rocky（GA 2026、複数のチェックタイプを対象とする自動根本原因分析）や Honeycomb Canvas Skills（Agent Observability、2026 年 5 月リリース。オープンソースの honeycombio/agent-skill リポジトリには、Claude Code と Cursor 用の honeycomb-investigator と instrumentation-advisor が含まれています）などのツールは、プローブのコンテキスト、リンクされたランブック、テレメトリーを読み取り、候補となる診断結果をチャットに投稿します。これはトリアージの補助として扱ってください。定型的な障害では MTTR を短縮できますが、未知のインシデントに対するオンコール担当者の判断に取って代わるものではありません。

---

障害モード

症状	考えられる原因	修正または確認
プローブは正常だが、ユーザーから障害の報告がある	プローブが HTTP 200 のみを検証し、目的を検証していない	コンテンツ／状態の検証を追加する（ダッシュボードの見出し、検索結果数、body.status）
アラートが断続的に発生する（発報と解決を繰り返す）	連続失敗ルールまたは複数リージョンルールがない	ページングの前に、2 回以上の連続失敗と 2 つ以上のリージョンを必須にする
プローブがローカルでは成功し、CI／リージョンでは失敗する	リージョン固有の障害または CDN のルーティング	リージョンごとの結果を比較し、レイテンシ差と x-cache の検証を確認する
実際の障害がないのにプローブが失敗する	合成アカウントの状態がずれている（アカウントの共有）	同時実行するプローブごとに専用アカウントを 1 つ用意し、安定したデータをリセット／シードする
オリジンがダウンしているのにプローブは正常なまま	CDN が古いキャッシュを配信している	200 だけでなく、cf-cache-status／オリジンの server ヘッダーを検証する
インシデントがないのにエラーバジェットが消費される	メンテナンス時間がダウンタイムとして計上されている	メンテナンス中の合成ページングを抑制し、予算計算からその時間帯を除外する
オンコールに通知されたが、対応できない	アラートにランブックがない、または空である	6 行のランブックを記入し、{link_to_runbook} が解決されることを確認する
信頼性の数値が良すぎる	合成トラフィックが SLO／RUM で実トラフィックとして計上されている	RUM、請求、エラーバジェットのパイプラインから is_synthetic トラフィックを除外する

---

検証

監視を信頼する前に、正常に機能することを証明してください。まずは最小限の確認から始めます。

1. ステージングに対してプローブが成功する。 ステージングに対して npx playwright test probes/ --reporter=list を実行し、宣言されたタイムアウト内にすべてのプローブが成功することを確認します（30s の上限を超えるプローブがないこと）。
2. 失敗によって実際にページングされる。 既知の不正な URL（503 または誤ったパス）に 1 つのプローブを向け、設定された連続失敗回数に達するまで実行させます。SLA の検知時間内にアラートがオンコールへルーティングされ、元に戻すと解決することを確認します。
3. 検証内容に意味があり、ステータスだけではない。 検証対象のコンテンツを一時的に壊し（ステージングでダッシュボードの見出しを変更し）、プローブが失敗することを確認します。この状況でもプローブが正常なままなら、誤った項目を検証しています。
4. 合成トラフィックが除外されている。 分析／RUM／請求のパイプラインで is_synthetic トラフィックをクエリし、除外されていることを確認します。

---

完了条件

• 検出時に特定した重要なユーザージャーニーごとにプローブが存在する（ホームページの稼働状況や単一のヘルスエンドポイントだけではない）。また、それぞれが 2xx だけでなく目的を検証する。
• 各プローブの実時間予算が 30s 未満で、retries: 0 である。
• アラート設定に、2 回以上の連続失敗ルールと複数リージョンでの確認ルールの両方が含まれ、プローブ結果に severity と probe のタグが付いてルートが一致する。
• SLA ダッシュボードに現在の可用性とエラーバジェットの消費量が表示され、RUM、請求、エラーバジェットのパイプラインから合成トラフィックが除外されている。
• テストアラート（失敗する URL に向けたプローブ）が SLA の検知時間内にオンコールへ届くことを、想定ではなく実際に一度確認している。
• すべてのプローブが、初動の確認項目、手動での再現方法、エスカレーション経路を記載した空ではないランブックにリンクしている。
• 監視の健全性を確認する、定期実行のレビュー用ジョブまたは繰り返し予定のカレンダー項目がある（レビューする意図だけではない）。

参考ファイル（references/ 内）

• probe-implementations.md — 実行可能なログインフロー、API ヘルス、検索の各プローブと、環境に対応したプローブ設定。
• platforms-and-ci.md — GitHub Actions のスケジュール実行ワークフロー、Checkly 設定、アラートのルーティングルールとタグ付けに関する注記、プローブごとのランブックテンプレート。

関連スキル

• testing-in-production — 安全にリリースするための手法（フラグ、カナリア、ガードレール指標）をロールアウト中に適用します。合成モニタリングは、スケジュールに基づく検証を継続的にロールアウト後に実行します。
• release-readiness — 特定のリリースにひも付いた、デプロイ後に一度だけ実施するスモークテストのゲートはそちらにあります。リリース後も長期にわたって実行される、継続的かつスケジュールに基づくバージョンについては、こちらを参照してください。
• observability-driven-testing — 本番環境のテレメトリ（これらのプローブからのシグナルを含む）を入力として、新しいテストを設計します。このスキルでは、プローブとそのテレメトリを生成します。
• performance-testing — 負荷テストは必要に応じてキャパシティを測定します。合成プローブは、負荷テストの間に本番環境のパフォーマンスの推移を追跡します。
• qa-metrics — プローブから得られる可用性、応答時間のパーセンタイル、エラーバジェットの消費量は、そちらで定義されている品質ダッシュボードに反映されます。
• ci-cd-integration — 合成プローブをデプロイ後の検証ステージとしてパイプラインに組み込むには、そちらを参照してください。