コラム

CTC教育サービス・ホーム　＞　コラム　＞　Windows/Linuxの実践トラブルシューティング　＞　第１回　トラブルシューティングの考え方その1

Windows/Linuxの実践トラブルシューティング

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第１回　トラブルシューティングの考え方その1 (加賀結衣) 2016年9月

こんにちは。加賀結衣（かがゆい）と申します。

このコラムでは、株式会社リックテレコムの「Windows/Linuxのトラブル追跡実践ノウハウ」をもとに、私が実際にPCに触りながら学んだことをまとめていきます。
コラム内のページ表記は、この書籍のページを示します(Pはページです)。
日々発生するコンピュータのトラブルに対し、どのようなツールを使い、どのような情報を収集すればよいか知りたいと思われている初心者の方に、このコラムが少しでもお役に立てば嬉しいです。

第1章　トラブルシューティングの考え方

この章では、トラブルシューティング（問題解決）の考え方について取り上げます。
現在のコンピュータシステムは複雑であり、複数のコンポーネントや技術が相互に作用しあって一つのシステムとして成立しています。
そのため、トラブルの原因は多岐にわたりますが、トラブルシューティングの現場では、
発生するトラブルの原因を特定することが求められます。
利用者から申し立てられるトラブルの内容は、通常は表層のみですが、この、表層に現れるトラブルのみで鑑別しても、必ずしも根源にたどり着くための情報が得られるとは限りません。

ここでは、熟練したシステム管理者が、利用者からの訴えからどのようにトラブルシューティングを進めていくのか見ていきましょう。

1.1 トラブルシューティングのプロセス（p.10)

トラブルシューティングにおいて重要なことは、システムへの期待が満たされなかった場合に利用者が抱く「負のギャップ」を解消することにあります。
利用者が現状のどこを不満に感じたのか理解、傾聴し、その内容を十分に見極めようと留意することが、トラブルシューティングにおける極意と言えます。

1.1.1 「仮説」と「検証」のスパイラル（p.10)

たとえば、「テレビのリモコンが操作できない」とします。
ここではまず、リモコン側のトラブルとして、電池の残量トラブルが発生していると仮説を立てます。このとき、電池残量を計測することで、その仮説を検証することが可能です。

ただし、この指針の取り扱いには注意が必要であり、電池残量が「低」と計測されたからと言って、リモコンが操作できない原因を電池残量のトラブルと断定することはできません。
もしかすると、別のトラブルが随伴しているかもしれないからです。

トラブルは、リモコン側ではなく、テレビの側にあるかもしれませんし、利用者が製作者の意図しない方法で利用している可能性もあります。

このように、ある検証によって原因の絞り込みができたとしても、利用者からの報告内容と何らかの矛盾がないか、症状のすべてが収集した情報によって説明しうるのか、仮説と検証を繰り返していかなければなりません。
そして、仮説の範囲は徐々に広げていくことが望ましいと言えます。

1.1.2　さらに7つのステップに分解してみよう（p.11)

トラブルシューティングのプロセスは、次の7つのステップに分解できます。

①問題認識ステップ
②仮説設定ステップ
③情報収集ステップ
④検証整理ステップ
⑤意思決定ステップ
⑥解決策の実行ステップ
⑦結果評価ステップ

以下、順に見ていきましょう。

①問題認識ステップ

ここでは、何をトラブルととらえて、解決してゆくのかの設定が重要となります。

②仮説設定ステップ

ここでは、対象のシステムについて、あるべき状態を熟知しておくことが重要となります。
あるべき状態と現状のギャップこそがトラブルです。

③情報収集ステップ

ここでは、過去事例や技術資料、検証などを通じて、類似事象を特定することが重要と言えます。
特にその仕様が一般に公開されているOSやアプリケーションを利用したシステムの場合、あなたが遭遇しているトラブルのほとんどは、別の誰かが同様に遭遇しているトラブルであることが多く、この場合、インターネットなどを利用した情報収集により、早期に問題解決できる場合があります。

④検証整理ステップ

ここでは、主観的情報と客観的情報を相互に裏付けし合いながら、システムにおけるトラブルの原因箇所を特定します。

なお、②仮説設定ステップ　-③情報収集ステップ　-　④検証整理ステップ　は、何度か繰り返し実施されることがあります。

⑤意思決定ステップ

検証整理の結果、解決策を実行する前に、システムの利用者を含むステークホルダー（利害関係者）に対して実行の承認をもらうステップです。
システム管理者は、予期せぬ不具合に備えたバックアップ計画を用意するとともに、利害関係者に、解決策におけるリスクについて事前に十分な説明を行っておくべきです。

⑥解決策の実行ステップ

解決策を実行するにあたり、既存の利用者に与える影響を十分に把握しておくことが重要です。
可能であれば、「ステージング環境（本番環境と同様に稼働している環境）」にて解決策の適用テストを実施した後に本番環境に適用するべきと言えます。

