日記/2012-08-31/何故webサービスのサポートは返信が遅いのか。

#blog2navi()

何故webサービスのサポートは返信が遅いのか。 †

fluentdとcasandraで作る、サポート支援ツール

webサービスのサポートは遅い？ †

webサービスのサポートで、返信が遅いという話を良く聞く。曰く、メールしてもなかなか返事が帰ってこないとのことだ。何故、サポートは返信が遅くなるのか、どうしたら早くなるのか、考えて見た。

一般的なサポートの流れ †

良くあるwebサービスので質問「ログイン出来ない」が、どのように処理されるか見てみよう。

1. ユーザー -> サポート ログインできません
2. サポート -> 企画 ログインできないそうです。
3. 企画 -> 開発 あるユーザーがログインできないそうです。
4. 開発 -> インフラ(本番サーバを触れる人) ログインできないそうです。ユーザーID xxx番で何日のログをgrepしてください。
5. インフラ -> 開発 いやログイン出来ている見たいよ
6. 開発 -> 企画 ログインできているみたいよ。
7. 企画 -> サポート ログインできている見たいよ。
8. サポート あ、すいません。ユーザーID間違えてました。

関わる人がすごく多い伝言ゲームになる。 理由は二つある。

1. 一つ目は、サポートは、あるユーザーからの問い合わせが、実際のプログラムにどう落とせるか分からず、そのため、開発を必要とする。
2. 二つ目は開発は本番サーバに触れないので、本番サーバのログにある、ユーザーの行動をトレース出来ない。 いきおい、この様な多段の伝言が生じる。

自分の職務で無いものの優先順位は、必ず下がる。 †

サポートは個人ユーザーの問題を解決すると言う職務がある。しかし、他の職種ではそうではない。企画は、面白いサービスをデザインすることが仕事で、開発はそれを確実に実装すること、インフラは、サービスを日々間違い無く運用することが仕事だ。

だから、ログインできないと言う問題の優先度は次のようになる。

1. サポート -> 企画 [大至急]
2. 企画 -> 開発 [早めで]
3. 開発 -> インフラ [出来れば早めに]
4. インフラ の心の中 「そのうち」

これは、個々人の人間の頑張りではどうにもならないと考えるべきだ。自分の職務で無い物の伝言は、必ず優先度が一ずづ下がる。これに例外は無い。

問題はどこか？ †

• 個々人の頑張りの問題ではない。 先に、人間個々人の頑張りではどうにもならないと書いた。それでは問題はどこにあるのか？問題は、この不具合に一番向き合わなければならない「サポート」に何のツールも解決手段を与えられていないことだ。つまり、サポート自体が、ユーザーの行動を自分自身で追跡できれば、優先度は、緊急のまま、問題に向き合うことが出来る。つまり、サポートがユーザーの行動ログを直接見ることが出来れば、実際そのユーザーがログインに失敗したのか、その現象は今での起きているのか？それとも、その問題はもう収まったのか、サポート自身が知ることが出来る。

なぜサポートはログが見られないのか？ †

多くの場合、サポートにコンピュータースキルは備わっていない。そのため、本番のサーバにログインして、色々いじくられるのは都合が悪いし、サポート自身にも、負荷が高い行動だろう。確かに、ユーザーの行動ログが本番サーバにしか無ければ、サポートのそれを触らせないほうが良いだろう。しかし、行動ログが、別に安全なマシンに転送されており、サポートはそれを見ることだけ出来て書き換えられなければどうか？つまり、ここで上で言っていた、fluentdとcasandraと言う話に繋がっている。

fluentdとcasandraによるリアルタイムログ収集解析ツール †

fluentdと言うログ収集サーバがある、様々なサーバに、ログ収集の機能を付与して、ログを収集し、他のストレージやRDBMS,NoSQL,HDFSにデータを蓄積できる。 図示すると以下のようになる。

図はこちらを参照、改変した。

このうち、casandraにデータを入れることを考えてみよう。 本番サーバで生成されたログは、fluentdを通して、リアルタイムで、casandraに蓄積される。その際、ユーザーIDとタイムスタンプをキーとして持たせておく。一行一レコードとして、データを突っ込む。 サポート向けには、webインターフェースを、用意して、問い合わせのあったユーザーIDを入力してもらう。タイムスタムプで、ソートされたユーザーの行動一覧が表示される。 そこにはいつログインし、いつ書き込みを見、いつコメントを書いたかと行ったユーザーの行動が記載されている。サポートはそれを手がかりに、ユーザーがどの行動を起こして、現在はどのような状況にあるかログから推測して行く。ログインできないと言う問い合わせがあった後、ログインしていれば、一応その後のログインは成功したと推測できる。

サポートが本当に欲しい情報とは †

サポートがまず第一に欲しい情報は、ある問題が起こったかどうかででは無い。その問題が現在も継続して起こっているかどうかである。もし、あるユーザーが問い合わせのあった時にだけログイン出来ないのであれば（現在はログインで出来ている）、それは問題であるが、まだ一呼吸置いて対処できる問題だ。しかし、現在もログインできないのであれば、それは何を置いても解決しなければならない問題になる。それは、エラーの行からは分からない。その後、行動が無いことで判断するしかない。しかし、その情報は、開発者やインフラからもたらされることは無い。彼らにそのような視点は無いからだ。

つらいサポートを緩和するために。 †

ユーザーがサービスに関して限定的な知識しか持たないようにサポートも限定的な知識しか持てない。なぜなら、開発やインフラから限定的な情報しか与えられないためだ。 でも自分自身で、情報を得られるなら、その様相は一変する。

1. 「ユーザーはアイテムが使えなかったと言っているが、ログには使用した旨書いている。つまり、思い違いをしているかもしれない」
2. 「ユーザーはログインできないと言って、確かにその時間にエラーが起こっている。しかし、その2時間後、ログインに成功している」

ユーザーに関する様々な情報がワンストップで、サポートの手に入れば、サポートは少なくともユーザーと同じように右往左往することは無い。 そのために、サポートには、ワンストップでログを一覧できるツールが必要なのだ。

#blog2navi()