収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
検索APIの可用性SLIを、利用者体験に最も近い形で定義したい。適切なのはどれですか？
答え： 有効な検索要求のうち期限内に正しい結果を返した割合
可用性SLIは、利用者が期待する有効な要求のうち、正しく十分速い応答を得られた割合として測ると、内部構成に左右されにくくなります。
30日間で可用性99.9%のSLOを設定した。単純化して許容される失敗時間の目安はどれですか？
答え： 約43分の失敗時間まで許容される
30日間は43,200分で、0.1%は約43.2分です。実運用では時間基準かリクエスト基準か、除外条件、集計窓も明示します。
月初の短い障害で30日エラーバジェットの40%を消費した。適切な判断はどれですか？
答え： 消費速度と原因を確認しリリースリスクを抑える措置を優先する
残量だけでなくバーンレートを見ると、同じ速度が続いた場合のSLO違反を早期判断できます。ポリシーに沿って変更抑制や改善へ切り替えます。
SLO違反を早期検知しつつ、一時的なスパイクによる誤った呼び出しを減らしたい。適切なアラート条件はどれですか？
答え： 短い窓と長い窓の両方でバーンレート閾値を超えたら呼び出す
マルチウィンドウバーンレートアラートは、短い窓の即応性と長い窓の持続性確認を組み合わせ、重大な予算消費を呼び出し対象にできます。
オンコールへ呼び出すアラートとして最も適切なのはどれですか？
答え： 利用者影響が進行中で即時対応が必要かつランブックがある
呼び出しは緊急性と実行可能性がある症状に限定します。予測や傾向はチケット、情報通知はダッシュボードなど適切なチャネルへ分けます。
データベース接続エラーとAPI 5xxが同時に増えた。最初に呼び出し対象とする考え方はどれですか？
答え： 利用者症状のAPI成功率低下を呼び出し対象にしDB指標は調査に使う
症状ベースの呼び出しを入口にし、原因候補のダッシュボードやリンクを付けると、重複した呼び出しを抑えながら影響と診断を結び付けられます。
アラートの重大度を決める基準として最も適切なのはどれですか？
答え： 利用者影響・緊急度・回避策の有無を定義済み基準に当てはめる
共通基準で重大度を決めると、対応資源・通知範囲・更新頻度を一貫して選べます。内部エラー量だけでは事業影響を表せません。
HTTPリクエストメトリクスへ追加するとカーディナリティ爆発を招きやすいラベルはどれですか？
答え： 利用者ごとのuser_id
メトリクスはラベル値の組合せごとに時系列を持つため、利用者IDや生URLのような非境界集合は避け、詳細検索はログやトレースへ寄せます。
オンラインサービスのゴールデンシグナルを素早く確認したい。REDメソッドの組合せはどれですか？
答え： レート・エラー・処理時間（Duration）
REDは要求率、エラー率、処理時間を中心にサービスの利用状況と症状を捉えます。資源側の飽和調査にはUSEなどを組み合わせます。
ノードのリソースボトルネックをUSEメソッドで調べる。確認する組合せはどれですか？
答え： 使用率（Utilization）・飽和・エラー
USEはCPU・メモリ・ディスク・ネットワークなど各資源について使用率、待ち行列や枯渇、エラーを確認し、ボトルネック候補を体系的に探します。
レイテンシ分布を複数インスタンスで集約し、全体のp95を求めたい。適切なメトリクス型はどれですか？
答え： 共通のバケット境界を持つヒストグラム
ヒストグラムのバケット件数はインスタンス間で加算でき、集約分布から分位点を推定できます。インスタンス別分位点の平均は全体分位点になりません。
メトリクス上のレイテンシスパイクから代表的なトレースへ直接移動したい。適切な仕組みはどれですか？
答え： ヒストグラムへトレースID付きのエグゼンプラーを関連付ける
エグゼンプラーは集約メトリクスの観測点へトレースコンテキストを関連付け、異常バケットから具体的なリクエストのトレースへ遷移できるようにします。
通常時はトレースを10%サンプリングしているが、希少なエラートレースを残したい。適切な方針はどれですか？
答え： コレクターでテールサンプリングしエラーや高レイテンシを優先保持する
テールサンプリングはトレース完了後のステータスやレイテンシを見て保持判断できます。ただしコレクターのバッファ、遅延、容量と障害時の流量を設計します。
障害調査に使いやすく、機密情報も抑えたアプリケーションログはどれですか？
答え： 時刻・レベル・サービス・トレースID・非機密の識別子を構造化する
構造化フィールドと相関IDにより検索・集計・トレース連携が容易になります。シークレットや不要な個人情報はマスクまたは収集対象外にします。
非同期メッセージ処理を元のHTTPリクエストのトレースへ関連付けたい。適切なのはどれですか？
答え： プロデューサーのコンテキストをメッセージで伝播しリンクを記録する
トレースコンテキストまたはスパンリンクをメッセージメタデータで伝播すると、キュー待ちを含む因果関係を追跡できます。信頼境界では受信コンテキストも検証します。
複数ホストのログ時刻がずれ、障害タイムラインが矛盾して見える。優先すべき対策はどれですか？
答え： 時刻同期を監視しイベント時刻と受信時刻を区別する
NTPなどの同期状態自体を監視し、イベント発生時刻と収集時刻を保持します。分散処理の因果順序はトレースやメッセージIDも併用します。
サービス概要ダッシュボードの最上段に置く情報として最も有効なのはどれですか？
答え： 主要SLI・SLO状況・直近デプロイ・依存先ヘルスへの導線
概要は利用者影響と変更点を短時間で把握し、原因調査ダッシュボードへドリルダウンできる構造にします。
内部メトリクスは正常だが、外部利用者からログイン不可の報告がある。追加すると有効な監視はどれですか？
答え： 外部地点から認証フローを定期実行する合成監視
Synthetic監視はDNS、CDN、TLS、認証画面など外部経路を含む重要ジャーニーを継続確認し、内部監視の盲点を補います。
実利用者のブラウザで地域別の表示遅延を測りたい。適切なテレメトリはどれですか？
答え： RUMでWeb Vitalsを地域やバージョン別に集計する
リアルユーザーモニタリングは端末・ネットワーク・配信経路を含む実体験を測れます。プライバシー、サンプリング、属性カーディナリティを設計して集約します。
障害時にテレメトリ量が急増し、コレクターキューが満杯になった。設計として適切なのはどれですか？
答え： コレクター自身のキューとドロップを監視し優先度付きで制限する
観測基盤も容量と故障モードを持ちます。アプリケーションへのバックプレッシャー、バッファ上限、重要シグナルの保持、ドロップ可視化を明示します。
重大障害で多数のエンジニアが同時に変更を始め、状況が悪化している。最初に整えるべき体制はどれですか？
答え： インシデントコマンダーを明確にし運用・連絡・計画の役割を分ける
明示的な指揮と役割分担により、変更競合を防ぎ、技術対応と情報更新を並行できます。未委任の責任はインシデントコマンダーが保持します。
障害の重大度を暫定宣言する時点として適切なのはどれですか？
答え： 利用者影響と範囲が基準を満たした時点で暫定宣言し更新する
重大度は対応体制とコミュニケーションを起動するための暫定判断です。原因確定を待たず、共通基準と現在の影響で宣言します。
障害対応中のステークホルダー更新として適切なのはどれですか？
答え： 影響・開始時刻・実施中の軽減策・次回更新時刻を定期共有する
既知の事実と不明点を分け、次回更新時刻を約束すると、復旧担当への個別問い合わせを減らし信頼を保てます。
決済失敗が拡大中で、原因はまだ不明である。最初の技術目標として適切なのはどれですか？
答え： ロールバックやトラフィック制限で影響を封じ込め証拠を保存する
インシデント中は利用者影響の軽減を根本原因確定より優先します。ただし不可逆操作を避け、タイムライン・ログ・変更履歴などの証拠を保持します。
デプロイ直後にエラー率が上がった。ロールバック判断を速める準備として最も有効なのはどれですか？
答え： デプロイ前にガードレール指標と自動ロールバック条件を定義する
事前のガードレールとバージョン別テレメトリにより、正常変動とリグレッションを共通基準で判定し、カナリア停止やロールバックを迅速化できます。
外部推薦サービスの障害で画面全体が失敗している。フィーチャーフラグの使い方として適切なのはどれですか？
答え： 推薦機能だけを止めるキルスイッチで基本画面を縮退提供する
機能単位のキルスイッチで非必須依存を切り離すと、コアジャーニーを維持できます。権限、監査、デフォルト値、期限切れフラグの削除も管理します。
実用的なランブックに含める内容として最も適切なのはどれですか？
答え： トリガー・影響確認・安全な軽減策・エスカレーション・ロールバック
ランブックは圧力下でも安全に実行でき、各ステップの期待結果と中止条件を示す必要があります。定期演習で有効性と権限を確認します。
一次オンコールが15分調査しても影響を軽減できない。適切なエスカレーションはどれですか？
答え： 定義済みの基準に従いオーナーやコマンダーへ文脈付きで上げる
エスカレーションは失敗ではなく、時間と専門性を適切に投入する仕組みです。影響、仮説、実施済み操作、結果、必要な支援を渡します。
障害タイムラインを正確に残す運用として適切なのはどれですか？
答え： アラート・判断・コマンド・観測を時刻と実行者付きで共有記録に残す
ライブインシデントドキュメントへ事実と判断を逐次残すと、交代・並行作業・ポストモーテムで共通の時系列を使えます。
インシデントコマンダーを別地域の担当へ交代する。安全な引き継ぎはどれですか？
答え： ライブドキュメントで口頭確認し新担当の受諾を全体へ通知する
明示的な受諾と全体通知により、常に一人の指揮者と共通状態を保ちます。影響、変更、仮説、リスク、次アクションを引き継ぎます。
非難なしポストモーテムで避けるべき記述はどれですか？
答え： 担当者の注意不足だけを根本原因として改善を終える
個人非難で終えると、同じ条件で別の人も失敗します。設計、ツール、レビュー、権限、負荷など再現可能な条件と防御改善を扱います。
ポストモーテムのアクションアイテムとして最も実行可能なのはどれですか？
答え： オーナー・期限・完了条件・チケットを持つ具体的な改善
アクションは追跡可能で効果を検証できる粒度にします。項目を増やしすぎず、再発可能性と影響を下げる高価値対策へ絞ります。
冗長系が自動切替に成功し利用者影響がなかったニアミスをどう扱うべきですか？
答え： 防御が機能した事実と余裕、次回失敗し得る条件を分析する
ニアミスは利用者被害なしで弱点を学べる機会です。防御層が意図どおりか、容量や復旧時間に余裕があったかを確認します。
エラー率が平常へ戻った直後にインシデントをクローズしてよいか判断する。必要な確認はどれですか？
答え： 主要SLIの安定・バックログ解消・整合性・縮退解除を一定時間確認する
復旧はエラー停止だけでなく、遅延作業・整合性・容量・暫定措置を含めて安定状態へ戻ったことを確認します。
プライマリDB障害後のフェイルオーバーで旧プライマリが書込みを再開し、スプリットブレインの恐れがある。必要な対策はどれですか？
答え： 旧プライマリをフェンスし世代やリースで新側だけに書込みを許す
フェイルオーバーはルーティングだけでなく旧Writerを確実に排除する必要があります。フェンシングトークンやSTONITH、リース世代で古い権限を拒否します。
バックアップジョブは毎日成功している。復旧可能性を保証する次の確認はどれですか？
答え： 隔離環境で定期リストア訓練を行い実測RTO・RPOを確認する
バックアップ成功はリストア成功を意味しません。暗号鍵、権限、手順、依存データ、整合性、所要時間を実際の復元で検証します。
通常時CPU 45%だが、トラフィックが2倍になるイベントを予定している。容量判断として適切なのはどれですか？
答え： 負荷テストで上限を測り障害余力を含む余裕を確保する
CPUだけでなくDB接続、キュー、レート制限、スケール速度、N+1障害時を含めて余裕を検証します。非線形な飽和は実負荷試験で確認します。
外部アドレスバリデーションAPIが停止した。注文受付を安全に継続する縮退策はどれですか？
答え： 最低限の形式検証で保留状態として受け付け復旧後に再検証する
業務上許される場合、状態を明示した遅延バリデーションでコアフローを維持できます。再処理、期限、利用者通知、重複防止を設計します。
障害開始時刻の直前に複数のデプロイと設定変更があった。切分けとして適切なのはどれですか？
答え： 変更イベントを共通タイムラインへ重ね対象範囲ごとの差を比較する
変更は有力な仮説ですが、時刻一致だけで因果とは限りません。バージョン別テレメトリや未変更群と比較し、一変更ずつ結果を記録します。
ゲームデーを本番相当環境で実施する目的と進め方として適切なのはどれですか？
答え： 復旧仮説と成功条件を定め限定した失敗を注入して検証する
ゲームデーは仮説駆動の演習です。影響範囲、停止条件、責任者、ロールバックを事前に定め、検出・連絡・復旧・検証のギャップをアクションへ変えます。
複数層が各3回リトライし、DB障害時にリクエスト数が急増した。再発防止として中核になる設計はどれですか？
答え： リトライを一つの層に寄せバックオフ・ジッター・全体予算を設ける
多段リトライは試行回数を乗算し、障害中の依存先をさらに圧迫します。リトライ可能性を分類し、一層で予算付きリトライを行い、期限切れ後の作業を止めます。
過負荷で大半のインスタンスがクラッシュループに入り、トラフィックを通常値へ戻しても復旧しない。最初の安定化策はどれですか？
答え： トラフィックを絞ってキャッシュを安定させ確認しながら段階的に戻す
縮小した容量では通常トラフィックも過負荷です。負荷シェディングで生存インスタンスを安定させ、キャッシュウォームアップや接続確立後に安全なステップで戻します。
高負荷でレスポンスが遅くなっただけなのにライブネスプローブが失敗し、Pod再起動が連鎖している。適切な改善はどれですか？
答え： ライブネスは回復不能かだけを軽く判定し受付可否はレディネスに分ける
ライブネス失敗は再起動を起こすため、過負荷や一時依存障害を条件にすると容量をさらに減らします。レディネスでトラフィックを外し、ライブネスはデッドロックなど自己回復不能に絞ります。
3可用性ゾーン構成で1ゾーン喪失後もピークトラフィックを処理したい。容量計画として適切なのはどれですか？
答え： 残る2ゾーンでピークと復旧余裕を処理できるよう負荷テストする
N+1設計は障害ドメイン喪失後の残存容量で評価します。スケールアウト時間、クォータ、キャッシュウォームアップ、依存DBやネットワークの限界も失敗テストへ含めます。
トラフィック急増からPod起動完了まで5分かかり、オートスケーリングが間に合わない。適切な改善はどれですか？
答え： 先行指標やキュー長で早めにスケールし最低容量と予測を組み合わせる
Autoscalingループには検知、プロビジョニング、起動、ウォームアップの遅れがあります。需要の変化速度より早く容量を用意し、突発負荷には余裕とアドミッション制御も備えます。
列リネームを伴うデプロイで、旧バージョンと新バージョンがローリング更新中に同時稼働する。安全な変更手順はどれですか？
答え： 新列を追加して両対応・バックフィル後に後続リリースで旧列を消す
Expand-and-contractは複数バージョンが同時利用できるスキーマを先に作り、データ移行と利用切替後に古い要素を除去します。ロールバック可能期間も明示します。
デプロイ後にエラーが増えたが、同時に不可逆なデータマイグレーションが完了している。ロールバック判断として適切なのはどれですか？
答え： 旧版が新形式を読めるか確認し無理なら前方修正など安全な緩和策を選ぶ
ロールバックは常に安全とは限りません。アプリケーション、スキーマ、データ、イベント形式の互換性をランブックで確認し、利用者影響を最小化する実行可能な緩和策を選びます。
設定変更を全インスタンスへ一斉反映した直後に障害が発生した。再発防止策はどれですか？
答え： 設定も版管理しカナリアへ段階配信してヘルスゲートで自動ロールバックする
設定も本番挙動を変えるリリース成果物です。スキーマ検証、ピアレビュー、段階配信、差分監査、迅速なロールバックをコードと同様に扱います。
バグにより誤った残高更新が継続し、データ破損が拡大している。初動として最も適切なのはどれですか？
答え： 影響する書込みを停止・隔離し証拠を保全して破損範囲を確定する
データ完全性インシデントではまず破損の進行を止めます。スナップショット、ログ、イベント、変更履歴を保全し、影響範囲と正しいソースを確認して検証済み修復を行います。
ダッシュボードでリクエスト数が突然0になった。サービス停止かテレメトリ断かを切り分ける方法はどれですか？
答え： 外形監視やLBなど独立シグナルとコレクターの送信失敗を比較する
Noデータとゼロは別状態です。利用者経路と観測パイプラインを独立シグナルで監視し、メトリクス欠損自体にもアラートを設けます。
プロセス再起動後に累積リクエストカウンターが小さくなった。レート計算として適切な扱いはどれですか？
答え： リセットを認識するrate関数を使い再起動メトリクスも併せて見る
カウンターは再起動で0へ戻ります。Prometheusのrate系関数などリセットを補正するクエリを使い、再起動の頻発自体も別シグナルとして監視します。
レイテンシヒストグラムのバケットが0.1秒と10秒しかなく、SLO境界0.5秒の達成率を測れない。改善はどれですか？
答え： SLO境界を含み分布を識別できるバケットを設計し互換性も評価する
ヒストグラムから閾値以下の割合を求めるには、その境界バケットが必要です。代表レイテンシ域とSLO境界を選び、不要に細かいバケットによるコスト増加を避けます。
OpenTelemetryコレクターがメモリ圧迫で停止し、テレメトリがまとめて失われる。適切な保護はどれですか？
答え： メモリリミッターと上限付き送信キューを設けドロップとキューを監視する
コレクターも有限容量のパイプラインです。メモリ上限前にバックプレッシャーやドロップを制御し、重要シグナルの優先度、永続キューの要否、バックエンド停止時間を設計します。
高トラフィックサービスでログ量を削減したいが、障害調査に必要なエラーを失いたくない。適切なサンプリングはどれですか？
答え： エラーや低頻度イベントは保持し反復する正常ログだけをサンプリングする
Value-awareサンプリングで診断価値の高いログを保護します。サンプリング前後の件数、ルールバージョン、トレース相関を残し、欠損を理解できるようにします。
ヘッドベースの1%トレースサンプリングでは発生率0.01%の重大エラーをほぼ保存できない。改善はどれですか？
答え： 完了トレースを評価するテールサンプリングでエラーを優先し上限も設ける
テールサンプリングはトレース完了後の結果を使って希少エラーやテールレイテンシを残せます。判断待ちバッファのメモリ、遅延、トレース完全性、サンプリング率を監視します。
CPU使用率は高いがトレースでは遅いコード箇所を特定できない。追加すると有効なテレメトリはどれですか？
答え： 低オーバーヘッドの継続的プロファイリングで関数別CPUを比較する
プロファイリングはCPU時間や割り当てをスタック単位で示し、メトリクス・トレースだけでは見えないホットパスを特定します。リリースバージョンやPod属性と相関させます。
毎週同じ手順で利用者アカウントを手作業修復している。SREのトイルとして適切な対応はどれですか？
答え： 頻度・時間・リスクを計測し原因修正か安全な自動化へ投資する
トイルは手作業、反復的、自動化可能、戦術的で、サービス成長に比例する作業です。量を可視化し、エンジニアリング作業で削減効果を追跡します。
一人のオンコールへ一晩で30件の呼び出しが届き、重要アラートへの反応が遅れた。改善として適切なのはどれですか？
答え： 呼び出しの実行可能性を棚卸しし重複集約と閾値修正を行い負荷を指標化する
呼び出し疲労はシステムリスクです。即時行動が必要な利用者影響だけを呼び出し対象にし、チケットやダッシュボードへ降格できるシグナルを分離してローテーションの持続性を守ります。
ポストモーテムアクションとしてアラート追加を完了したが、同じ障害を本当に早く検知できるか不明である。適切な完了確認はどれですか？
答え： 過去データのリプレイか制御した失敗テストで発火から応答まで確認する
アクションアイテムはコード変更だけでなくリスク低減を検証して完了です。検知から人の行動まで試し、偽陽性や通知経路も評価します。
外部決済プロバイダーの可用性が自社チェックアウトSLOを下回る。SREとして適切な設計判断はどれですか？
答え： 依存先を含むジャーニーSLIを測りフォールバックやキューで達成可能にする
利用者は障害主体ではなくチェックアウト結果を体験します。依存関係予算を算出し、必要なら冗長化、非同期化、縮退、契約変更によりエンドツーエンドSLOを成立させます。
同じ観測期間に、リージョンAは900件中900件、Bは100件中90件が成功しました。全リクエストを等しく扱う可用性SLIは何%ですか？
答え： 成功件数を合算して総件数で割り、99%とする
全体の成功率は(900+90)/(900+100)=99%です。リージョン別成功率の単純平均は、件数が違うのに両地域へ同じ重みを与えます。全体SLIとは別に地域別の悪化も監視します。
リクエスト成功率のSLOは99.9%、直近の観測窓の失敗率は1%でした。バーンレートを失敗率÷許容失敗率で求めると、いくつですか？
答え： 許容失敗率は0.1%なので、バーンレートは10倍
許容失敗率は100%-99.9%=0.1%です。1%÷0.1%=10で、基準の10倍の速度で失敗予算を消費する水準です。この値だけで既に月間予算を使い切ったとは判断できません。
PrometheusでPod別の累積リクエストカウンターからサービス全体の毎秒件数を求めます。一部Podの再起動によるリセットも扱うには、集計順序をどうしますか？
答え： 各Podへrateを適用し、必要なラベル単位で合算する
たとえば sum by (service) (rate(http_requests_total[5m])) とします。個々の時系列でリセットを処理してから集約する順序が重要です。先に合算すると、別Podの増加がリセットを隠す場合があります。
Prometheusアラートに for: 5m を指定しています。同じラベルの条件が3分間真、1回の評価で偽、その後3分間真になりました。評価欠落がない場合の理解はどれですか？
答え： 偽で待機がリセットされ、再成立から5分の継続を待つ
forは真だった時間の累積ではなく、同じアラート要素が継続して成立する期間を指定します。偽になれば待機状態は解消され、再成立後に待機し直します。
一つのサービス障害で多数のPodから同種のアラートが発生しました。各アラートは保持しつつ、通知をサービス単位のまとまりにしたい場合、Alertmanagerで使う機能はどれですか？
答え： Groupingで、サービスなど共通ラベルごとに通知をまとめる
Groupingは関連アラートをまとめて通知する仕組みです。必要な環境・サービスのラベルを選び、異なる障害をまとめ過ぎないようにします。通知抑制や検知停止とは異なります。
クラスタ停止アラートが発火中だけ、同じクラスタの派生アラート通知を自動で抑えたい設計です。別クラスタの通知には影響させないAlertmanager設定はどれですか？
答え： クラスタラベルを一致させたInhibitionルールを設定する
Inhibitionは特定のアラートが存在するときに別の通知を抑えます。親子の条件と一致させるクラスタラベルを定義し、対象ラベルが確実に付くことも検証します。
計画メンテナンス中の特定サービスだけ、1時間の通知停止が必要です。監視データとアラート評価は残します。適切な運用はどれですか？
答え： 対象と期限を絞ってSilenceを作り、解除も確認する
Silenceはラベル条件と時間範囲で通知を抑えます。対象・期限・理由を記録し、期限後に抑制が残っていないことを確認します。評価やメトリクス収集を止める必要はありません。
Linuxサーバーで小さなファイルの新規作成がENOSPCで失敗します。対象ファイルシステムの df -h では容量に余裕があります。次に確認すべき資源はどれですか？
答え： df -iでinode使用量と残数を確認する
バイト単位の空き容量とinodeの空きは別です。inodeが枯渇すると容量が残っていてもファイルを作れないことがあります。対象のマウント先を確認し、所有者・保持方針に沿って原因ファイルを整理します。
Linuxで大きなログファイルを削除しましたが、ディスク使用量が減りません。ログプロセスは稼働中です。考えられる原因と適切な確認はどれですか？
答え： 削除済みファイルのopen参照を調べ、保持プロセスを特定する
最後の名前が削除されても、プロセスがファイルを開いていれば領域は最後の参照が閉じるまで残ります。保持プロセスを確認し、製品の手順に沿ったログ再オープンなどを検討します。無差別な再起動は避けます。
非同期注文キューの件数は少ないのに、数件が長時間処理されず納期を超えています。件数監視に加えて、遅延の検知に有効な指標はどれですか？
答え： 最古の未処理注文の経過時間と期限を比較する
件数が少なくても滞留時間は長くなり得ます。業務上の未完了注文の最古経過時間や処理所要時間を監視します。ブローカーの近似年齢には再配信・DLQなどの扱いに制約があるため、指標の対象範囲も確認します。