最初の架電中に2回目の架電が発生しました
回答済み
お世話になっております。
本日、異例な架電の挙動があったとユーザー報告がありましたので、事象を確認したく、ご協力をお願いいたします。
【ユーザー報告】
電話「09*******9」へのkompira架電が入りPHSで受電しているところ、
その直後「09********9」にkompira架電され、他のPHSで受電。
どちらも同じ架電内容で、架電回数は２回。
同時刻に同アラートの複数発生は無し。
【懸念点】
１．Kompira連絡履歴では3回の架電になっているが、実際には2回しか電話は鳴っていない
２．１アラートが別々の架電先で受電されてしまうと、特に夜間など1アラートに対し複数の障害対応が発生する
【要望】
◆今回の事象がどういった仕様で発生しているのかをきちんと把握したい
【状況】
対象架電の resultID：a9f1d293-dc5f-43ce-b298-9b96ed1fa4cf
API のcalls（架電結果一覧）で状況を確認したところ、Kompira としては以下の記録になっていた。
①Pigeon は3回かけて、3回目で成功
②calls 採取情報
③1回目の架電終了時間が、2回目の架電開始より後になっている。すなわち、ユーザーの申請通り、1回目の架電が終了しないうちに2回目の架電が発生している
④PHSについて
・2台の PHSはそれぞれ電話番号を持っている
・「PHSピックアップ」という機能を使い、他の電話が鳴っている時に手元のPHSで電話を取っている（「09*******9」が通話中とならないように）
以上です。
よろしくお願いいたします。
-
（一部お客様のものと思われる電話番号が記載されておりましたので、伏字処理させていただきました）
ご質問ありがとうございます。
こちらの事象について、詳細調査を行いました。
最初に polling timeout したものを「架電①」、 could not ring the phone により失敗したものを「架電②」 、成功扱いになったものを「架電③」として、事象発生の流れを下記の通り記載いたします。- 15:28 に 架電① が開始。 Pigeon から架電システムへリクエスト送出。
- 発信処理が開始せず、 10 分が経過した時点で Pigeon がタイムアウトと判断（こちらが polling timeout として記録されております）
- 同時架電枠が空いたことで、架電② が開始。 Pigeon から架電システムへリクエスト送出。
- このタイミングで架電②と同時に 架電① の発信処理が開始
- 架電① が成功し、ユーザーが受電。同時に 架電② が発生したが、同じ電話番号による重複発信のため失敗（こちらが could not ring the phone として記録されております）
- 架電② が失敗したことで同時架電枠が空いたと判断され、架電③ が開始
- 結果、架電① の実施中に 架電③ が行われ、重複発信の形となった
- 架電①に関しては 2 の時点で Pigeon による追跡が終了しているため、最終的に成功したものの polling timeout として記録された
要点としては上記の 2 〜 4 において、「15:28 に発生するはずの架電がすぐに処理開始せず、次の架電のタイミングで同時処理された」ことが異常挙動となります。
この異常挙動について、現在架電システム側のベンダへ詳細調査を依頼中です。
結果が得られ次第、追ってご報告させていただきます。大変ご迷惑をおかけし、申し訳ございません。
以上、よろしくお願いいたします。 -
お世話になっております。
調査に入っていただき、ありがとうございます。
よろしくお願いいたします。
架電しているのはサーバーやアプリの異常通知なので、1つのアラートに対し、複数の人間がそうとは知らずに対応してしまうと、２次障害を招く恐れがあります。
ご説明から、受電側デバイスによるものではなく、Kompira架電システムによる事象のようなので、昼夜問わず発生するリスクがあることから、できれば早めのご対応をお願いいたします。以下、追加質問です。
【質問１】>>8. 架電①に関しては 2 の時点で Pigeon による追跡が終了しているため、最終的に成功したものの polling timeout として記録された
との事ですが、受電者は2人とも「１」を返答しています。
架電①の ガイダンスに「１」を応えた操作を、Pigeon はどのように受け取っているのでしょうか？
そのお答えにもよると思いますが、すでに発信されたガイダンスの中で、受電者が異常に気付くことはやはり不可能ですか？ガイダンスのリターンを受けた時に、Pigeon が状況の不一致を知らせる手立てはあるのでしょうか？
ユーザーとの認識合わせのために、今回の事象を図にしました。
この認識で合っているか、お手数ですがご査収願います。
以上、引き続きよろしくお願いいたします。
-
架電①の ガイダンスに「１」を応えた操作を、Pigeon はどのように受け取っているのでしょうか？
Pigeon では架電システムに対してリクエストしたあと、結果を10秒間隔で取得（ポーリング）します。この定期取得について、今回のようにイレギュラーが発生した場合に永遠に取得を継続してしまうと次の連絡を発生させることができなくなりますので、10分間続けても終了を確認できない場合は定期取得をやめ、架電失敗として取り扱います。こちらが polling timeout のケースとなります。
そのため、今回のように polling timeout と判断された後に結果が取得可能になったとしても、その時点では結果の定期取得は終了しているため、 Pigeon からは結果の追跡をすることが不可能となります。
ガイダンスのリターンを受けた時に、Pigeon が状況の不一致を知らせる手立てはあるのでしょうか？
先述の通り PIgeon 側での架電結果取得が終了しているため、 Pigeon は本ケースにおいてそもそも電話発信が発生したこと自体を把握していない形となり、本ケースにおいて Pigeon から問題を検出するのは困難となります。
ユーザーとの認識合わせのために、今回の事象を図にしました。
この認識で合っているか、お手数ですがご査収願います。基本的にこちらの認識と相違ございませんが、厳密に言えば架電システムにおける処理順としては（架電②がリクエストされたタイミングで）架電①が先に開始し、架電②のほうがごくわずかに後に開始したものと推定しております。
-
お世話になっております。
大変遅くなりまして申し訳ございません。本件の原因と対応について取りまとめを行いましたので、下記の通り報告させていただきます。事象発生の契機について
Pigeon から架電サービスに対してリクエストを行うと、サービス側で下記の流れで処理が行われます。
- 架電実行要求プログラムが架電実行のための一時ファイルを生成する
- 架電実行プログラムが一時ファイルの生成を検知し、架電処理が開始される
このように 2 つのプログラムの連携により架電実行が行われますが、今回の事象では上記の 1 にて生成したファイルを 2 において架電実行プログラムが認識せず、次のリクエストによる一時ファイル生成を契機に残存していた一時ファイルを含めてまとめて処理が発生したことによります。
事象解消の経緯について
本事象は先の 2 つのプログラムのうち「架電実行プログラム」の挙動によるものですが、こちらはベンダーによる開発ではない オープンソースソフトウェア であり、根本的な原因と解決が難しい状態にございました。
そこで今回の対応では、先の 1 において一時ファイルを生成した後、実際に処理が開始しているか確認する監視プログラムを追加し、処理が開始しない場合にリトライをかけ再度架電実行要求が行われるよう対応を行いました。
こちらにより、同事象を引いたとしても架電が滞留し続けることを防いだ形となります。重ね重ね、ご迷惑をおかけし申し訳ございません。
何卒よろしくお願いいたします。 -
お世話になっております。
今回の架電トラブル事象の収束に向けて、社内で情報を共有しておりますが、指摘が何点がございました。危惧されている内容としましては、オープンソースに対し、新監視プログラムで機能を補填した対応となっているが、それが「架電要求と架電実行が正しい関係で即時・確実に処理される保証となりえるか」というものです。今回のトラブルは、架電システムとして「保証されていてしかるべき」基幹部分かと存じますので、
お手数ですがご回答をお願いいたします。
①今回の「事象解消の経緯」において、架電実行要求プログラムとリトライとの関係に言及がない。
リトライの間隔 ＞ 一時ファイルの滞留監視間隔
上記の条件は成り立っているでしょうか？
プログラムが3本登場し、1本はオープンソースで改修不可、1本はその監視プログラムでリトライを発行という関係性の上で、上記の条件が保証されているか、ご回答ください。
②今回の原因となった「架電実行プログラム」はオープンソースであり、正常に動作しなかった原因が判明していないと認識している。
今回の改修は「リトライ」すれば、架電処理が正常に実行されることが大前提の改修かと思われるので、原因が判明していない中で、今回の改修で「確実」に架電実行されるのか、保証があるか確認したい
③以前に営業サイドにて「不可」との回答を得ているが、②の「確実性」が不透明なため、再度御社側で、以下の検知は可能か確認したい。
また、以下の事象の原因と報告できる体制の有無についても確認したい。
更に、もし②の確実性が保証されないならば、報告体制についてご一考いただけるかどうかもお尋ねしたい。※この③については、②の確実性が保証されるのならば不要です。・監視プログラムによるリトライ発生
・リトライ処理による架電実行の正常性確認
・二重架電発生時には検知し、速やかにユーザーへ報告する
以上です。
厳しい要求かとも思いますが、基幹部分のトラブルとその対応ですので、ご了承いただければ幸いです。 -
ご理解に相違が見られますので、改めてより詳細な説明を記載させていただきます。
「架電実行プログラム」の挙動について
「架電実行プログラム」での処理をより詳細に記載させていただきますと、下記のようになります。
- （架電実行要求プログラムにより行われた）特定のディレクトリへのファイルの生成を検知する
- ディレクトリ内のファイルを全て読み、それぞれのファイル内容に応じた架電実行を行う
今回の事象は、上記の 1 におけるファイル検知が発生しなかったことによります。
このファイル検知については「一定時間ごとにディレクトリ内のファイルを確認する」という性質のものではなく、「ディレクトリを常時監視してファイル検知のタイミングをリアルタイムで確認する」性質となっており、一度取り漏らした場合、次の検知は「別の新たなファイルが生成されたタイミング」となります。
今回、2件目のリクエストのタイミングにおいて1件目のリクエストがまとめて処理されたことからも、この挙動が伺えます。
新たに導入した監視プログラムの作用について
監視プログラムにおいて監視するのは「架電サービスに対して外部から行われたリクエスト」に対して、「最終的に架電実行プログラムでの架電処理が発生したか」となります。すなわち、先の架電実行プログラムにおける処理ステップで言う 3 が発生したかどうかを監視している形となります。
このとき、架電実行が発生していないことを検知した場合にはリトライを行いますが、このリトライは先のステップで言う 2 の再実行にあたります。
ご質問に対する回答
以上を踏まえた上で、追加でいただいたご質問に回答させていただきます。
①今回の「事象解消の経緯」において、架電実行要求プログラムとリトライとの関係に言及がない。
リトライの間隔 ＞ 一時ファイルの滞留監視間隔
上記の条件は成り立っているでしょうか？先に示した通り、監視プログラムでは実行の滞留を検知次第速やかに架電実行プログラムにおける処理のリトライを行います。そのため、滞留の監視（正確には検知）のタイミングと、リトライのタイミングは同時となります。
②今回の原因となった「架電実行プログラム」はオープンソースであり、正常に動作しなかった原因が判明していないと認識している。
今回の改修は「リトライ」すれば、架電処理が正常に実行されることが大前提の改修かと思われるので、原因が判明していない中で、今回の改修で「確実」に架電実行されるのか、保証があるか確認したい今回問題となったのは生成したファイルを検知するステップ（先の「架電実行プログラム」の挙動で言う 1 ）により検知が発生しなかったことであり、これに関しては確かに原因不明となっております。
一方で、今回の改修による「リトライ」ではファイルを読み込み架電実行を行うステップ（先の「架電実行プログラム」の挙動で言う 2 ）の実行指示を直接行いますので、問題となった検知ステップはリトライ時には無関係となり、架電実行は確実に行われる形となります。
以上、ご確認のほどよろしくお願いいたします。
-
お世話になっております。
ご回答ありがとうございました。
内容を確認し、以下処理フローを作成してみましたので、添付いたします。
また、このフローの認識が合っているとの想定の上で、
以下の質問3点をお願いしたいと思います。
※1.架電実行要求PGMのファイル作成と、監視PGMのリトライはバッティングしないのでしょうか？
※2.架電実行PGM からのRequest発行は「架電処理の発生」と同意であり、Requestが発行され、監視PGMがそのRequest は正しいと判断するなら、架電処理は確実に実施されることになりますか？
※3. S1. 1が動作しない事象と、S3.の監視ロジックが対になるのがよくわからない
何か検知するはずなのに、後続の S2. が実行されていない、ということがわかる状況があるのでしょうか？ -
処理フローについて
図に関して正確でない点に先に触れておきますと、この一連の流れを行う架電サービス（「架電実行要求プログラム」「架電実行プログラム」「監視プログラム」の集合体）は Pigeon からリクエストを受けて架電処理を直接実施する仕組みであり、Pigeon 自体は架電を直接執り行う機能を持ちませんので、架電実行プログラムから Pigeon に対してリクエストを送信する、と言う理解は誤りとなります。
架電実行プログラムは全体のフローの中で実際に電話連絡を発生させる、最終的な実行器という立ち位置となります。
追加の質問点について
※1.架電実行要求PGMのファイル作成と、監視PGMのリトライはバッティングしないのでしょうか？
架電実行プログラムにおいて「ファイル作成の検知」と「（ファイルを元にした）架電処理の実行」は完全に独立した処理となっており、前者はあくまで後者の処理を呼び出すための契機に過ぎません。そのため、後者の呼び出しを直接行うことに関しては原理上問題となりません。
また処理に関してはデータベーストランザクションを利用することで原子性の担保が行われており、新たなリクエストとのタイミング重複等により短時間の間に複数回の処理実行が発生したとしても、それが直ちに処理重複につながることもございません。
こちらについてはこれまでの Pigeon を提供する中でも、短時間のリクエスト集中を原因とした処理重複が確認されたことはなく、実際の挙動としての辻褄はあうものと考えております。
※2.架電実行PGM からのRequest発行は「架電処理の発生」と同意であり、Requestが発行され、監視PGMがそのRequest は正しいと判断するなら、架電処理は確実に実施されることになりますか？
架電実行プログラムにおける「架電処理の実施」（図中の S2. ）は実際に架電が発生することと同義となります。（何らかの別原因の内部エラーによ架電処理自体が失敗することは可能性としては考えられますが、本件の論点からは外れるものと考えます。）
※3. S1. 1が動作しない事象と、S3.の監視ロジックが対になるのがよくわからない
何か検知するはずなのに、後続の S2. が実行されていない、ということがわかる状況があるのでしょうか？示していただいたフローは「架電実行要求プログラム」に対して外部 ( Pigeon ) からリクエストが行われることで開始しますが、このリクエストはアクセスログとして全て記録されております。一方で、実際の架電は「架電実行プログラム」において行われますが、この架電実行はデータベース上に履歴として記録されます。
監視プログラムではこのアクセスログに対して、架電実行の履歴が生成されたかを確認する形となります。すなわち、監視観点は「リクエストに対して実際に架電が発生したかどうか」であり、「ファイルの検知に成功したかどうか」ではございません。つまりは、架電実行が発生していない原因が「検知漏れ」である否かには関知せず、（仮に別の原因であったとしても）架電実行の発生漏れ自体を防ぐための方策となります。
そのため厳密には今回の事象「のみ」に対する対処にはなっておりませんが、今回の事象を含む、より包括的なケースへの対処になっており、サービス外から見た振る舞いを担保する上では十分な対処であると弊社では受け取っております。
以上、よろしくお願いいたします。
-
お世話になります。ご丁寧な説明をありがとうございました。
①図を修正いたしましたので、ご確認いただけますか？
②また、以下の1文について確認をさせてください。
>>監視プログラムではこのアクセスログに対して、架電実行の履歴が生成されたかを確認する形となります
この1文の意味を以下のように認識しています。認識違いはないでしょうか？
・「架電実行要求プログラム」は外部 ( Pigeon ) からリクエストが行われることで開始し、この（Pigeon）リクエストはアクセスログとして記録されている
・「架電実行プログラム」において行われる実際の架電実行はデータベース上に履歴として記録される
・監視プログラムは、「架電実行要求プログラム」のアクセスログと「架電実行プログラム」のデータベース履歴を参照しており、「（Pigeon）リクエストに対し実際に架電が発生したかどうか」を確認、発生と実行に差異があった場合は、実行の滞留を検知したとして速やかに架電実行プログラムにおけるstep2のリトライを行う。この処理の流れは「トランザクションの原子性」で担保されており、架電実行の発生漏れ自体を防ぐための方策となっている
-
お世話になっております。
図および文面について、ほぼ相違ございません。
一点だけ、下記の文面
この処理の流れは「トランザクションの原子性」で担保されており、架電実行の発生漏れ自体を防ぐための方策となっている
について、データベースのトランザクションにより防止しているのは「処理の重複」となりますので、この点を明確にして
また、リトライと新たなリクエストが同タイミングで行われたとしても、データベースのトランザクション機能により処理の重複を防ぐようになっている。以上の流れにより、架電実行の発生漏れを防ぐための方策となっている。
などとした方が説明としてはわかりやすくなるかと思います。
以上、よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
21件のコメント