#blog2navi()
*何故webサービスのサポートは返信が遅いのか。 [#mdb4fa5c]
&color(red){fluentdとcasandraで作る、サポート支援ツール};
** webサービスのサポートは遅い？ [#d26ec563]
webサービスのサポートで、返信が遅いという話を良く聞く。曰く、メールしてもなかなか返事が帰ってこないとのことだ。何故、サポートは返信が遅くなるのか、どうしたら早くなるのか、考えて見た。
** 一般的なサポートの流れ [#m1691d97]
良くあるwebサービスので質問「ログイン出来ない」が、どのように処理されるか見てみよう。
+ ユーザー -> サポート ログインできません
+ サポート -> 企画 ログインできないそうです。
+ 企画 -> 開発 あるユーザーがログインできないそうです。
+ 開発 -> インフラ(本番サーバを触れる人) ログインできないそうです。ユーザーID xxx番で何日のログをgrepしてください。
+ インフラ -> 開発 いやログイン出来ている見たいよ
+ 開発 -> 企画 ログインできているみたいよ。
+ 企画 -> サポート ログインできている見たいよ。
+ サポート あ、すいません。ユーザーID間違えてました。
&color(red){関わる人がすごく多い伝言ゲーム};になる。
理由は二つある。
+ 一つ目は、サポートは、あるユーザーからの問い合わせが、実際のプログラムにどう落とせるか分からず、そのため、開発を必要とする。
+ 二つ目は開発は本番サーバに触れないので、本番サーバのログにある、ユーザーの行動をトレース出来ない。
いきおい、この様な多段の伝言が生じる。
** 自分の職務で無いものの優先順位は、必ず下がる。 [#i140cd91]
サポートは個人ユーザーの問題を解決すると言う職務がある。しかし、他の職種ではそうではない。企画は、面白いサービスをデザインすることが仕事で、開発はそれを確実に実装すること、インフラは、サービスを日々間違い無く運用することが仕事だ。
だから、ログインできないと言う問題の優先度は次のようになる。
+ サポート -> 企画 ''[大至急]''
+ 企画 -> 開発 ''[早めで]''
+ 開発 -> インフラ ''[出来れば早めに]''
+ インフラ の心の中 ''「そのうち」''
これは、個々人の人間の頑張りではどうにもならないと考えるべきだ。自分の職務で無い物の伝言は、''必ず優先度が一ずづ下がる''。これに例外は無い。
** 問題はどこか？ [#aca772fb]
- 個々人の頑張りの問題ではない。
先に、人間個々人の頑張りではどうにもならないと書いた。それでは問題はどこにあるのか？問題は、この不具合に一番向き合わなければならない「サポート」に何のツールも解決手段を与えられていないことだ。つまり、サポート自体が、ユーザーの行動を''自分自身''で追跡できれば、優先度は、緊急のまま、問題に向き合うことが出来る。つまり、サポートがユーザーの行動ログを直接見ることが出来れば、実際そのユーザーがログインに失敗したのか、その現象は今での起きているのか？それとも、その問題はもう収まったのか、サポート自身が知ることが出来る。
** なぜサポートはログが見られないのか？ [#f8dc1c50]
多くの場合、サポートにコンピュータースキルは備わっていない。そのため、本番のサーバにログインして、色々いじくられるのは都合が悪いし、サポート自身にも、負荷が高い行動だろう。確かに、ユーザーの行動ログが本番サーバに''しか''無ければ、サポートのそれを触らせないほうが良いだろう。しかし、行動ログが、別に安全なマシンに転送されており、サポートはそれを見ることだけ出来て書き換えられなければどうか？つまり、ここで上で言っていた、fluentdとcasandraと言う話に繋がっている。
** fluentdとcasandraによるリアルタイムログ収集解析ツール [#pc275644]
fluentdと言うログ収集サーバがある、様々なサーバに、ログ収集の機能を付与して、ログを収集し、他のストレージやRDBMS,NoSQL,HDFSにデータを蓄積できる。
図示すると以下のようになる。
&ref(./fluentd-kousei.png,30%);
図は[[こちら>http://tech.aainc.co.jp/archives/1981]]を参照、改変した。
このうち、casandraにデータを入れることを考えてみよう。
本番サーバで生成されたログは、fluentdを通して、リアルタイムで、casandraに蓄積される。その際、ユーザーIDとタイムスタンプをキーとして持たせておく。一行一レコードとして、データを突っ込む。
サポート向けには、webインターフェースを、用意して、問い合わせのあったユーザーIDを入力してもらう。タイムスタムプで、ソートされたユーザーの行動一覧が表示される。
そこにはいつログインし、いつ書き込みを見、いつコメントを書いたかと行ったユーザーの行動が記載されている。サポートはそれを手がかりに、ユーザーがどの行動を起こして、現在はどのような状況にあるかログから推測して行く。ログインできないと言う問い合わせがあった後、ログインしていれば、一応その後のログインは成功したと推測できる。
** サポートが本当に欲しい情報とは [#oe5201ac]
サポートがまず第一に欲しい情報は、ある問題が起こったかどうかででは''無い''。その問題が''現在も継続して''起こっているかどうかである。もし、あるユーザーが問い合わせのあった時にだけログイン出来ないのであれば（現在はログインで出来ている）、それは問題であるが、まだ一呼吸置いて対処できる問題だ。しかし、''現在もログインできない''のであれば、それは何を置いても解決しなければならない問題になる。それは、エラーの行からは分からない。その後、行動が無いことで判断するしかない。しかし、その情報は、開発者やインフラからもたらされることは無い。彼らにそのような視点は無いからだ。
** つらいサポートを緩和するために。 [#r8eef9c6]
ユーザーがサービスに関して限定的な知識しか持たないようにサポートも限定的な知識しか持てない。なぜなら、開発やインフラから限定的な情報しか与えられないためだ。
でも自分自身で、情報を得られるなら、その様相は一変する。
+ 「ユーザーはアイテムが使えなかったと言っているが、ログには使用した旨書いている。つまり、思い違いをしているかもしれない」
+ 「ユーザーはログインできないと言って、確かにその時間にエラーが起こっている。しかし、その2時間後、ログインに成功している」
ユーザーに関する様々な情報がワンストップで、サポートの手に入れば、サポートは少なくともユーザーと同じように右往左往することは無い。
そのために、サポートには、ワンストップでログを一覧できるツールが必要なのだ。
RIGHT:Category: [[[評 webサービス>日記/Category/評 webサービス]]] - 02:36:24
----
RIGHT:&blog2trackback();
#comment(above)
#blog2navi()
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
