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

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

元気なシステムには不用意に手を加えない

　では、どうすればそれぞれの時間を短縮できるのでしょうか。ここからは筆者自身も経験している、運用現場にありがちな失敗談も交えながら順に考えていきましょう。

◎（2）故障が発生したことに気付く

　（1）は少し特殊なので、まず（2）から説明しますが、故障は発生した直後に気付くとは限りません。前述の通り、多重化されているシステムの一方が壊れても、もう一方が生きていればITサービスは稼働し続けます。そのままでは、システムの一方が壊れた、ということになかなか気づかない可能性があります。

　そのため、「故障が発生したことをいち早く検知する仕組み」の導入が必要です。最も一般的なのは、前回も紹介した「障害監視ツール」です。故障が発生したり、故障の原因となる事象が発生したり（前回の例では、サーバ筐体内の温度が異常に高くなるなど）したときに管理者に通知する仕組みを導入します。これにより、故障を素早く検知しようというわけです。

　もう一つは、「普段のトレンドをしっかり把握しておく」ということです。例えば、「あるシステムは月末に負荷が集中して遅くなるが、普段はそれほどでもない」というようなことを管理者が理解しておく必要があります。月末でもないのにシステムのレスポンスタイムが遅いと感じた場合は、もしかしたら故障の前兆かもしれません。

◎（3）故障が発生したことを記録する

　これは故障の履歴を管理するためにも重要です。専用のデータベースシステムでも、Accessのような簡易なデータベースシステムでも、いっそのことExcelでもかまいません。簡単に故障の履歴を入力しておき、後で容易に検索・集計できるようにしておきましょう。記録そのものは面倒ですが、そうした記録があれば「この機械はそろそろ故障しそうだ」というような傾向を把握できます。傾向が把握できれば、「故障する前に部品を交換する」という予防保守の正当性が高まります。結果的にシステムが故障しにくくなるわけです。

◎（4）故障箇所を特定する

　これは時間がかかる可能性の高い作業です。第3回にも書きましたが、一つのインシデントでも故障原因の可能性はたくさんあります。例えば「クライアントPCから電子メールが送受信できない」というインシデント一つ取っても、以下のような可能性が考えられます。

1. クライアントPC上のメールソフトの不具合、あるいは設定の不具合
2. クライアントPCで稼働しているOSの不具合、あるいはOS上の設定の不具合
3. クライアントPCそのものの障害（特にネットワークカード）
4. クライアントPCに接続されているネットワークケーブルの不具合
5. ハブ、スイッチ、ルータなどの通信経路の不具合
6. ファイアウォールの障害、あるいはファイアウォール上の設定の不具合
7. 電子メールサーバに接続されているネットワークケーブル
8. 電子メールサーバそのものの障害（ネットワークケーブル、HDDの故障や容量不足等）
9. 電子メールサーバで稼働しているOSの不具合、あるいはOS上の設定の不具合
10. 電子メールサーバプログラムの不具合、あるいは設定の不具合

　筆者の経験では、故障が発生したとき真っ先に疑うべきは「最近、何か変更したか？」ということです。誰が言ったか、「障害の70％は変更が原因である」という言葉があります。これはあながち的外れでもないようです。気分良く正常に動いているシステムには手を入れるべきではありません。正常に動いていたシステムが突然動かなくなるのは、変更が直接の原因であることが本当に多いのです。

　また、「故障」とは「ハードウェアの不具合」だけではありません。「ソフトウェアの不具合」や「設定の不具合」も広い意味では故障です。機器が突然動かなくなった際、短絡的にハードウェアの故障だと決めつけてしまうと、いつまでたっても故障箇所が特定できない場合があります。

　故障箇所を特定する際に重要なことは、「順番に1つずつ変える。一度に2カ所以上を変えない」ということです。上記の例の場合、通信経路がおかしいと思って、ハブやスイッチなどの機器を別のものに交換してみる、ということがあります。そのときうっかりネットワークケーブルまで交換してはいけません。これも筆者の経験ですが、ネットワークがつながらなくなったことがあります。実際には、ハブの物理的な故障でした。

　筆者は故障箇所を特定するため、機器を順番に別のものに交換して、通信が回復するかどうか調べていました。故障の犯人であるハブを交換してみる際、ついうっかりハブと一緒にネットワークケーブルまで交換してしまったのです。しかもよりによって、その交換した後のネットワークケーブルは中で断線していました。つまり、

壊れたハブ ＋ 正常なケーブル

を

正常なハブ ＋ 壊れたケーブル

　に交換してしまったため、やっぱり通信は回復しなかったのです。「あれー？ おかしいなー？」と思いながら、結局、全ての機器を交換しても故障が特定できませんでした。