そのシステム変更、大丈夫?:ITILを深める! サービスサポート編(2/2 ページ)
システムにおいて変更が生じないことはまずない。しかし、これが原因で、システムの可用性を下げることも多い。そうならないためには、どうしたらよいだろうか?(攻めのシステム運用管理)
まだ、変更管理手法・体制を確立できていないという場合は、第一段階として「変更管理マネジャー(責任者)」を選任することが重要である。変更管理を誰が責任をもって担当するのか明確にすることで、変更管理プロセスをスムーズに遂行する体制を整えるためだ。実際に体制を整える際には、責任者のほかに、技術的な担当者も選任することをお勧めする。これにより、主に変更手順・テスト計画の監査においてスムーズな変更管理が可能となる。変更管理マネジャーは、まず、RFCの受け入れ・拒絶の判断、変更の承認などに対し責任を持つことになる。
変更管理マネジャーとともにもう1つ体制面で設置が必要となるのが、変更諮問委員会(CAB:Change Advisory Board)である。これは、重要な変更(複合的、または、多大なインパクトがある変更)に対して決定権を持つメンバーから構成される。その際には、IT部門・ビジネス部門それぞれの代表者が選任されるべきである。変更管理マネジャーにより、重要な変更と判断された場合、このCABにより変更時のインパクトや問題、変更による追加リソース割り当てなどを審議する。ただし、CABはこれらの審議結果に責任を負わない。変更に対する責任はあくまで変更管理マネジャーとなる。また、CABの一部として緊急変更の際に召集される緊急委員会(CAB/ED:Change Advisory Board Emergency Committee)も併せて設置しておく必要がある。
第二段階としては変更の分類を定義する必要がある。これは、変更に対する影響の重要度に基づき分類される。分類するにあたり、主に以下の要素が考慮される必要がある。
- 変更時にサービス停止の有無
- サービスの影響範囲(全ユーザーか、一部対象ユーザーか)
- 緊急度
- 追加リソースの有無
- 過去の変更実績(標準手順化の有無)
このほかにも部門や業務の必要に応じて、分類要素を設定し、変更の分類を定義する必要もある。変更管理マネジャーは、この変更の分類に基づいて、受け付けたRFCに対して変更手続き方法を決めるわけだ。例えば、サービス停止が発生しせず、影響度合いの低い標準手順化された日常的な変更については、変更管理マネジャーの承認のみで変更実施を行うのが一般的だ。反対に、インパクトの大きい深刻な変更の場合は、前述のCABによる審議が必要になり、さらに重大な変更と判断された場合は、経営会議で審議される。
第三段階としては、変更管理プロセスの各サブプロセスにおける成果物(文書)や基準を定める必要がある。以下は一例である。
サブプロセス | 変更要求者提出文書 | 記録文書 |
---|---|---|
RFC受付 | 変更要求書 | RFC管理表 |
優先順位割り当て | ― | RFC管理表 |
変更の分類 | ― | RFC管理表 |
インパクトとリソースの評価 | 変更計画書 | RFC管理表、CAB(CAB/EC)議事録、変更計画評価表 |
変更の承認 | ― | RFC管理表、変更計画評価表 |
変更スケジュールの設定 | 変更計画書、スケジュール | RFC管理表 |
方法・手順の監査、テスト・実施の調整 | 本番移行計画書、変更手順書、テスト計画書 | RFC管理表、本番移行計画評価表、変更手順評価、テスト計画評価表 |
変更レビュー | 変更結果報告書 | RFC管理表、変更管理報告書 |
このようにサブプロセスにおける基準や文書を明確化しておくことにより、変更管理プロセス全体の円滑な遂行が可能となる。
最後に、実施が承認または提案された変更の詳細なスケジュールを把握する必要がある。このスケジュールは、「将来的な変更スケジュール」(FSC:Forward Schedule of Change)と呼ばれる。これは、計画上のサービスの可用性(PSA:Projected Service Availability)を作成する上で必要となるものだ。また、PSAは、合意されたSLAとサービスの可用性に対する、現在計画されているFSCに基づく文書になるのである。
関連記事
- 「○○さんに聞かなければ……」からの脱却
ITインフラを統合的に維持・管理し、ユーザーにサービスを提供するには「構成管理」が欠かせない。「○○さんに聞かなければ……」というのはダメな運用管理だ。 - 問題の原因を突き止めろ!
原因の判明しないイベントをどう処理するか。根本原因の究明と恒久的な予防は非常に重要だが、問題管理はできているだろうか? - 「忙しい」の定量化で、終電仕事を解消
サービス品質を妨げるイベントを迅速に回復するには、インシデント管理の考え方が欠かせない。終電まで対応していた仕事が19時に終わったという事例もある。 - 運用業務の効率化に効く
情報システムのために働いてはいないだろうか。ITILの「青本」に書かれているサービスサポートの概念を基に、より高い目標を持ったITサービスを実現していこう。 - 上手なキャパシティ管理
- 運用部門だけが孤軍奮闘しても……
- 知らないと恥ずかしい、ITIL超基礎
- 抜け穴を探すエンドユーザーたち
- 特集:攻めのシステム運用管理
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.