Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Incident Managerでインシデント発生時のエスカレーションを自動化する

Incident Managerでインシデント発生時のエスカレーションを自動化する

taiko19xx

June 14, 2022
Tweet

More Decks by taiko19xx

Other Decks in Technology

Transcript

  1. JAWS-UG GameTech #1 2022/06/14
    木村俊彦 / 株式会社インフィニットループ
    Incident Managerで
    インシデント発生時の
    エスカレーションを自動化する

    View Slide

  2. ● Incident Managerをエスカレーション目的で利用・運用しています
    ● 導入に至った経緯
    ● 検証してわかったこと
    ● 等々お話します
    本日の内容

    View Slide

  3. ● 導入の経緯
    ● 実際に構築
    ● 運用前検証
    ● まとめ
    目次

    View Slide

  4. 導入の経緯

    View Slide

  5. ● 新規構築時にエスカレーションの管理について検討
    ● 「連絡がつかない場合」のエスカレーションをどうするか
    ○ 特に休日や夜中など
    ● 可能な限りAWS内で完結できないか検討
    経緯

    View Slide

  6. View Slide

  7. ● 本来はコンタクトセンターの構築運用向け
    ● 「問い合わせフロー」と、それを起動するLambdaの組み合わせで検討
    ● 電話番号の利用料+発信料金と料金もシンプル
    ● 日本の携帯電話番号(090/080/070)への発信は制限解除申請が必要
    Amazon Connect

    View Slide

  8. フローやLambdaを構築し検証

    View Slide

  9. しかし...

    View Slide

  10. ● エスカレーションの各種管理をどうするかの設計が必要
    ○ 順番、発信済みかどうかの管理、受諾したかどうかのチェック
    ● 電話番号どこに保持するかの検討が必要
    ○ メンバーの入れ替え時に番号も入れ替えが必要
    ● 管理するリソースが多いのではないかという疑問
    ○ フロー、Lambda、それら付随する様々
    ○ 特にLambdaはメンテナンス性を考慮する必要がある
    検証してわかったこと

    View Slide

  11. View Slide

  12. ● 正確には AWS Systems Manager Incident Manager
    ○ Systems Manager内のサービス
    ● インシデントの起票や管理、呼び出し(エスカレーション)を行ってくれる
    サービス
    ○ CloudWatch Alermと組み合わせれば自動化できる
    ● SlackやAmazon Chimeとも連動
    ● 対応プランの数に応じて課金
    ○ インシデント起票時のテンプレートのようなもの
    Incident Manager

    View Slide

  13. View Slide

  14. ● エスカレーション開始時に、「誰に」「どの方法で」「どの間隔で」通知する
    か設定できる
    ● 通知先はメール・SMS・通話
    ● 間隔やトータルの実行時間、件数はクォータの範囲内で設定
    エスカレーションプラン

    View Slide

  15. View Slide

  16. これで行こう!

    View Slide

  17. 構築する

    View Slide

  18. 初期の構成

    View Slide

  19. ● アラートはIncident ManagerとSlackへ送信
    ○ 回復通知はSlackのみ
    ● 事前設定した対応プランに沿ってインシデントが開始
    ● 対応プランに紐付けられた設定でエスカレーションも開始
    シンプルに設計

    View Slide

  20. そんなある日

    View Slide

  21. レベルによって調整したい

    別システムにも通知してほしい

    View Slide

  22. View Slide

  23. ● 基本的な構図は変わらず
    ● Alertからの橋渡しはEventBridge
    ● 1つめのLambdaはレベルの切り分け
    ○ EventBridgeから渡されたデータに基づいて判定
    ○ それを元に対応プランとエンゲージメントを起動
    ● 2つめのLambdaは別システムへの通知
    要望に合わせて改良

    View Slide

  24. 結局複雑なのでは...

    View Slide

  25. ● それぞれの処理はシンプル
    ○ メインロジックは30行以内
    ● 用途は異なるので、1つで済ませず、別々に構築
    Lambdaはシンプルに

    View Slide

  26. ● アラームとLambdaをルールで紐付けるのみ
    ● 入力トランスフォーマーでレベルを付与
    EventBridgeもシンプルに

    View Slide

  27. いざ検証

    View Slide

  28. ● Incident Managerからの通話は英語
    ● アクティベーションの確認番号は聞き取れる
    ● エスカレーション時の通話が辛い...
    ○ とにかく早口で長い
    ○ 通話中に「1」を押すと確認済みになり、「9」を押してしまうとリストから
    外されてしまう
    ○ 周知することで対処
    通話が英語

    View Slide

  29. ● もしくは非通知、番号は変わる場合もある
    ● いたずら電話と思われたり、拒否設定にしていると届かない可能性がある
    ○ 許容できない場合は、Amazon Connectが選択肢になる
    ● あらかじめ周知して対策
    ○ 最悪取らなくてもチャットは見てほしい
    電話の発信元がアメリカ

    View Slide

  30. View Slide

  31. ● いきなり電話は考え物
    ● 呼び出し時は最初メールで通知
    ○ エンゲージメントを承認するコードが記載されている
    ● それにも気づかれていないようであれば電話というフロー
    ○ 間隔は10分~15分後
    順番を考慮する

    View Slide

  32. View Slide

  33. ● こだわりが少なければシンプルな構成
    ○ 既存のアラートに埋め込める
    ○ こだわっても何とかなるはず
    ● 英語という壁こそありますが、乗り越えられれば最有力?
    ● 一連のフローについては定期的に訓練という形で検証を行い、問題ない
    ことを確認する予定
    ○ 肝心な時に動かないのでは意味がない
    ● ぜひ検証からはじめてみてはいかがでしょうか
    まとめ

    View Slide

  34. ● 木村俊彦 / @taiko19xx
    ● 株式会社インフィニットループ
    ● 主な業務
    ○ バックエンド構築(PHP/C#) / インフラ構築(AWS)
    ● 好きなゲーム
    ○ Civilization / Age of Empires / Rize of Nations etc…
    ● 好きなAWSのサービス
    ○ LambdaとDynamoDB
    自己紹介

    View Slide

  35. ありがとうございました

    View Slide