運用サイクルに取り込んで初めて真価を発揮
ここではデータのバックアップを例にとっているが、もちろん他の目的や手段についても同様だ。事業継続や災害対策だけでなく、コスト削減、運用効率化、情報共有など様々な目的に対して実に多様な手段が提供されているが、それらを導入すれば万事が解決するのではない。システムの導入は外形的に分かりやすい。あたかも何らかの成果を上げたように勘違いしがちだ。しかし、それはスタートに過ぎない。自社のシステムの運用サイクルの中に取りこんで、本来の目的を達成するための歯車として回転させて初めてシステムを購入した意義が得られる。
例えば、ある大手金融機関の災害対策を見ると、そのことが良くわかる。災害対策として国内数カ所にデータセンターを所有するこの金融機関は、毎週のようにプライマリーサイトを切り替えて運用している。ある週に東京の拠点をプライマリーサイトとして運用した場合、翌週は東北に切り替え、東京は災害対策サイトとする。同様にプライマリーサイトを各データセンターに転々と切り替えながら運用していく。通常の運用プロセスの中に災害対策サイトへの切り替え作業が組み込まれているため、いざという時にもスムーズに切り替え作業ができるようにトレーニングをしているわけだ。
もちろん、企業によってITにかけられるコストは異なるだろう。すべての企業が金融系の様に豊富な予算を持っているわけではないし、同様の投資をしなければならないというわけでもない。しかし、自社が選択した手段については、それが有効に機能するような仕組みを確立しておくことが必要だ。災害が発生した時に本当に動かせるか。どのような手順で、どれくらいの時間を要するものなのか。何人いれば足りるのか。夜間であっても対応できるのか？ 具体的な運用のイメージなくしては、せっかく高価なシステムを導入しても、埃をかぶっていざという時に役立たない。
システムを動かすために必要な視点
では、実際に機能する仕組みをどのように構築すれば良いだろうか。筆者がおススメしたいのはITILだ。もはや使い古された言葉として認識されつつあるが、そこで提示されている考え方は依然として有効だ。ITILは、ITシステムを媒介としたサービスを提供する「ITサービスマネジメント」を実践するためのガイドラインとして、システムの企画から設計、構築、検証、運用までシステムに関わる手順を提示している。示されている手順はシステムの全体サイクルの中に位置づけられているため、それらを踏んでいけば一貫した運用が可能になる。
ITILの特徴は、一連の運用プロセスがサービスレベルの達成を目的として敷かれている点にある。例えば、メールサーバーを運用するにあたって、どの程度の機能を提供しなければならないか。万が一、停止した場合には何時間以内に復旧しなければならないか。まず、初めにメールシステムの利用者に対して提供すべき価値を明確に定義する。あくまで、システムの運用者にとっての都合ではなく、利用者のニーズを達成することに重点が置かれていることがポイントだ。
メールシステムの利用者が、障害発生時には3時間で復旧してほしいと言えば、原則として、それに対応することを目標としなければならない。一方で、運用管理の担当者は24時間365日動かし続けること自体を目的とするケースが多いが、業務時間内だけ動いていれば良い場合も少なくない。
要件が固まったら必要な運用サイクルを決めていく。例えば、リストアの許容時間が3時間ならばバックアップ先はテープではなく、時間内にリストアできるディスクにする必要があるといった対応が決まる。導入して一安心。あとは、いざという時を待つというのではサービスの提供者としては不十分だろう。必要な設備を購入した後は、本当に3時間で復旧が可能なのか試してみる必要がある。対応できる人間は必ずその場にいるのか？担当者は一人で大丈夫なのか？いざという時に担当者が自信を持って対応できるような状態を維持するためには、一連の作業を定期的に練習しておかなくてはいけないということが分かるかもしれない。
このように要求定義から導入、運用まで一連のサイクルが達成すべきサービスレベルに向かって一貫して形成されることになる。ITIL自体は欧米の考え方が強く反映されていることもあって、事情が異なる日本では完璧に実践することは難しいかもしれないが、その考え方を取り入れることで現行のシステム運用サイクルを相対化し、見直しを図るための有力な手がかりになることは間違いないだろう。少なくとも、データを保護するためにバックアップ装置を購入したものの、実際に役立つかどうかはわからないという事態を回避するには役立つはずだ。
