DOPインシデントとイベントへの対応
あるエンタープライズ企業のSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）チームは、月に数十件発生する「中程度の優先度の運用上の問題」（例：EC2インスタンスのCPU高騰継続・RDSのスロークエリ増加・Lambdaのタイムアウト多発）に対応するワークフローを改善しようとしています。現在の課題は以下の4点です：
・CloudWatchアラームごとに担当者が手動でチケットを作成しており工数が大きい
・同一リソースで複数のアラームが発報すると重複チケットが作成される
・対象リソースのCloudWatchメトリクスやAWS Configの変更履歴を別々のコンソールで手動収集している
・過去の同種問題で使用したSSM Automationランブック（runbook：標準化された手順書）を再利用できていない
これら4つの課題をAWSネイティブのサービスで最も効率的に解決する設計はどれですか？
AAWS Systems Manager OpsCenter を有効化し、CloudWatchアラームのアクションに「OpsItemの作成」を設定する。重複排除設定を行い、OpsItemコンソールから関連CloudWatchメトリクス・Configタイムラインを参照してSSM Automationランブックを直接実行する
✓ 正解
OpsCenter は CloudWatch アラームとの直接統合で OpsItem を自動作成し、同一リソース・タイトルの重複排除、関連リソース情報表示、OpsItem 画面からのランブック直接実行が標準機能です。
BAWS Systems Manager Incident Manager でレスポンスプランを作成し、CloudWatchアラームから自動的にインシデントを起票する。インシデント画面からSSM Automationランブックを実行し、オンコール担当者への自動ページングを行う
Incident Manager はクリティカルなサービス停止レベルのインシデント向けで、中程度優先度の運用問題の大量処理・重複排除・ランブック再利用には OpsCenter が適切です。
CAmazon EventBridge ルールでCloudWatchアラームを捕捉し、AWS Step Functionsステートマシンを起動してチケット作成・担当者通知・ランブック実行を自動化するオーケストレーションワークフローを独自に構築する
Step Functions + EventBridge は柔軟なワークフロー自動化が可能ですが、重複排除・関連リソースコンテキスト表示・ランブック管理UIを自前で実装する必要があり開発コストが大きいです。
DAWS Service Catalog でランブックカタログを作成し、CloudWatchアラームからSNS経由でオペレーターにメール通知する。オペレーターがService Catalogから適切なランブックを選択して手動実行する
Service Catalog + メール通知はオペレーターの手動選択・実行が必要で完全自動化を実現できず、重複チケット問題の解決もできません。
解説
AWS Systems Manager OpsCenter は運用上の問題（OpsItem）を一元管理するサービスで、CloudWatchアラームとの直接統合でOpsItemを自動作成できます。同一リソース・同一タイトルのOpsItemが既存の場合は新規作成しない重複排除機能、関連リソースのCloudWatchメトリクス・Configタイムラインのコンテキスト表示、OpsItem画面からのSSM Automationランブック直接実行を標準機能として持ちます。
選択肢B の Incident Manager はP1/P2レベルのクリティカルなサービス停止など緊急対応が必要なインシデント向けで、オンコールページング・エスカレーション計画が主な機能です。「中程度の優先度の運用問題」を大量に処理し重複排除・ランブック再利用を行うユースケースにはOpsCenter（軽量なオペレーショントラッキング）が適切です。
選択肢C の Step Functions + EventBridge は柔軟なワークフロー自動化が可能ですが、重複排除・関連リソースコンテキスト表示・ランブック管理UIを自前で実装する必要があり開発・運用コストが大きくなります。
選択肢D の Service Catalog + メール通知 はオペレーターの手動操作が残るため自動化の要件を満たさず、重複チケット問題も解決しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →