変更・構成・リリース管理

変更管理は AP のサービスマネジメント分野で頻出。CMDB と CAB (変更諮問委員会) の役割を押さえます。

鳴海 理央

変更管理?
は変更によるリスクを評価・承認・実装・レビューするプロセス。
構成管理?
は CI (構成項目) を識別・管理し、CMDB?
に保存します。
リリース管理?
は変更を本番環境に展開するプロセス。

砂原 ニコ

ねぇ、CABって何?

緒方 ナオミ 先生

Change Advisory Board。
変更を評価・助言する委員会よ。
重要変更は CAB の承認が必要、緊急変更は ECAB (Emergency CAB) で迅速対応、というふうに使い分けるの。

藤咲 まりあ

標準変更って何ですかぁ?

鳴海 理央

補足すると、事前承認済みの定型変更 (例: ユーザ ID 発行・パッチ適用) で、CAB の都度承認は不要なんです。
リスクが低く繰り返し行うものを高速処理するための区分ですね。

緒方 ナオミ 先生

AP では『変更の3区分 (標準・通常・緊急)』『CMDB の役割』が頻出よ。

通常変更を申請から事後評価まで追う

販売システムのデータベースを更新する例では、まず変更要求に目的、対象CI、希望日時、リスク、テスト結果、実施手順、ロールバック条件を記録します。次にCMDBで、対象DBに接続するAPI、監視、バックアップ、業務サービスとの関係をたどって影響を分析します。権限を持つ変更権限者やCABが承認した後、検証環境で確認済みのリリースを本番へ展開し、監視結果と利用者影響を確認します。最後に成功・失敗、想定外事象、構成情報を記録して変更を閉じます。

緊急変更でも承認と記録を省略するわけではありません。通常の会議を待てないためECABなどで判断経路を短縮し、復旧後に事後評価を行います。反対に標準変更は、手順、低リスク性、承認条件があらかじめ定義された繰返し作業です。「急いでいるから標準変更」ではなく、事前承認済みかどうかで区別します。

変更・構成・リリースの成果物を区別する

典型誤答は、CMDBを単なる資産台帳やソースコード保管庫とみなすことです。CMDBの価値はCI同士とサービスとの関係を持ち、影響分析に使える点にあります。また、CABがすべての変更を承認すると考えるのも誤りです。変更の種類とリスクに応じて権限を委譲し、CABは重要な通常変更などを評価します。