2021/5/11 にリリースされた「Incident Manager from AWS Systems Manager」の紹介です。
AWS上のシステムを運用する立場として気になるこのサービス、どんな内容か見てみました。

情報は、2021年6月時点のものです。

はじめに

Incident Manager について

Incident Manager は1995年のAmazon.com立ち上げ以来の、主要インシデント管理チームの経験を活かして作られたサービスとのことです。

このサービスが 2021/6 時点で提供している主な機能は以下になります。

インシデント対応の対応、エスカレーション先を定義できます。
インシデント対応時の対応経緯を記録できます。
対応後、分析を目的としたヒアリングテンプレートをつけることができます。

背景についてより詳しく知りたい方は、公式ブログをご参照ください。

AWS Systems Manager の新機能である Incident Manager で IT インシデントを迅速に解決

所感

いいところ

簡単に、障害の起票、発生通知する仕組みを作れる。電話もあり。
障害後のふりかえり用のテンプレートも設定できる。

注意点

1定義(対応プラン) 7 USD/月なので、パターンを絞る形にしないと導入説得には悩むかもしれない。
インシデントの一括操作はできなそう。1日に何十もインシデントを出してる環境だと、見切れないかもしれない。

この記事で話すこと

簡単な利用イメージを紹介します。
初期セットアップの流れと気になりごとを紹介します。

利用の大まかな流れ

さっと触ってみた感触での使い方のイメージです。

対応編

連絡先設定に従って、連絡を受ける
インシデントに対応を記録する
インシデントをクローズする
クローズしたインシデントを分析する

設定編

インシデントが発生するリージョンを含むレプリケーションセットを作成
どこに、どういう手段(メール、SMS、電話)で連絡するかを定義
対応プランに連絡先と、指示、ランブックを記述する
CloudWatch Alarm, EventBridge に対応プランを関連づける

Incident Manager の料金

気になるお値段です。
2021/6 時点、対応プランごとに月額 7 USD だそうです。(インシデント通知100件まで)

そのほか、CloudWatch や Automation の値段は、設定内容に応じて追加でかかります。

AWS Systems Manager の料金

対応プランをフローと捉えたとき、「1フローごとに月額 7 USD」となると、何でもかんでも細かくフローを分けるのは厳しいかもしれないですね。

Incident Manager を使ったインシデント対応

インシデントの登録

インシデントの登録方法は、いくつかあります。

Incident Manager の画面から作成
CloudWatch Alarm のアクションで指定する
EventBridgeのターゲットに指定する

CloudWatch Alarm であれば、以下のように対応プランを選びます。
(表現上、CloudWatch Alarm では「レスポンスプラン」になってます)

EventBridgeでは内部仕様の都合？なのか「Operahouse インシデント」で指定できました。

IncidentManagerの画面であれば、トップに作成ボタンがあります。
これがあることで、監視設定で検知できなかったインシデントも登録できますね。

インシデントが発生すると、トップにインシデントが並びます。

インシデントが多すぎると、このパネルがたくさん並びます。
今時点、一括選択などもできないので、1つずつの対応で追いつける量のインシデント数になっていることが利用条件になりそうです。

インシデントを開くと、詳細が見れます。
インシデント対応の記述は、後述の「対応プラン作成」でデフォルト表示内容を markdown でかけます。
最初は、簡単なTODOを書いておくところから始めると便利そうですね。

「タイムライン」タブから、対応内容を登録することもできます。

インシデントが解消したら、左上の「インシデントを解決」を押して終了です。

インシデント解決後の分析

インシデントを解決したのち、「その時の対応がどうだったか」のヒアリングがあります。

インシデント解決後、「分析を作成」を選ぶと回答できます。

分析内容は、標準でAmazon所有のものが提示されます。

標準では、以下が問われます。ざっくり訳です。

Detection (検知、より効果的にインシデントに気づくには？)
1. 検知時間は短縮できる？半分にできる？
2. 検知するメトリクスに工夫要素はある？
3. 検知するアラームに工夫する要素はある？
Diagnosis (診断、より効果的にインシデント対応するには？)
1. 調査時間は短縮できる？半分にできる？
2. 連絡先を適正にし、連絡を早くする必要はある？
Mitigation (軽減策、MTTR短縮など)
1. 復旧までの時間は短縮できる？半分にできる？
2. 復旧のランブックは改善できる？不要な手順や、手助けが必要なものはなかった？
Prevention (防止策)
1. 問題の 5 whys をしてみよう。
2. ほかに学びはある？

自作することもできるみたいです。
https://docs.aws.amazon.com/incident-manager/latest/userguide/analysis.html#analysis-templates

セットアップの概要

初期セットアップでは、以下のような準備ステップを提案されます。

リソース	概要
レプリケーションセット	「全般設定」で作ります。
連絡先	インシデント発生の通知先です。SMS, メール、音声から選択します。
エスカレーションプラン	時間経過とあわせ、どの連絡先に連絡するかを定義します。
対応プラン	インシデント発生時の対応テンプレートを定義します。 CloudWatchアラームなどに関連付けできます。インシデント発生時の連絡先や、対応ランブックの関連づけも行えます。

レプリケーションセットの作成

Incident Manager のサーバを配置するイメージです。
以下の2つを指定します。

配置するリージョン (メインと、レプリケーション先)
暗号化方法 (AWS所有 KMSキー or 既存の KMS キー)

作ってみたとき、メインに指定した東京リージョンh東京リージョンは 2~3分で完成しましたが、
レプリケーション先(シドニーを指定) は 10分くらいかかりました。

⚠️注意です。

