📲

Amazon Connectを用いた無人監視（後編）

2023/10/03に公開

AWS

監視

Connect RPC

tech

概要

無人監視にする上で、システム化の難易度が比較的高いのが電話通知かと思います。
今回は障害アラートが発生した際に、Amazon ConnectのAPIを利用して、
システム担当者に自動で電話をかけ、アラートの内容を通知するということをやってみました。

前編では構成や仕組み、後編では工夫した点や考察などをまとめましたので適宜気になるところを読んでいただけると幸いです。

工夫した点

アラートの静観

システム担当者が障害アラートの電話を受けた際に、
電話越しに静観の設定ができるような仕組みを考えてみました。

ConnectのContact Flow内でシステム担当者に静観の設定を入力してもらい、
設定した時間をパラメータとしてLambdaに渡してデータベースに登録します。
（静観をする場合は9を押してもらい、そのあと時間をボタンで入力してもらう）

データベースに静観設定用のテーブルを用意しておき、静観が終了する時間をエポック時間で格納します。

静観するかどうかは、Connectで電話をかける前にテーブルの静観レコード有無で判定するようにしました。
（レコードがあれば電話しない、レコードがなければ電話する）

電話に関する例外処理

前編でお伝えした通り、電話ごとに一意に払い出されたContact IDを使い、
Describe Contact APIで電話が正常に終了したかどうかを確認することができませんでした。。
そのためContact Flowで電話を切断する直前に終了ステータスをデータベースに登録する必要がありました。

正常に終了する以外に例えば、

電話がつながらなかった
システム担当者が誤操作で切断してしまった
ネットワークの問題で電話できなかった

などの例外が発生する場合があると思います。
その際、何が原因で電話がかからなかったのかをAmazon ConnectのCTR（問い合わせレコードデータモデル）と呼ばれるレコードで取得することができます。

このCTRはS3やKinesisとつなげることができるので、今回はKinesisにつないで不通となった原因を確認し、データベースに登録するようにしました。

ちなみに、原因の分類にはいくつかありますが「CUSTOMER_DISCONNECT」と「CONTACT_FLOW_DISCONNECT」を考えてみました。

分類	説明
CUSTOMER_DISCONNECT	顧客から切断されました。
AGENT_DISCONNECT	問い合わせがまだ通話中に、エージェントから切断しました。
TELECOM_PROBLEM	通信事業者、ネットワークの輻輳、ネットワークエラーなどに起因する、通話の接続の問題により切断されました。
CONTACT_FLOW_DISCONNECT	フローで通話が切断されました。
OTHER	これには、前のコードで明示的にカバーされていない理由がすべて含まれます。問い合わせが API によって切断された場合などです。

システム担当者が途中で切断する場合は「CUSTOMER_DISCONNECT」に分類され、
不通だった場合は「CONTACT_FLOW_DISCONNECT」に分類されるようでした。

困ったことに正常終了時も「CONTACT_FLOW_DISCONNECT」に分類されるようで、
不通なのか正常終了したのかの見分けがつかないためContact Flowの切断前にLambdaを実行し、
正常終了フラグをデータベースにつけることで判別するようにしています。

（check_flagが1の時はアラートが確認済み、check_flagが0でdiscon_reasonがCONTACT_FLOW_DISCONNECTは不通と判断）

留守番電話判定

検証時にContact Flowで通話直後にアラート内容を伝えるようにブロックを定義した場合、
不通時には留守番電話に繋がり障害アラートの通知内容が途中から留守番電話に記録されました。

また、タイムアウトまで留守番電話に記録され続けるので次の担当者への連絡に進まず、
全体として処理時間が長くなるという問題が起こりました。

留守番電話か人が出たのかを判定するためブロックとして、
「通話の進捗確認」というブロックがあるようなのですが2023/10/3現在東京リージョンでは使え内容でしたので、少し工夫をしてみました。

通話直後に入力を求めるブロックを用意するし、
入力がない場合に留守番電話と判定して終了するフローにすることで、
留守番電話による問題を軽減することができそうです。

Connect APIのスロットリング対策

仕様によると、Connect APIごとにLimitが設けられており、アウトバウンドAPIは2req/s～5req/sのようでした。

