サービス構成管理を考える
最近、サービス構成管理について質問を受けることが多いので、少し考えをまとめてみようと思います。
構成管理の対象を明確に！
まず、構成管理の話を始めると、「OS含む、ソフトウェアのバージョン管理だよね」という内容と、「HWとかIT資産管理の話だよね」という内容が混在して、「はて、私たちは今、何の話をしてるんだっけ？」となることが多いです。
以下にITILで構成管理の対象になるものと、関連するプロセスをまとめてみました。
けっこうゴチャゴチャしてしまったので、ひとつずつ解説してみます。
構成管理の目的
まずは構成管理の目的を整理しておきましょう。
インシデント管理系
ハードウェアやソフトウェアの構成情報を最新化しておくと、障害などのインシデント発生時に、どのシステムのどの部分でトラブルが発生したのかわかりやすくなります。
また、インシデントの恒久対策としてソフトウェアのバージョンアップを行う場合に、他のシステムで同じバージョンを使っている構成要素がないかの確認を横ぐしで行えるため、インシデントの予防にもなります。
また、最新のソフトウェアバージョン情報がわかれば、パッチ適用などの脆弱性対応にも利用できます。
こちらもセキュリティインシデントを未然に防ぐ活動になります。
変更管理系
システムの関連図などの構成情報がそろっていれば、システムに対する変更を行う場合に実施影響をかなり正確に予想できることになります。
逆に関連システムの構成要素が把握できていない状態で変更を行うことは、ギャンブルの要素が強くなります。
もしあなたが幸運の星の下に生まれているのであれば、いっちょ賭けてみるのもアリだと思いますが、賭けに負けてサービス停止などの大規模インシデントが発生したら目も当てられません。
変更管理の変更審査を行うために、構成情報は必須になると言えるでしょう。
サービス財務管理系（お金の話）
ここまでは、主にハードウェアやソフトウェアの話をしてきましたが、「サービス構成管理」と言っているぐらいなので、サービスを構成する要素、つまりデータセンタなどの建屋、オフィス、運用要員、アプリ保守要員、ハードウェア保守契約、SaaSなどクラウドサービスのライセンス、従量課金、アウトソース先との契約など、サービスに必要なモノすべてが対象といえば、対象です。
ここまでをしっかり管理すると、各サービスにどれぐらいのランニングコストがかかっているのかを構成管理から導き出すことができます。
これらのランニングコストの情報は、サービスポートフォリオ管理の基礎情報にもなります。
ドキュメント管理系
ここまで話してきた要素は、何かのドキュメントに記載されている情報がほとんどです。
ハードウェア ⇒ 発注書や領収書、基本設計書、システム構成図・一覧、ラック図 など
ソフトウェア ⇒ パラメータシートや契約書、基本設計書、システム構成図・一覧 など
建物 ⇒ 契約書、建屋図面 など
人（自社社員） ⇒ 人事情報、運用体制図、連絡先一覧 など
クラウドサービスなど ⇒ 契約書、月次レポート など
アウトソース ⇒ 契約書、付帯資料一式、月次レポート など
すべての情報を一元管理するのは、現実的ではありません。
大切なのは、どのような情報の分散管理を許容して、どのような情報を構成管理データベースとして一元管理するかを決めることです。
そのためには、まずは構成管理で何がしたいのかという目的をはっきりさせる必要があります。
現実的な構成管理
目的が何となくわかってきたところで、現実的な構成管理を考えてみます。
ハードウェア管理
ハードウェア管理は、サーバー/クライアントの特性を理解しておく必要があります。
サーバー側はサーバー、ストレージ、スイッチなど、少数で高額なモノが多い傾向があります。（無線アクセスポイントなどは判断が難しいところですが。。。）
AWSやAzureなどのパブリッククラウドをシステム基盤にしている場合、サーバー側のハードウェアをほぼ無くすことができます。
サーバー数が少ない場合は、サーバー側のハードウェア管理をExcel台帳で行うことも無理ではないでしょう。
大量にサーバーがある場合は、ソフトウェア管理も含めて管理ツールの導入を検討します。
クライアント側は、PC、iPhoneなどのモバイルデバイス、モバイルルータ、マウスなど、少額で多数多品目になることが多いです。
クライアントの管理数は社員数に比例するので、中小企業の場合はExcel管理も無理ではないです。
ただ、大企業の場合は何かしらのIT資産管理ツールを入れて管理するのが一般的でしょう。
ソフトウェア管理
ソフトウェア管理は、サーバー/クライアント問わず、ソフトウェアのバージョン管理ツールを入れて管理した方が良いでしょう。
セキュリティの観点でも、どこにパッチが適用されていて、どこが未適用なのかを把握することは重要です。
バージョン情報が収集できるクラウド脆弱性管理ツールも出てきているので、まったく管理できていない場合はツールを利用してスモールスタートするのもよいでしょう。
ドキュメント管理
構成管理におけるドキュメント管理で重要なことは、ツールで収集されている情報については、ツール情報を正としてドキュメントの更新を止めることです。
その際、ドキュメントには「○○ツールで情報を収集しているので、YYYY/MM/DD以降は本項を更新しない」といった情報を残しておきます。
ツール導入の効果を最大化し、二重管理による情報の読み間違いを防ぐという目的があります。
逆に、ドキュメントに最新情報を残している個所は、システム変更後にしっかりとドキュメントを更新する仕組みを変更・リリース管理フローに組み込みましょう。
人的リソース
誰がいつ何をやって、どれぐらいの工数がかかっているかについては、運用項目一覧などで管理が可能です。
人間がシステムに対して、定期的に行っている作業も広義では構成管理といえなくもない気がします。（ほぼ違う気もしますが。。。）
なににせよ、しっかり運用設計しようと思ったら運用項目一覧を作成しなければならないので、各システムで運用項目一覧＝手作業の一覧を可視化しておくと良いでしょう。
ということで、書き始めたらけっこうな大作になってしまいました。
もし皆さんが、サービス構成管理を検討しなければいけないという時には参考にしていただければ幸いです。
システムの運用設計に関する書籍を出しています。
ご興味ある方はぜひ！