導入
可観測性のデータが揃っても、それを「誰が・いつ・どう見て・どう対応するか」の仕組みがなければ活きません。この章の締めくくりとして、監視の可視化からインシデント対応までの一連の流れを見ていきます。
説明
監視からインシデント対応までの流れは、次のように整理できます。
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）を実行するか」をあらかじめ定義し、インシデント対応そのものを標準化・自動化する。属人的な「詳しい人にとりあえず電話する」対応から脱却する。
具体例
「利用者からのクレームで初めて障害に気づく」受け身の運用を、能動的な体制へ改善します。あるECサイトの一日：
- 利用者が気づく前に検知（Synthetics） … CloudWatch Syntheticsが数分ごとに「ログイン→商品検索→カート投入」を模擬実行。ある朝、決済ページが500エラーを返し始めたのを、最初の実ユーザーが困る前に検知。
- AWS側か自社かの切り分け（AWS Health） … 通知を受けて、まずAWS Healthを確認。「東京リージョンの特定AZでネットワーク障害」というAWS側の情報が出ていれば、原因はAWS基盤。自社のコードを無駄に疑わずに済む。
- 対応の標準化（Incident Manager） … インシデントが起票されると、あらかじめ定義したエスカレーション先（オンコール担当）が自動で呼ばれ、対応Runbookが提示される。「詳しい人にとりあえず電話」の属人対応から脱却。
- 自動アクション（EventBridge） … 「GuardDutyが脅威検知」などのイベントを起点に、Lambdaで自動対処や通知を配線。
「利用者が気づく前＝Synthetics、AWS側か自社か＝AWS Health、対応手順の標準化＝Incident Manager」。可観測性の“データ”を、対応の“仕組み”に変えるのがこの締めくくりです。
読んでみよう
「利用者が気づく前に障害を検知したい」は合成監視、「AWS基盤側の問題か自社の問題かを素早く切り分けたい」はAWS Health、「インシデント対応の手順・エスカレーションを標準化したい」はIncident Managerが対応します。これでドメイン3の運用・可観測性・信頼性の改善は一区切りです。次章ではセキュリティとコストの改善に進みます。