ある日、A社でシステム管理を担当しているM君が出社すると、社内は騒然としていた。強い感染力で知られるワームが社内に侵入し、朝から蔓延していたのだ。原因は数週間前に見つかったOSのセキュリティホールである。すぐにパッチがリリースされ、M君も職場のみんなにパッチを当てるよう依頼していたのだが、結局徹底されていなかったようだ。パッチを当てなかった人に理由を聞いたところ「パッチを当てて、アプリが動かなくなったことがあるからだ!」と逆に怒られた。一体どうすればよかったのか……
最近、ITシステムのセキュリティはどこの企業でも大きな関心事になっており、特にウイルスやワームが与える被害は甚大です。「蟻の一穴」の故事にもある通り、1台でも未対処のマシンがあると、そこを足がかりにウイルスやワームが社内に被害を広げる危険があります。もちろん、対策としてすべてのマシンに洩れなくパッチを適用することが重要ですが、エンドユーザー任せではそれも難しいでしょう。今回はこうしたパッチなどを確実に適用するためのプロセスである「リリース管理」について見ていきましょう。
ITILのリリース管理では、パッチ適用やバージョンアップ等の変更は、エンドユーザーでなく、すべて情報システム部などのリリース管理プロセス下で行なわれます。リリース管理はいつ、どんな変更を、どのCI（構成アイテム。詳細は『第4回 構成管理』を参照）に行なうかを決定します。この適用の集合を「リリース」と呼び、適用の形態によりいくつかの種類に分けることができます。
OSがWindows 2000からWindows XPに変更され、アプリケーションにも変更が生じるといった例を見てみます。この際、変更になるドライバ等のファイルだけを配布するものを「デルタリリース（変更／追加になるコンポーネントのみ配布する）」、ドライバも含め、ワープロソフトやプレゼンテーションソフト全体を配布するものを「フルリリース（変更しないものも含め、全てのコンポーネントを展開する）」、そしてワープロやプレゼンテーションソフトだけでなく、Webブラウザ等、デスクトップ環境を丸ごと配布するものを「パッケージリリース（関連するいくつかのフルリリースまたはデルタリリースをまとめて展開する）」と呼ばれています。まず、リリースの際には、変更されるファイルの数や、相互の依存関係等を考慮して、上記3種類のどのリリース形態にするかを検討する必要があります。
また、リリースの際には、まずどのようなリリースを行なうかという「リリースポリシー」を決めておきましょう。このリリースポリシーでは、上記のリリース種別やリリースに含まれる内容、展開される範囲等を定義します。たとえば、以下のような項目が必要です。
A社の事例では、まずリリースポリシーが定められておらず、いつ、どのようなパッチを当てるのかはエンドユーザー任せになっています。そのため、早急にリリース管理のプロセスを確立する必要があります。セキュリティホールが見つかり、パッチが発行された時点でシステム管理担当者のMさんはRFC（変更要求）を発行し、パッチの影響を評価するとともに、リリースポリシーの検討をスタートするという体制が必要です。
 |  |
|---|
 |
||||
 |
 |
 |
|
 |
 |
||||
「ITILでシステムの効率化を目指そう」トップへ
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】