AWS Systems Manager Incident Manager によるインシデント対応の実践について

富士通株式会社 パブリック＆ヘルスケア事業本部　小沼 真実

# はじめに
AWS環境に構築したシステムを安全かつスケーラブルに運用管理するためには、マネージドサービスである **AWS Systems Manager**（以降、**SSM** とする）を使いこなす必要があります。
SSM と一言で言っても、その中には多種多様なサービスが存在するため、AWS 環境のシステムを安全かつスケーラブルに運用するためのコックピットとして、目的ごとに使い分けていく必要があります。
本記事では、その SSM の中でもAWS上で発生したインシデントを記録・管理するための **Incident Manager** について、設定時の留意点やインシデント対応の実践などを解説します。

# 目次
　1. [背景](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#1-%E8%83%8C%E6%99%AF)
　2. [SSMサービスの種類](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#2-ssm-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E7%A8%AE%E9%A1%9E)
　3. [Incident Managerとは？](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#3-incident-manager-%E3%81%A8%E3%81%AF)
　4. [Incident Manager の設定](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#4-incident-manager-%E3%81%AE%E8%A8%AD%E5%AE%9A)
　5. [Slack連携の場合](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#5-slack-%E9%80%A3%E6%90%BA%E3%81%AE%E5%A0%B4%E5%90%88)
　6. [Teams連携の場合](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#6-teams-%E9%80%A3%E6%90%BA%E3%81%AE%E5%A0%B4%E5%90%88)
　7. [インシデント対応の実践](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#7-%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E5%AF%BE%E5%BF%9C%E3%81%AE%E5%AE%9F%E8%B7%B5)
　8. [Incident Manager 料金](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#8-incident-manager-%E6%96%99%E9%87%91)
　9. [まとめ](https://qiita.com/Masami_Konuma/items/1bb0d50eec323c693f78#9-%E3%81%BE%E3%81%A8%E3%82%81)

# 1. 背景
デジタル庁が公開している「**政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針**」（※）において、「クラウドスマート」という方針のもと、クラウド環境特有の技術として「**マネージドサービス**」と「**IaC (Infrastructure as Code)**」を活用することが求められています。
公共系のシステムをAWS環境に移行する場合など、運用管理向けマネージドサービスの中心である SSM を使いこなすことで、この方針に従うことが可能となります。そこで、まずは SSM にどんなサービスがあるのかを理解するために、以降の章で解説します。

※ [政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針](https://www.digital.go.jp/resources/standard_guidelines/)　2022/12
　「政府情報システムのシステム方式について、クラウドサービスの採用をデフォルト（第一候補）としつつ、単にクラウドを利用するのではなく、クラウドを適切（スマート）に利用するための考え方等を示した標準ガイドライン附属文書」

# 2. SSM サービスの種類
頭に **SSM** の名称を冠したAWSの各種サービスについて、改めて以下の表に整理します。
　[AWS Systems Manager とは?](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/what-is-systems-manager.html)

|№|カテゴリ|サービス名|概要|
|:---:|----|----|----|
|1|運用管理|Explorer|AWSリソースに関するオペレーションダッシュボード|
|2||OpsCenter|運用作業項目を一元的に表示、調査、解決できる機能|
|3||**Incident Manager**|**インシデント発生から、復旧、分析まで効率的に管理**|
|4|アプリケーション管理|Application Manager|アプリに関するAWSリソースの問題、調査、修正管理|
|5||App Config|アプリ設定や機能フラグを作成、管理、デプロイする|
|6||Parameter Store|設定データ管理と機密管理のための安全な階層型ストレージ|
|7|変更管理|Change Manager|運用上の変更要求、承認、実装、レポート作成するフレームワーク|
|8||Automation|メンテナンスとデプロイでの一般的なタスクを自動化|
|9||Change Calendar|指定したアクションの実行可否を制御するカレンダー|
|10||Maintenance Window|パッチや更新プログラムのインストールなど、管理タスクを実行する定期的なスケジュールを設定|
|11|ノード管理|Fleet Manager|統合されたUI エクスペリエンス、ノードをリモート管理|
|12||Compliance|パッチコンプライアンスと設定の整合性を検出する|
|13||Inventory|ソフトウェアインベントリの収集プロセスを自動化|
|14||Session Manager|AWS CLI などを介してブラウザ ベースで EC2を管理|
|15||Run Command|マネージドノードの設定をリモートから安全に大規模管理|
|16||State Manager|マネージドノードの定義を維持するためのプロセス自動化|
|17||Patch Manager|マネージドノードにパッチ適用するプロセスを自動化|
|18||Distributor|デプロイパッケージを作成してマネージドノードに展開|
|19|共有リソース|Document|SSM が実行する操作を定義したドキュメント|

![SSMサービスの種類.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620338/da620ed8-3f19-03da-7788-1a2fe257ffd8.jpeg)

# 3. Incident Manager とは？
インシデントとは、そもそもサービスにおける計画外の中断やサービス品質の低下をもたらすものになります。**Incident Manager** は、そのインシデントを検知してから、調査、対応、解決、分析するまでの作業を効率化し、影響を軽減するため役立つサービスになります。

|№|Incident Manager 機能|詳細|
|:---:|----|----|
|1|連絡先|・インシデント発生時の連絡先|<br>・E メール、 SMS 、音声 電話 による連絡が可能|
|2|エスカレーションプラン|・エスカレーションパス<br>・輪番コールのように連絡先の応答有無に応じて次の連絡先へ連絡を行う|
|3|オンコールスケジュール|・インシデント時の連絡先ローテーションや連絡を行うスケジュールの設定<br>・日、週、月の単位でローテーションが可能|
|4|**Chatチャネル**|**・インシデントの更新と通知をChatチャネルに連携可能<br>・Slack 、 Teams 、 Chime に対応**|
|5|Runbook|・インシデント対応に必要な手順書の役割を持つ（手動ステップ）<br>・アプリケーションおよびインフラストラクチャタスクを自動化することも可能|
|6|対応プラン|・連絡先、エスカレーションプラン、オンコールスケジュール、Chatチャネル、 Runbook をまとめたもの<br>・インシデント発生時は関連する対応プランが呼び出される|

![Incident Manager 機能.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620338/791d3c0c-947b-e683-3d77-6b601713c946.jpeg)

# 4. Incident Manager の設定
**Incident Manager** は、SNSを経由して **AWS Chatbot** と連携し、**Slack**や**Teams**、Amazon Chimeに通知することが可能です。

:::note warn
設定時の注意点
AWS Organizationsのサービスコントロールポリシー（以降、**SCP** とする）により、セキュリティ上、通信及びデータを日本国内（東京リージョン、大阪リージョンのみ）に制限されている場合、AWS Chatbot への連携が制限に引っかかります。
:::

これは、AWS Chatbot が IAM や Route53、CloudTrail などと同様に、リージョンをまたがって世界で共通なサービスを提供するグローバルサービスとして定義されているためです。もし、この制限に引っかかった場合は、AWS Organizations の管理者に働きかけて利用許可を取得し、**SCPのルールを緩和してもらう**必要があります。

AWS Chatbot が使えなかった際の代替手段として、Slackのチャネルに設定したDM 用メールアドレスに対し、SNSを用いてSlackのチャネルに配信することは可能です。その場合は、Slackに配信されたメッセージから、AWSコンソールにログインすることなく直接承認するなど、**ChatOpsを用いた操作が実現できません。**

![Incident Manager 設定.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620338/63e60604-268e-2c8a-ff93-432bfcf35efe.jpeg)

# 5. Slack 連携の場合
**Incident Manager** からSNSを経由して AWS Chatbot と連携し、**Slack**に通知するという**ChatOps** を実現するためには、組織のSlack担当に確認し、接続リクエストを許可してもらった上で、以下の流れで設定することになります。

|№|ChatOps用Slackワークスペース設定手順|Slack|AWS|
|:---:|----|:---:|:---:|
|1|Slackでワークスペースの新規作成画面を開く。|○||
|2|ワークスペース名を入力し、「次へ」を押す。|○||
|3|プロフィール確認画面で、「次へ」を押す。|○||
|4|メンバーを追加し、「次へ」を押す。|○||
|5|チャネル名を入力し、「次へ」を押す。|○||
|6|「チャネル詳細を表示する」を押す。|○||
|7|「設定」タブより、チャネル設定をプライベートにする。|○||
|8|「チャネル情報」タブより、チャネルIDをコピーする。(後の作業で使用)|○||
|9|「インテグレーション」タブより、チャネルのメールアドレスをコピーする。|○||
|10|「インテグレーション」タブより、「アプリを追加する」を押す。|○||
|11|**「アプリを管理する」画面より、「Chatbot」の「インストール」を押す。AWSコンソール画面へリダイレクトされる。**|○||
|12|Chatbot設定画面より、「新しいクライアントを設定」を押す。||○|
|13|「Slack」を選択し、「設定」を押す。||○|
|14|権限の確認画面より、「許可する」を押す。||○|
|15|Chatbot設定画面より、「新しいチャネルを設定」を押す。||○|
|16|Slackチャネル設定画面より、設定名を入力する。||○|
|17|**Slackチャネル設定画面より、チャネルタイプ、チャネルIDを入力する。**||○|
|18|Slackチャネル設定画面より、チャネルロールを指定する。||○|
|19|Slackチャネル設定画面より、ガードレールを指定する。||○|
|20|Slackチャネル設定画面より、SNSトピックを指定する。||○|
|21|Chatbot設定画面より、チャネルが登録されたことを確認する。||○|
|22|Slackのワークスペース画面下部の「App」に、「aws」が登録されたことを確認する。|○||
|23|**Slackのチャネル詳細「インテグレーション」に、「aws」が登録されたことを確認する。**|○||
|24|AWSコンソールへのログイン後、Chatbotから「Slack」を選択する。登録しているチャネルを選択し、「ユーザロール」タブより「編集」を選択する。|○|
|25|**ユーザロールの編集画面が開く。ユーザロールで「****-Chatbot-role」を選択し、「保存」を選択する。**||○|
|26|ワークスペースが設定対象のものを選択し、「許可する」を選択する。|○|
|27|AWSコンソールへリダイレクトされ、正常に設定されたことを示すメッセージが表示される。|○|

![Slack連携.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620338/cba2bbee-c74b-cfaf-b45b-15bdcae01429.jpeg)

# 6. Teams 連携の場合
**Incident Manager** からSNSを経由して AWS Chatbot と連携し、**Teams**に通知するという場合、基本的に上記と同様の流れで設定できます。なお、組織のセキュリティポリシーにより、ワークスペースに対してAWSアプリを追加できないことがあるため、注意してください。

■Teams設定時における管理者の権限
　[AWS Chatbot が Microsoft Teams で利用可能に](https://aws.amazon.com/jp/blogs/news/aws-chatbot-now-integrates-with-microsoft-teams-2/)
■Teamsへのアプリケーション追加の制限について
　[Teams 管理センターでのアプリ管理とガバナンスの概要](https://learn.microsoft.com/ja-jp/microsoftteams/manage-apps#allow-and-block-apps)
　[アプリのアクセス許可ポリシーを使用してアプリへのユーザー アクセスを制御する](https://learn.microsoft.com/ja-jp/microsoftteams/teams-app-permission-policies)

:::note info
**Teams**と**Slack**の**ChatOps**操作の違いについて、AWSサポートに確認した結果、軽微な違いはあるかも知れませんが、実行できるコマンドなどに差はないとのことです。
:::

# 7. インシデント対応の実践
顧客との連絡手段として、主にTeamsチャットを使用する前提で、実際に **Incident Manager** を用いて、インシデントを検知してから調査、対応までの運用シミュレーションした場合、以下のような流れになることが想定されます。

|№|顧客担当|運用担当|内容|対象|操作例|
|:---:|----|----|----|----|----|
|1|||運用担当者が定常時の運用監視を実施中である。|コマンド|EC2（Windowsの場合）で、以下のコマンドを実行し、イベントログを出力する。<br>EventCreate /L Application /T Information /SO “CreateEventTest” /ID 999 /D "【テスト】バッチ処理が異常終了しました。"|
|2||**監視**|**障害発生し、AWSからアラートメールが飛ぶ。**|**AWS**|**アラート通知が登録したメールアドレス宛に届いていることを確認する。**|
|3||**状況確認**|**AWSコンソール、環境へのリモート接続を行い、確認を開始する。**|**AWS**|**CloudWatchログから「wev-lgrp01」該当するイベントログを確認する。CloudWatchダッシュボード「wev-web-log-wrn-alarm」の状態を確認する。**|
|4||障害認知|障害の状況を認知する。||　|
|5|投稿(受)|投稿(送)|運用担当者がTeamsチャネルへ第１報を投稿する。|Teams|■影響<br>影響度：中<br>エスカレーションレベル：L1<br>■状況・利用者影響<br>EC2がハングアップ状態で、利用者へメールが送信されていません。<br>■依頼事項<br>インシデントを発行し、ご連絡します。|
|6|投稿(送)|投稿(受)|顧客担当者が運用担当者へ対応開始を連絡する。|Teams|「了解しました。」|
|7||**調査**|**インシデントを発行し、障害の調査対応を開始する。**|**AWS**|**Incident Manager よりインシデントを発行する。<br>概要：障害レベル、影響度を記載する。<br>関連項目：画像ファイルを添付する。**|
|8|　|対処検討|調査結果をもとに対処方法について検討する。|||
|9|投稿(受)|投稿(送)|運用担当者がTeamsチャネルへ対処方針を投稿する。|Teams|■影響<br>影響度：中<br>エスカレーションレベル：L1<br>■状況・利用者影響<br>EC2がハングアップ状態で、利用者へメールが送信されていません。<br>■依頼事項<br>EC2の再起動が必要となるため、以下の対処について、ご承認をお願います。<br>（１） EC2停止<br>（２） EC2起動<br>（３） 制御起動・動作確認<br>作業中は、対象業務が停止するため、関係部門へのご連絡をお願いします。|
|10|投稿(送)|投稿(受)|顧客担当者が運用担当者へ対処承認依頼を指示する。||「了解しました。承認依頼を出してください。」|
|11|**依頼(受)**|**依頼**|**運用担当者が Incident Manager から顧客担当者へ作業承認を依頼する。**|**AWS**|**対象のメールアドレスへ作業承認依頼を送信する。**|
|12|**承認**|**承認(受)**|**顧客担当者がメール本文の承認URLよりSlackで、作業承認する。**|**Slack**|**Slackより作業を承認する。**|
|13|投稿(受)|投稿(送)|運用担当者がTeamsチャネルへ対処開始を投稿する。|Teams|■影響<br>影響度：中<br>エスカレーションレベル：L1<br>■状況・利用者影響<br> （対処開始）<br>■依頼事項<br>随時ご連絡しますので、お待ちください。<br>(時間報告は●●：●●を予定)|
|14||**対処実施**|**運用担当者がRunbookからAutomationを実行し、対処を実施する。**|**AWS**|**RunbookからAutomationを実行し、EC2を再起動する。**|
|15|投稿(受)|投稿(送)|運用担当者が顧客担当者へ対処完了を連絡する。|Teams|■影響<br>影響度：中<br>エスカレーションレベル：L1<br>■状況・利用者影響<br> （対処完了）<br>■依頼事項<br>関係部門へのご連絡をお願いします。|
|16|投稿(送)|投稿(受)|顧客担当者が運用担当者へ対応完了を指示する。|Teams|「対処完了を確認しました。」|

![インシデント対応の実践.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620338/129dfa64-9d24-41fb-8eec-240d531a090b.jpeg)

# 8. Incident Manager 料金
**Incident Manager** の料金は、一か月単位で、アクティブな対応プランの数に基づいて課金されます。一か月あたり**最大 100 件の SMS または音声メッセージは無料**となっていますが、 それ以上に追加メッセージを送信したい場合、受信者の国に応じて課金されます。

|№|詳細|料金|
|----|----|----|
|1|対応プラン|対応プランごとに月額 7 USD|
|2|SMSおよび音声メッセージ|メッセージごと、SMS および 1 分間の音声メッセージの宛先国の料金に基づく<br>　[AWS Systems Manager country rates](https://aws.amazon.com/jp/systems-manager/pricing/country-rates/)|

# 9. まとめ
今回は SSM の中でも、特に **Incident Manager** に関してご紹介してきましたが、いかがでしょうか？
最初に述べましたが、AWS環境において効率的に運用管理するには、マネージドサービスである SSM を使いこなす必要があり、特に **Incident Manager** は、AWS上で発生したインシデントを効率的に記録・管理するための手段として、おススメします。

最後までお読みいただき、ありがとうございました。

# 参考文献
* [[AWS Black Belt Online Seminar] AWS Systems Manager 資料及び QA 公開](https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-systems-manager-2020/)　2020/2
* [2023年4月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 AWS Systems Manager Incident Manager 編](https://aws.amazon.com/jp/blogs/news/2023-04-aws-blackbelt/)　2023/4