この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。
AWS 上でシステムを稼働させている皆様はどのようなインシデント管理を実装していますでしょうか。
SaaS 製品を活用されている方は多くいると思います。自己管理 (EC2 上) のソリューションを展開しているケースもあるかと思います。
また、複雑な要件が無い場合は CloudWatch と SNS で完結することもあると思います。
アメリカ時間の2021年5月10日 Incident Manager が発表されました。
Incident Manager を使用すると、CloudWatch Alarm や EventBrige Events から検出された様々な異常状態やイベントをインシデントとして管理することが可能になります。
執筆日 (2021/05/12) 時点の対応リージョンは以下です。
- バージニア北部
- オハイオ
- オレゴン
- アイルランド
- フランクフルト
- ストックホルム
- 東京
- シンガポール
- シドニー
Incident Manager の主な機能
対応プラン
インシデントを登録するためのテンプレートと考えると解りやすいと思います。
「ALB レスポンスタイムの低下」「EC2 インスタンスの CPU 使用率異常」など想定されるインシデントに対応するプランを作成しておきます。
Runbook と自動実行
インシデント発生時に予め準備しておいた Runbook を自動実行します。
Runbook は Systems Manager Automation ドキュメントを使用します。
特定のコマンドを実行する、EBS ボリュームを拡張する、リソースをスケールアップさせるといった復旧自動化を実現させます。
自動実行の他にも手動復旧のためのガイダンス・手順書を記述しておくことが可能です。
AWS が提供している AWSIncidents-CriticalIncidentRunbookTemplate というドキュメントでは
Triage → Diagnosis → Mitigation → Recovery という4つのステップに沿ってインシデントを解決するための手順が示されています。
これをカスタマイズして自社独自ガイダンスを作成することになると思います。
インシデントの追跡
Runbook を適切に設定しておくことでインシデントの追跡が可能です。
インシデントが登録された時間、対応を完了した時間に記録や、
上で例示した Triage → Diagnosis → Mitigation → Recovery のステップのうち、現在の対応状況はどこにあるか、
何時何分にステップを完了したのか等の追跡を行います。
任意の対応状況を追跡履歴に残すことも可能です。
エンゲージメントとエスカレーション
インシデント発生時の連絡先、エスカレーション先を設定します。
執筆日 (2021/05/12) 時点の連絡先は以下になります。
- Eメール
- SMS(ショートメール)
- 電話
最初の連絡先へ通知、設定した時間以内にインシデントの解決が無い場合は次の連絡先へエスカレーションします。
インシデントの確認があった場合でも特定時間経過後エスカレーションといった設定も可能です。
チャットチャンネル
AWS Chatbot を使用して予め Slack または Chime のチャンネルを設定しておきます。
インシデントが発生するとそのチャンネルに通知されます。
インシデント対応時はそのチャンネルを通じて対応者間のコミュニケーションを行います。
Slack には以下のような通知が行われます。
Incident Manager | Incident started | ap-northeast-1 | Account: xxxxxxxxxxxx
Incident title:
EC2_CPUUtil_Anomaly [CPU_Util_Anomaly]
Created by: CloudWatch Alarm
Alarm name: CPU_Util_Anomaly
Start time: 2021-05-12 01:01:28 UTC
Engaged: yoshiiクロスアカウント
AWS RAM (Resource Access Manager) を使用してクロスアカウントを実現します。
一つのインシデント管理アカウントと複数のアプリケーション実行アカウントといったイメージです。
やってみた
AWS マネジメントコンソール
マネジメントコンソールで Incident Manager を開きます。
初めてアクセスすると 準備 ボタンが表示されると思います。クリックします。
セットアップ
全般設計から セットアップ をクリックします。
規約に同意
利用規約をよく読んで同意します。
レプリケーションセット
リージョンダウンに備えてインシデントデータを複製しておきたいリージョンを選択します。
特に要件がなければ使っているリージョンだけで大丈夫です。
連絡先
セットアップが終わりましたら、左側ペインから 連絡先 をクリックします。
連絡先を作成 をクリックします。
連絡先の詳細
連絡先情報を入力します。
名前とエイリアスは任意の名称を入力します。
連絡先チャネル
連絡先チャンネルにインシデント発生時の連絡先を入力します。
電話番号は国番号 +81 を付与した形式で入力します。
連絡先入力後はアクティベーションを行います。
メールの場合は登録したメールアドレス宛にメールが届きますので、本文中のコードをマネジメントコンソールで入力します。
電話の場合は電話でコードが案内されます。英語の自動音声でそれなりに早口ですので頑張ってヒアリングします。
「h t t p s colon slash slash ...」後に6桁の数字が「One Nine Four ...」のような形で案内されますので、そのコードをマネジメントコンソールで入力します。
エンゲージメントプラン
エンゲージメント時間は、Incident Manager でインシデントを検知してから何分後に通知するかを指定します。
対応プランの作成
左側ペインから 対応プラン をクリックします。
対応プランを作成 をクリックします。
対応プランの詳細
名前と表示名を入力します。
判別しやすく一意な名称にします。
名前は以下である必要があります。
- 対応プラン名は 1～200 文字
- 有効な文字: A～Z、a～z、0～9、- (ハイフン)、_ (アンダースコア)。
インシデント作成の詳細
タイトルを入力します。
インシデント一覧に表示されるようになります。一意で識別容易な文字列にしましょう。
インシデントの影響度をリストから選択します。
概要をマークダウンで記述可能です。
インシデントが何を意味しているかを記述します。
チャットチャネル - オプション
障害対応時の関係者間連絡をするためのチャットチャンネルを指定します。
予め AWS Chatbot で設定しておきます。
エンゲージメント - オプション
前の手順 エンゲージメントプラン で設定した連絡先を指定します。
ランブック - オプション
手動のガイダンス、または、自動アクションを指定します。
何もアイデアが無い場合は AWS が提供しているテンプレートからランブックを複製しておくと便利かもしれません。
ランブックを指定する場合は IAM ロールの作成が必要です。
公式ドキュメント Response plans を参照してロールを作成ください。
CloudWatch Alarm の作成
今回は CloudWatch から Incident Manager へインシデント登録をしてみます。
手順は割愛します。
アラーム作成画面の途中で Systems Manager アクション を指定する箇所がありますので、こちらで対応プランを指定します。
テスト
今回は「EC2 CPU 使用率が50%を超えたら」という条件してみます。
テストなので意味が無いしきい値なのは見逃してください。
負荷かけ
得意の yes コマンドを打ちます。
$ yes >/dev/nullメトリクスの確認
CloudWatch Alarm 画面が以下です。
Incident Manager の確認
インシデントが登録されました。
メールの確認
登録しておいてメールアドレスには
件名「You have been engaged into Incident: EC2_CPUUtil_Anomaly [CPU_Util_Anomaly]」でメールが届いていました。
本文は「Please visit the Incident Manager Console to view detailed information.」なので詳細は判断できませんが
何かが起きていることは把握できます。
Slack 見るなりマネジメントコンソール見るなりは必要です。
電話の確認
登録して電話番号宛に英語の自動アナウンスで入電します。
こちらも詳細は伝えられないですが、AWS アカウント xxxxxxxxxxxx で何かが起きていることは把握できます。
Slack 見るなりマネジメントコンソール見るなりは必要です。
インシデントの解決と分析
インシデントを解決 ボタンをクリックするとステータスが「解決済み」になります。
インシデントは解決しただけでは不十分で、分析と改善策が必要です。
分析を開始 ボタンをクリックします。
分析
分析サマリー
分析結果やインパクトを簡潔に記述し、記録を残します。
まずはここから。
インシデントに関する質問
テンプレートで用意されている質問に回答します。
これにより改善策の精度が向上することを期待します。
改善策
アクションアイテムに改善策を記述しました。
タイムライン
対応履歴が時系列で表示されています。
12:59:14 にある「かくにん」は任意で挿入したイベントです。
ランブックのステップとあるのは AWS 提供のテンプレートです。
まとめ
いかがでしょうか。
Slack 等に通知することはしていても、通知後の対応や改善までをシステムで管理することは大変だと思います。
が、大変でも重要なことなので実施できる体制は整えておきたいところです。
Incident Manager を使って実現してみてください。
有償の SaaS 製品を導入するまでの規模ではないけど、インシデント管理や電話連絡はしてみたいという需要は満たせると思います。
参考
インシデントマネージャー ユーザーガイド
Resolve IT Incidents Faster with Incident Manager, a New Capability of AWS Systems Manager
以上、吉井 亮 がお届けしました。
2
