COLUMN

１．監視オペレータ業務が抱える問題点とは

最初に一般的なITシステムを例に挙げ、監視オペレータ業務が抱える問題点を紹介しました。

先ず今回の業務改善対象である一般的なITシステムの運用での業務体制から解説しました。

一般的なITシステムの運用の業務体制

• 24時間365日の体制でITシステムを監視オペレータが日中帯と夜勤帯で監視
• アラートが発生した場合は、一次措置を監視オペレータが実施
• 重要度が高いアラートであった場合、各サービスに精通しているスペシャリストにエスカレーションを実施

次にITシステムの運用を日中帯と夜間帯に分けて、それぞれの監視オペレータの業務の手順を紹介しました。

• ①アラートが発生した際、アラートの確認とアラートの種類判別を確認
• ②確認したアラートの決められたフローに則り、状況の把握を実施
• ③状況により監視オペレータが個別に対応できる場合、静観対応または一時措置を実施
• ④対応が難しい場合、サービスシステムに精通しているスペシャリストにエスカレーションを行う（日中帯は電話やメール、コミュニケーションツールのSlack、どの手段でも連絡可能）

夜間帯の問題点

• メールやSlackなどは業務外なので連絡に気付かず、電話であっても夜間の呼出しのため気付かない恐れがある
• そのため、何度もエスカレーション先を変更して連絡を図るため、監視オペレータの業務に負担がかかる

夜間帯に発生するこれらの問題点を洗い出すため、監視オペレータの業務を次のようなフローで表しました。

今回は赤線で囲んだ後半部分のエスカレーション部分に注目

監視オペレータの手順は以下の通り

• ①エスカレーション先を確認
• ②スペシャリストへ電話
• ③スペシャリストが電話に出た場合、これまでのアラートの内容を引き継ぎ
• 電話に出られなかった、または出たものの対応が難しい場合は以下につづく
• ④再度エスカレーション先を確認
• ⑤スペシャリストへ電話
• ⑥スペシャリストが電話に出た場合、これまでのアラートの内容を引き継ぎ

課題点

以下の業務が時間帯問わずに行うことが困難

• システムアラート毎に定められているエスカレーション先を確認
• 電話に出ない場合は再度、次の担当者を確認

現状では夜間帯の場合に電話に出て貰えない可能性が高い

業務改善を目指すシステムの構築の要件

• 毎回のエスカレーション先の確認を不要にする
• 第一担当者が電話に出られなかった場合は、自動でリダイレクトされるようにする

以上の要件を満たすシステムを内製で開発することが出来るのか？

疑念点としては「開発難易度」「導入時間」「コスト」などが考えられる

解決手段

選択肢の一つとしてクラウドサービスのAmazon Connectの利用が挙げられる

２．Amazon Connectを使った課題解決

ここでは実際にAmazon Connectを使った監視オペレータ業務の課題の解決方法を詳しく紹介しました。

先ずは今回の課題解決に利用するAmazon Connectの特徴について簡単に解説しました。

Amazon Connectについて

AWSのコンタクトサービスであり、コンタクトセンターシステムや自動受付システムを構築・運用ができる

テレワーク環境を構築する際に会社電話番号や着信対応を社内外で実現することが可能などの電話サービスにも対応

クラウドのメリットである従量課金制やAWSの他のサービスとの連携ができるなどの面でも魅力的なサービスである

Amazon ConnectのUIの操作感について

シンプルなUIで簡単に電話の転送フローや分散措置を設定、構築することができる

エスカレーション業務の効率化

次に実際にAmazon Connectの適用箇所について詳しく解説しました。

エスカレーション業務以外の効率化について考察

Amazon Connectでは他のAWSサービスと組み合わせることが大きなメリットになります。そのため、それらのサービスを利用することで監視オペレータ業務そのものの効率化に枠を広げることが期待できます。

ここではフロー前半の業務について検討しました。

「アラートメトリクス確認」→「フロー確認」→「エスカレ判別（状況を確認してエスカレーションの判断を行う）」

• 「アラートメトリクス」「フロー確認」
  システム上で反映できるメトリクスの閾値などの内容をシステムのアラートメール機能に代替
• 「エスカレ判別」
  アラート確認とエスカレーション先に電話をかける処理についてはAWS Lambdaで行う

