今回の記事では、主に企業の情シス向けとして、ヘルプデスクにおけるトラブル対応や、システム障害などのシステムトラブルが発生した場合に実施する「トラブルシューティング」に関するコツや、気を付けないといけないポイントを紹介していきます。
初めに
企業の情報システム部門で働いていると、日々色々なトラブルの報告が舞い込んできます。
- 業務システムが動かない
- ネットワークが繋がらない
- パソコンが起動しない
- サーバーが不安定
- マルウェアに感染した
などなど・・・。
トラブルの対象としては、ユーザーが使用するパソコンに纏わるトラブルから、サーバーや社内全体のネットワークといった規模の大きい、且つ高度なトラブルまで幅広く発生します。
今回の記事では、主にヘルプデスクなどで、ユーザーが使用するパソコンに関するトラブルやシステム障害などの問い合わせを受けたケースを想定していますが、トラブル対象はサーバーやネットワークなどのより規模の大きいものや、ベースとなる技術が高度なものであっても、「トラブルシューティング」において注意すべき点やコツは同じです。
また、情シスに限らず、普段ヘルプデスク的な業務をしていない技術者であっても、トラブル対応の経験が少ない場合は、今回の記事における「ユーザー」を「顧客」と読み替えてもらえれば、そのまま同じように参考にしていただけると考えています。
情シスにおけるトラブルシューティング能力向上のすすめ
トラブルが発生している現地で確認ができる状況であれば切り分けもやりやすいのですが、遠隔地だったり電話のなかで対応をしないといけない場合も多く、こういった対応を的確に実施するにはある程度の経験と、ITに関する基礎的な知識なども必要になり、トラブルシューティングに不慣れな人にとっては非常に労力が掛かる業務の一つです。
ただ、このようなトラブルは汎用的なケースも多く、コツやポイントを掴むことで、他社や他のIT業種でも通用する立派なITスキルになります。
今回の記事では、社内のユーザーからトラブルや障害の報告を受けた場合に頭に入れておきたいトラブルシューティングのコツや注意点、ポイントを紹介していきます。
是非今後の業務の参考にしてください。
トラブルシューティングにおけるポイントや大事な考え方
当項では、トラブルの問い合わせがきたり、障害に対応する場合に、意識しておく必要のあるポイントや、必ず守るべき原則、考え方を紹介していきます。
報告内容を鵜呑みにしない
問い合わせや報告をしてきた人は、大抵ITに対して知識の浅い場合が殆どです。
その為、自身が遭遇している現象を客観的、且つ正確に説明してきていることを期待してはいけません。
トラブルシューティングに慣れていない場合、報告内容をそのまま受け取り、原因を切り分けていってしまう場合も多いのですが、その報告自体が正確ではなかった場合、初動でまったく見当違いの対象を調査してしまい、原因の特定や解決までに大きく回り道をしてしまう可能性は大きいです。
よって、まずは
■インターネットに繋がりません
→実際にはインターネット接続に不具合は発生しておらず、ブラウザでアクセスしようとしたWebサイトのトラブルやブラウザの設定上のトラブルといったケース。
■業務システムが動かない
→「動かない」という報告が既に間違っており、実際にはNumロックキーなどで文字入力ができておらずシステムにログインできないだけといったケース。
「正確な報告」と「誤った報告」を判別する一つの手段としては、報告内容に矛盾点が有るか否かに着目することも効果的です。
不正確な報告には、必ず内容に「矛盾点」が生まれます。
問い合わせを受けて現象や状況をヒアリングする際には、その「矛盾」に注意し、もし「矛盾点」を発見したら、そのままその報告を聞き流すことはせず、必ず相違している内容のどちらが正しいのかを確認していきます。
適切な対応をするには、正確な情報が必要です。
相手の「主観」に基づいた情報ではなく「客観」を重視した正確な情報を引き出しましょう。
トラブルの対象範囲や影響を正確に把握しよう
トラブルを切り分ける為には、その報告を受けたトラブルの対象範囲や影響を正確に把握する必要があります。
前述したように、ユーザーは大まかで主観が混ざった報告をしてきます。
ネットワークのトラブルとして報告をしてきたが、実はブラウザの問題かも知れないですし、ネットワークとは関係のないパーツの故障や不調かも知れません。
そもそも何の障害も起こっていないかも知れない。
その為、その報告内容に対して、以下の様な確認をしながら、具体的なトラブルの対象や影響などを把握するようにします。
- 何を持ってそのように感じたのか？
- 普段と今では具体的にどう違うのか？
- いつからその現象が発生するようになったか？
- 過去に同様の現象が発生したことはあったか？
- 自身の端末だけで発生しているのか、周囲の端末でも同様に発生しているのか？
これらの質問内容のポイントは、
客観的な事実を引き出していくことで、そのトラブルの正確な対象範囲や、実際に起きている現象の影響範囲を把握することができ、その後の対応を適切に検討することができます。
客観的な事実を確認するための質問を投げ掛けよう。
「なぜ？」「いつ？」「どこ？」は確実に確認していきましょう。
対応履歴を可能な限り記録に残そう
トラブルの問い合わせを受けて対応をして解決する。
それを繰り返していくことで、自身の知識として定着していきます。
ただ、多くの問い合わせを受けるにつれて感じるのは、トラブル内容はパターン化されており、過去にも同様の問い合わせを受けて同じような対応をしていることが結構多いということです。
一見すると異なる事象にも見えるが、結果的には同じ原因で発生しているといったケースもあります。
問い合わせを受けて、すぐに対応方法が思い浮かばない場合に、過去の対応した履歴を振り返り、そこから対応方法のヒントを得ることができる場合もあります。
また、貴方がチームで問い合わせを受けているなら、記録に残した事例をチーム内で共有し、全員の知識になります。
また、履歴を分析することで、頻繁に問い合わせがくるトラブル内容の傾向を見つけ出し、そのトラブルがそもそも発生しないような対策を講じることもできます。
様々な業務を掛け持ちしながら、トラブル対応をしていることが大半であり、対応が完了したら、すぐに次の仕事に取り掛かりたくなるものですが、そこはいったん手を止めて、対応した内容を記録に残していきましょう。
その為に必要になる時間は、長文で細かく書くことをしなければ、せいぜい5分もあれば十分です。
記録に残すことで、個々のトラブルは「ノウハウ」になります。
その未来の「ノウハウ」を捨ててしまってはもったいない！記録していきましょう。
現象に対して原因の仮説を立てて行動しよう
トラブルの報告を受けた際に、その与えられた情報や確認できた事実から、その現象に対する原因と、その原因から今に至る経緯を推測します。
それを当項では「仮説」と定義しています。
その仮説が合っているかは、実際に行動に移して検証します。
仮説が合っていれば、それが自身の経験として身に付き、間違っていれば別の仮説を立てて検証をすることを繰り返します。
「仮説を立てる」とは、トラブルの原因について以下の様に、論理的に推測をすることです。
トラブルの状況や事象を確認→この事象は〇〇に起因して発生しているかも→その場合は〇〇を変更すれば改善する。
逆に、適切に仮説を構築できていない場合は以下の様な対応になります。
トラブルの状況や事象を確認→よくわからないけど、以前に同じような現象で〇〇を触ったら改善したからやってみる
これでは、改善するまでに何度もトライアンドエラーを繰り返すことになり、仮に改善したとしても、トラブルの現象に至る過程や原因はわからないままになってしまいます。
トラブルの事象を元に、必ずそこに至る過程や根本の原因に対する仮説を立てて行動するようにしましょう。
トラブルシューティングが上達するということは、仮説の精度が上がっているということ。
論理的な仮説を発想できるようにトレーニングしていきましょう。
原因追及に固執せず復旧することを優先しよう
トラブルが起こった場合に、その原因の調査をします。
調査をすることで原因が判明し、その原因を対処することでトラブルが解消します。
ただ、トラブルによっては、原因の解明に時間が掛かり、迅速な障害の解消が難しい場合もあります。
真面目で論理的な人は、根本的な原因を解消しないと意味がないと考えがちです。
その為、障害の解消より原因の解明を優先しがちですが、ユーザーからしたら根本原因の解明はどうでもよくて、それよりも今すぐに使えるようにしてほしいと考えています。
原因の予測ができており、トラブルの解消のできる目途があれば良いですが、もしすぐに原因の解明が出来なさそうであれば、すぐに対応を切り替えて、応急処置的な対応でも良いので、まずはユーザーが使用できる状態にすることを優先しましょう。
その応急処置で、例えばネットワークやシステムが30分しか使えるようにならないとしても、その間はユーザーが作業を再開することができます。
また、その30分の間に、原因の仮説を立てたり、対応するための時間を確保することができます。
トラブルに直面するとついつい焦ってしまい、ユーザーの業務を止めないという原則を見失いがちですが、そこは気持ちを切り替えて、代替案を検討し早急にユーザーがネットワークやシステムを利用できる状況に戻してあげることを優先してください。
ユーザーの業務を止めることで発生する経済的損失は重大です。
ユーザーの業務を長時間止める可能性があれば、応急処置でも良いのでユーザーの業務を継続させることを優先しましょう。
障害の痕跡や証拠を取得して後から調査できるようにしておこう
前述した通り、トラブル時やシステム障害時には、原因の追究や解明よりも、まずはシステムやネットワークを利用できる状態にして、業務を継続させることが必要であると紹介しました。
ただ、原因の追究や解明をする必要がない訳ではありません。
原因の追究や解明を疎かにしてしまうと、同じトラブルや障害を防ぐことができず、再度同様の事象を発生させてしまう恐れがあります。
よって、システムやネットワークを利用できる状態に迅速に持っていくに場合でも、
ここで記載した「記録」とは具体的には以下の様なものです。
- 業務システムでエラーが発生した際のスクリーンショット
- 再起動などに伴って削除される揮発性のログ
- 時間が経過すると不鮮明になる発生当時のユーザーの操作手順や状況
- システム障害時における表面上で確認できる異常な挙動
などなど・・・。
この様な記録を取得しておくことで、いったん復旧をさせた後に、その原因の調査も行えます。
また、そのトラブルや障害の発生元のシステムやネットワークを他社のベンダーなどで構築していたり、管理を委託していた場合などは、障害の証拠としてこれらを提出することが必要になります。
トラブルや障害に対峙している状況下では、冷静さを欠くことも多く、ユーザーからのクレームやプレッシャーなどから、後ほど実施すべき原因の調査を考慮しないまま、先に復旧作業だけを実施してしまった場合に、調査に必要な情報が何も残らず原因がわからないままという事態は避けなければなりません。
復旧を優先することは大前提ですが、後から調査が行えるように状況がわかるデータを取得しておくことはとても重要です。
残さないといけないデータと後からでも確認できるデータを判別できるように備えておきましょう。
根拠の存在する対応を実施しよう
トラブル時によくある発想として「取り敢えず再起動しよう」というケースがあります。
これ自体は効果的な場合も多いのですが、状況や対象によっては、再起動を実施することで障害を広げたり、調査を妨げる恐れがあります。
例えばパソコンの再起動といったケースであれば、それによるリスクは小さく、再起動に起因して何らかの問題が発生したとしても、対象はそのパソコンのみで限定的です。
また、再起動をしている間に、対応方法を検討する時間を稼ぐといった別の目的でも実施される場合もあります。
ただ、サーバーのサービスやサーバーそのものを再起動するといった場合は、それをすることでサービスが起動しなくなる、又はサーバーそのものが起動しなくなるといったリスクもあり、そうなった場合の影響ははかり知れません。
また、前述したように、後から調査をするためのログや状況などの客観的な証拠が消失してしまう恐れもあります。
再起動以外の対応でも同様ですが、対応内容に対して明確に改善する根拠を持った状態で実施することが大事です。
「よくわからないから取り敢えず〇〇してみよう」
といった無計画な対応を真っ先にするぐらいであれば、
前述した通り、必ず「仮説」を立てて、根拠のある対応を心掛けましょう。
原因に対する仮説のないまま実施する対応は、昔のブラウン管テレビが調子悪いときに叩いて直す行為と同じです。
技術者らしく、論理的な根拠に基づく対応を行う様にしよう。
基本的なIT知識の習得も併せて進めよう
トラブルシューティングをするにあたって、正確な原因の切り分けや対応方法の検討をするにあたって、最終的に必要になるのは「ITに関する知識」です。
医者が大学で専門的な教育を受けて試験に合格し、その知識を根拠に患者との診察時に適切に診断が下せるのと同様に、IT技術者がトラブルの原因となっている技術や部品などの専門的な知識がないままに、適切な切り分けを実施することは困難です。
トラブルやシステム障害の対象によっては、高度なIT技術や知識が必要になりますが、ユーザーが使用するパソコンに纏わるトラブルといったレベルの内容であれば、例えば「ITパスポート」などのIT技術者の入門資格レベルの知識があれば、適切な対応方法の検討が十分に可能です。
トラブルシューティングは経験を重ねることで、様々な障害事例が知識として蓄積されて対応能力も向上しますが、その能力を更に押し上げるには、ベースとなるITに関する基礎的な知識の習得は不可欠です。
トラブルシューティングは一つの技術ですが、その精度を高め広げるには、ベースとなるIT知識の習得は不可欠です。
貪欲に学習しましょう！
最後に
今回の記事では、企業の情報システム部門向けの内容として、「トラブルシューティングのポイント」を紹介してきました。
IT技術者として、大きくスキルアップしたりや経験値を得ることのできる経験の一つとして、トラブル対応やシステム障害対応があります。
トラブル対応やシステム障害対応を何度も経験することで、それらに対して臨機応変に対応する能力や、過去の事例を参考に、それらを未然に防ぐ能力が備わります。
また、大きいプレッシャーのなかで冷静に調査や対応を進めるタフな精神力も身に付きます。
これらの能力はIT技術者にとっては非常に重要です。
所謂「ベテラン」や「凄腕」の技術者達は、このような経験を何度も乗り越えてきています。
よって、もし貴方がトラブルやシステム障害に対して対応を迫られる状況になった場合には、積極的に関わるようにしましょう。
苦労したり努力したことは、必ず未来の自分自身に対する成長の糧になります。
果敢に挑戦してください。
それでは、今回も長々と読んでいただきましてありがとうございました。
また次回もよろしくお願いします。
