どうしても語りたい AWS Systems Manager の魅力 ! ~ 第 4 回 こんなに簡単にインシデント通知ができるなんて !

瀧田
いや〜上野さん。 AWS Systems Manager って普段のシステム運用で活用できるシーンこんなにあるなんて想像以上でした !
最後に・・・もう一つだけシステム運用で困っていることがあるのですが相談しても良いですか ?

上野
もうここまでくれば何でも聞いてください !

瀧田
ありがとうございます！それでは早速・・・。
おかげさまで運用自動化の理解は進んだのですが、どうしても予想外のトラブルって起きちゃうんですよね。
なので重要なインシデントが起きたら、すぐに気づいて対応したいんですよ。

上野
私も運用していたので分かります。
インシデントによってはどうしても人手で確認して復旧作業が必要になるケースもありますよね。

瀧田
そうなんです！
以前、重要なシステムを運用していたときの話なのですが、インシデント発生時には監視センターの方に人手で電話連絡をしてもらっていたんです。最初に誰に連絡してほしい、このインシデントのときはこちらの部署に電話してほしいなどを Excel で管理していて結構大変だったんです。
その後効率化しようと思って自動化にチャレンジしたのですがプログラムで実装しようとすると処理が複雑で断念したことがありまして。
これって例のごとく Systems Manager でなんとかなったりしませんか・・・?

上野
そうですね！
もしかしたら Systems Manager の一機能である Incident Manager ならできちゃうかもしれません !

瀧田
やっぱり !! 早く・・・! 早く教えてください !! 上野さん !!!

上野
ちょっと落ち着いてください ! (笑)
まず、 Incident Manager とは何かを簡単にお伝えしますね。

上野
Incident Manager とはインシデントの解決、影響を軽減するまでの時間を短縮させるための機能となっていまして、全体図は以下のようになっています。インシデントの解決のためにあらかじめ設定した処理を自動で実行したり、電話だけではなくチャットや SNS で通知したりできるサービスです。

瀧田
まさにほしい機能がありそうですね！

上野
はい！
とはいえもう少し先ほどの「当時の複雑で断念した」という部分を教えていただけますか ?

瀧田
はい！ありがとうございます !
実は平日日中帯は普段運用しているメンバー全員が同じオフィスのフロアにいたので、インシデントが起きたときには代表電話に電話をかけるだけで良かったのですが・・・。
定時後や休日はインシデントの内容に応じてアプリとインフラを担当している運用者で分けたりしたり、ずっと同じ担当者にならないように月でシフト決めて組んでたりしました。また深夜帯は電話がかかってきてもうっかり寝ちゃっていることもあったので、A さんが電話に出なかったら B さんにかけるなどもやっていたんです。このあたりを実装するのが難しくて。

上野
システム運用の苦労が伝わってきますね。
瀧田さんのやりたいことは

• インシデントの内容に応じて任意の連絡先に電話連絡ができること。

• 輪番コールのように連絡先の応答有無に応じて次の連絡先へ連絡ができること。

• インシデント発生時の連絡先ローテーションやスケジュールでシフトを組めること。

と理解しました !
Incident Manager で実現できると思います !
せっかくなので一緒にそれぞれ設定してみましょう !

瀧田
ありがとうございます ! ぜひお願いします !

上野
まずは単純なユースケースとして、特定のインシデントが発生したときに電話連絡をやってみましょう !
Incident Manager の画面から連絡先(コンタクト) を設定して、連絡する順番 (エスカレーションプラン) を決めて、実際にインシデントが発生したときの対応方法 (対応プラン) を設定するだけでできちゃいます !
意外と画面を見るだけでもできちゃうので騙されたと思ってやってみてください !

瀧田
(ホントかな ?) やってみます !

瀧田
まずは連絡先 (コンタクト) を設定して・・・E メール、SMS、音声 (電話) から選択できるんですね !

上野
はい ! 一つの連絡先に複数の連絡手段を登録することができて、例えば、画面上のコンタクトチャネルで E メール、SMS 、音声 (電話) を登録することができます。

瀧田
ありがとうございます！連絡先として、連絡手段 (コンタクトチャネル) に私の SMS と音声 (電話) を登録してみますね。

瀧田
え・・・ ! なんか電話がかかってきました !

上野
連絡先をアクティベーションするコードを音声で教えてくれるので出てみてください !

瀧田
ピッ！と・・・activation code XXXXX.
これを入れれば良いんですね !
これってどの電話番号からかかってくるって事前にわからないのでしょうか ?

上野
安心してください !
Incident Manager からの SMS 通知または音声通知において、通知元が Incident Manager であることを確認するために、vcfファイルが公開されている ので電話帳に登録しておくと良いですよ !

瀧田
ありがとございます !

上野
次は連絡する順番のエスカレーションプランを設定しましょう !

瀧田
このエスカレーションプランってどういった機能でしょうか ?

上野
エスカレーションプランとは、連絡する順番を制御できる機能です。
エスカレーションプランの中でステージを分けることで、最初の連絡先は A さん、5 分間応答がなかったら B さんへと次の連絡先に連絡することが可能です。
もちろん連絡先が一つでも設定できますよ !

瀧田
ありがとございます ! 先ほど登録した連絡先を登録してみますね。よしっと。

上野
最後に対応プランを設定しましょう ! 対応プランとは、実際にインシデントが発生したとき何をしてほしいかの対応方法を設定できます。

