Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Incident Managerでインシデント発生時のエスカレーションを自動化する
Search
taiko19xx
June 14, 2022
Technology
290
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Incident Managerでインシデント発生時のエスカレーションを自動化する
taiko19xx
June 14, 2022
More Decks by taiko19xx
See All by taiko19xx
Bedrockで遊ぼう! 短期間で色々開発してみた
taiko19xx
1
190
LambdaカスタムランタイムでPHPでもサーバーレス!
taiko19xx
0
99
IoTっぽいアプリをk3s+Raspberry Piで実行する
taiko19xx
0
370
ハニーポットから見たWebサーバへの攻撃
taiko19xx
0
3k
PHPなプロダクトをAmazon ECSで開発運用してる話
taiko19xx
0
1.4k
RaspberryPi+AWSでIoT(っぽ い)GPSロガーを作ってみた
taiko19xx
0
1.7k
PHPからWin32APIをいじってみた
taiko19xx
0
1.8k
Other Decks in Technology
See All in Technology
いちAWSエンジニアのAI活用を振り返る #devio2026 / devio osaka 2026 kawahara
masahirokawahara
2
390
IR Today: Theory, Practice, and Agents
dtunkelang
0
350
AI時代だからこそ推したい!Gitコマンド再入門
munakata
0
150
全社共通データ基盤をつくる。ソニーのDatabricks活用とデータガバナンス設計の裏側
sony
0
430
継続的なAIコスト最適化
bgpat
1
160
「とりあえず動く」の先へ。 AI時代のチーム開発と内部設計/2026-slsdays
slsops
0
150
AI時代のAPI開発を加速する品質ガードレール / API Quality Guardrails in the AI Era
yokawasa
0
160
AIに攻撃される前に、AIに攻撃させる
tsuchikazu
0
150
契約書画像からの情報抽出に特化した視覚接地モデルを育てる話
sansantech
PRO
1
150
DWH の限界突破! AI エージェント向け爆速リアルタイムデータ基盤 ClickHouse
jozono
1
200
Kernel testing frameworks
ennael
PRO
0
110
Futexes the good, the bad, the ugly
ennael
PRO
0
130
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
Designing for Performance
lara
611
70k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
300
Rebuilding a faster, lazier Slack
samanthasiow
85
9.7k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
Statistics for Hackers
jakevdp
799
230k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
910
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
480
What's in a price? How to price your products and services
michaelherold
247
13k
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
970
The World Runs on Bad Software
bkeepers
PRO
72
12k
The Pragmatic Product Professional
lauravandoore
37
7.5k
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 自己紹介
ありがとうございました