年々難しくなる「障害検知」のコツ：システム管理入門（6）（1/2 ページ）

ITシステムの複雑化に伴い、年々速やかな検知が難しくなっているシステム障害。今回は障害をいち早く検知し、効率的に対処するためのポイントを紹介する。

[谷 誠之（テクノファイブ），＠IT]

「インシデント」と「障害」は別のこと

　皆さん、こんにちは。前回までは「リリース管理」のようなITILっぽいお話もしましたが、今回はITILを離れておおまかに障害管理についてお話をすることにします（とはいえ、ときどきITILっぽいお話もしますのでご承知おきください。ただ、本連載は ITILを勉強することが目的ではないので、ITIL V2、V3のどちらを参照するか、ということまでは言及しません）

　さて今回は、第2回「インシデント管理＝障害対応という誤解」の復習をしましょう。

　第2回では、インシデントとは「利用者がやりたいと思ったことをやれない状態」のことだと定義しました。利用者が「やりたいことをやれない」原因として、最も多いのは「障害」ではないでしょうか。

　一般に、障害は次の3つに分類できます。

◎ハードウェア障害

• 機器の故障
• 停電や過電流などによる機能停止
• 過負荷による機能停止、あるいは応答時間の大幅な遅れ　　など

◎ソフトウェア障害

• 機能的な不具合（データが壊れる、使いたい機能が使えないなど）
• 非機能的なバグ（画面が乱れる、表示がずれるなど）
• ソフトウェアが適切に構成されていないことによるデータの欠損
• ソフトウェア間の互換性のなさによるデータの欠損
• セキュリティ上のぜい弱性を突いた攻撃 　 など

◎ヒューマン・エラーが原因の障害

• 過失による誤操作
• 思い込みや勘違いによる誤操作

　以上のそれぞれが原因の障害は、枚挙にいとまがありません。

　ここで「ヒューマンエラー」も障害に含めていることに注意してください（「ヒューマンエラー」は厳密には、障害を引き起こす「原因」なのですが）。つまり、「ハードウェアもソフトウェアも正しく動作しているのに、作業員が誤操作をしてしまったがために障害が発生する」という類のものです。

　筆者が経験した一例に、「サーバAをシャットダウンしてからサーバBをシャットダウンしなければならないのに、間違えて、サーバBを先にシャットダウンしてしまったがためにサーバAがシャットダウンできなくなった」ということがありました。

　技術者の立場としては「そんなの、サーバAに『サーバBが存在しなくてもシャットダウンできる』機能を付けていない、ソフトウェア的な問題なんじゃないの？」と言いたくなるかもしれません。しかし、そうではありません。信号無視をして交通事故が起こった場合、「信号が赤ならそもそも渡れない、という遮断機のような機能を付けていない信号機が悪いんじゃないの？」と言うのはナンセンスなのと同じです。

　「サーバAをシャットダウンしてからサーバBをシャットダウンすること」という運用手順が確立されており、それを守る限り障害が発生しないことが分かっているのであれば、その運用手順を（過失でも故意にでも）守らなかった場合は「ヒューマンエラー」と言えるのです。

　いずれにしても、障害管理を行う上で重要なことは、

どんなに注意して設計・構築・操作していても、障害は必ず発生する

　という認識を持つことです。

　昔は「うまく行って当たり前、故障しないのが当たり前」という認識がまかり通っていましたが、昨今はそうも言っていられません。IT機器に求めるニーズが複雑化・多様化していくことに起因し、IT機器そのものもますます複雑になってきています。その複雑なIT機器同士がこれまた複雑に接続されているのですから、ますます障害が発生する確率は高くなっていると言えるでしょう。

ITシステムの複雑化とともに、難しくなる障害検知

　さて、障害管理の目的は、おおまかに3つあります。

（1）障害の検知（障害が発生したことを知る）
（2）障害の復旧（障害を元の状態に戻す）
（3）原因の究明と再発防止（同じ障害が二度と起こらないよう努める）

　ITIL的に言えば、（1）と（2）はインシデント管理の役割、（3）は問題管理の役割です。ここでは（1）の「障害の検知」について詳しくお話しましょう。

　障害が発生したことを知って初めて、障害対応が始まります。「障害が発生した瞬間」と、「その障害が発生したことを知る瞬間」との間には、どうしてもタイムラグがあります。そのため障害検知においては、「いかに素早く障害が発生したことを知るか」ということが重要なポイントになります。

　しかし、昨今ではこのトリガがあまり信用できなくなってきている傾向にあります。具体的には、「障害が原因で業務が止まる」ことを防止するため、機器の多重化が進んでいることが挙げられます。また、一部のサーバ仮想化ソフトウェアは、「物理マシンに障害が発生すると、自動的にその物理マシン上で動作している仮想マシンを別の物理マシンに移動させて稼働を継続する」という機能を持ちます。

　つまりハードウェア的にもソフトウェア的にも、「障害発生のタイミング＝インシデント発生のタイミング」とは言えなくなってきているのです。

　障害が発生していることに気付かず稼働を継続させることで、二次障害を発生させたり、多重化しているもう一方の機器に障害が発生してシステムが全滅したり、といった「よりひどい状況」を生む可能性もあります。

（注）　何度も書いていますが、障害＝インシデント ではありません。インシデントは、「やりたいことができない」という状態のことです。障害は、そのインシデントを引き起こす原因のひとつです。例えば「ルータが故障したことでサーバに接続できなくなった」という場合は、「サーバに接続できない」という状態がインシデントで、「ルータが故障した」という事象が障害（ハードウェア障害）です。

　従って、障害をいち早く検知するための管理ツール、いわゆる「障害監視ツール」の導入が必要不可欠となります。障害監視ツールはさまざまなメーカーから多種多様なものが販売されていますが、いずれのツールも障害が発生したことを検知すると、管理者や担当者に電子メールやポップアップメッセージ、画面やパネルの点滅といったの手段を使って通知する機能を持ちます。中には障害を検知すると、機器のそばに設置したパトランプが回り出し、けたたましくアラームが鳴るといったものも存在します。