そのシステム変更、大丈夫？：ITILを深める！ サービスサポート編（1/2 ページ）

システムにおいて変更が生じないことはまずない。しかし、これが原因で、システムの可用性を下げることも多い。そうならないためには、どうしたらよいだろうか？（攻めのシステム運用管理）

[インフォリスクマネージ，ITmedia]

　ITに限らず、あらゆるシステムにおいて「変更」が生じないことは、まずないといってよいだろう。特にIT環境においては、そのインパクト・重要性・頻度からシステム運用業務の中核をなすプロセスといって過言ではない。例えば、セキュリティパッチの適用や、システムコンフィギュレーションの変更、バッチジョブの組み換え――など、システム運用者には絶対に避けて通れないプロセスである。

　特に、ここ数年は、ウイルスやセキュリティ問題によって、システム変更が頻繁に行われる傾向にある。　また、システム変更に起因する事故や不具合が、システムの可用性を下げる原因になることが多いのも事実である。この傾向は、昨今のシステム構成要素の高度化・複雑化によって、より一層顕著になってきた。

　このような状況下では、安全かつ効率的で速やかにシステム変更を行えるように、あらかじめ標準化した方法と手順によって、的確に変更が実施されることが非常に重要だ。ITILが定める「変更管理」プロセスは、変更によって発生するインシデントがなくなる、もしくは、あったとしても最小限のインパクトに止めることを目標にしたものだ。

変更管理の導入

　一般的な変更管理における大まかなプロセスは、ほかの管理プロセス(主にインシデント管理、問題管理、サービスレベル管理、可用性管理、キャパシティ管理など)からの変更要求(RFC：Request For Change)を受け付け、記録する。そして、インパクトとリソースの評価を実施した上で、変更の承認・変更のレビューを行うという流れになる。

　ここで注意してほしいのが、実際の「変更の実施」と「構成管理情報の変更」は、別のプロセス(主に「リリース管理」および「構成管理」)として区別されており、変更管理プロセスには含まれない点である。管理と実施を明確に区別することで、より確実に変更を実施するできるように考えられているのである。

各プロセス相互関連

　実際に一般的に行われる変更管理プロセスは、以下のような活動(サブプロセス)を実施する必要がある。

• RFC受け入れの記録とフィルタリング
• 優先順位割り当て
• 変更の分類
• インパクトとリソースの評価
• 変更の承認
• 変更スケジュールの設定
• 方法・手順の監査、テスト・実施の調整
• 変更レビュー(導入後レビュー)

変更管理プロセス