A社の研究開発部門では、Webサーバ、メールサーバを独自に運用し、Mさんが管理者としてサーバの運用を行なっていた。ある月曜の朝、Mさんが出社すると、みんな口々に「週末からメールが読めないんだけど」と文句をいう。そのうち本社のIS部門からも「そちらの部署からメールが読めないという問い合わせをたくさんいただいていますが」という連絡が。「す、すいません」とあわてて電話を切って調べてみると、メールサーバのディスクが一杯でスプール領域が足りなくなり、メールサーバのプロセスが止まっていることが判明した。そこで、Mさんは不要と思われるユーザーファイルやシステムログを削除してとりあえず復旧させた。
しかし数週間後またメールのトラブルが……。原因はまたもやディスクの容量不足だった。いったいどうしたらいいんだろう?
Mさんがとりあえずでもサーバを復旧させたのは、とてもよいことです。障害が発生したとき、ビジネスを正常な状態に戻すことが管理者にとって一番重要なことだからです。それに加えて、プロセス管理ツールや可用性の監視ツールでサーバの応答を監視し、動いていなければディスク容量をチェック。さらに不要なファイルを削除したりプロセスを再起動したりすれば、今回のようなトラブルは回避できるでしょう。しかし、障害が起こるたびに応急処置を施しているだけでは、いつまで経ってもトラブルは減りません。
そこで登場するのがITILです。ITILはよりプロアクティブ(積極的)な方法で、未然にこうした障害が起こらないような方法を定義しています。ITILは日々の運用管理を記述した「サービスサポート」と中長期的なサービスの管理手法を記述した「サービスデリバリ」の2つから成り立っています。今回はこれらの中にある「キャパシティ管理」や「インシデント管理」、「モニタリング」を中心に見ていきましょう。ITILのうち、キャパシティ管理が目指すのは使用状況データを継続的に測定し、トレンド分析を行なうことです。これにより容量不足が自然増加によるものなのか、突発的な異常値なのかを判別できます。また、いつ、どのくらいのディスク増設が必要かを判断することで、計画的な設備投資が可能になります。
最初のステップは、いつ、どんな事象が発生したのか記録を取っておくことです。専用のノートに書きとめておくのでもよいのですが、あとで検索することを考えるとExcelなどを使ってデータベース化することをお勧めします。面倒ですが、積み重ねていくと事象の発生する傾向が見えてきて(たとえば月曜に多い、午後いちばんに多いなど)、障害の原因を推測する手がかりになります。また、どのような手順で復旧させたかも合わせて記録に残しておきましょう。そうしておけば、もしMさんがいない時でも別の人が対処できます。
こうした障害などのITILでは「インシデント管理」と呼びます。インシデントとは「出来事」や「異変」という意味で、ここではトラブル自体やそれにつながると思われる事象を指します。
「ステップ2 モニタリングと問題解決」へ続く|
|
||||
|
|
|
|
|
|
|
|
||||