問題管理の技法のひとつとして障害の分離と言われていも、 思いあたる人が少ないのではないでしょうか。 しかし、実はよく知られていて、教えられなくても自然と行っている技法です。 一般には、「問題の切り分け」と言われているこの技法は、 ＩＴのさまざまな領域で自然発生的に実施されています。
すぐに思いつく話題だけでも、次の３つを挙げることができます。
・マルチベンダー環境における障害の分離
・ネットワーク環境における障害の分離
・プログラミングにおける障害の分離
マルチベンダー環境における障害の分離
マルチベンダー環境でなくても不可欠な技法ですが、 マルチベンダー環境においては、分析結果が責任の所在、コストの負担、サポート組織など、 技術以外の領域に波及するので、 自分の担当領域以外に問題であることを願いながら障害の分離を行った経験を、 ほとんどのエンジニアが持っているのではないでしょうか。
ネットワーク環境における障害の分離
ネットワーク障害の原因には多くの可能性があり、それらの要因が複雑に絡み合っています。 通信には相手があり、切り分け作業そのものが難しい場合も少なくありません。 ネットワークのトラブル・シューティングに日々取り組んでいる、 ネットワーク技術者の方には本当に頭が下がります。
プログラミングにおける障害の分離
一般には、デバッグと言われています。 バグのないコードを作成できるに越したことはありませんが、 多くの人は誤りを犯します。 個人レベルにおけるプログラミングの生産性に大きく関わるのは、 このデバッグのセンスかもしれません。 悪い箇所を見つけるゲームみたいなものなので、 プログラマの中には、この作業が好きな人もいます。 正直、筆者も嫌いではありません。
この障害の分離を、ITILでは次のように説明しています。
『このアプローチでは、 問題のきっかけとなったトランザクションまたはイベントを、 障害のあるＣＩが識別されるまで、一度に１つのＣＩずつ、 慎重かつ段階的に再実行する必要がある。 再実行の作業はトランザクションまたはイベントの開始時にやり取りを行った最初のＣＩへと進み、 次に、正常に動作するかどうかがチェックされる。 次に、作業はイベントの連鎖にある次のＣＩに進み、 そのCIがチェックされる。 そして、次のCI、次のCIと、障害に遭遇するまで続けられる。 障害を再現できない場合、 トランザクションまたはイベントに関連するＣＩの健全性を問い合わせる、 この技法の変形版を試すことができる。 例えば、１つのＣＩに障害があると考えられる場合、 トランザクションまたはイベント経路の始点から終点の間にある他のすべてのCIの健全性が調査される。』
（サービスオペレーション P100）
ITILは、物事を論理的に説明しようとするため、 かえって伝わりにくくなっているように思います。 「ITILが嫌いな人」や、「ITILが分かりにくいと言う人」の気持ちが分からないでもありません。
次回は、2013/11/25の予定です。