AWS Lambdaを使ってAmazon Connectへ電話

AWS Lambda：サーバを構築しなくてもサーバ代替機能を補ってくれるサーバーレスサービス

苦労した点

今回の対応で苦労した点、想定外だった点、それらに対する改善点について紹介しました。

AWS Lambdaからの呼出しで１番目のスペシャリストが電話に出られなかった場合、次のスペシャリストに回す処理に苦労

その他に見つかった課題点

実際に監視オペレータ業務をシステムに代替してみると、電話を受けるスペシャリストに対し、次のような要件が見つかった。

• ①同じ内容のアラートで数分間に何度も呼び出しがかかってしまう
• ②電話に出たとしても対応不可かどうかの選択できる余地が欲しい
• ③電話される人を増やしたい、順番を変更したい
• ④特定期間中（メンテナンスなど）は、アラート架電を抑止したい
• 以上の要件に対し、次のような対処を実施
• ①電話した時の時刻のタイムスタンプを保存し30分以内なら再架電をしない
• ②電話時に押す番号で「対応できる/できない」を決める
• ③番号をDBで管理する→DBに登録者を増やす・取り出す順番を変更する
• ④サービス毎に電話をするかどうかのスイッチを設定
  →Yesであれば電話、Noであればメールなどにする

３．NTT東日本での運用形態ご紹介

ここまでAmazon Connectを利用した、監視オペレータ業務の課題の解決方法について解説してきましたが、ここでは現在NTT東日本で運用しているAmazon ConnectやAWS Lambdaなどを利用して監視オペレータの業務をシステム化したアーキテクチャを紹介しました。

アーキテクチャ解説

• 1. Amazon SESでアラートメールを受信
• 2. Amazon SES からAWSのオブジェクト・ストレージサービスであるAmazon S3にアラートメールを転送
• 3. Amazon S3にアラートメールを転送されたことを契機に架電システムをスタートするLambdaがキックされる
• 4. 架電用のLambdaでは以下を実施してエスカレーション先へ電話をする
  • ①アラートメールの内容を読み込み
  • ②AWSデーターベースサービスのDynamo DBから「アラート内容に対応した音声原稿」と「各種エスカレーション先」を読み込む
  • ③Amazon Connectを呼び出し、エスカレーション先へ電話をする
• 5. 電話に出られなかった、または電話にでたものの対応できない場合、再度電話をするためLambdaへ戻るような構成をAWS Step Functions Workflowで設定

Amazon Connectを導入した効果について

NTT東日本の関連組織内の運用では以下のような効果を確認

電話に出られなかった時間や再度連絡するといった工程を省くことで１件につき5分～10分、一週間に平均10件～15件のエスカレーションが発生していることから、週に約150分の時間の削減を実現

４．まとめ

最後にまとめになります。

本セッションではITシステム運用で監視オペレータの業務改善に焦点を当てました。

次のような問題点に関してAmazon Connectを利用して対処しました。

• 従来の監視オペレータでは対応するサービスが多くなるとエスカレーション先の把握や再連絡が面倒になる
  ⇒Amazon Connectを用いることで多くのエスカレーション先への電話の自動化環境が簡単に構築できる
• 監視オペレータ業務そのもののシステムを代替できないか
  ⇒AWS LambdaやAWS Set Functions他のAWSサービスを使用して実現

※今回のAmazon ConnectやAWS Lambdaなどを使用した対処方法は一次措置などが定型業務でないシステムには使用できない場合もあるため、ケースに合わせた利用を推奨

５．おわりに

本レポートでは「監視オペレータはもういらない？ ～Amazon Connectを用いたスペシャリスト自動手配システムの内製開発～」を紹介しました。監視オペレータ業務が抱える問題の改善を検討中の方の参考になれば幸いです。

NTT東日本では、今回紹介しましたAmazon Connectを使用した監視オペレータの業務改善の他、さまざまなクラウド導入・運用サービスを提供しております。

自社でクラウド導入をご検討されている企業さま、クラウドを活用したビジネスでのパートナーをお探しの企業さま、すべての企業さまからのお問い合わせや個別のご相談を随時お受けいたしております。些細な疑問でも是非一度お問い合わせください。