構成管理

読み：こうせいかんり　／　英語表記：Configuration Management

性能・監視・運用

構成管理とは、システムの構成要素や設定とそれらの関係を把握し、導入・変更・運用を通じて構成情報の整合性を保つ管理活動である。ネットワークでは機器や接続の記録に加え、稼働に必要な設定の投入や更新も扱う。

イマシルちゃんの解説

会社のネットワークには、たくさんの機器や設定が組み合わさっているよね。
構成管理は「何がどこにつながり、どんな設定で動いているか」を把握して管理する活動なんだ。
機器の名前だけでなく、ソフトウェアの版や接続先と変更の履歴も記録するよ。
そうするとスイッチを交換するときに、どの部署やサービスへ影響するかを調べやすくなるんだ。
作業が終わったら実際の状態を確かめて、記録も新しい状態に合わせることが大切だよ。
最新の設定ファイルを保存するだけでなく、機器同士のつながりまで分かるようにしておくんだね。

より深い解説

ネットワーク運用の中で担う役割

構成管理が答えるのは「何を使い、どのように組み合わせ、どの状態で動かすか」という問いである。管理対象には装置の型番や設置場所だけでなく、インタフェースの設定、ソフトウェアの版、接続関係などが含まれる。機器を追加してから撤去するまで情報を更新し、運用中のシステムを説明できる状態に保つ。

OSI管理の機能分類は頭文字からFCAPSと呼ばれる。各領域の主な関心は次のように整理できる。

領域	主な関心	ネットワークでの例
Fault：障害管理	異常を発見して正常な状態へ戻す	回線断の検出と原因調査
Configuration：構成管理	機器や設定を把握し運用可能な状態を管理する	接続情報の記録と設定の更新
Accounting：課金管理	資源の利用を計測し利用者へ対応付ける	部門別の利用量の集計
Performance：性能管理	資源や通信の効率を測定して評価する	帯域利用率と応答時間の監視
Security：セキュリティ管理	通信や管理機能の安全性を管理する	管理者の権限とアクセスの制御

ITU-T X.700は構成管理に識別や情報収集だけでなく、動作パラメータの設定や起動・停止なども含めている。この分類は通信プロトコルや製品の種類を表すものではない。同じ監視装置や設定情報が複数の管理領域で使われる。

一方、ITIL 4のサービス構成管理では、サービスとそれを支える対象について信頼できる構成情報を提供することに重点がある。ネットワーク装置の設定操作とサービス全体の情報管理は関係するが、管理の範囲や活動の区切り方は同一ではない。

管理する単位と関係を決める

個別に識別して管理する対象を構成アイテムという。英語ではConfiguration Itemであり、CIと略す。物理的な機器だけでなく、ソフトウェアや設定ファイル、設計書なども対象にできる。どの細かさで分けるかは、変更の影響を判断するために必要な情報と維持できる手間に合わせて決める。

例えば、拠点ルータには管理番号、シリアル番号、設置場所、管理IPアドレス、OSの版、担当者などを記録する。それに加えて「どの回線を収容するか」「どのスイッチへ接続するか」「どの業務がその経路を使うか」という関係を持たせる。この情報があれば、装置の交換が他の設備や業務に与える影響をたどれる。

こうした対象の情報と相互の関係を保存するデータベースをCMDB（Configuration Management Database）という。ServiceNowの製品説明でも、対象の情報とサービスとの関係を管理する用途が示されている。ただし専用製品を導入すれば情報が自動的に正しくなるわけではない。識別子の重複や更新漏れを防ぐルールが必要である。

資産台帳は購入日や費用、所有者なども管理する。構成管理ではこれらの情報も利用するが、故障や変更の影響を説明できる接続・依存関係が特に重要になる。「何台あるか」という一覧だけでは、どの通信が止まるかまでは判断できない。

基準となる状態と実機の状態を照合する

ある時点でレビューされ承認された構成を、将来の構築や変更の基準として定めたものをベースラインという。承認済みの設計や設定値が基準であり、実機から取得した最新の設定が無条件に正しい基準になるわけではない。不正な変更や作業ミスが入った状態をそのまま基準にすると、ずれを発見できなくなる。