⑦結果評価ステップ

解決策の実行後の現状と期待した結果とを比較して評価を行います。

なお、ときにはいったん解決したと思われた問題が再発することがあり、その場合、①問題認識ステップに戻り再びこのプロセスを初めから回しなおすことも検討すべきです。

一連のステップにおいて注意すべきことは、目標設定を見誤らないことです。
それぞれの利用者の動機について明らかにしつつ目標設定を行って下さい。

1.2　何をトラブルとするのか（p.15)

トラブルシューティングにおいてもっとも重要なのは、負のギャップを「インシデント」、「問題」、「既知のエラー」に区別することです。
これらの用語は、ITサービスマネジメントのベストプラクティスであるITIL（Information Technology Infrastructure Library)で定義されています。

「インシデント」とは、サービスの標準の運用に属さない、サービス品質を低下させるあるいは低下させるかもしれないあらゆる事象です。
「問題」とは、インシデントを発生させるおそれのある未知の原因です。
「既知のエラー」とは、既に「ワークアラウンド（回避策）」が明文化された事象です。

1.2.1 「インシデント」「問題」「既知のエラー」の区別と記録（p.15)

ITILの「問題の識別と記録」プロセスにおいては、インシデントレコードをもとに問題レコードを記録することが推奨されています。問題レコードにタイトルを記録する際、重要なことは、タイトルから要点をも読み取れるよう正確な専門用語で、事実のみを並べることです。
回避策が提供されていない新規の問題は、開発部門、または二次サポート部門へのエスカレーションが行われるため、「○○が疑われる」といったあいまいな記載は、不必要に調査範囲を狭め、調査の差し戻しの原因となる可能性があります。インシデントレコードとの紐づけを意識しつつ、トラブル解決までの道のりを考慮してタイトルを記録、変更していきましょう。

1.2.2　「未知の原因」を「物理障害」と「論理障害」に分けよう（p.16)

情報システムにおけるトラブルは、「物理障害」と「論理障害」に分けることができます。

■物理障害とは、物理的な障害に起因するトラブルです。

このような場合、ソフトウェアの修正による回復は不可能であるため、できるだけ早期段階に特定することが望ましいといえます。そこで推奨するのは、トラブルシューティングの開始準備段階において、問診票（基本情報）を作成することです。

問診票の作成とは、対象システムがその動作に必要なシステム要件を満たしているか「基本情報」を確認する作業のことです。確認すべき主なハードウェアとして「メモリ」「CPU」「ハードディスク」「ネットワークアダプタ」などが挙げられます。この作業段階において、ハードウェアに致命的な問題が発生している可能性を完全に排除しておくことが効率的です。

ハードウェアの自己診断機能などはBIOSまたはUFFI上に用意されたハードウェア診断メニューで確認できることがほとんどです。自身のシステムにおいて、どのような手順でメニューを起動するのか、また、そのメニューで何が診断できるのかをあらかじめ確認しておく必要があります。

また、「Ultimate Boot CDhttp://www.ultimatebootcd.com/)」や「Grml（http://grml.org/)」などの、ハードウェア診断に特化したLive CD タイプの OS を使って、物理障害が起きているかどうかについて診断を行うことも有効です。

fig01

■論理障害とは、物理障害以外のトラブル、つまり、物理的な障害に起因するもの以外のトラブルです。

これは、ソフトウェアの修正により改善されることが期待できます。この種のトラブルにおいて、確認すべき基本情報としては、システムに搭載されているOSまたはソフトウェアにおけるバージョン（ビルド番号）や修正プログラムの適用状況などがあります（第2章以降で取りあげます）。
特定の機能に関するトラブルの場合、当該機能に対する設定が正しいことを示し、オペレーションミスがないことをあらかじめ示しておく必要があります（第3章以降で取り上げます）。また、ネットワーク接続に依存するシステムの場合、ソフトウェアとは異なる角度からの調査が必要になることも知っておいてください（第5章以降で取り上げます）。

今日のまとめ

★トラブルシューティングにおいて重要なことは、利用者が抱く「負のギャップ」を解消することにある。
★また、負のギャップを「インシデント」、「問題」、「既知のエラー」に区別することが重要である。

なお、顧客システムを十分に理解し、ネットワーク・サーバ（OS）分野における原因究明の仕方や切り分けなどを行う方法を基礎から学びたい方には、CTC教育サービスのオリジナルコースである「システムトラブルシュート（ファーストステップ）」がお勧めです。本コースはトラブルシューティングという現場経験から学ぶことが多い特殊ノウハウを体系だてて学べる特定のベンダーに依存しないコースとしては唯一のものになります。実践的なトラブルシューティングのノウハウを学びたい方は是非受講ください。
詳細は、以下のリンクをご参照くださいませ。
http://www.school.ctc-g.co.jp/course/SSE01.html

最後まで読んでくださってどうもありがとうございました。次回もどうぞお楽しみに。