ネットワーク監視ツールの導入失敗例
失敗例１．目的と異なるツールであった
監視する現場とツールを選定するチームが別部門であった際に発生しやすい失敗例です。監視現場で将来を考えて多機能なツールを選定したものの、目的とする監視機能が付属機能で使い物にならなかった例もあります。
ネットワーク監視は多くの機能を備えています。たとえば、死活監視、遅延監視、経路監視、状態監視、ソース監視、帯域監視などです。さらに統合監視ツールになると、サーバの監視、データセンターにある仮想サーバの監視、アプリケーションの監視まで対応します。多機能になるとそれなりに高価なツールになり、利用現場では投資対効果が求められます。
ところが、ツールには得手不得手があり、その選択を間違えていることが少なくありません。多機能だから何でも得意というわけではないのです。
たとえば、帯域監視をしたいと現場では考えていたとします。これに対し調達側はSNMPに対応する多機能なツールを選定しました。SNMPは機器の詳細は情報を得ることができ、ネットワーク監視を効率化します。
しかし、その情報収集にはネットワーク機器の大きなCPU負荷がともないます。ネットワーク帯域を1分間隔で監視しようとすると、ネットワーク機器に大きな負担がかかり、逆に障害となりかねません。同社では帯域監視のために、追加でsFlow対応のツールを購入せざるを得ませんでした。ずいぶんと高価な監視ツールの購入となってしまいました。
失敗例２．鳴り止まないアラーム……
ネットワーク監視装置は24時間365日の監視が基本となっていますが、その間、ずっと人間が張り付いているのは不可能です。目視では見逃してしまう異常値もあります。そこで、ツールにはしきい値を越えるとアラームが鳴る、あるいはアラートメールを飛ばす機能が用意されています。これに振り回された企業がありました。
同社では、導入当初しきい値の設定がよくわかりませんでした。しかし、ツールには推奨するしきい値が初期値として設定されています。開発事業者が推奨するしきい値だから間違いはないだろうとそのまま運用を開始したら、アラームが鳴り続けます。
管理者はこのアラームの確認に追われることになりました。アラームの内容がわかってくるにつれ、しきい値の設定がふさわしくないことが判明しました。おそらく開発事業者は責任追及を逃れるため、低めに初期設定したに違いないと考え、次第にしきい値を下げていきます。それにつれ、アラームの回数も減っていきました。
そしてある日、いきなりネットワーク障害が発生し、ビジネスの継続に大きな影響を与えてしまいました。同社ではしきい値の再設定を、コンサルタントを交えて検討することにしました。
失敗例３．監視業務の属人化
ネットワーク監視ツールは、誰にでもできる標準的な対応が求められます。あまりに専門的で特別の知識やノウハウが求められるツールでは、属人化してしまう危険性があります。ある企業は属人化を回避するため、極めてシンプルなGUIで操作できるシステムを導入し、ネットワークは安定稼働していました。
ところがある日、同社の運用部門でネットワーク管理者の交替がありました。新たな担当者に替わったとたん、ネットワークに障害が発生し、その障害の切り分けができませんでした。そこで、旧担当者を呼び出し、応援を求めます。旧担当者はすぐに「1ヵ月前に設置したWebカメラが怪しい」と、原因を突きとめます。
その1週間後、またネットワーク障害が発生し、このときも旧担当者をすぐに呼び出しました。すると「今A棟でネットワーク機器の更新を行っている。ケーブルの差し違えが原因ではないか」と推測します。
ここで、同社ではネットワーク監視が属人化していたことがわかりました。旧担当者はツールに頼ることなく、自分のカンと経験で障害の発生原因を突きとめていたのです。運用グループでは、初心者でも原因を突きとめることのできる新たなツールの再検討を開始しました。
ネットワーク監視ツールは、正しく導入・運用して、安全で安定したネットワーク運用を目指してください。
