12 IBM iのトラブルシューティング ～障害の原因を調査し解決するための5つのステップ　｜新・IBM i入門ガイド［操作・運用編］

一般的にトラブルシューティングとは、発生した障害の原因を調査し解決するまでの手順や方法論を指す。障害が発生したら早期解決が求められるのは当然のことである。

しかし早期解決を目指していたはずが本来の目的を見失い、解決までむしろ時間がかかってしまうこともよく見受けられる。そのような事態を回避するためにも、ここではトラブルシューティングの基本的な流れを押さえ、それぞれの段階における作業のポイントをまとめる。

基本的な流れ

図表1は、トラブルシューティングの一連の流れをまとめたものである。

障害発生とは、本来あるべきとおりにシステムが稼働しないことを指す。問題解決にあたっては論理的に、確実にステップを踏むことが重要である。そのためには、ゴールの明確化およびメンバーの役割と責任範囲の明確化を常に意識しておくことを忘れてはならない。

1．状況把握

障害発生の原因としては、さまざまな要因が考えられる。状況把握では、正常時と比較して何がどのように違うのか、現象を正確に把握する必要がある。同時に、障害の発生前後でシステムに変更点が発生していないかどうかを確認する。

変更点は大きく内的要因と外的要因に分けられる。

内的要因は、たとえばPTFの適用、アプリケーションの変更、システム構成の変更（ハードウェアのパーツの交換、OSのバージョンアップ、設定値の変更）などが該当する。

一方、外的要因としては、システムの連携先であるシステムの変更、ネットワーク環境の変更、接続するクライアントの変更（接続数や接続タイプ）などが該当する。

また、障害発生時のシステム環境を正しく理解し整理することも必要となる。たとえばIBM iのバージョン、PTFレベル、ハードウェア／ソフトウェア構成、ネットワーク構成、クライアント構成などである。

最後に、その障害が業務やユーザーに与えている影響も確認する。影響範囲によって、解決に求められるスピード感がおのずと決まってくる。

2. 問題の切り分け

障害として現れた現象については根本的な問題が原因で発生している現象と、2次的に発生している現象がある。全体の中から問題のないところを切り分けていき、問題となっている範囲を狭めて明確にする必要がある。ここで切り分けをせず、場当たり的に感覚で対応を進めると、効率が悪く、かえって解決までに時間がかかってしまうこともある。

問題の切り分けができたら、再現性のある条件を特定し、絞り込んでいく試みを行う。問題の発生条件の絞り込みを行うことにより、原因が見えてくることもある。

3. 原因の仮説・検証

次に原因の仮説を立て、検証する。机上の検証以外に、場合によっては実機を使用して事前に検証できる場合もある。実機検証では効果を見極めるためにも、一度に複数の検証項目は盛り込まず、1つずつ検証する。

実機検証は解決方法の安全性を確保できる一方で、不必要な検証まで実施してしまうケースも見受けられるので、検証のケースを策定する場合には目的を見失わないことが重要である。

また実機検証については実施までに時間がかかることもあるため、原因特定までの時間とのバランスをとる必要がある。複雑な障害や、原因が特定できてもPTF適用が必要などで早急に対処できない障害については、運用面で回避策を検討することも必要である。

4. 対処

検証結果を踏まえ、有効な方法を対処する。一度の対処で解決しない場合や被害を最小限に抑えるために一時的な対処を実施した場合は、前フェーズの「原因の仮説・検証」と「対処」を正常稼働するまで繰り返す。

5. 再発防止

今回発生した障害を事例として、再発防止策を検討し、必要に応じて運用に反映させる。システムが正常稼働したところではなく、再発防止の検討まで行ってはじめて障害が解決し、トラブルシューティングが完了したと言える。

システムを運用する上では残念ながら、何らかの障害は発生してしまう。発生する障害は多種多様であり、障害の規模や種類によって解決にかかる時間も異なるが、各ステップで対応すべき基本的な作業は変わらないことを理解して、問題解決にあたってほしい。