システム運用（変更管理） - 社内SEになりました

システム運用の変更管理の説明です。

変更管理の対象は基本的には構成管理の対象と同じですが、構成管理が対象としないものとして「人」の変更があります。PMBOK系のプロジェクト管理で体制の変更が変更管理の対象になるのと似ています。担当者の変更、役割の変更、プロセスや手順の変更などです。人を含めたIT資産の変更をする際、変更管理プロセスが発動します。

変更管理では変更の受付を行い、変更理由、変更方法、リスク、必要なリソース、実施者、他の変更との依存関係などから変更に対しての評価を行い、変更の承認（あるいは却下）を行います。

実際の変更自体は、リリース管理の対象となり、リリース後の評価時に変更管理にフィードバックされます。

f:id:SystemEngineers:20210102202655p:plain

１．変更管理の目的

変更管理の主な目的は、以下になります。

①変更による障害発生時に備えて変更履歴を残す

②リスク判断やレビューをプロセス化することで変更による障害を最小限に抑える

③過去の変更を蓄積することで類似案件の対応を効率化する

変更管理の目的は、変更そのものを管理することではなく、変更によるシステムへの負の影響をコントロールすることです。

そして重要なことは、変更の承認の判断基準を明確にすることです。

２．構成管理の履歴との違い

変更管理では変更の履歴を残しますが、構成管理も変更の履歴を残します。

これは同じものでしょうか？

一つ一つの要素は同じものですが、管理の軸が異なります。

構成管理の履歴は「資産」の変更履歴です。それに対して変更管理の履歴は「案件」の履歴です。

f:id:SystemEngineers:20210103101523p:plain

例えば、年に１回動く機能で障害が発生したとします。該当機能について変更の有無を構成管理の履歴で調べたところ、半年前にプログラム改修が発生していたことが分かりました。構成管理では通常、同タイミングで変更をした他のプログラムも洗い出すことができますが、同タイミングで実施したサーバー構成の変更や手順書の変更といった種類の異なる資産の変更までは把握できないことが多いです。

そこで変更管理です。同タイミングで変更した全ての資産を管理しているので、改修の全体像を把握することができます。

変更管理を調べた結果、該当の案件ではWebAPサーバーをシングル構成から冗長構成に変えています。その際、WebAPサーバーで起動するバッチプログラムを冗長構成に対応できるように改修していたことが分かりました。

今回、障害が発生した機能は、そのWebAPサーバーで起動するバッチプログラムであることが判明したため、一次対応としては、バッチプログラムを戻し、サーバー構成もシングル構成に戻して再処理するという方法が考えられます。

３．変更管理の実態

変更管理は非常に重要ですが、運用部門の役割が小さく、開発部門が保守を担っているような組織の場合、独立した管理にしていない場合が多いです。

f:id:SystemEngineers:20210103104839p:plain