瀧田
最後に対応プランを設定すると。影響度合いや概要などを設定できるんですね。

上野
そうですね。インシデントの影響に合わせて適切に設定しておくことで運用担当者が優先順位の判断に役立てることができます。

瀧田
先ほど設定した、エスカレーションプランを設定して・・・あれ ? チャットチャネルを設定するオプションもありますね。これってもしかして Slack にも通知できたりするのでしょうか ?

上野
そのとおりです ! AWS Chatbot と連携することで Slack や Teams に連携することができて、例えばチームメンバーの方が Slack でインシデントのステータスを確認できたりするので実用的なんですよ !

瀧田
めっちゃ便利じゃないですか !

瀧田
ランブックを設定できるオプションもありますね ! これはもしかして 第 1 回目 で紹介したやつですよね ? もしかしてインシデント発生時に自動化した処理を実行してくれたりするのでしょうか ?

上野
さすが瀧田さん ! 鋭いですね〜 ! インシデント対応に必要な処理をステップとして定義することで、インシデント対応時間の短縮に役立てることができますね！

瀧田
これも便利ですね ! 必ず確認したいコマンドは決まっていたりするのでこれは助かります。

瀧田
ここまで設定したのですが、実際のインシデントに対してはどのように設定すればよいのでしょうか ? 例えば Amazon EC2 が停止してしまった時の場合に通知させたいです！

上野
はい ! インシデントは Amazon CloudWatch の Alarm アクションや Amazon EventBridge のルールから設定することができます。

瀧田
なるほど。CloudWatch の Alarm アクションが使えるならプロセスの停止や任意のログなども通知のトリガーにできますね。今回は EC2 の停止を検知したいので、EC2 の状態変化取得できる EventBridge を使ってみますね。

瀧田
EventBridge のルールから任意の EC2 インスタンスのステータスが stopped に状態変化したことを設定して・・・

瀧田
ターゲットを選択のプルダウンで Incident Manager レスポンスプランを選択すると・・・先ほど設定した対応プランが出てきますね ! それを設定してルールの作成っと。

上野
これで設定は完了です ! 試しにイベントを設定した EC2 インスタンスを停止してみましょう !

瀧田
やってみますね ! EC2 インスタンスを停止っと。

瀧田
おお ! 電話かかってきました !! すごい ! プログラムも書かずにできちゃいました !! まだ設定し始めてから 10 分くらいしかたっていません !

上野
イケてますよね ! 今度は Incident Manager の画面を開いてみましょう !

瀧田
はい ! これはもしかして・・・

上野
はい ! インシデントが発生してからのタイムラインを表示してくれるので発生してから何が起こっているかが一目で確認することができるんです !

上野
インシデントの通知を受けたらエンゲージメントというタブから応答したよということを示すために承認登録をしましょう！電話連絡の場合は、電話越しに「1」のダイヤルを押すだけで OK です ! 承認登録することで、輪番コールのように順番に複数の連絡先へ連絡を行う設定をしていた場合、途中で停止することができます。

瀧田
ちなみに、インシデントによっては複数回同じエラーが出たりするんですけど、その場合って何度も連絡が来ちゃうのでしょうか？深夜とかずっと電話が鳴りっぱなしなのは嫌だなぁと・・・。

上野
良い質問ですね ! 実は同じインシデントイベントの場合、インシデントがオープン中は同じインシデントに集約されます !試しにもう一度イベントを設定した EC2 インスタンスをもう一度停止してみてください。

瀧田
やってみます ! 先ほどと違って電話は・・・かかってこないですね。

上野
タイムラインを見てください。EventBridge ルールに一致したというのが再度出ていますよね。こんな感じでまとめて管理してくれているのが分かります。

瀧田
この機能は嬉しいですね。深夜に電話地獄にならなくてすみます・・・。

上野
対応が完了してインシデントが解決したら、インシデントを解決を選びましょう ! 解決後に同様のインシデントが発生した場合はもちろん通知が届きます。

上野
基本的な機能はこんなところでしょうか。改めて実現したことを振り返ってみると・・・

上野
こちらは先ほど設定した連絡先や対応プランを複数用意しておくことで、インシデントの内容に応じて連絡先を分けることができます !

瀧田
はい ! 先ほどと同じように設定すれば良いですね !

上野
こちらはエスカレーションプランの中でステージを分けることで実現可能です !

瀧田
この機能は便利ですよね。指定した時間を過ぎても応答していなければ次の連絡先へ連絡するというのはシンプルで分かりやすいです !

上野
こちらはオンコールスケジュールを利用することで実現可能です ! 以下のスライドのようにローテーションを組みながらシフトを繰り返す頻度を設定することができます。もちろん設定次第で、平日日中帯は A さんへ、定時後は B さんへといったこともできますよ !

瀧田
当時できなかったことがプログラムも書かずにできちゃうんですね !
実はずっと心残りだったので・・・ちょっと感動しています。

上野
お役に立てて良かったです !
Incident Manager は他にも複数の AWS アカウントを管理できるクロスアカウント対応ができたり、他の製品・サービスとの統合できたりする機能もあるので詳しくはこちらを見てくださいね。

・AWS Black Belt Online Seminar - AWS Systems Manager Incident Manager 編

瀧田
ありがとうございます !
上野さん ! 今度は・・・

上野
何でも聞いてください !
(これは日が暮れそうだ・・・)