システムは安定稼働して初めて，ビジネスを支援するという本来の目的を果たせます。だから，カットオーバー後の運用を見据えて設計しておくことは非常に大切です。最近でこそ「ITIL（Information Technology Infrastructure Library）」という運用の標準ガイドラインも登場していますが，設計者や開発者の多くは，残念ながら運用の経験やノウハウを持っていません。その結果，運用設計がおろそかになるケースは少なくないのが実情です。
そこで，Webシステムの運用設計のコンセプトと実践法を取り上げます。
運用とは何か
「運用」という言葉の範囲のとらえ方は人によって差がありますので，ここでは4種類の作業で定義します。4種類の作業とは，システム停止を防ぐ「サービスの維持管理」，日常的な管理業務である「システム・オペレーション」，問題が発見されたソフトウエアを修正する「ソフトウエアの改修」，現行システムに含まれない機能を付け加える「ソフトウエアの追加開発」です（表1）。このうち最も重要なのは，サービスの維持管理と言えます。なぜなら，そのほかの三つはいずれもサービスを維持管理する目的で生じると考えられるからです。
| 表1●運用で必要な作業は4種類に大別できる [画像のクリックで拡大表示] |
 |
運用の全体像をつかむため，以下では運用をフェーズに分けて説明します。
インシデントの発生でフェーズが移る
運用をフェーズに分けると，（1）通常オペレーション，（2）インシデント管理，（3）問題管理，（4）変更管理――の四つになります（図1）。各フェーズで，前述した4種類の作業を実施します。例えばシステム・オペレーションという作業は，（1）～（4）のすべてのフェーズで実施される可能性があります。
 |
| 図1●運用のライフサイクル 安定稼働を阻害する出来事（＝インシデント）を検出し，インシデントに対処して通常オペレーションのフェーズに戻る，というプロセスを繰り返す。同じインシデントが繰り返される場合は，問題管理フェーズに移り，解決策を探る。ハードウエアやソフトウエアの変更が必要な場合は，変更管理フェーズに移り，その内容を記録・管理する。問題が解決すれば，通常オペレーション・フェーズに戻る [画像のクリックで拡大表示] |
（1）通常オペレーションのフェーズは，平常時のシステム・オペレーションのみを実施している状態です。この状態が長く続いているシステムほど安定稼働しています。
システム障害やセキュリティ侵害といった安定稼働を阻害する出来事（＝インシデント）が発生すると，（2）インシデント管理のフェーズに移行します。インシデントの発生は，システムの利用者からの問い合わせで判明するケースや，システムの監視作業で検知するケースがあります。どちらのケースでもインシデントが発生すれば，システム管理者が何らかの対処（例えばサーバーの再起動など）を実施し，それらの記録を残さなければなりません。
同じようなインシデントが繰り返し発生する場合は，根本原因を探って改善する方が効率がよいでしょう。そのための解決策を導き出すフェーズが，（3）問題管理フェーズです。このフェーズでは，システムをどのように変更すれば問題が解決するかを検討します。例えば，ハードウエアのリソースを追加，ソフトウエアをバージョンアップ，各種設定を変更――といった内容になるでしょう。
問題管理フェーズは解決策を導き出すまでで，それをシステムに反映させるのは（4）変更管理フェーズです。変更管理フェーズは，解決策をシステムに適用すべきかどうかの検討から始めます。変更した場合の影響範囲と影響度を分析し，変更の可否を判断します。変更管理はソフトウエア開発で重要とされていますが，運用上も不可欠と言えます。変更が加わる場合は，変更の具体的な内容や理由を記録しておくことが必須です。運用担当のシステム管理者が不在のときや異動・退職したときでも継続的に管理するためです。
変更管理に伴い，「キャパシティ管理」や「構成管理」も実施します。キャパシティ管理とは，ハードウエアなどの物理リソースの量に着目した管理手法で，具体的にはCPUやメモリー，ディスクの使用量などを監視して記録します。
一方の構成管理は，システムの構成要素や設定状況に着目し，ハードウエアやミドルウエアといったインフラ部分と，アプリケーション部分の両面で管理します。システムの設計/開発段階でも構成管理は実施しますが，一般にインフラ部分はシステム構成図があるだけで，アプリケーション部分の構成管理しか実施していません。運用時の構成管理では，インフラ部分まで含めて“変化する要素”として管理します。構成管理のデータは，従来は紙の台帳やExcelシートなどに記録していましたが，最近ではRDBMSなどで「構成管理データベース（CMDB）」を構築することも多くなりました（図2）。
 |
| 図2●構成管理データベース（CMDB）の具体例 提供するシステムがどのようなハードウエアやソフトウエアで成り立っているか管理することを「構成管理」と呼ぶ。従来は紙の台帳に記録することが多かったが，最近では構成管理データベースを構築するケースが増えている [画像のクリックで拡大表示] |
事例で見るインシデントへの対応
具体的な事例で，運用の各フェーズを見ていきましょう。（2）インシデント管理→（3）問題管理→（4）変更管理の流れで示します。
あるWebシステムの利用者から，「パフォーマンスが非常に低下する日がある」というクレームが寄せられました（（2）インシデント管理の開始）。パフォーマンスがたびたび低下したので，システム管理者が原因究明に乗り出しました（（3）問題管理の開始）。その結果，サーバー機のテンポラリ領域（UNIXの/tmp領域）が満杯になっていることが分かりました。業務マニュアル（手順書）には「テンポラリ領域は毎日削除する」となっていたのでその指示通りにしていましたが，アクセス数の増加に伴い，1日1回の削除では追いつかなくなっていたのです。
抜本的な解決策として，（A）テンポラリ領域の空き容量を監視して警告する，（B）削除を1日1回から1日2回に増やす，（C）テンポラリ領域を増量する――などの方法を検討しました。このケースでは，導入していた運用監視ツールがディスク容量の監視機能を備えていなかったので，（A）の方法は見送りました。また，（B）の方法では稼働中に（テンポラリ領域の）ファイルを削除しますので，最悪の場合，障害復旧に必要なファイルを削除してしまう危険がありました。回避するには，必要なファイルを削除しないようなプログラムを開発しなければなりません。そのための工数がかかります。（C）の方法は新たにディスクを増設しなければなりませんが，最近はディスクの価格が安いので，（B）の方法より得策であると判断しました。
システム管理者は，ハードディスクの追加と，テンポラリ領域の拡張という二つの変更要求の実施に伴う影響を調査しました（（4）変更管理の開始）。単にディスクを追加するだけであれば影響は小さいのですが，ディスクの増設に伴って新しいディスク・ドライバが必要になることが分かりました。システム管理者は，新たなディスク・ドライバによって動作不良を起こすシステム・モジュールがないかを検証し，問題が起こらないことを確認して増設に踏み切りました。
|
