補遺編1 ネットワーク管理のあるべき姿にわか管理者奮闘記(7)(3/3 ページ)

» 2004年07月30日 00時00分 公開
前のページへ 1|2|3       

トラブルばかりで管理しきれない

 とにかく中村君の会社のネットワークはトラブルが多い。トラブルも、部分的にサーバが止まるとか、ネットワークが突如重たくなるなどの大きなものから、IPアドレスのバッティングや、Webサイトが見られない、メールがなかなか届かないなど細かいものまで、毎日毎日これでもか、というくらいトラブルが出てくるのだ。


 もともと全く構成管理されていないネットワークなのだから、トラブルが出ない方が奇跡だ。となると、むしろそのトラブルをどのように管理し、再発防止、類似案件防止などを念頭に置いたうえで、どのように次につなげるかというのが重要になる。

 要員が増えた(増やしてもらえた)ときもスムーズに管理できるよう、複数のメンバーでこれまでの対応履歴を共有できるようにしておく仕組みもこのときに考えておくべきだろう。もちろん、この際に履歴の更新手順も考えておく必要がある。

  • × 日々の対応をしたらしっぱなし。
  • △ 日々の対応を紙にメモする。
  • △ 日々の対応をExcelのワークシートなどで管理する。
  • ○ 日々の対応をWikiやBTS(バグ追跡システム)などで管理。

稼働中のサーバでソフトウェアの検証をしない

小野さん 「ウチで今度売り出すソフトウェアを試したい、って営業から強くいわれたんだよね。そのソフトウェアってメールサーバと連携するみたいなんだけど、いわれたとおりの設定をしただけなんだけどなあ。設定したところでおれ倒れちゃったんだよね。試したいっていうのは久保部長にいわれたのでその辺りは知ってるはずだけど……」


 このようなソフトウェアの検証のために社内インフラを構成するサーバを使ってはならない。きちんと検証用のサーバを別に用意すべきであり、また、検証は通常のインフラとは隔離された専用の検証用ネットワーク内でのみ実施すべきだ。間違っても問題なく動いている通常のインフラには、緊急の問題対策以外で手を入れないようにしておくべきである。

 だが、もし万が一、そういう要請を突っぱねることができなかったとしたら、どうなっても責任は取れない、ということを上司や要請を出してきた相手に納得させるべきだろう。そのサーバの管理責任を要請元が取ること、および、インフラへの影響などをかんがみて一方的に切断する場合もあること、また、接続期限が明記されているといった内容の確認書を取っておくとよいだろう。そのうえで、できる限り素早く復旧する準備をしておき、そこで初めて実験をやらせるべきだ。もちろん「やらせない」で済むのであれば、それが一番良いわけだが。

  • × 実験的な用途に社内インフラを構成するサーバを使用。
  • △ 実験的な用途に社内ネットワークに検証用サーバを接続し、検証。
  • ○ 実験的な用途に実験ネットワークに検証用サーバを接続し、検証。

構成はきちんとメンテナンスしておこう

 常に最新の実物の構成と、それに対応したドキュメントを用意しておくべきだ。その場合、メンテナンスするに当たっての手順もちゃんと定義しておき、担当部門のほかの担当者が知らないうちに構成が変わっていた、ということがないようにしておかないと、同様の事故の再発は防止できない。

※ご注意
本記事はフィクションであり、実在の人物・組織などとは一切関係ありません。


基礎解説記事

  • 5分で絶対に分かるシリーズ
  • 管理者のためのセキュリティ推進室
  • 情報セキュリティ運用の基礎知識
  • Security&Trustウォッチ

全記事一覧から各連載にアクセスできます。



前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。