IBM 現場SEのITな日々

IBM現場SEが日々駆使している技術、現場SEの経験・知見を綴るブログです

(⭐︎か)問題解決へのアプローチ

問題解決(障害)について

ITエンジニアには障害対応がつきものです。

ここでは、我々が問題解決を行う場合について整理してみました。

1. PD/PSI
1.1 PDとはProblem determination で、問題はハードウェアかソフトウエアか のプロセスで切り分け後はそれぞれの専門家が対応します。
1.2 PSIとはProblem Source Identification で、PDでソフトウェアが原因である場合に、OSかミドルウェアかアプリケーションか を切り分けます。
その後はそれぞれの専門家が対応することになります。

2.問題解決のアプローチ:フローチャートか仮説検証か
問題解決には大きく分けて2つの方法があるように思います。
既知の問題であれば、フローチャートによる問題解決は有効ですが、複数の原因が絡むような未知の問題には仮説検証法でないと対応は難しいでしょう。

2.1 フローチャート または枝分かれ問題解決法
 例: Aのランプはついているか?
     Yes: Bのランプを見る
     No: Cのランプを見る
と、問題解決の手順に沿って原因を突き止める方法

利点:基本的なスキルはあるが、その分野には詳しくない場合でも問題解決ができる
欠点:原因究明まで時間がかかることが多い
   手順を作成するのが手間がかかる、また技術変更により手順の修正も発生するためきちんと保守しないと役にたたない手順となる

当職が経験した実例:

入社して数年頃、あるお客様で作業をしていたところ、知り合いのCEさんがIBM3540の修理にきました。現象はReadyにならない とのこと
IBM3540 (8 inch Diskette Reader)はその当時でももうあまりない機械でその技術員も修理は初めてのようでした。
やおら保守マニュアルを引っ張り出し、手順に沿ってPD/PSIが開始されました。

1)現象確認 再現性あり
2)手順に沿って、ある接点の波形をオシロスコープで測定 → 波形が出てない
3)手順に沿って、センサー部を視認 → ほこりが溜まっていた
4)手順に沿って、清掃を実施
5)オシロスコープで再度波形を確認 →波形が正常
6)ディスケットを挿入 → Ready となる 修復完了

現場でオシロスコープを使用してPDを行うのを見るのは初めてでしたが、手順が完備されていればIBM3540を知らなくてもオシロスコープの使用法がわかれば解決できるのだな と感心しました。

2.2 仮説検証法
既知の問題であっても、経験が豊富なエンジニアであればこちらの方が解決までの時間は早いでしょう。複雑な問題でフローチャートではたどり着けないような問題へのアプローチではこちらが有効と思います。

1)問題を特定する 何が問題か、何を解決すべきか を特定する
2)情報を集める どのような現象か? 最近どこか変更を行ったか? 発生条件はあるのか?
3)問題の仮説を立てる XXが不足している? YYのバージョンが古い? ZZの手順が正しくない? 
4)3)を検証するための調査を行う
 → 調査結果が仮説と合わない => 別の仮説を検証する
5)仮説が立証される => 対策を施す

利点:結果を得るまでの時間は短い(一般的に)
欠点:問題解決にあたるには、ある程度の経験やスキル、及びアプローチ方法を理解する必要がある。

次は、この仮説検証法についてもう少し深く説明してゆきます