照合するときは、基準の設定と実際の設定の差分を調べる。例えば、管理用通信の接続元を限定する設計だったのに実機では制限が外れていた場合、誰が何の目的で変えたのかを変更記録で確認する。必要な変更が承認されていたなら記録の更新漏れを直し、承認されていない変更なら原因を調べて適切な状態へ戻す。

設定や設計書は版管理によって過去の状態も追跡できるようにする。日時だけでなく変更理由、実施者、承認の記録を関連付ければ、障害が起きた時点の状態を再現しやすい。NIST SP 800-128はセキュリティに重点を置く構成管理として、基準の確立と変更の統制、実際の状態の監視を扱っている。

設定を変える前後に何を確認するか

システムへの変更を申請から評価、承認、実施、結果の確認まで統制する活動を変更管理という。構成情報はその判断材料になる。何を変えるかが分かっていても、そこに依存する機器や業務が不明なら適切な作業計画を立てられない。

例えば、拠点ルータの接続先IPアドレスを変えるときは対向装置だけでなく、監視設定やアクセス制御、経路設定も調べる。変更によって影響を受ける対象の広がりを影響範囲として明確にし、利用者への影響と作業時間を見積もる。

作業前には対象の取り違えがないかを確認し、変更前の設定と必要な記録を保存する。検証環境などで手順を確認し、成功を判断する条件と中止する条件を決めておく。問題が起きたときに以前の状態へ戻すことをロールバックといい、その手順も準備する。設定ファイルがあっても管理接続が切れて操作できなければ戻せないため、復帰に使う接続経路も検討する。

作業後は設定値の反映だけでなく実際の通信を確認し、構成図や管理記録を更新する。緊急対応で先に設定を変える場合にも、実施内容と理由を残して後から承認や記録の整備を行う。作業の完了と情報の更新を対応させることで、次の担当者も実機の状態を説明できる。

自動化しても保存先の意味を区別する

機器の台数が増えると手入力だけでは記録が追い付かない。機器から情報を収集して一覧や設定の履歴を更新する仕組みを利用する。SNMPによる管理情報の取得に加え、設定を構造化して取得・変更するプロトコルとしてNETCONFがある。自動化には同じ設定を再現しやすくする利点があるが、誤った設定も広範囲へ反映できるため対象と結果の確認が欠かせない。

設定を保存する場所の意味にも注意する。RFC 6241では現在の稼働設定を表すデータストアをrunningとしている。また別の起動用データストアを持つ機能に対応した装置では、起動時に読み込む設定をstartupとして扱う。その機能では稼働中の設定変更が起動用へ自動的にコピーされるわけではない。

したがって、設定変更直後に通信できても再起動後に同じ状態となるとは限らない。保存の手順は機器や管理方式によって異なるため、その仕様を確認する。また動的に学習した経路や通信量などの運用状態は、投入した設定そのものと区別して記録する。

記録が実態から離れないようにする

運用の途中で実機の設定が管理された基準からずれていくことを構成ドリフトという。手作業の変更や緊急対応の反映漏れが重なると、設計上は同じ装置でも設定が異なっていく。定期的な照合や変更時の自動収集によってずれを早く発見し、意図した変更かどうかを確認する。

自動収集できる範囲にも限界がある。機器の接続先は取得できても、その回線を使う業務の責任者や停止可能な時間帯までは分からないことがある。収集日時と情報の出所を残し、人が補う情報の担当者も決める。また設定ファイルに認証情報などが含まれる場合は、閲覧権限や保存方法を適切に管理する。

拠点のスイッチを交換する場面なら、ポートと接続機器の対応、VLANの割当て、上位装置への接続、管理用の通信経路を一緒に確認する。型番だけが一致しても必要な通信を再現できるとは限らない。交換後の接続と設定を照合し、利用する業務まで動くことを確認して記録を確定させる。このように構成管理は、変更と障害対応の判断に使える情報を保つ活動である。