こんにちは、四ツ屋です。
最近SQL関係の記事ばっかりだったので、ちょっと今日は気分転換に、システム管理者向けの不具合切り分け方法をご説明したいと思います。
ニッチな記事のような気はしますが、このブログ自体がニッチなところだという自覚があるので・・・(笑)
あなたはシステム開発会社のカスタマーサポートです。
ある日のこと、いつものようにお客様から問合せが来ました。
さて、あなたは一人で問合せをクローズまでもっていけるでしょうか?
最も重要なことは、状況を正確にヒアリングすることです。
サポートをする上で最も重要な能力で、これさえ出来ればあとはぶっちゃけ、何とでもなります。
自分で対応を判断しかねる場合でも、ヒアリングさえできていれば他の人に助けを求めたときのパスが圧倒的にスムーズになるからです。
しかし実は一番むずかしいのが「ヒアリング」です。
問い合わせてくるお客様のシステム理解度によっては何を言っているのかわからない!ということも少なくありません。
人によっては、なんかもう言ってることが支離滅裂だってこともしょっちゅうです。
もちろん、支離滅裂なサポート窓口の人もいますが(笑)
・・・では、一体どのようにして問合せを処理すればよいでしょう?
■原因究明が先?代替案が先?
問合せの内容には緊急度が高いもの、重要度が高いもの、様々なものがあります。
お客様からの問合せでは「今すぐなんとかして!」というものが少なくありません。「いつでも良いけど見ておいて~」なんて、滅多にないですよね?
しかし、何でもかんでも「今すぐ!」は難しいですし、「なるはやで!」って言われてしまうと他のタスクに忙殺されて放置し、怒られてしまう・・・なんてことも。
※注)なるはや=なるべく早く、の略ですが、最近じゃお客様からのメールででも頻出の略語ですね。
まずは何よりも、緊急度の確認が重要です。
お客様の作業は止まってしまいませんか?
あと一時間で、セールが開始されるのに間に合わない!なんてありませんか?
急ぎの問合せや、緊急事態が発生している場合には、まずは深呼吸。
解消しなければならないリミットがいつなのかということを確認しましょう。
リミットが迫っているにも関わらず原因が分からないようなケースでは、代替案を提示するなどして時間を確保し、その上でしっかりと原因究明と対応を行うことも時には必要です。
様々な事案を個別に判断する必要がありますが、何よりもまずは緊急度を確認することが重要です。
※急がない場合には?※
急がない場合は、じっくりと腰を据えて原因の究明ができます。
しかし急がないといって、何日も音信不通のまま放置しておくのはいけません。
サポートのメンバーにとっては何社も取引しているうちの一人のお客様かもしれませんが、お客様にとっては困りごとがあるからこそ問合せをしているのです。
原因の調査が難航していても、その進捗の報告を待ちわびています。急がない場合だとしても、折に触れて進捗の報告などをしましょう。
■調査するには?
調査できる時間を確保したら、腰を据えて調査をしましょう。
問合せには様々な種別がありますが、基本的に運用が軌道に乗っているシステムの場合、ざっくりと下記の内容に分けられます。
<意図した動きをしない・不具合・エラーが発生している場合>
・システム上の不具合(バグ)
・お客様の運用上の操作ミス
・設定内容のの変更
<質問や要望の場合>
・運用方法の変更や新施策に伴う機能利用の方法について
・新機能・オプション機能の適用について
・エンドユーザからの問合せについて
ざっくりとはこんなところかと思いますが、もちろん複合しているケースもあれば、特定の操作によって発生する不具合などのケースもあります。
まずは不具合やエラーに関するものから紹介していきましょう。
■不具合の調査
不具合が発生している場合に確認すべき内容を見ていきましょう。
【1.不具合内容の確認と正常な状態を想定】
・画面上でエラーの表示が出ている
・画面が遷移しない、動かない
・表示されている内容がおかしい ・・・など。
できれば実際の画面を見るのが一番ですが、できない場合にはどのような表示がされてしまっているのかを文章やキャプチャなどで確認しましょう。
自分の環境で確認できない場合には、お客様にキャプチャ画像を送ってもらうこともアリです。
その際には必ず、「あるべき姿」がどういう状態なのかを想定しておいてください。
最終的にどのように動いているのかが正しいのかをお客様と認識のすり合わせをし、他の人に説明できる状態であることが重要です。
(システムの仕様をきちんと理解していることが前提です・・・)
なお、この時点で過去に前例がないかを確認するのも良いでしょう。
その場合には所属しているサポートチームごとにナレッジをもっている可能性があるので、関連する単語で一通り調べてみましょう。
【2.発生手順と状況を確認する】
・いつ、誰がどのような手順で操作をおこなったのかをお客様に確認する
・操作ログ、アクセスログ、IISログなどを確認する
その不具合がどのような操作手順で発生したのかを知ることは原因究明の有用な手段です。
操作手順を知ることで、原因がわかるケースはとても多いのです。
もしログを落としているのであれば、各種ログを確認することで実際にどのような手順で操作をしていたかを確認することも出来ます。
ログを落としているシステムであれば日頃からログを見る癖をつけると、いざという時に役に立ちます。
【3.再現できるかどうかを確認する】
・まったく同じ操作を同じ環境で実施して再現するか
・同じ環境で行えない場合にはテスト環境、開発環境などで実施
手順を確認したら、その手順で再現できるかどうかを確認しましょう。
再現してしまえば、原因はほぼ掴めたと言ってもよいでしょう。
常に再現しない場合には、問合せされたお客様のに再度発生するかを確認し、お客様側の他の担当者の端末で発生するかどうかを確認することも有効な手です。
不具合が再現しない場合は、特殊な操作をおこなった、端末特有の不具合、ネットワーク等インフラの状況、同時刻にバッチ処理が行われていたなど、想像だにしない原因であるケースがあります。
最も厄介なのが、再現したりしなかったりするケースです。最悪です。
この場合にはもう周りに助けを求めるようにしてください。
同じ手順を繰り返すことによって再現する特定の条件が分かることもありますが、一人で悩むとドツボにハマるのでオススメしません。相談大事です。
================================
これだけの手順を踏んでも分からないケースは沢山あります。
最後まで分からないけどなんとなく発生しなくなった、とかいうこともあります。
しかし、ここまで一人で確認でき、内容と結果の説明が出来るようになると、他の人に助力を求めやすくなります。
特に技術者は、よく分かってないのに「どうしたらいいですか?」って訊いてくる人を嫌う傾向にあります。
ある程度は自分で情報を拾い集め、それをまとめた上で、何が正しい状況であるのかを説明できるようになっておいた方が良いです。
次回は、技術畑に生きる人々への「調査、お願い♡」の仕方をやります。