あるあるネタで学ぶ、障害対応“7つの鉄則”：システム管理入門（7）（1/3 ページ）

業務を止めないためには、起きた障害をいち早く解決することと、そもそも障害が起きないような備えをしておくことが大切。今回は障害対応を高速化する7つのポイントを、筆者独自の経験における“あるあるネタ”も絡めながら紹介しよう。

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

ITIL v3で「インシデント」の定義がさらに明確化

　皆さん、こんにちは。前回から、障害管理のお話について書いています。と、本題に入る前に――。

　2011年6月30日で、ITIL （注1）v2 Foundation試験の再試験が終了するのはご存じでしょうか？ すでに昨年の6月30日に新規の受験は終了していました。今後は完全にITIL v3に移行します。しかし、当のOGC（Office of Government Commerce：ITILを取りまとめている英国商務局）は、今後「ITIL is ITIL」というキャンペーンを展開していく予定だそうです。つまり、v2、v3という分け方ではなく、“ITILはあくまでもITILだ”ということを強調していくわけですね。

【参考リンク】
OGCのITIL公式サイト

　よって、われわれも今後は「v2、v3のどちらか」という考え方をやめ、「システム運用管理の教科書的な存在である“ITILを勉強する”」というイメージで、ひとまとめにとらえていくと良さそうです。事実、ITIL v3はv2に比べて比較的洗練されている部分もあります。（部分的に）実践していくことを考えると、「よく練られているなぁ」と感じるところもあり、v2に絞ってしまうのはもったいないことでもあります。

　例えば、ITIL v3ではインシデントの定義がほんの少しだけ変わっています。要は「インシデント≒障害」のニュアンスがさらに高まっているのです。

　前回、インシデントとは「利用者がやりたいと思ったことをやれない状態」のことだと定義しました。この定義に基づくと、「そのハードウェアやアプリケーションにはやりたい機能が備わっているのに、取り扱い説明書を読んでいなかったり、そもそも、その機能に到達する手順が難しかったりして、利用者がその機能に気付かない」のもインシデントだ、ということになります（事実、ITIL v2ではこれらもインシデントとして扱っていました）。しかしITIL v3では、このような事象を「サービス要求」と呼んで明確に区別するようにしています。

　一方で、v3では「利用者がやりたいことを継続してやれていても、将来やれなくなるかもしれない事象」もインシデントだということを明確化しています。

　例えば、「機器が多重化されていて、一方のシステムが止まっていても、もう一方が生きているから大丈夫」というような状態だとしましょう。このとき、もう一方のシステムが生きているので、「やりたいことがやれて」います。しかし、その動いているシステムも止まってしまったら、今度こそ「やりたいことがやれない」状態になります。そのような、「そのまま放っておいたら、やりたいことがやれなくなるかもしれない」状態も、ITIL v3 ではインシデントとして扱うことになったのです。まぁ、自然といえば自然なんですけどね。

　ただし、前回解説した「障害＝インシデントではない」ということはITIL v3でも変わっていません。障害は「そのインシデントを引き起こす原因の一つ」です。よって、ITIL v3における「インシデント」の定義をまとめると、「やりたいことができない」状態だけではなく、前述のように、「やりことができない、またはできなくなる可能性が高い」状態

　ということになります。その主たる原因が「障害」だというわけです。

障害対応＝壊れた部分を“迅速に”修理すること

　さて、その「障害」への対応が今回の本題です。障害をいち早く検知したら、今度はその障害をいち早く取り除かなければなりません。この「障害をいち早く取り除く作業」のことを、本連載では「障害対応」と呼ぶことにしましょう。

　ただ、ここで気を付けたいのは、これもやはり第2回で書いたように「インシデント管理＝障害対応」ではない、ということです。インシデント管理の本質は「原状復帰」です。従って、障害を取り除けなけなくても――例えば、壊れたプリンタをそのまま放置して、別のプリンタを用意しても――それは「インシデント管理」である、と言えるのです。

　しかし実際には、（廃棄してしまうなど、そのままにしておくことが妥当な選択肢である場合を除いて）、壊れた機器をそのままにしておくわけにはいきません。よって、きちんと「障害対応」をする必要があります。

　では、その「障害をいち早く取り除く作業」＝「障害対応」とは、より具体的に言うと、どのような対応を指すのでしょうか？ これは基本的に「壊れた部分を修理する」ことを指します。しかも「可能な限り迅速に」。言うのは簡単ですが、実際にやるとなるとこれが難しい。では、なぜ難しいのでしょうか？

　まずは、「壊れた部分を修理する」ための手順を考えてみましょう。以下は一連の手順です。

（1）故障が発生する
（2）故障が発生したことに気付く
（3）故障が発生したことを記録する
（4）故障箇所を特定する
（5）修理、または交換する
（6）故障が直ったことを確認する（まだ直っていない場合は4に戻る）
（7）故障が直ったことをユーザーに通知する

　そう、このそれぞれの手順に時間がかかるから「迅速に」行うのが難しいのです。よって、システム管理者は以上の各工程において「どれだけ時間を短縮できるか」について対策を講ずる必要があります。これが障害対応の基本になります。

（注1）ITIL