システム運用では、原因究明より大切なことがある：システム管理入門（8）（1/3 ページ）

システムに異常が発生した際、原因を究明することも大切だが、そればかりに気を取られてしまうとITシステムにとって最も大切な「業務の遂行を安定的に支える」という要件を無視することになりかねない。

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

インシデント管理の本質は現状復帰。原因究明ではない

　皆さん、こんにちは。今回は、障害対策の第3回目、原因究明と再発防止に関してです。ここまでさんざん「インシデント管理＝障害対応」ではない、と書いてきました。しつこいようですが、これは非常に重要なことなので今回も繰り返します。

　インシデント管理の本質は原状復帰です。この中には、原因の究明も、故障部分の修理も、本質的には含まれません。ただ、インシデントの原因がどこに潜んでいるか、という「切り分け」は行います。メールが送受信できなくなった、というインシデントに対して、メールサーバが悪いのか、ネットワークの経路のどこかが悪いのか、クライアント側のメールソフトが悪いのか、はたまた別の場所が悪いのか、という「インシデントの元になった場所の特定」はやらないといけません。

　その上で、どうすれば原状復帰できるかを考えます。すでにワークアラウンド（一時対応策）があれば、それを適用させます。そうでない場合は、復帰の手順を考えます。もちろん、「修理しないと復帰できない」場合もあるでしょうし、とりあえず「故障した機器を正常な機器に交換すれば直る」とか、「再起動したら直る」といったようであれば、そうします。

　一方、障害対応の基本は、前回も書いた通り「壊れた部分の修理」です。厳密には必ずしも「障害＝故障」というわけでもないのですが、まぁほぼ等しいと思っていいでしょう。これは、可能な限り迅速にやりましょう、と書きました。厳密に言うと、ITサービスを提供する側とそれを利用する側とで、努力目標を作成して合意しておきます。例えば、「最悪でも24時間以内には修理します」ということを決めておき、その時間内の解決を目指すわけです。そのような合意は、SLA（Service Level Agreement）という文書を作成して明記しておきます。

　では、この「修理」という活動の中に、今回お話する「原因究明」が含まれるかというと、これがまた難しい。含まれる場合もあれば、含まれない場合もあるからです。今回はこの点を事例を使って整理してみたいと思います。

お金と時間が必要な原因究明

　これは私がある会社に勤務していたころの、かなり以前のお話です。その会社が存在していたビルは結構古く、今ほどPC やネットワーク機器などが普及するよりもずっと以前（30年ほど前？）に建てられたものでした。そんな私の会社にも、オープンやクライアントサーバの波が押し寄せてきて、1人1台のPCが割り当てられるようになりました。そんな時のお話です。

　私の部署には16台のPCが従業員用に、合計3台のPCサーバが部署内サーバ用に設置されました。部署内サーバはサーバルームではなく、オフィスの空いている席に設置されました。

　しばらくは順調でした。しかしやがて、そのうちのある1台が頻繁に再起動するようになったのです。それも、とても不定期に。何かある操作をすると再起動する、というわけではなく、本当に気まぐれに再起動するようになったのです。

　そのPC のメーカーとは保守契約を結んでいたので、さっそくメーカーに症状を伝えて修理を依頼しました。サービススタッフは、「その“気まぐれ再起動”の原因は電源だ」とすぐに見破りました。「PC内部の電源装置が安定して動作していないから、気まぐれに再起動するのでしょう」と。

　これは想像ですが、もしかしたらそのPCの機種には、そうした電源装置の不具合という症例がたくさんあったのかもしれません。メーカーはさっそく電源装置を交換してくれました。仕事が早いと気分も良いものです。私はそのサービススタッフ（と、サポート体制を整えているPCメーカー）をすごいと思いました。

　これは、電源装置が悪いという「故障箇所の特定と、その修理を行った」という例であり、「なぜ電源装置が故障したのか」という「原因究明はやっていない」パターンです。いや、もしかしたらPCメーカー内部で、「なぜ電源装置が故障したのか」の究明をしていたかもしれません。しかしたいていは、「なぜ電源装置が故障したのか」と原因究明にコストと時間をかけるよりも、疑わしい電源装置を全部取り替えてしまった方がコストも時間もかかからない場合が多く、実際そのようにしてしまうことも多々あるのです。