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

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