Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Incident Managerでインシデント発生時のエスカレーションを自動化する
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
taiko19xx
June 14, 2022
Technology
270
0
Share
Incident Managerでインシデント発生時のエスカレーションを自動化する
taiko19xx
June 14, 2022
More Decks by taiko19xx
See All by taiko19xx
Bedrockで遊ぼう! 短期間で色々開発してみた
taiko19xx
1
160
LambdaカスタムランタイムでPHPでもサーバーレス!
taiko19xx
0
86
IoTっぽいアプリをk3s+Raspberry Piで実行する
taiko19xx
0
360
ハニーポットから見たWebサーバへの攻撃
taiko19xx
0
3k
PHPなプロダクトをAmazon ECSで開発運用してる話
taiko19xx
0
1.3k
RaspberryPi+AWSでIoT(っぽ い)GPSロガーを作ってみた
taiko19xx
0
1.7k
PHPからWin32APIをいじってみた
taiko19xx
0
1.8k
Other Decks in Technology
See All in Technology
Discordでリモートポケカしてたら、なぜかDOを25分間動かせるようになった話
umireon
0
120
ふりかえりがなかった職能横断チームにふりかえりを導入してみて学んだこと 〜チームのふりかえりを「みんなで未来を考える場」にするプロローグ設計〜
masahiro1214shimokawa
0
340
サイバーフィジカル社会とは何か / What Is a Cyber-Physical Society?
ks91
PRO
0
160
LLM とプロンプトエンジニアリング/チューターを定義する / LLMs and Prompt Engineering, and Defining Tutors
ks91
PRO
0
330
さくらのAI Engineから始める クラウドネイティブ意識
melonps
0
140
AI前提とはどういうことか
daisuketakeda
0
180
Digitization部 紹介資料
sansan33
PRO
1
7.2k
プロダクトを育てるように生成AIによる開発プロセスを育てよう
kakehashi
PRO
1
930
「決め方」の渡し方 / How to hand over the "decision-making process"
pauli
8
1.3k
試されDATA SAPPORO [LT]Claude Codeで「ゆっくりデータ分析」
ishikawa_satoru
0
350
Kubernetes基盤における開発者体験 とセキュリティの両⽴ / Balancing developer experience and security in a Kubernetes-based environment
chmikata
0
240
プロンプトエンジニアリングを超えて:自由と統制のあいだでつくる Platform × Context Engineering
yuriemori
0
170
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
57
14k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
RailsConf 2023
tenderlove
30
1.4k
Balancing Empowerment & Direction
lara
5
1k
We Are The Robots
honzajavorek
0
210
The Limits of Empathy - UXLibs8
cassininazir
1
290
Speed Design
sergeychernyshev
33
1.6k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
450
Producing Creativity
orderedlist
PRO
348
40k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
100
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.2k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
410
Transcript
JAWS-UG GameTech #1 2022/06/14 木村俊彦 / 株式会社インフィニットループ Incident Managerで インシデント発生時の
エスカレーションを自動化する
• Incident Managerをエスカレーション目的で利用・運用しています • 導入に至った経緯 • 検証してわかったこと • 等々お話します 本日の内容
• 導入の経緯 • 実際に構築 • 運用前検証 • まとめ 目次
導入の経緯
• 新規構築時にエスカレーションの管理について検討 • 「連絡がつかない場合」のエスカレーションをどうするか ◦ 特に休日や夜中など • 可能な限りAWS内で完結できないか検討 経緯
None
• 本来はコンタクトセンターの構築運用向け • 「問い合わせフロー」と、それを起動するLambdaの組み合わせで検討 • 電話番号の利用料+発信料金と料金もシンプル • 日本の携帯電話番号(090/080/070)への発信は制限解除申請が必要 Amazon Connect
フローやLambdaを構築し検証
しかし...
• エスカレーションの各種管理をどうするかの設計が必要 ◦ 順番、発信済みかどうかの管理、受諾したかどうかのチェック • 電話番号どこに保持するかの検討が必要 ◦ メンバーの入れ替え時に番号も入れ替えが必要 • 管理するリソースが多いのではないかという疑問
◦ フロー、Lambda、それら付随する様々 ◦ 特にLambdaはメンテナンス性を考慮する必要がある 検証してわかったこと
None
• 正確には AWS Systems Manager Incident Manager ◦ Systems Manager内のサービス
• インシデントの起票や管理、呼び出し(エスカレーション)を行ってくれる サービス ◦ CloudWatch Alermと組み合わせれば自動化できる • SlackやAmazon Chimeとも連動 • 対応プランの数に応じて課金 ◦ インシデント起票時のテンプレートのようなもの Incident Manager
None
• エスカレーション開始時に、「誰に」「どの方法で」「どの間隔で」通知する か設定できる • 通知先はメール・SMS・通話 • 間隔やトータルの実行時間、件数はクォータの範囲内で設定 エスカレーションプラン
None
これで行こう!
構築する
初期の構成
• アラートはIncident ManagerとSlackへ送信 ◦ 回復通知はSlackのみ • 事前設定した対応プランに沿ってインシデントが開始 • 対応プランに紐付けられた設定でエスカレーションも開始 シンプルに設計
そんなある日
レベルによって調整したい + 別システムにも通知してほしい
None
• 基本的な構図は変わらず • Alertからの橋渡しはEventBridge • 1つめのLambdaはレベルの切り分け ◦ EventBridgeから渡されたデータに基づいて判定 ◦ それを元に対応プランとエンゲージメントを起動
• 2つめのLambdaは別システムへの通知 要望に合わせて改良
結局複雑なのでは...
• それぞれの処理はシンプル ◦ メインロジックは30行以内 • 用途は異なるので、1つで済ませず、別々に構築 Lambdaはシンプルに
• アラームとLambdaをルールで紐付けるのみ • 入力トランスフォーマーでレベルを付与 EventBridgeもシンプルに
いざ検証
• Incident Managerからの通話は英語 • アクティベーションの確認番号は聞き取れる • エスカレーション時の通話が辛い... ◦ とにかく早口で長い ◦
通話中に「1」を押すと確認済みになり、「9」を押してしまうとリストから 外されてしまう ◦ 周知することで対処 通話が英語
• もしくは非通知、番号は変わる場合もある • いたずら電話と思われたり、拒否設定にしていると届かない可能性がある ◦ 許容できない場合は、Amazon Connectが選択肢になる • あらかじめ周知して対策 ◦
最悪取らなくてもチャットは見てほしい 電話の発信元がアメリカ
None
• いきなり電話は考え物 • 呼び出し時は最初メールで通知 ◦ エンゲージメントを承認するコードが記載されている • それにも気づかれていないようであれば電話というフロー ◦ 間隔は10分~15分後
順番を考慮する
None
• こだわりが少なければシンプルな構成 ◦ 既存のアラートに埋め込める ◦ こだわっても何とかなるはず • 英語という壁こそありますが、乗り越えられれば最有力? • 一連のフローについては定期的に訓練という形で検証を行い、問題ない
ことを確認する予定 ◦ 肝心な時に動かないのでは意味がない • ぜひ検証からはじめてみてはいかがでしょうか まとめ
• 木村俊彦 / @taiko19xx • 株式会社インフィニットループ • 主な業務 ◦ バックエンド構築(PHP/C#)
/ インフラ構築(AWS) • 好きなゲーム ◦ Civilization / Age of Empires / Rize of Nations etc… • 好きなAWSのサービス ◦ LambdaとDynamoDB 自己紹介
ありがとうございました