SE関のノーツ/ドミノ徒然草: 第14回 分散でも集中、集中でも分散の運用管理

『PCサーバーを各部門に配置するので運用は部門にサーバー管理者を置く分散管理にしなければならない』。『UNIXサーバーを本社に集中設置するので運用は情報システム部の集中管理ができる』。とかくノーツの運用管理に関してもこのような単純な議論をよく聞きます。しかしノーツの運用はこれほど単純ではありません。ノーツの場合、部門に管理を任せたとしてもかなりの運用管理の仕事が中央にも残りますし、また逆に集中管理しても部門に近いところに運用管理の役割は残るのが普通です。今回はこのノーツサーバーの運用管理について、特に分散と集中の問題について考えてみましょう。

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社



2006年 4月 17日

まずノーツの運用管理と言ったときにどんな仕事があるでしょう。まず運用管理と言えば、主にサーバーのハードウェアやソフトウェアがきちんと稼動しているか、そしてバックアップをとったり、何か障害が起こったら対応したりする、いわゆるシステム管理とも言えるものがすぐ頭に浮かぶでしょう。このシステム管理はサーバーの置いてある場所で行なうのがやりやすいでしょうから、分散してサーバーを配置すれば分散管理、逆に一ヶ所に集中してサーバーを配置すれば集中管理となるでしょう。ただ最近はリモートでサーバーを操作できるような運用管理ツールがでてきて、サーバーを分散していてもかなりの部分を集中して管理することができるようにもなってきました。ノーツに限らず、そのようなツールを使ってのシステム管理は分散サーバーでも集中化に向かっていると言えるでしょう。

システムの運用管理に関しては、このようなシステム管理の他にノーツは独自の世界を持っています。というのは、ノーツが会社全体などの大きな単位でドメインを構成していることからきています。つまりドメインとしての情報が詰まっている公開アドレス帳に関する運用管理です。公開アドレス帳と言えば、サーバーやサーバー間の接続に関するシステム的な情報はもちろんのこと、ユーザーそれぞれの定義、ユーザーを束ねたグループの定義などユーザーが利用する情報も持っています。システム的な情報は通常のシステム管理のようなものですから集中して管理することが自然かもしれません。一方ユーザーに関する情報では、ユーザーの登録や削除などはセキュリティーを厳密にするにはやはり中央で集中して管理するのが望ましいでしょう。ではグループはというと、よく人事データベースから組織情報を取り出して、自動的にグループを作成する仕組みを作って集中化している例などもあります。ただ、ことグループに関して言えば、昨今の組織の柔軟化、人事権の分権化、はたまた組織はこうだけど実際にはこんなプロジェクト的な組織で仕事をしているなど、たいへんダイナミックな動きをしています。これらを完全に集中化するには一部無理があり、やはり現場で人がきたら登録して、いなくなったら削除などという分散で運用している例もかなりあり、その方が合理的な場合も多々あります。

さて運用管理というとシステム管理がほとんどと一般には思われがちですが、アプリケーションの管理も当然あります。ノーツで言えばデータベースがそれぞれのアプリケーションということになるわけです。データベースの作成や削除、そしてノーツで独特な複製の作成、さらにデータベース設計のバージョン管理などがあるでしょう。ノーツのデータベースは普通のクライアント/サーバーシステムのアプリケーションと違い、エンドユーザーがどんどん作成して恐ろしいくらいに数が増えます。メールを除いてもユーザー数よりデータベースが多いというような状況もよくあることです。しかもユーザーが作りたいと思えばテンプレートを使ってすぐにできてしまいます。このようなアプリケーションの管理は中央で集中化してそれを行なうこともできるでしょうが、ユーザーに近いところでニーズに応じて対処できる分散管理も捨て難く、その方がユーザー満足度も高いかもしれません。

次にグループウェアのノーツの運用管理としてユニークなのがコンテンツ管理とも言えるものでしょう。これはデータベースの入れ物や設計ではなく、その中身の管理です。データベースには今までのアプリケーションと違って多くのユーザーがその中身を作る権限を持っています。そのためあっという間にコンテンツは増え、古いコンテンツを消すなどの初歩的なものから、コンテンツがデータベースの目的と合致して適正かどうか、または適正でない場合の処置、さらには中身の充実のための活動など、よくパソコン通信で言われている電子会議のシスオペの仕事のようなものが必要になってきます。これがコンテンツ管理です。これらもノーツを適切に会社で利用するために必要な運用管理でしょう。このようにデータベースごとに異なり、しかも業務などに深くかかわる中身であるコンテンツに関する運用管理は、システム部門が集中してやるには無理があるでしょう。むしろ中身に精通した担当者、それはほとんどユーザーのような人が分散的にやるのが自然と言えるでしょう。

このように運用管理の仕事を見てくると、もはやノーツでは単純に集中管理か分散管理かという問題でないことは明らかでしょう。どんなに集中しようとしても分散の部分は残り、反対にどんなに分散しても集中の部分は残るというのがどうも正解のような気がします。どうしてこんなことになるかというと、ノーツがおそらくシステムとしては初めて全社員に近いくらいのユーザーから利用されるシステムで、かつユーザーが主導でどんどんアプリケーションを作ったりするシステムだからでしょう。つまり全社員に近いユーザーの動き、つまり会社の動き自体がノーツに投影されている訳です。なるほど会社の中の普通の仕事を眺めてみれば、ある事柄は中央集権的に決めたり動いたりしていることもありながら、同時に効率が悪いからとある事柄は組織別に分権化して決めたり動いたりしているものもあります。それがそのまま投影しているのがノーツのシステムですから、当然、すべて集中またはすべて分権などとは言えないでしょう。

ではノーツの運用管理はどうしていったらいいのでしょう。これは会社の動きでも集中が多い会社と分散が多い会社があるように、会社によって違うように思えます。運用管理の仕事をきちんと定義してそれを分類し、そしてそれぞれを効率や実施できるスキル、そして環境などの観点から集中か分散か決めていく、そんな形が一つのやり方であるように思えます。一般に言えることはシステム的な部分はその技術的な専門性から集中化できればした方が効率がよく、一方アプリケーション的な部分、特に内容に関わることは、その量と内容の組織別の専門性から分散したほうがよいということぐらいかもしれません。

考えてみればノーツではなんでもできるスーパーな管理者は簡単には定義できません。またサーバーに関する管理者、公開アドレス帳に関する管理者、公開アドレス帳の特定の種類の文書に関する管理者、データベースごとの管理者、はたまた単一の文書の管理者など、あらゆる管理対象が分権化できるように工夫されています。いろいろなセキュリティー権限が分散して別々に定義できるノーツ。ノーツが初期のころからそうだったということはノーツの設計者は、もともと会社での運用管理というものはそんなものだと分かっていたように思えてきます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339082
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第14回 分散でも集中、集中でも分散の運用管理
publish-date=04172006