導入
可観測性のデータが揃っても、それを「誰が・いつ・どう見て・どう対応するか」の仕組みがなければ活きません。この章の締めくくりとして、監視の可視化からインシデント対応までの一連の流れを見ていきます。
説明
監視からインシデント対応までの流れは、次のように整理できます。
flowchart TD
M["メトリクス/ログ/トレース"] --> D["CloudWatchダッシュボード<br/>（可視化）"]
M --> SC["CloudWatch Synthetics<br/>（合成監視）"]
EB["EventBridge"] -->|"AWSサービスの状態変化"| A["自動アクション/通知"]
AH["AWS Health"] -->|"AWS側の障害情報"| A
A --> IM["Incident Manager<br/>（インシデント対応の自動化）"]
| ツール | 役割 |
|---|---|
| CloudWatch ダッシュボード | 複数メトリクス・アラームを1画面に集約、関係者への状況共有 |
| CloudWatch Synthetics（合成監視） | 定期的に模擬リクエストを送り、利用者視点での可用性を能動的に監視 |
| EventBridge | AWSリソースの状態変化イベントを検知し、自動アクションへつなぐ |
| AWS Health | AWS側の障害・メンテナンス情報を、自分の環境への影響つきで通知 |
| Incident Manager | インシデント発生時の対応手順（誰を呼ぶか、何をするか）を自動化・標準化 |
- 合成監視（Synthetics）: 実際の利用者がアクセスするまで異常に気づかない、という受け身の監視の弱点を補う。定期的にログインフローや主要APIを模擬実行し、問題が利用者に気づかれる前に検知する。
- EventBridge: 「EC2インスタンスがStoppedになった」「GuardDutyが検知した」といったAWS内部のイベントをトリガーに、Lambdaの実行やSNS通知を自動でつなげる、いわば運用自動化の配線盤。
- AWS Health: AWS基盤側の障害やメンテナンス予定を、自アカウントのリソースに影響があるものだけフィルタして通知する（Personal Health Dashboard）。「AWS側の問題か、自分たちの問題か」の切り分けに使う。
- Incident Manager: 障害発生時に「誰にエスカレーションするか」「どの手順（Runbook）を実行するか」をあらかじめ定義し、インシデント対応そのものを標準化・自動化する。属人的な「詳しい人にとりあえず電話する」対応から脱却する。
読んでみよう
「利用者が気づく前に障害を検知したい」は合成監視、「AWS基盤側の問題か自社の問題かを素早く切り分けたい」はAWS Health、「インシデント対応の手順・エスカレーションを標準化したい」はIncident Managerが対応します。これでドメイン3の運用・可観測性・信頼性の改善は一区切りです。次章ではセキュリティとコストの改善に進みます。