AWS SSMのIncident Managerを大活用しよう！
本記事では、AWSリソースを含むシステムの運用をする際に便利なサービス「AWS Systems Manager」を複数回にわたってご紹介します。
前回に続き、今回もIncident Managerを取り上げ、今回はより応用的な内容に踏み込んで解説します。
CloudWatchやEventBridgeとの連携
CloudWatch、EventBridgeと連携して、インシデント発生時にIncident Managerでインシデントを作成するように設定することができます。
CloudWatchアラームの設定
CloudWatchでアラームを検出した際にインシデントを作成するためには、CloudWatchアラーム側で設定する必要があります。
CloudWatchアラームの作成または編集ウィンドウの「ステップ２：アクションの設定」画面まで移動します。
「アクションの設定」画面を下にスクロールしていくと、「Systems Manager アクション」の設定欄があります。ここで、アラーム状態になった際に実行するSystems Managerの操作を設定でき、Incident Managerにインシデントを作成することができます。
アラーム状態になるとともにインシデントを作成する場合は、「インシデントを作成」を選択状態にし、レスポンスプラン（対応プラン）を選択します。レスポンスプランの選択は必須ですので、Incident Managerにて事前に作成しておきましょう。
今回はCPU使用率（CPU Utilization）がしきい値を超えたらアラーム状態になり、インシデントを作成するように設定してみました。
CPU使用率がしきい値を超えると、CloudWatchのアラーム詳細画面では次のように表示されます。青線はCPU使用率、赤線はしきい値を示し、ある時点から青線が赤線の値（51.1）を超過していることが判ります。
また、Incident Managerの方を見ると、次のようにインシデントレコードが作成されていました（インシデント情報はAWS Systems Manager画面左ペインの「運用（オペレーション）管理」＞「Incident Manager」リンクを選択することで表示できます）。
登録されるインシデントの名前は “インシデントタイトル[CloudWatchアラーム名称]” の形で登録されます。インシデントタイトルは、CloudWatchアラーム側で紐づけた対応プランの「インシデントのデフォルト」欄で設定した「タイトル」の値がセットされます。
その他、影響度やエンゲージなどの設定も対応プランのパラメータを継承します。
EventBridgeの設定
Amazon EventBridgeでは、特定のイベントが発生した際にインシデントを作成することができます。EventBridgeで作成したルールの設定にて、Incident Managerの対応プランをターゲットにすることで設定できます。
初めてAmazon EventBridgeを扱う方は、EventBridgeサービスに移動し、ナビゲーションペインより「ルール」のリンクをクリックしてルールを新規作成してください。
イベントの発生をトリガーとしてインシデントを作成する設定は、ルール編集画面の「ステップ３：ターゲットを選択」画面で行います。
「ターゲットタイプ」は「AWSのサービス」を選択し、「ターゲットの選択」欄で「Incident Manager レスポンスプラン」を選択します。関連付ける対応プラン（レスポンスプラン）の設定と実行ロールに関する設定項目が表示されるので、相応な値を指定しましょう。
今回は、EC2のステータスが停止状態に変わるイベントをトリガーとして、インシデントを作成するEventBridgeルールを新規で作成しました。
以下に示す画面は、停止操作を実施した直後のEC2インスタンス一覧です。今回EventBridgeのルールと紐付けたのは、以下赤枠で囲んだ test-linux-server01です。
EventBridge側でイベント発生によるトリガーが起動したことを確認するには、作成したルールの「モニタリング」タブを見るといいでしょう。いくつかメトリクスが表示されますが、「TriggeredRules」や「呼び出し実行」が記録されていればルールが実行されたと判断できます。
Incident Managerを確認すると、次のようにインシデントレコードが作成されていました。
作成されるインシデントの名前は “インシデントタイトル[EventBridgeルール名]” の形です。
このように、CloudWatchアラームからの場合も、EventBridgeルールからの場合も、Incident Managerの対応プランと連携させる設定は簡単にできます。
エスカレーションの検証
続いて、エスカレーション機能を検証してみます。導入として、混同しがちなエンゲージメントとの違いを説明することから始め、実際に機能を検証してみます。
エンゲージメントとエスカレーションの違い
エンゲージメントは、インシデント作成と共に対応プランが開始した際、指定の連絡先やオンコールスケジュールへをエンゲージ（参加）させる機能です。一言で言うと、インシデント対応に関係者の参加を促す機能です。
作成したコンタクトやオンコールスケジュールを対応プランと紐付けたい場合、必ず対応プランのエンゲージメント設定に組み込む必要があります。エンゲージメントを何も設定しないと、インシデントが発生した際にコンタクトやオンコールスケジュールへの通知は行われません。
コンタクト（連絡先）設定からは、時間の経過と共に複数の連絡先へエンゲージすることもできます。次の画面では、インシデントの発生から１分後にsmsへの通知、3分後にメールへの通知を行う設定をしています。
一方、エスカレーションは、ステージング（段階）制御による連絡フローを構築する機能です。例えば、ステージ１でサービスデスクなどの１次対応者をエンゲージさせ、一定の時間が経過したらステージ２として高等技術者や上位権限者などの２次対応者をエンゲージさせることが可能です。
先に説明したエンゲージメントでも時間経過による制御ができたので、これだけ聞くとエンゲージメントとの違いが分かりにくいかもしれません。ただ、エスカレーションは１次対応者が確認を実施したら２次対応者をエンゲージさせないといった制御が可能です。
例えば、１次対応のリミットを１時間として、１時間以内に１次対応者で解決できない場合に２次対応者へ通知をすることができます。
検証計画
次のようなイメージでの検証を想定しています。
対応プランは１つです。１次対応として２つのエンゲージメントを用意し、インシデント発生から１分後にSMSチャネルをエンゲージさせ、３分後にメールアドレスチャネルをエンゲージさせます。１次対応でインシデントが解決されない場合、エスカレーションプランを発動して２次対応へ進みます。２次対応では、インシデント発生から５分後に音声（電話）チャネルをエンゲージさせます。
検証設定
連絡先（コンタクト）
連絡先はエスカレーションフローに合わせて２つ作成します。１次対応者となる連絡先は、「通常の連絡先」という名前で作成しました。対応プランのエンゲージメント設定に表示される名前ですね。
コンタクトチャネルには、第１エンゲージのSMS、第２エンゲージのメールアドレスを追加します。
追加したコンタクトチャネルをエンゲージメントプランに追加します。SMSはインシデント発生から１分後にエンゲージさせるので、「エンゲージメント時間（分）」に “１” を設定します。メールアドレスは３分後なので “３” を設定します。
２つ目の連絡先は、「テクニカルサポート」という名前で作成してみました。
２次対応者は音声（電話）チャネルをエンゲージさせるため、音声チャネルを追加して連絡先となるスマートフォンの電話番号を設定します。
エスカレーションプラン発動と共にエンゲージを行いたいため、エンゲージメントプラン設定におけるエンゲージメント時間の値は “０” とします。
エスカレーションプラン
最後にエスカレーションプランの設定を行います。プラン名は「usually」にしました。
ステージは２つ作ります。ステージ１は、連絡先「usually」を指定します。「ステージ期間」は、次のステージ２に移るまでの待機時間（分単位）です。今回はステージ１の開始から５分後にステージ２に移るように “５” を設定します。
ステージ２は、連絡先「テクニカルサポート」を指定します。設定値はエイリアスとなるため、「technical_support」が表示されます。
対応プラン
「usually」という名前の対応プランを作成しました。表示名は「normal」です。
対応プランにおけるエンゲージメント設定は、先に作成したエスカレーションプランを指定します。コンタクトを個別に設定するのみだと、エスカレーションプランは実行されませんので注意してください。
検証実施
検証は、先述のEventBridgeルールにより実施することにしました。EC2インスタンスを停止して、想定通りのフローをたどるか確認してみましょう。
EC2サービス管理コンソールより、インスタンスを停止します。
停止操作を行い、対象のEC2インスタンスが停止済み状態に変わりました（17:22）。
その１分後、１次対応者の第１エンゲージとしていたSMSに、Incident Managerよりメッセージが届きました（17:23）。
インシデント発生から３分後にIncident Managerよりメールが届きました（17:25）。
インシデント発生から5分後、音声（電話）へのエンゲージも確認できました。エスカレーションプランも実行されたようです（17:27）。
インシデントの詳細情報で「エンゲージメント」タブを確認すると、エスカレーションプランが実行されていることを確認できます（実行されていない場合、エンゲージメント情報は記録されません）。
このように、エスカレーションプランをうまく活用することで、インシデントの発生から解決まで最短時間で実施でき、サービス品質を高めることができそうです。
インシデント解決後の分析
インシデントを解決すると、インシデントの詳細画面より分析ができるようになります。分析を行うことで、インシデントの根本原因を理解し、今後のインシデント対応を改善するのに役立ちます。
分析によって具体的に何をできるかについては、AWS公式のドキュメントを参照してください。
https://docs.aws.amazon.com/ja_jp/incident-manager/latest/userguide/analysis.html
分析を行うには、解決したインシデントの詳細画面より、「分析を作成」をクリックします。
タイトルは元のインシデント名より自動的に入力されます（変更可能）。必須項目として分析プロセスのテンプレートを選択する必要がありますが、AWSがデフォルトで用意している「AWSIncidents-PostIncidentAnalysisTemplate」を利用することができます。
テンプレートを新規で作成することも可能ですが、その場合もデフォルトテンプレートをベースに作成することをAWSは推奨しています。
分析の作成を実行すると、特に注目して取り上げたいのは、「質問（Question）」タブの内容です。質問に答えることで、インシデントの「検出」、「診断」、「緩和」、「予防」について改善策を見出すことをサポートしてくれます。
次のような質問が用意されています。
▼検出
| 検出にかかる時間はどのように改善できますか？時間を半分にするにはどうすればよいですか？ |
| 検出に使用されるメトリクスについて、どのような調整を行うことが可能ですか？ |
| 検出に使用されるアラームについて、どのような調整を行うことが可能ですか？ |
▼診断
| 診断にかかる時間をどのように改善できますか？時間を半分にするにはどうすればよいですか？ |
| 正しい連絡先を迅速にエンゲージするために、次のいずれかを更新する必要はありますか？ |
▼緩和
| 緩和にかかる時間をどのように改善できますか？時間を半分にするにはどうすればよいですか？ |
| インシデントのランブックを改善できますか？ランブックには、不要なステップが含まれていたり、役に立つステップが不足していたりしませんか？ |
▼防止
| 問題の調査 – 5 つのなぜ ※問題を定義し、問題発生の理由や教訓を整理します |
| 得られたその他の教訓 |
AWS Chatbotとの連携
AWS Chatbotとの連携による、チャットチャネルへのを検証してみます。
AWS Chatbotは「Amazon Chime」、「Microsoft Teams」、「Slack」に対応しています。
Slack設定
先にSlackでワークスペースを作成しておきます。ワークスペース名は「Incident Manager」で作成しました。
ワークスペース名の設定後、プロジェクト名の入力を求められますので、任意の値を入力しましょう。今回は「Incident Manager検証」と入力しました。このプロジェクト名はAWS Chatbotクライアントのチャネル設定で出てきます。
また、作成したワークスペースのURLは、AWS Chatbotとの連携で必要となるので控えておきましょう。
AWS Chatbot設定
AWS Chatbotのサービス画面より、「新しいクライアントを設定」をクリックします。
直後に表示される「新しいクライアントを設定」のポップアップで、クライアントの種類を選択します。今回はSlackと連携したいので「Slack」を選択しています。
AWS Chatbot がSlackワークスペースにアクセスする権限をリクエストする画面が表示されるので、「許可する」をクリックします。
クライアントの作成が完了すると、クライアントの詳細画面が表示されます。画面中央にある「新しいチャネルを設定」をクリックします。
「Slackチャネル」欄では、「パブリック」を選択しました。招待者のみワークスペースへの参加を許可する場合などは「プライベート」を選択し、チャネルIDで指定もできます。ちなみに、この設定項目に表示されるパブリックチャネル名は、Slackで作成したワークスペースのプロジェクト名が表示されます。
「アクセス許可」欄では、ロール設定を行います。今回は、AWS既存ロールの「IncidentManagerIncidentAccessServiceRole」を選択します。
Slackと連携する場合、「通知」欄でSNS（Simple Notification Service）トピックの設定をする必要があります。これは必須です。今回の検証では、東京リージョンを選択して「Default_CloudWatch_Alarms_Topic」を指定しました。
ここまで設定を終えたら、画面下にある「設定」をクリックします。以下に示す画像のように、設定済チャネルとして表示されればOKです。
対応プラン設定と検証
最後に、Incident Managerの対応プラン側でチャットチャネルの設定を行います。
対応プランの編集画面で「チャットチャネル」欄まで移動し、作成したSlackチャネルを指定します。また、チャットチャネルのSNSトピックとして「Default_CloudWatch_Alarms_Topic」を指定し、編集を完了します。
ここまでで設定作業は完了です。実際にインシデントを起こして、Slackに通知されるか検証してみましょう。
実際にSlackに通知された結果がこちらです。
見事、Slackに通知することができました。
さいごに
今回は「AWS Systems Managerフル攻略マニュアル」の第４回ということで、Incident Managerの実践的な内容を検証したうえで説明してみました。
今回説明した内容以外にも、Incident Managerには便利な機能が用意されています。GUI操作で簡単にインシデントへの対応を実施でき、複雑な設定等なく様々な機能が扱えるのは嬉しいですね。必要なロールや分析テンプレートなども標準で用意されていて使い易いです。
インシデント管理を導入していない現場には、ぜひこの記事を読んでいただいたことをきっかけに導入をしてみませんか。既にインシデント管理をしている方も、Incident Managerを取り入れることでより効率的かつ質の高いインシデント管理を実施できる可能性があります。是非とも参考にされてください。
この記事をシェア