CloudWatch Alarm からインシデント登録する際、ここでレプリケート先指定したリージョンでしかインシデントをあげられません。
- しかし、リージョン数も上限3つです。ここは利用上の制約になるでしょう。
- Replication sets per account は1. Global でレプリケーションセットも1つしか作れません。リージョンで独立してインシデント管理、というのもできません。
メインリージョンは、今時点後から変えられなそうです。(GUIだと無理。CLIもそれを意図したコマンドは見当たらない)

なお、上で書きましたとおりレプリケーションのグループはグローバル一意です。
最終的なインシデント一覧を出しますが、以下の通り「どこで発生した」は意識されません。あくまで「レプリケーション」ですね。
(以下の例では、「sns-api-call」は東京、「list-sns-alert-sydney」はシドニーで発生したアラーム)

参考まで、CLI でレプリケーションセットの情報を取ると以下のようになります。

{
    "replicationSet": {
        "createdBy": "arn:aws:iam::xxxxxxxxxxxx:root",
        "createdTime": "2021-06-14T08:33:44.920000+00:00",
        "deletionProtected": false,
        "lastModifiedBy": "arn:aws:iam::xxxxxxxxxxxx:root",
        "lastModifiedTime": "2021-06-14T08:33:44.920000+00:00",
        "regionMap": {
            "ap-northeast-1": {
                "sseKmsKeyId": "DefaultKey",
                "status": "ACTIVE"
            },
            "ap-southeast-2": {
                "sseKmsKeyId": "DefaultKey",
                "status": "ACTIVE",
                "statusMessage": "Tagging inaccessible"
            }
        },
        "status": "ACTIVE"
    }
}

連絡先の作成

問題発生時の連絡先を定義します。
連絡先は、クォータ情報をみる限り 1,000 まで作れるようです。(試してない)

連絡先には、以下の情報を含めます。

項目	説明
名前	表示名として捉えたら良いと思います。
一意のエイリアス	IDとして捉えたら良いと思います。
連絡先チャネル	連絡先への連絡方法を定義します。音声、Eメール、SMSから選択します。チャネル名を指定し、複数設定できます。
エンゲージメントプラン	実際の連絡方法です。0分経過でメール、5分経過で電話のように指定できます。

Eメールの場合はメールアドレス、SMS, 音声をした場合は電話番号を指定します。
(070-1234-5678 の場合、+817012345678 のように指定)

連絡先チャネルを設定すると、それぞれにアクティベーションコードが送られます。
電話の場合は急に英語の電話がかかってくるので、登録する人に事前に案内しておいた方が良いでしょう。(英語で、番号を伝達されます)

Welcome to AWS Systems Manager Incident Manager.
Your contact channel is being created. 
Please go to the Console at https://console.aws.amazon.com/systems-manager/incidents/home 
to activate the contact channel with activation code 123456. 
Configure / opt-out this contact channel in the Console.

エンゲージメントプランにて、連絡先チャネルを使うタイミングを指定します。

エスカレーションプラン

問題発生時の連絡順序を定義します。

エスカレーションプランには、以下の情報を含めます。

項目	説明
名前	表示名として捉えたら良いと思います。
エイリアス	IDとして捉えたら良いと思います。
ステージ	連絡順序を定義します。

ステージは最大5つ、1ステージあたり 10の連絡先が定義できます。¹
ステージを複数定義すると、「ステージの期間」で次のステージまでの時間が指定できるようになります。

対応プラン

ようやく、メインとなる対応プランです。

対応プランは、6つのセクションで定義を行います。

項目	説明
対応プランの詳細	対応プランの表示名を設定します。
インシデント作成の詳細	インシデントのデフォルトタイトル、影響、概要情報、重複排除文字列を定義します。
チャットチャネル	Slack, Chimeとの連携ができます。
エンゲージメント	エスカレーションプラン、または連絡先を指定し、インシデント通知先を定義します。
ランブック	エスカレーションプラン、または連絡先を指定し、インシデント通知先を定義します。
タグ	エスカレーションプラン、または連絡先を指定し、インシデント通知先を定義します。

必須は対応プランの詳細と、インシデント作成の詳細のみです。

「インシデント作成の詳細」では、起票されるインシデントの雛形が定義できます。

この定義により、実際以下のようにインシデントが起票されます。
(CloudWatch Alarm から起票した例)

エンゲージメントを設定しないと、インシデント発生が通知されないのでご注意ください。

先程の対応プラン、CLIで取得したものです。

{
    "actions": [],
    "arn": "arn:aws:ssm-incidents::123456789012:response-plan/Plan1",
    "displayName": "プラン1",
    "engagements": [
        "arn:aws:ssm-contacts:ap-northeast-1:123456789012:contact/esc-plan"
    ],
    "incidentTemplate": {
        "impact": 3,
        "summary": "## インシデントの対応\n\n- 何かやる",
        "title": "インシデントのタイトル"
    },
    "name": "Plan1"
}

ここまで設定すれば、インシデント対応が開始できます。

なお、レプリケーションセットと対応プランのみ CloudFormation対応です。

最後に

Incident Manager の使い勝手について書いてまいりました。
今まで、障害管理のためにインシデント管理ツールを立ち上げたり、
電話エスカレーションのためにConnect構築やら人員を雇うやらしたり。。。というのが解消されました。

ある程度インシデント対応が落ち着いていることは条件になりますが、
運用フェーズをお手軽に始めるのにいいサービスなのは間違い無いですね。

最初は Markdown で対応の箇条書きをしておいて、
インシデント内容を見てサービス側に自動復旧を仕込むか、Runbookに対応処理を仕込むかを選んでいくのかなと思います。

Stages per plan = 5, Contact channels per stage = 10 Incident Manager service quotas ↩