はじめに
この世の中に完璧なプログラムやシステムなどはなく、どんなに周到にリリースされたシステムであってもトラブルは付き物です。
不意にトラブルに見舞われたとき、誰しもが問題をいち早く解決したいはずで、担当者間の些細な行き違いにより解決までに余計な時間がかかる、というようなことは絶対に避けたいかと思います。
そこで本記事では、迅速にトラブルシューティングを進めるために「トラブルに直面した側(以降ユーザ側と記載)」と「トラブルを解決する側(以降サポート側)」がどのように行動すればよいのかを、以下の対応ステップごとに示し、少しでもトラブルシューティングのお役に立てればと思います。
1. トラブル発生時の初期対応
2. 不足していた情報の確認とトラブル状況の整理
3. 調査結果の報告と追加対応の実施
4. クローズ処理の実施
現実のトラブルシューティングでは、上記2者以外に問い合わせ窓口や別の担当者が間に入ってやりとりを行うことも多いですが、本記事では単純化のため、2者の視点に絞って記載しております。
間に入る立場の方につきましては、ご自身が「トラブルに直面した側(以降ユーザ側と記載)」と「トラブルを解決する側(以降サポート側)」どちらにより近いかを意識したうえで、遅延なく中継を行うようにして頂ければと思います。
1. トラブル発生時の初期対応
ユーザ側
- いつ
- どのシステム(アプリケーション)で
- 誰が(どんな権限のユーザが)
- 何をして
- どのような問題が起きたのか
- 本来期待する動作は何だったのか
以上を簡潔にまとめてサポート側へ問い合わせをして下さい。また画面の出力内容やログファイル、設定ファイルなどを確保できる場合は、できる限りそれらも一緒に提供できればgoodです。
システムトラブルなんて開発(提供)側の問題なんだから何とかしろ、繁忙期に冷静な対応などしていられるか！というお気持ちも十分理解できますが、トラブルの早期解決にはユーザ側の協力が必要不可欠です。
サポート側もエスパーではないので、いきなり「○○が止まった何とかしろ」とだけ言われても対応に困りますので、どうかご協力頂ければと思います。
サポート側
サポート側へ最初に届いた問い合わせに、必要な情報が全て揃っていることは極めて稀です。またトラブル内容によっては問い合わせ元がパニックに陥っており、一体何を言っているのかがよくわからない、という状況さえありえます。
ユーザ側の対応でも書いた内容ですが、問い合わせ内容に以下の情報が含まれているのかをすぐに確認し、不足した情報があればなるべく早く確保するよう、ユーザもしくはシステム管理者(ログやデータベースがユーザ管理外のシステム上にある場合)へ指示を行ってください。
- いつ
- どのシステム(アプリケーション)で
- 誰が(どんな権限のユーザが)
- 何をして
- どのような問題が起きたのか
- 本来期待する動作は何だったのか
- 画面やファイルに何か出力はされていないか？
- ログファイルはあるか？
- 設定ファイルもしくは設定に関する情報はあるか？
- システム・アプリケーション固有で取得できる情報(データベース等)がないか？
上記内容については予め問い合わせのフォーマットを作成しておき、事前にユーザ側と共有しておくとよいと思います。
問い合わせシステム等を提供している場合は、問い合わせフォームで必要な情報が網羅されるようにしておきます。
もしユーザがパニックに陥っている場合は、サポート側で問い合わせ内容を整理したうえで、ユーザが求めるゴールがどこにあるのか(トラブルの早期復旧が優先か、根本原因の特定が優先かなど)、厳守すべき回答期限は何時かを明確化し、ユーザ側に意識違いがないかを確認しましょう。
2. 不足していた情報の確認とトラブル状況の整理
ユーザ側
サポート側から不足した情報の提供依頼があった場合、なるべく早く情報を提供するようにして下さい。
またよくある事例として、トラブルが起きた後問い合わせを後回しにしてしまい、数日が経過している場合がありますが、トラブルの原因特定が困難になるため、気づいた時点でなるべく早く問い合わせを行うよう、心がけて頂ければと思います。
必要なログがログローテーションにより削除されてしまったり、一時ファイルがOSやアプリケーションの再起動で消えてしまったりすると、トラブルの形跡が消滅して原因の特定が困難になります。
また、トラブルに見舞われてから少し時間が経つことで落ち着きを取り戻した場合、ユーザ側でもトラブルの状況整理を行い、自身が求めるゴールを明確化したうえで、サポート側へ伝えるようにして下さい。
サポート側
ユーザ側から追加で提供された情報を逐次確認し、トラブルの全容を俯瞰します。
この作業は担当者の経験・過去に蓄積されたトラブル事例に基づいた、ある種の職人技によって行われる部分もあり、人それぞれのやり方がありますが、概ね以下のような流れで実施します。
- 過去の事例・類似事象の調査
過去の問い合わせ履歴等から、ユーザから報告されたトラブルと同じか、類似した事象がないのかをまず調査します。同じようなトラブル事例が見つかった場合、その原因と対策、同じ事例と特定するために必要な情報(エラーログの出力パターンなど)を確認します。 - ログ・出力内容の解析
ログファイル等の確保に成功している場合は、"ERROR"や"WRNING"等のキーワード検索を行い、異常を示す形跡が出力されていないのかを確認します。またトラブルが発生した時間帯前後のログの流れを精査し、トラブルが起きるまでにどのような経緯を辿っているのか、トラブルが起きた後にどのような影響が生じているのかを確認します。 - 問題の切り分け
ログファイル等からエラーや不審な挙動を示す形跡が見つかった場合、それが自分達でサポート可能なものか(自前で開発したアプリケーションの出力など)、外部の専門家などに調査を依頼すべきものなのか切り分けを行います。
切り分けが終わったら、それぞれの問題について以下の対応を行います。- 自分達でサポート可能な問題の調査
問題が自分達の開発した範囲で発生していた場合、該当箇所の開発を担当したメンバと連携し原因の特定と修正案の検討を行います。この作業にはそれなりに時間がかかる場合もありますので、サポートと開発担当メンバが別である場合は、最終的な問題解決にどの程度時間がかかりそうか、という点を常に担当者間で共有しておくよう注意して下さい。 - 外部の専門家に調査を依頼すべき問題の調査
OSやミドルウェア、各種フレームワークやライブラリ等に依存したエラーなど、自分達の管理外にある問題が確認された場合、それがライセンス購入済みかつサポート契約を結んでいる製品であれば、速やかに該当製品の問い合わせ窓口へ2次問い合わせ(エスカレーション)を行います。
(システム内で商用製品を利用している場合であれば必ずライセンス購入とサポート契約を締結されていると思います。ライセンス違反ダメ絶対)
オープンソースとして開発されているもの(当然ながら開発コミュニティのライセンスを遵守したうえで使用していることが前提)に関しては、web検索で同様のエラーや類似のトラブル事例、解決策などがないか、特に開発元のコミュニティ(githubやメーリングリストなど)を中心に調査を行います。もし問題が未知のものであった場合は、github上でイシューを起票するなどしてコミュニティに問題を報告し、解決に向けた相談を行います。
外部へ問題を報告する際は、ログなどに機密情報や個人情報等が含まれていないか十分注意し、不要な情報はマスキングするようにして下さい。
また所属する組織において、外部へ問い合わせを行う場合のルールが定められている場合は事前にルールを確認し、ルール違反を行わないように注意して下さい。 - 自分達でサポート可能な問題の調査
3. 調査結果の報告と追加対応の実施
ユーザ側
サポート側からの回答でトラブルの回避策が提示された場合、迅速に回避策が有効か確認し、トラブルが解決したか否かをサポート側へお知らせ下さい。
もしトラブルが解決しなかった場合は、初期対応でサポート側に伝えるべき内容を添えて、トラブルが解消しなかった際の状況をサポート側へお知らせ下さい。
サポート側
これまでの調査結果をまとめ、ユーザ側へトラブルの回避策を回答します。
もしユーザ側から指定された期限までに原因の特定や解決策の提示が難しい場合(外部への調査依頼や追加開発が必要な場合など)は、これまでの途中経過を報告したうえで、ユーザ側と回答期限や作業の優先度について調整を行います。
回答後にユーザ側からトラブルが解消しなかったとの連絡があった場合は、追加で受領したログなどについて再度 2. の手順にて追加調査を行います。
4. クローズ処理の実施
ユーザ側
これまでの対応を進めた結果、無事トラブルが解消しましたら、サポート側へ問題が解決しこれ以上の対応は不要である旨を連絡して下さい。
(サポート側で対応のための人員を確保している場合がありますので、なるべく早く連絡して頂けるとありがたいです)
またサポート側から対応についてのアンケート依頼などがありましたら、今後の回答品質向上のため忌憚のない意見を寄せて頂ければと思います。
サポート側
最終的にユーザ側からトラブルが解消した旨の連絡を受けたら、対応をクローズしこれまでの調査結果と対応履歴を次回問い合わせ時に参照可能な形で記録します。
もし担当内でgithubのイシュー機能やTracなどのチケット管理システムを運用している場合は、対応開始時点から逐次情報を投入し、記録漏れがないようにして下さい。
自前の問い合わせシステムなどを提供されている場合は、アンケート機能などを使用して今回の対応についての満足度調査をユーザ側に対して実施し、次回以降の回答品質改善に繋げるようにすればなおよいかと思います。
おわりに
以上、簡単ではありますがトラブルシューティングの一連の流れに沿って、各担当者がとるべき行動の指針を書かせて頂きました。
本記事はかつて私がテクニカルサポートの現場にいたときの経験を元にしておりますが、よりよい方法やもっとこうすべきというご意見もあるかと思いますので、是非ともコメントでご教示頂ければと思います。