ソフト・ハードのリリースに失敗しないためにITILを深める! サービスサポート編(1/2 ページ)

ITインフラの運用のトラブルの原因は変更や新規導入によるものがほとんどだ。ITILの変更管理プロセスと同様、リリース管理は非常に重要になってくる(攻めのシステム運用管理)。

» 2005年09月22日 11時01分 公開
[インフォリスクマネージ,ITmedia]

 ITインフラを運用していくにあたってトラブルの原因となるのが、ソフトウェア・ハードウェアの新規導入や変更によるものがほとんどである。前回説明した「変更管理」がシステム変更の全体を管理するものに対し、リリース管理は実際にソフトウェアやハードウェアの配置・変更を調整・実施するプロセスである。よって、変更管理プロセスと密接に連携する必要がある。

 近年、ビジネスのスピード化・効率化が目覚しい勢いで進んでおり、ITのライフサイクルもどんどん短くなってきている。ソフトウェアのバージョンアップやハードウェアの増強が当たり前のように日々実施されているのである。そんな中、ビジネスサイドの要求により、スピード・効率優先で十分な考慮がされないまま、変更が実施され障害を引き起こすケースが多く見られる。

 これにより、サービスの信頼性・品質が低下し、ついては顧客満足度の低下を招く恐れがでてくる。このようなリスクを低下させるためには、リリースの成功率を高める必要がある。そのために「リリース管理」プロセスが必要となるのだ。リリース管理の目的は、正式な手順に基づいて正確にリリースを行い、サービスの環境・品質を保全することにある。

リリース管理を導入するポイント

 リリース管理の目的は、前出の通りサービスの環境・品質保全である。そのためには、まずITサービスの変更をきちんと把握することが大前提となり、「変更管理」および「構成管理」と密接に連携するのが望ましい。つまり、ITサービスの構成アイテム(CI)が正確に管理されていて、変更要求に対する管理(評価・計画・承認)が厳密に行われていなければならない。これらがなされないまま、リリース計画を策定しても、その効果はほとんど得られないだろう。

図1 プロセス相関図

 これらができているのであれば、次に実施したいのが、リリース・ポリシーの策定である。これには、例として以下のような事項が記載される。

  • 識別番号および名称の定義
  • リリースの規模(タイプ)と頻度
  • 各サブプロセスにおけるインプット(申請書など)とアウトプット(成果物)
  • リリースされるソフトウェア・ハードウェアの受入基準
  • リリース管理の役割と責任範囲

 実際には、上記のほかにも、アプリケーションであれ、その名称ルールであるとか、バージョン番号の定義などが記載されたりする。このリリースを実施する場合、このリリース・ポリシーに基づいてリリースが行われていることを確認する。

 次に、実際のリリース管理に必要なサブプロセスの例を以下に記述していく。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