その他のオペレーションではすべて、1 秒 2 リクエスト (RateLimit) と、1 秒あたり 5 リクエスト (BurstLimit) になります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/amazon-connect-service-limits.html#api-throttling-quotas

障害アラート数が小規模の場合は事足りそうな気もしますが、
回線障害などによる一斉アラート時にはスロットリングが起きそうな気配があります。

そのため、SQSを挟んでキューに通知する障害イベントを格納するようにしてみました。

注意点

国内電話への発信制限解除申請

デフォルトでは固定電話や米国への発信のみが許可されているようです。
そのため、国内の携帯（080、090など）に対して電話をかける場合は事前にAWSにホワイトリストに登録してもらえるように申請を出す必要があります。
申請には数営業日かかること可能性があるため、前もって申請をしておきましょう。

考察

大規模障害によるアラート

過去の経験上例えば回線断などが原因で大量アラートが生じる可能性がありますが、
オペレータが電話をかける場合はわざわざすべてのアラートに対して1つずつ電話をかけるのではなく、
まずは回線断の障害アラートを担当者に伝えて、関連アラートはその後の担当者の判断で通知するかなど柔軟に対応すると思います。

この部分はもう少し工夫がいりそうなところだなと思うところで、
雑に最近流行りの生成AIに任せてみるとか（できるかどうは別として）、
あとは特に考慮せず淡々と電話がかかるようにするとかあると思うのですが、一旦は後者で作ってみました。

もしかしたら同じ時間帯のアラートについてはまとめて電話を通知するなどの処理があると有効かもしれません。

固定電話への電話

オペレータが電話をかける際には、
日中は会社の固定電話で夜間は携帯にかけるといったケースがあるかと思います。
固定電話への自動音声による電話は必ず担当者が出るわけではないので現実的ではなく、
基本的に担当者への電話はすべて携帯になるのかなと思いました。

営業日のみ電話

システム担当者によっては、
営業日のみ電話を受付、非営業日は電話を受付しないなどのケースもあるかと思います。

データベースの担当者一覧に、
営業日関連の属性を持たせることで実現できそうですが今回は試していません。

また、営業日かどうかを判定するにはカレンダー情報が必要かと思いますが、Systems Manager Change Calenderと組み合わせれば営業日判定ができて実現できそうな気がします。

チャットオペレーション

自動通知からは少し逸れますが、
Chatbot連携をしてシステム担当者がアラートを受け取った後に簡単なコマンド実行できるととても便利そうだなと思いました。

例えば、EC2の疎通ができないという障害アラートを電話で受けた後に、
システム担当者がChatbotからCLIコマンドでEC2を再起動をして復旧させる、
Systems Manager Automation（手順書の想定）を実行して復旧させる、
などができると面白そうだなと思いました。

BIツールによる可視化

Connectの通話履歴を記録したCTRを、
QuickSightなどのBIツール、もしくはAWS ESなどで可視化すると、
月別に着信がどれくらいあったのか、受電が何％だったのかなど品質測定ができるて面白そうだなと思いました。

実際に電話がかかるのか

試しにcurlで以下のAPI Gatewayに架空の障害イベント情報をPOSTしてみます。

curl -H 'Content-Type:application/json' \
 -H 'x-api-key:API GatewayのAPIキー' \
 -X POST \
 -d '{"input": "{\"alertinfo\" : [{ \"host\":\"Serve1\", \"service\":\"CPU Utilization\", \"lastcheck\":\"2023-10-03 13:20:52\",\"systemname\":\"XYZ\"}]}" \
 API GatewayのURL

すると無事電話がかかってきました。

通知内容と音声ガイダンスに従いアラート確認をしていき、
一応Step Functionsも確認すると、無事処理ができていることを確認できました。

最後に

いかがでしたでしょうか。
Amazon Connectを使った障害アラートの無人電話ができると、
有人監視から無人監視への切り替えが大きく前進するのではないかと思います。
実際に構築するコストと運用コストが、有人監視にかかるコストを下回るか次第ですが非常に魅力的なシステムではないかと思いました。

この記事がどなたかの参考や助力になれると幸いです。
最後まで見ていただいてありがとうございました！