ITIL活用〜構成管理プロセス設計その2〜

構成管理の管理対象を決めたら次に実施すべきは構成識別です。

構成識別とは、一言で言うのであれば管理粒度決めです。

なぜ粒度を決めるのかというと、アプリケーションモジュールを管理対象としたとしても、その一つ一つを管理すると数万モジュールになってしまう場合などあり、一つ一つを管理する事は現実的ではないケースがあります。

その為、どの粒度で管理するかが運用面や得られる成果において重要になります。

一例ですが、アプリケーションモジュールの管理においては、リリースパッケージ化された単位で管理する事が多いと思います。

ちなみパッケージ化という言葉を使いましたが、リリースする際に一つの障害対応や機能追加するモジュールごとにリリースせず、複数まとめてリリースすると思います。そのまとめたものリリースパッケージといいます。

構成管理の粒度を決める上では、構成情報をどう使うかによって要件が変わってきます。

リリースパッケージ単位の管理の例だと、何かトラブルがあった場合、ユーザーの環境がどのリリースパッケージのバージョンなのか特定できれば、障害点の切り分けはしやすくなります。

構成識別は顧客に検討を依頼すると大体どの粒度まで管理すべきか教えて欲しいと言われます。妥当性や確からしい粒度が分からないと。

構成識別は確からしさを求めるとドツボにハマるケースがあります。構成識別に限らずプロセス設計全般に言えますが、一般的な確からしさを求めるのではなく、まず自分達が実現したい成果が最低限出せるレベルで設計する事が重要です。

後日、構成管理のその他の活動や評価指標について話していければと思います。